Speaking only for myself, I'm very excited for the Steam Machine. A console I can plug into my TV and it just works and gives me access to all* of the Steam library is an amazing proposition. A Windows 11 box doesn't do that**.
* Almost. Anti-cheat remains a big hole.
** No, I'm not going to use a keyboard or do Windows admin crap from my couch.
> A piece of software, open source, written in Rust is equivalent to proprietary software from my perspective.
Unlike a project's license, this situation is entirely in your control. Rust is just a programming language like any other. It's pretty trivial to pick up any programming language well enough to be productive in a couple hours. If you need to hack on a project, you go learn whatever environment it uses, accomplish what you need to do, and move on. I've done this with Python, Bash, CMake, C++, JavaScript, CSS, ASM, Perl, weird domain-specific languages, the list goes on. It's fine to like some languages more than others (I'd be thrilled if C++ vanished from the universe), but please drop the drama queen stuff. You look really silly.
It's pretty disappointing when people like him try to block new technology just because they don't want to learn any more... but there's absolutely no way anyone is going to be productive in Rust in "a couple of hours".
Just be clear, it is not a case of I don’t want to learn anymore. That’s actually pretty far from the case. As an example and sticking to programming languages, I am currently putting Koka and Eff through their paces and learning a decent amount about the incorporation of algebraic effects into languages at scale, I’m also working my way through Idris 2’s adoption of Quantitative Type Theory. I genuinely enjoy learning, and particularly enjoy learning in the comp sci field.
But, that doesn’t have any bearing on my lack of desire to learn Rust. Several other comments basically demand I justify that dislike, and I may reply, but there is nothing wrong with not liking a language for personal or professional use. I have not taken any action to block Rust’s adoption in projects I use nor do I think I would succeed if I did try. I have occasionally bemoaned the inclusion of Rust in projects I use on forums, but even that isn’t taken well (my original comment as an example).
There's nothing wrong with disliking something. It's more that your dislike alone is not going to convince anyone else. Supporting arguments might either result in one or more of 1) people agreeing with you, or 2) you learning something that helps address your concern, or 3) Rust being improved to address your concern.
Of the three options you presented as being potential results of putting forward arguments supporting my dislike of Rust, the third is interesting. I am quite sure that a vast majority of actual Rust programmers would consider addressing my concerns to be an active degradation of the language. Somewhat related is that I'm not particularly concerned with people (particularly Rust users) agreeing with me, nor do I think that would be a plausible result. So, that leaves the potential for being shown information that would "address [my] concern" as a potential result. So...
I have relatively strong opinions about quite a few areas that Rust, as a language and accompanying programming & tooling philosophy touch on, so I'll just do a few as examples:
1) I am strongly adverse to package managers (I didn't pick this example to get a rise out of you in particular) and their usage by programming languages. I am hostile toward the trend toward more and more dependencies in a given executable, which is only made worse by the industry adoption of languages that support and promote the "find a crate/get from NPM" attitude toward incorporation of dependencies. I don't know if there is evidence of a exponential explosion of transitive dependency in languages relying and building on a package manager ecosystem, but I wouldn't be surprised if it worked toward that point. I know that one does not have to use Cargo and the crate ecosystem, but it is a huge point of pride for the community and is THE idiomatic way to handle dependencies in Rust.
2) I have strong philosophical disagreements with ad-hoc polymorphism in general and with Rust's choice of pervasive reliance on its trait system all through the standard library and all examples of idiomatic code. At this point in development I don't even think there is a means to remove the ad-hoc polymorphism from Rust's implementation as a language. This point in particular I can not see any active Rust user being seen as an improvement of the language. Further, and although Rust does not have a definition of the language or a formalization of the type theory used by the language, I can not see a world where Rust adopts Haskell's position on the typeclass system being a convenient syntax sugar for a non-primitive and more explicit semantic form.
3) I am both practically and philosophically opposed to the usage/presence of 'ownership semantics' as a core part of the semantics of a programming language. Note, that I don't oppose the encoding of the commonly used meaning of 'ownership' at the type level via expressive types, as it can be an accurate description of the relationship between various data in a program. I do object to 'ownership' being the foundational semantic understanding of all programs and data used therein. There is a chance that Rust could incorporate a sophisticated type theory in a future release that relegates the current imposition of universal ownership semantics into a constrained area and allows for alternative semantics to be used in appropriate places, but I think it is nearly impossible to do and maintain validity for any prior programs.
So, do any of those three example look particularly appealing? I know you, only by reputation and seeing previous comments on HN, and know you are fairly involved in the development of Rust from several directions. Can you see Rust becoming a language with very limited ad-hoc polymorphism, a strong break away from the ownership semantics used today, and a language that does not place a package manager in a place of importance for idiomatic development?
Of those three examples the only one I can see anything being said that would alleviate my dislike is to just not use Cargo and build everything from scratch or find and download tarballs, which I would probably do and not complain if I had to use Rust. Thanks for your response being not particularly aggressive, I appreciate any time you gave to read this wall of text.
This has nothing to do with Rust the language, other than the incidental fact that cargo happens to be bundled with Rust. There are no cargo-specific concepts whatsoever in the Rust language, just like there are no Cmake-specific concepts in C++. I know you alluded to this in your post; I just want to make sure it's crystal clear to everyone reading.
Consequently, people can, and do, use Rust without Cargo. That is obviously not what the majority does, because cargo is so easy to use with rust, but it is certainly possible both in theory and in practice.
If it's a "point of pride in the community" and "idiomatic" -- who cares? Rust is a general-purpose systems programming language. You can use it however you want, without listening to what people on Twitter think about it.
This particular complaint strikes me as social/cultural rather than technical -- "people who like Rust do something I find annoying, therefore I must conclude that they're not of my tribe, and reject rust". That is very understandable human nature, but not logically justified.
As for your other two complaints, you are correct that they are fundamental to the language and will never change for at least as long as the language is called "rust".
But since these complaints are totally subjective (a reasonable person might like or dislike them), it doesn't really seem fair to bitch about a language existing and becoming popular that has these properties.
For example, I complain about Go because I think it has actual defects that make it harder to use for almost any competent programmer. I also don't like Python, but I think the tradeoffs it chose to make are at least intelligible and some people prefer the Python style, so it would make no sense for me to complain that other people use it in their projects.
My reason for citing the package manager (and its popularity) as a reason I dislike Rust is because the language org that oversees the language oversees Cargo and its ecosystem. It’s not a tribal thing, it’s a “I feel like this choice enable the active pursuit of a societally/industry detrimental practice”. But I did and do concede that the package manager is not likely to be a part of an eventual formal definition of Rust.
Regarding that it might not be fair to ‘bitch’ about a language ‘existing and becoming popular’ over subjective disagreements: as I’ve said in other comments, and other places, I do not have any issue with developers using or enjoying Rust in their work, I’m all for people making software that is more economical in its usage of hardware and associated/entailed resources. I just don’t want Rust to be imported into existing codebases in other languages (and certainly not into software where it adds a non-copyleft dependency to a GPL’d core).
How is it any harder than using C? Sure, the C standard library gives you random numbers, but it doesn't, for example, give you any containers (hash maps, vectors etc.) which are needed even more often.
> Generate a random number.
Well, obviously, I would use cargo and pull in the `rand` package, because I'm not an anti-dependencies ideologue. Cargo makes it easier to depend on third-party code; that's the whole point. But the OP explicitly doesn't want that, so presumably he'd write his own RNG from scratch, or download a tarball of the `rand` package and build it manually without cargo. None of this is any harder in Rust than it would be in C or C++.
Working on adding that to the standard library, along with a handful of other "you should be able to do this without a dependency" things. We're being very cautious to not fall into the trap of "the standard library is where code goes to die", which is the problem some languages' standard libraries have had. But there are more things we should add, nonetheless.
From the outside looking in, it seems that despite trends in language development to the contrary, Rust has taken an extremely conservative stance on the inclusions into and the evolution of its standard library. I applaud the decision and the will of the core teams for sticking to their guns in this area. I had assumed that the reasons you give above were the motivating factors for being vigilant about the slower cadence of development and smaller ‘size’ of additions/alterations/removals to the standard library . But having it confirmed makes it very comfortable for me to think it is a nearly unqualified positive stance for the language to take.
I have seen your talk about the long future of Rust and I think there is the implication that you and the other Rust language developers are looking toward a 25-30 year timeframe (which encompasses nearly every language in wide spread use today) as the minimum expected lifespan of the language, with a view to be responsive and flexible enough to see the language continue to adapt and evolve throughout a longer period as well. With that type of longevity as an active consideration in planning the language’s growth/evolution I think Rust is setting a good precedent for non-BDFL style governance and stewardship of programming languages. I would hope a more long term compatible view takes hold in programming language development particularly, but general software development could probably stand to benefit if the time horizon was lengthened well beyond what seems to be standard today.
Thank you very much; all of that is very gratifying to hear.
And yes, being conservative about what we add to the standard library is a very deliberate decision. We also try not to do novel design in the standard library; design and iteration should happen in the ecosystem.
There are also some things that we're unlikely to ever add, such as cryptographic algorithms, precisely because we wouldn't be confident that we could fix issues with them without breaking compatibility. Crates in the ecosystem get to have a 2.0; the standard library doesn't. (Editions give us some ability to evolve the standard library, but the standard library still has to support every past edition.)
Also: I wish this level of discourse were what we could have with everyone who expresses a dislike of Rust. This has been an entirely pleasant experience, and I appreciate your feedback. Even if Rust isn't your particular cup of tea and you'd prefer to write your own code in something else, I'm gratified to know that things like this make it more tolerable. We often have to deal with code in languages that aren't our first choice.
> I have strong philosophical disagreements with ad-hoc polymorphism in general
What disagreements are those, if you don't mind typing more? PL design is something I'm interested in but not particularly experienced with so more perspectives are always nice to hear.
> I can not see a world where Rust adopts Haskell's position on the typeclass system being a convenient syntax sugar for a non-primitive and more explicit semantic form.
As someone who isn't familiar with Haskell, do you mind elaborating on Haskell's syntax sugar and what it reduces to?
My problem with ad-polymorphism is primarily that it encourages more generic-ness in authoring code, which I am aware is often lauded as a positive characteristic of a given program. Taken to the extreme, there are whole communities of developers that pride themselves of writing the most generic code possible. I hold the opinion that all code should be clearly specified and particularized to processing the actual data required by the specification of the problem domain. I am certainly on the extreme end of the spectrum of generic to highly specified, but I genuinely feel that better code and the resulting programs come from a low level and data specific design ethos.
Additionally, and more relevant to Programming Language Theory, the entanglement between ad-hoc polymorphism implementations and the detention of a programming language are a huge mistake from my perspective. This is where Haskell becomes relevant, because although there are some differences (implicit self, orphan issues, etc) between Rust traits and Haskell’s typeclasses, they are an extremely similar mechanism for achieving ad-hoc polymorphism. At this point in its development, and due to the pervasiveness of usage throughout the stdlib, I see it as almost certain that Rust will attempt to kludge traits into a formal definition of its type theory and language definition making any attempts at coexisting with other language in a single application more difficult. Comparably, in Haskell, typeclasses are merely syntactic sugar allowing for a better developer experience using ad-hoc polymorphism. Specifically, Haskell, the language as defined, achieves ad-hoc polymorphism by passing a dictionary parameter to functions using overloaded function names. This is done using the standard terms in Haskell and has a clear denotaional semantics for such terms. Rust usage of traits is talked about and reasoned about as a more primitive part of the language, not just a pretty piece of sugar with a more basic existence in the formally defined core of a programming language.
If ad-hoc polymorphism is something a language designer wants to incorporate into the usage of a language, my position is that defining a typeclass style sugar over a clearly defined set of terms in the core, formally defined language would be at least a method of prohibiting issues with the resolution, definition, and various methods of implementation of ad-hoc polymorphism polluting the syntax and semantics of the language itself. But the above requires a firm definitional boundary between what is the language and what is syntactic sugar to be built into the definition of the language and built into the compiler infrastructure.
A more out of band way to achieve ad-hoc polymorphism would be to have a pre-processor that is a part of the language distribution and maintained by the language designer/org that does the resolution/solving of the ad-hoc polymorphism and then presents the compiler with source text with no overloading.
There are also type theoretic solutions to ad-hoc polymorphism l, but that’s a little outside the scope (even if it my personal solution to having and limiting ad-hoc polymorphism in a language).
Woah! Thank you for taking the time to explain your perspective and thoughts! It's a lot of food for thought. I wish I had the background and knowledge to discuss things on equal footing :(
Just a few additional questions/comments:
> Specifically, Haskell, the language as defined, achieves ad-hoc polymorphism by passing a dictionary parameter to functions using overloaded function names. This is done using the standard terms in Haskell and has a clear denotaional semantics for such terms. Rust usage of traits is talked about and reasoned about as a more primitive part of the language, not just a pretty piece of sugar with a more basic existence in the formally defined core of a programming language.
Would it be accurate to say that Swift's non-monomorphized generics are more along the lines of the Haskell approach you prefer (i.e., single function implementation with a separate parameter for additional type info)?
And a bit more hand-wavey, but IIRC Rust's generics were defined in such a way that monomorphization is technically an implementation detail; in other words, I want to say a Haskell-like approach isn't strictly ruled out. I'd take that with a large grain of salt, though.
> If ad-hoc polymorphism is something a language designer wants to incorporate into the usage of a language, my position is that defining a typeclass style sugar over a clearly defined set of terms in the core, formally defined language would be at least a method of prohibiting issues with the resolution, definition, and various methods of implementation of ad-hoc polymorphism polluting the syntax and semantics of the language itself. But the above requires a firm definitional boundary between what is the language and what is syntactic sugar to be built into the definition of the language and built into the compiler infrastructure.
Might MiniRust [0] be something along the lines of what you would desire? It seems to fit the general idea of a smaller formally-specified "core" language. There's also this bit about traits specificlaly from the readme:
> That translation [from Rust to MiniRust] does a lot of work; for example, traits and pattern matching are basically gone on the level of MiniRust.
Swift is a good reference point in this area because Swift essentially took the dictionary-passing approach of Haskell and added the ‘low level’ type information like bit-width, offsets, etc as a Type Metadata parameter. The big upside is that Swift gets a good deal of performance boost compared to Haskell and other languages that have uniform datatypes (boxed values). So to extend the concept I was describing from Haskell to Swift would be creating concrete syntax for the language, which has no semantic identity outside those already existing in the semantics of Witness Tables. Sometimes the term “derived form” is used to talk about syntax like this. It is the term for concrete syntactic forms that are only defined in terms of syntax forms in the base/core language. It is, for the most part, correct to view derived forms as macros or as a more general metaprogramming construct, but but in Haskell’s case the macros are implemented in the compiler and expanded in a particular phase of compilation.
Swift is also good touch point for considering what the compiler does with the actual implementation of ad-hoc polymorphism. Swift is optimizing to monomorphized instances of a generic function give some heuristics about expect performance gains by specializing the function for a given type (Haskell also does this in GHC, but still pays a performance price for using boxed values).
So to answer the question: the part of Haskell’s implementation of typeclasses that I think is the correct method is that it is merely a derived syntactic form that is expanded by the compiler into Haskell’s actual language (its abstract syntax as encoded as ghc-core in GHC in particular). From this perspective Swift doesn’t provide the derived form, it just provides the implementation directly for developers to use omitting the sugar that Haskell provides. I tend towards explicitness as a strong default in language design.
Rust doesn’t have a formal semantics currently, so they could certainly adopt a derived form approach to traits, but I don’t know enough Rust to be able to determine what issues existing thoughts, assumptions, and type theory ‘commitments’ would act as obstacles to such a semantic.
As to MiniRust, Ralf Jung (at ETH Zurich) has done some excellent work, along with some of his students (Max Vistrup’s recent paper on Logics a la Carte is very, very good). MiniRust does attempt to be comparable to Haskell’s GHC-core. So in the sense of being or approaching what I would view as the (excluding type theory based options) correct way to implement ad/hoc polymorphism, yes, to sum: MiniRust as the semantic definition of a derived syntactic form and a compilation phase for ‘expansion’ of the trait macro.
Those explanations aside, my issues with ad-hoc polymorphism do not go away under this implementation, I’m generally opposed to generic functions (especially function name overloading). But I think that if a language is pursuing ad-hoc polymorphism as a feature they should pursue it in a well founded and formal manner.
Both of the example things you picked are generic types, and container-esque types at that. I think that my opposition to generics in general is a scale of dislike for different uses of generics. So, an off the cuff scale from (well founded and acceptable in certain cases) to (a strict negative in nearly all cases) would be:
Polymorphic Types
Parametricly Polynorphic functions
‘Well Motivated’ Ad-hoc Polymorphism
Basic Function overloading
Basic ‘Operator Overloading’
Function overloading for symbols that are treated as ‘special’ by the compiler
I think the hashmap case is illustrative for my general perspective. I do see the value in being able to have polymorphism for function arguments which are generic in a type parameter. However, consider that the ideal/most performant hashing function for keys differs not just based on general types (int vs string) but can differ based on something like string length or bit width or signededness. My position is that a language should prioritize the ability to encode those exact requirements in a data structure and difficulties for achieving generic-ness be damned. Each function taking a hashmap as argument should be tied to the optimizations and low level considerations intended by the developer.
I am not opposed to some duplication of code where it produces the appropriate code for the problem being solved. My generalized dislike of ‘generics’ is there, but in my comment above I was mostly discussing ad-hoc polymorphism as a means of enforcing some general reasoning ability onto function name overloading. And as I implied in my scale above I find it particularly distasteful (basic function name overloading), if not actively harmful.
For generics there are two areas often conflated in conversation that I find to be wildly different in formalizations of type theories and languages: first, there is static phase type application associated with System F and higher order polymorphic lambda calculus more broadly. I obviously would like to see a more specific and limited implementation of generics at all levels of abstraction, but the higher the abstraction goes the more ‘sense’ generic-ness makes. Second, there is generics as a name for function name overloading, which is distinct from parametricly polymorphic function as well as distinct from generic types. I really dislike this usage of generics and do not think it is a good practice for developing quality software or for readability, maintainability, or efficient optimization. Obviously this is a scale as well. I would put Swift in the lead with Witness Table semantics for generics, then typeclasses and traits, then any less structured implementations at the bottom.
That's a helpful explanation, thank you. I do generally agree that overuse of generics can produce bad interfaces. I also agree that generics tempt people to assume that the type fully determines the desired behavior, rather than giving any other means of selecting it.
(It's worth noting, for instance, that HashMap lets you replace the hasher, if you have some strings with a property that make them more hashable. But if we didn't have that, then the generic would force a given type to have only one hasher, and force a newtype wrapper to change the hasher, which would make for suboptimal designs.)
I agree there are significant costs to generics (especially readability), but there are large classes of problems that are a right pain without them. Even Go added them eventually.
In (2), I'm surprised to hear your description of Rust's generics as "ad-hoc polymorphism". I tend to hear that term used to describe non-trait based systems, like C++ generics (in the absence of "concepts"), which act like a compile-time version of duck typing. I think of Rust's generics as trait-based polymorphism, not ad-hoc polymorphism, and I prefer the former over the latter. To a first approximation, I see Rust's generics system as somewhat related to Haskell's. I would be interested to better understand how you see the differences.
From the way you're describing it, it sounds like you might not fundamentally object to generics in general, just to the idea of doing it through monomorphization rather than "dyn Trait"-style vtables? If so, then that's understandable. I like that Rust has both options, but I can absolutely appreciate preferring to do everything via vtables, which has both advantages (code size, one kind of conceptual simplicity) and disadvantages (more difficult to do per-implementation optimization, without doing devirtualization which amounts to monomorphization anyway).
We do have some forms of first-class "type functions" or "type constructors" or "rank-2 polymorphism", in the style of Haskell, so that you can be generic over something like `Vec`. It's a little indirect at the moment, going through traits with associated types, and I'd love to see a more direct version where you can literally write `Something<HashMap>` or `Something<BTreeMap>` and have those be type functions of one parameter (Haskell "kind" star -> star).
In any case, we have talked many many times about the idea of having more global options to say "don't monomorphize by default, do everything with trait objects". We also are likely to build a stable ABI atop trait objects and vtables eventually, so that it's possible to pass around pointers to data structures and their associated functions, without relying on the layout of the structure.
For (1), I do think we need some mechanism to integrate dependencies. I can appreciate the aversion to the default of "get things from the network". We do try to have good support for vendoring and similar, and this is critical for many projects (e.g. Rust in the Linux kernel, or Rust in CPython, are not going to allow downloading dependencies from the network). All that said, there is a tradeoff between "one first-class package manager and build system" and "lackluster support for various build systems", and Rust picked the former deliberately. We do like being able to implement things in rustc and plumb them through Cargo, so that they're available through the whole stack when that's necessary to make a feature useful. But we also have many users who need to use rustc without cargo, and who ensure that rustc features work with other build systems, notably large corporate monorepo build systems.
As for (3), fair enough, that is very much a philosophical difference between you and Rust, and Rust isn't likely to change that. I do think we're going to make ever more sophisticated ownership semantics in the future (e.g. making self-referential data structures possible), but I doubt Rust's model will stop fundamentally being based around ownership and borrowing.
I just wanted to drop a quick comment to clear up your first question. The term ad-hoc polymorphism to describe both Haskell and Rust’s typeclasses/traits is taken directly from Wadler and Blott’s paper which introduces the idea/concepts of type classes to Haskell. The name of that paper is ‘How to make Ad-Hoc Polymorphism less Ad-hoc’. This paper laid the groundwork for the implementation Rust uses and it is a mechanism for restraining ad-hoc polymorphism. But I think the term still applies to both Haskell and Rust’s typeclasses. Ad-hoc polymorphism is not a derisive term (when used as a term of art in discussions of implementations of programming languages), it is merely the PLT way of saying function name overloading. Rust and Haskell use very similar system to impose restrictions and semantic guiderails on ad-hoc polymorphism, but both languages still have it. To sum, I certainly do not mean any negative connotation with the term, I feel I am using it appropriately and as intended in this domain of discourse.
PS. I intend to write a more substantive reply to your comment, but didn’t think I should leave this unsaid.
I didn't take it as having a negative connotation; I just didn't interpret it in the manner referenced in that paper, and instead interpreted it as being not based on traits/concepts. Even given that, I didn't take it as negative; some people prefer the C++-style model, just as some people prefer dynamic typing.
Productivity is incremental. In a couple of hours, you could figure out enough to clone a repository of a project you care about, build it successfully, and make a trivial change (e.g. improve an error message, or add an alias to a command-line argument). That doesn't mean you know enough to start using Rust for your next project.
Opposing one purchaser does not imply supporting another purchaser. I don't know the details of this specific transaction, but I would guess the Chinese buyer does not have the same market power that Amazon does, so isn't running afoul of antitrust law. It's also possible Warren is opposed to this purchase, too, but no longer has the influence to stop it.
> Opposing one purchaser does not imply supporting another purchaser
Opposing the merger in this case necessarily meant embracing iRobot going out of business. Their financial position was clear, and no one else was in that business vertical but iRobot and Chinese companies. So either iRobot folds and the market is owned by Chiense companies, or iRobot folds and its IP is bought by Chinese companies.
> but I would guess the Chinese buyer does not have the same market power that Amazon does
In home robotics? They own the whole market.
> Warren is opposed to this purchase, too, but no longer has the influence to stop it.
Warren is too blindly ideological and frankly stupid to have pieced this together.
It is absolutely the the role of government to regulate commerce and establish competitive markets (note the lack of the word free here).
I also have zero faith in tech leadership as they have been the major driver of mass misery across humanity. Not only should they be stripped of their positions in their companies, but leadership should be directly given to the workers.
It's the only way to right to the wrong. If it's good enough for executives (voting for other executives, pay packages, and company direction), it's also good enough for workers.
How did iRobot hurt anyone? It seems like Warren hurt their workers by denying them the opportunity to keep their jobs. Moreover the whole home robotics industry no resides in China where the companies are run in an even more authoritarian fashion.
She should be, honestly. To me as an American, China has a better reputation than Amazon. Of those two choices, I'm happier with this outcome than giving even more stuff to Amazon.
As an American with a strong personal interest (kids) in keeping the country strong and competitive in the future, it seems bizarre to cheer for our largest adversary to gain advantages over us.
I also would have preferred to keep it in the country, but the fact is that Amazon does more harm and is a larger threat to Americans and your children than China is. Hence "Of those two choices... I pick China."
I would love for there to have been more than those two options, but this is where we ended up after decades of not enforcing anti-trust law, thanks in no small part to Amazon.
See downthread comment[1], and please keep in mind the context of this conversation is specifically, "Amazon does more harm and is a larger threat to Americans than China is".
Chinese doctrine explicitly has labeled America as the enemy for 10-20 years, with a goal of taking a democracy by force (after crushing dissent in HK and taking it over earlier than promised), and steals the West’s IP, and manipulates American businesses, and is actively committing a genocide for the past decade.
That's all pretty hand wavey and abstract, not very convincing (for example, I'm pretty sure China is not committing a genocide in the US, and Western IP law is arguably not worth much respect anyway). I'm not saying China is without problems, I'm just saying they're less harmful to Americans than Amazon is.
You’re claiming that documented and active IP theft and anti-democracy and enemy-action doctrine is handwavy and better than a tax paying business that supports democracy and that is not trying to undermine the west? You’re wrong
I similarly can't understand how you can look at the US over the last 10-20 years and think the US's biggest threat is some country on the other side of the planet who makes the stuff that we ask them to make, and not the billionaires and megacorps who control every aspect of our economic and political system which directly lead to the situation we are in now. The call is coming from inside the house, man :)
Meanwhile, Amazon and its executives are union-busting to keep worker rights minimal, running a nation-wide law enforcement surveillance network, supporting Republican politicians and all of their anti-American policies and practices, lobbying to oppose anti-trust enforcement to keep hold of their illegal market positions and keep our economy weak, and they own one of the nation's largest newspapers specifically so they can control the narrative over their own actions. And that's all happening right here, in the US, influencing our laws and our media, right now today, not in some theoretical future.
So yeah in terms of entities that are actually doing real harm to Americans, Amazon beats China no question.
There are threats from without and threats from within.
China isn't going to physically invade the US. They want to take our place as the world's cultural leader and relegate the US to approximately the current state of the UK.
Companies like Amazon want to increase the wealth of the owners at any cost including domestic political capture. They would see the country being run by oligarchs like Russia.
To be fair, shopping at Amazon is nearly the same as shopping at some Chinese company. They bring in Chinese products by the boatload, warehouse them here and offer 2 day shipping. That's virtually their entire retail business and value proposition. It's a slightly curated selection, easy ordering and fast shipping. You can buy all the same stuff for less at Ali Express if you don't mind waiting 3 weeks.
I don't mean to make light of what Amazon actually does. Their logistics are incredible. But, really, that's what they are. A logistics company. Your money still goes to China and you pay more so an American company can get their cut too.
>"To be fair, shopping at Amazon is nearly the same as shopping at some Chinese company."
Have you actually used AliExpress? I use both Amazon and AE, and the former definitely offers a lower-deceit, easier to use, and better customer experience. Amazon powers most of the web, whereas AE regularly has massive bugs (I was completely unable to sign in for over a month due to a UI bug last year).
> when my boss said, on the phone to a client, "yes, I've got a resource for that".
Hahaha, I got hit with that, too, also working for a small company. Luckily it was the client who called me "a resource", not someone from my company, but good lord what a way that is to talk about human beings.
I agree with your overall point (and I'm pretty confident improved infrastructure will fix the problem for non-homeowners... eventually), but I didn't understand this part:
> usually not the only vehicle either
It doesn't seem like EV or not would make a difference for whether to have more than one vehicle? My wife and I have shared one car, first ICE and now EV, for more than a decade and it didn't make a difference in our habits.
There's no real reason with modern EVs unless you really love road trips, but I feel like I very rarely meet or hear of EV owners who don't own more than one vehicle. That's probably less of a thing now that most new EVs have decent range.
Yeah, that's why that poster said "upfront" costs. EVs are like 10+ times cheaper than ICE cars in the long term, but we're making our children pay most of the costs of the ICE version, so it's cheaper for us. Yay for us, I guess?
> I think if I could afford to retire tomorrow, I'd have no trouble keeping myself busy for the rest of my life.
Completely agreed. I took 6 weeks off between jobs a couple years ago, the longest continuous span without work or school since I was 14. It seemed crazy long. My goal was to get bored so I'd be ready to go back to having a job at the end of it. I completely failed, I filled those 6 weeks and would eagerly have filled many more self-directed months. Maybe it'll be different when I'm older but right now, I could easily spend years and years keeping myself busy if I didn't have like bills and stuff to pay.
Microsoft is a public company. That means their primary product is not products or services, it's their stock. Selling products & services can be an advertisement for their stock, but there are other methods of convincing people to buy their stock, too. Currently the stock market only wants stocks that have "AI" associated with them. It doesn't matter whether users like it or not, because having a viable business is not what the stock market is currently focused on. So, Microsoft is doing what they need to do to sell their primary product: shove AI into everything.
If you're someone who owns Microsoft, what option would you prefer?
1. Stock price remains the same but revenue doubles.
2. Revenue stays the same, but stock price doubles.
Assuming all else equal, and recognizing that this is absolutely a simplification, but if these were the two choices then it seems a no brainer that you'd go with option 2. Revenue is a means of increasing stock price.
I guess it depends on what kind of investor you are.
If you're holding MS stock long-term, and you plan to gradually shift away from equities as you near retirement and then gradually liquidate your holdings to fund your retirement, juicing the stock in the short term does nothing for you.
If you're holding short-term, then you also need to sell the stock after it gets juiced, so that you can move your capital to not-yet-juiced stocks.
Missed a point above - that for said short-term investor... that strategy doesn't actually work, since a "sell high buy low" strategy on individual stocks is outperformed by just holding ETFs long-term.
So really, which investors does short-term stock juicing benefit? Insider traders, I guess.
That’s like asking whether you’d rather have a pizza with the same diameter but twice the area, or a pizza with twice the diameter but the same area. It makes no sense.
Stock prices were, are, and will always be rough approximations of the NPV of future profits. It’s not perfect, of course, but it’s roughly true.
Doubling revenue in any remotely sustainable way will have way more than a 2x impact on stock price because of exponential growth. So yeah, as a stockhodler, you’d rather double revenue with flat stock price because you’d buy the crap out of the stock when you realize the market has not factored revenue growth in to pricing.
Imagining that public companies care about stock price more than revenue is literally like saying a hungry customer care more about pizza radius than area.
A long term investor would prefer 1. Most likely option 2 would shortly be followed by halving of the stock price. Option 1 lets someone buy shares in a company that is greatly undervalued and will lead to long terms gains.
I just think you are the other person who replied to me are making the same mistake, which is mixing the means of accomplishing a goal with the goal itself. This is a mistake I see a lot (especially in software development), where people get too attached to a specific means or method that they end up confusing the method itself with the actual thing that needs to be accomplished.
The goal for an investor is captured in the stock price itself. In programming terms, a corporation is a function whose output is its stock price/market cap, and revenue is but one of a host of inputs into that corporation that determines what the stock price is. Other inputs can be operating expenses, whether dividends are issued, future prospects for the company such as entering new markets etc etc... and you can have beliefs about how those various inputs affect the output or how these inputs change the output over time (short term vs. long term), that's perfectly fine... but when push comes to shove, the goal is not the revenue, it's not entering a new market, it's not reducing operating expenses... the goal is increasing the stock price (well technically the market cap).
That's precisely the argument I'm making. A company's stock price can be undervalued, which exactly means that the stock price can increase without any change in the company's revenue or profitability. The stock price can increase strictly because the actual value of the company has not yet been fully realized without any material change necessary on the part of the company.
As an investor, that's the ultimate goal of your investment.
Sure. Decision makers are paid in stock price, not revenue. They would rather do whatever increases the stock price the most, with the least effort/expense.
Yyes, and prefer it to doubling profit or cashflow etc.
I have not looked at MS in particular, but generally that is what the remuneration of the people at the top of most public companies is most strongly linked to.
I've been thinking about this recently. The centrality of the stock market, while historically a great tool to allocate resources efficiently, might actually be a big weakness for the USA today. A capable adversary, like China, can kill entire strategic sectors in the US using the stock market. If they undercut the US companies and are willing to accept low returns on their investments, then the respective USA competition will be driven out of business by their investors, because there will be other sectors to invest in, with higher RoI. Do this at various points in strategic value chains, and over a decade or so it might kill entire verticals in strategic sectors, leaving the US economy vulnerable to any kinds of shocks.
As someone who is essentially financially illiterate, what does this mean, "allocate resources efficiently?" Nobody's investing in companies that promise to cure world hunger or alleviate childhood suffering. They're investing in technologies that can extract the most wealth from the population, regardless of externalities. Is that desirable?
Then again, I can't fathom what people would be doing with their money if the stock market weren't there. I imagine they might naturally wind up with some sort of...stock market.
The operating principle here being that prices are units of information, which in aggregate reveal some combination of market demand, present supply, production costs, etc. All else being equal, an investor who's looking to put an investment into a new business will try to find the best rate of return. The existence of a relatively higher profit margin for an industry suggests an unmet market need, and then directs the flow of capital into it (if you expect that for every $1 you invest into a roofing nail plant will return $1.25 over the next year vs a $2 return from a new insulin plant, more new cash will flow into the insulin plant, more insulin gets made, and if the investor guessed right about the demand for it, they turn a profit). In a sentence, money flows towards trying to give people what we think they want more of.
The theory posited above is that you could try to manipulate these signals as a sort of economic warfare. If you expect that every dollar you put into our aforementioned roofing nail factory will get you minuscule or negative return, nobody's going to want to invest in building/expanding nail factories, and they'll put their cash somewhere it can grow instead. This is all well and good so long as you've got happy trading relationships with people who can sell you nails, but if one day the nails stop coming--you've got a supply chain shock until you either open new factories or find someone else willing to sell nails to you. The theory here being that if you had a LOT of goods that became tied up in a single point of failure--someone forcing that failure could create a great deal of internal instability to be exploited for geopolitical ends.
That's what's meant by efficiency, it's allocating it to the place that has the highest return on investment.
As you point out, in practice what's efficient is what can capture the highest return, not necessarily the highest return per se. If say investing in education had high returns society wide but those returns couldn't be captured, that's not an efficient use of private capital.
As somebody doesn't consider himself a capitalist, wouldn't it be fair to say it is "the most efficient" in precisely one thing: capital reproducing itself?
And if so, why is that necessarily a good thing? Why should that be our goal as society as opposed to things like minimizing child mortality, increasing literacy rates, making sure we don't have a ton of our fellow humans living on the street in misery etc etc - things that make the lives of our fellow humans better? Why is capital growth the metric we have chosen to optimize for? Surely there's better things to optimize for?
Excuse the polemic, but infinite growth with no regard for anything else is the ideology of a cancer cell - and to me that is increasingly what it feels like when we are wasting all these resources on a dying planet just to make numbers go up.
Ultimately that money is made by people choosing to spend their money on something, because it helps them, because they like it, because they need it for whatever reason (real or imagined). That's what grounds the financial markets: eventually someone is buying a thing because they want the thing, and all the rest of it is basically just figuring out who can make the thing, how many people want the thing and how badly, and whether the stuff used to make the thing could make a different thing that people want more. Financial markets can depart from that reality for a while, but mainly because of a collective belief in some falsehood about the above (everyone really badly wants AI, right?).
Number go up infinitely is due to inflation and that's basically just an incentive to not hoard cash indefinitely, and instead use it for something useful. But the only thing that uses up is numbers. Everything else is because people, on average, want more stuff and are willing and able to work hard to get it.
(Of course, this generally means that the markets chase the desires of those who have something valuable enough. People who don't will be marginalised by this mechanism, for sure. And of course there's lots of opportunity for people to steal or abuse powerful positions in the market to the detriment of others. Which is why a free market is not the be all and end all of organising a society, and other organisational structures exist to regulate it and to allocate resources in a less transactional manner)
But isn't that counter to the very article we're commenting on? Everyone is shoving half baked AI junk into everything because that's what makes number go up on the stock market, but I'm pretty sure that's not actually what most people would want those resources to be used for.
I'd posit that markets are completely detached from the real world and are more of a speculative/religious element than an indicator of any ground truths.
Edit: I just realized I missed a sentence of yours where you kinda spoke to this. I still believe that this is more of a rule than an exception - there is nothing inherently tying markets and reality together - they're mostly about people making bets on what the next big hype is; not on what is actually useful to anyone.
Most people or most people with money? Ultimately it's the people making investment decisions you need to convince in order to get the money from them. Then the reality check is whether you can give them that money back and more. Those investors should in theory be self-interested in making sure that this is actually useful, because if they don't they'll lose their money, but in practice they are not superhuman and prone to fads and echo-chambers (especially because it's a relatively smaller group that can move a lot of money around, and short-term investing rewards running with the crowd to some degree), but there's not a single group of people that would not fall victim to poor decisions in this regard (whether you're imagining a centrally managed economy, the electorate, or some hypothetical benevolent dictator).
Optimizing for capital returns is a simplification of the real world, where it allows for comparing whether it makes more sense to put one's money into opportunity A or B.
There's a lot that's not captured by solely looking at dollars, like the examples that you bring up, such as quality of life, human welfare, and so on.
If you care about minimizing child mortality, increasing literacy, pulling people up out of poverty, you should be a capitalist, as it's empirically the best way to meet those goals. This seems to be a hard thing for many to understand or accept because it is largely a second order effect, the capitalist primarily concerned with their own personal gain but winds up improving the lives of others as a side effect.
This is the essence of Adam Smith's often misunderstood invisible hand metaphor. Of the individual he observed: "By pursuing his own interest, he frequently promotes that of the society more effectually than when he really intends to promote it." Second order effects stack up and improve quality of life for more people better than trying to do so explicitly.
Multiplying capital creates abundance and that abundance allows for improved standards of living for and the means to spend excess resources in support of charitable endeavors. Growth is good because it means more abundance and opportunity. I would argue that pursuit of growth is not an ideology but a force of nature. Life is opportunistic and will expand to wherever there is fertile conditions, and often adapt even when they are not. We are part of nature and understand this intuitively, seeking growth opportunities. As an example, one is better off being part of a growing company (more wages and opportunities) than one that is stagnant or declining (fighting for scraps and survival).
>If you care about minimizing child mortality, increasing literacy, pulling people up out of poverty, you should be a capitalist, as it's empirically the best way to meet those goals
If you look at it empirically, the majority of people brought out of poverty (and I suspect the other metrics but am not as familiar with them) in the past few decades have been in China as the result of deliberate policies by the CPC.
We’re already there when it comes to having the industrial base necessary to fight a protracted conventional war with china. Which leaves a large ? over the US dominance over the pacific.
Y-yeah. HYPOTHETICALLY, this is something an adversary to the USA might attempt to do, and it would really kneecap the US if they were successful.
But would only happen if USA decided to totally financialize all sectors of its economy and make a small set of oligarchic corporations THE load-bearing element of its strategic capacity, leading us to chase market returns even if those returns totally kneecapped our ability to build anything at all of actual value.
While not strictly necessary, it is a great power multiplier.
It helps as it is both a gauge of the success of the strategy, and also a lever where the process can be fine tuned, eg. slowly buying stock then strategically dumping in the right time, correlated with other external shocks can have wider effect to whole industries through controlling the public opinion on specific industries.
It rewards self-destructive behavior in favor of short-term gains. Shareholders have *zero* commitment to the companies they buy shares from and will happily switch their entire portfolios on a whim. It's essentially people chasing the new shiny thing every single day.
Let's not forget it's a known fact that people with insider knowledge will profit over everyone else.
How is that efficient in any shape or form?
> If they undercut the US companies and are willing to accept low returns on their investments, then the respective USA competition will be driven out of business by their investors, because there will be other sectors to invest in, with higher RoI.
You're basically explaining one of the reasons stocks are a horrible idea for distributing resources.
It has nothing to do with whether or not it's central or distributed, it's merely the incentives they create. It's essentially Goodhart's law on steroids.
Depends what you compare it with. I grew up in the post soviet union. That system allocated resources to various monopolies who were too big to fail. Turns out allocating capital based on who can make things that people want/need to buy, and do it with a profit, multiplies said capital way faster. From this point of view, over time your initial base grows into all kinds of industries etc. That's probably why the USA won the cold war.
Until your economy congeals into various monopolies who are too big to fail, and you lose the rematch because you're so busy counting beans you stop paying attention.
A bad system is still bad even if something else is worse.
> That system allocated resources to various monopolies who were too big to fail.
Like our banks today? Like OpenAI is trying to sell themselves as so the US government bails them out when they inevitably can't pay off their debts? Like all the other monopolies that are too big to fail?
I can't see the difference.
> turns out allocating capital based on who can make things that people want/need to buy, and do it with a profit, multiplies said capital way faster.
That assumes the stock market does that. It simply doesn't and history is proof. It's also a fact that free market capitalism has consistently done worse than before based on actual numbers.
I highly suggest you read 23 things they don't tell you about capitalism. It goes into a lot more detail and helps you understand things in a broader perspective.
If we want to improve our world we need to move past the faults of the current capitalist system and the soviet union. We need better incentives. Profit has proven to be too disconnected from actual value.
The stock market weirdly enough ruins the idea of capitalism. Catering to shareholders hurts the idea that competition would create better and cheaper products.
Its not the stock market per se. The biggest problem is a lack of good regulation to ensure competition and the resulting drift of oligopolies.
The stockmarket enables that by making takeovers easier as you have a higher proportion of short termist shareholders who 1) fail to block value destroying acquisitions on one side and 2) jump at the chance to make a quick profit on the other.
that's not the idea of capitalism; the idea of capitalism is that you should be able to make money by virtue of owning stuff. it's an inherently rich-get-richer scheme, competition has little to do with it.
I don't see how free market capitalism fixes that. I looked up a definition to make sure I wasn't missing something and as per investopedia:
"The term “free market capitalism” refers to an economy that puts no or minimal barriers in the way of privately owned businesses. Matters such as worker rights, environmental protection, and product safety will be addressed by businesses as the marketplace demands."
it's basically worship of owning the means of production and not being regulated in its use, e.g. if you own a company you get to dictate all sorts of unreasonable things to your employees, and any benefits gained from automation accrue to whoever can afford the up front money to own the machines.
Competition creating better products isn't an idea that defines capitalism though: the same would apply to cottage industry.
Capitalism is defined by having the capitalist, who provides capital, and without the ability to sell their share of stock it's difficult to see what the value would be. So you kind of require stock markets.
Edit: which is why it's odd to call China communist. They have 3 stock exchanges. They're really a capitalist single-party state.
China uses Capitalism as a tool where the Party feels it would be beneficial (for the Party), and crushes it mercilessly when it gets in the way (other than this real estate problem they have right now).
In the U.S. we have mistaken Capitalism for a religion, and so it wags the dog, so to speak. Since our founding we have made some attempts at finding a balance between our use of the tools of Capitalism and socialism (in more the Democratic Socialism style, rather than the Communism style), and we had a good run in the decades after WWII. But starting with McCarthyism, and really picking up under Regan we have prided ourselves on adopting Capitalism as a religion, and it really shows up in both the income inequality as well as the increasing role of (and corrupting influence of) money in our politics/government.
It's basically the reason this bubble not only exists but has a chance not to pop : there is so much stock value in it that the big tech all want to keep feeding it, and they're sitting on so much cashflow they can afford to do it
It's absurd, but that's where it is. And a company like OpenAI basically hangs on it, because they have obligation almost ten time their revenue and the only way this does not deflate quickly is if others keep feeding it cash.
> Boeing spent about $300,000 to help Ortberg move to Seattle. His decision comes more than two decades after Boeing leadership decided to move company headquarters out of Seattle. Ortberg received about $18 million for the months he was the CEO in 2024.
> In 2022, Calhoun received $22.5 million from Boeing. Most of his 2022 compensation was in the form of estimated value of stock and option awards. He received the same $1.4 million salary as in 2021. ... In February 2023, Boeing awarded Calhoun an incentive of about $5.29 million in restricted stock units to "induce him to stay throughout the company's recovery". In March 2023, Boeing announced Calhoun was being given shares worth $15 million that will vest in installments over three years.
Works for Tesla, the absolute poster child for this kind of behavior. They can lose double digit percentage of market share in key places and still give the CEO a trillion dollars.
That's fair, I should reframe. The incentive given to decision makers at Microsoft is company stock. That means the primary focus for everyone who makes decisions at Microsoft is the stock price, which in turn means the stock price is the primary product for the company itself.
Name a major U.S. public company in recent years that has consistently prioritized improving its product over boosting short term stock price or extracting maximum profits. If capitalism were truly a healthy system about building strong products to create healthy markets, this should be the norm (and enshitification shunned), not the exception.
What we actually see is a system of chartered extraction. Corporate executives are like Norman lords, granted their 'title' (CEO of instead of Earl of) by shareholders (rather than a king) in return for which both are/were expected to extract maximum value by any means necessary. Extractive tactics often at the expense of long-term product strength are behaviors shareholders expect if the CEO is to keep their bestowed 'title'.
Don't forget the progenitor joint stock company The East India Company, Capitalism in it's purest form without government restriction. Profit-maximizing, absentee extraction, with company executives serving as quasi-feudal lords over assets and people. Modern corporate capitalism is hard to distinguish, in its structure,history, behavior, and incentives, from the Norman extraction system, it's just dressed in a more politically palatable wrapper and forced to mellow out from it's desired East India Company style final form.
> Name a major U.S. public company in recent years that has consistently prioritized improving its product over boosting short term stock price or extracting maximum profits.
Well in some perverse sense, I'd say Meta qualifies here. Zuck isn't beholden to other shareholders and is free to burn truckloads of money on worthless projects. The big asterisk is that for Meta, "improving its product" is effectively "creating the best digital cigarettes".
Lots of companies do this (Arizona green tea immediately comes to mind), but more importantly, this has no bearing on the discussion of whether or not capitalism is "good" (really, who ascribes morality to any economic system?), because the US is primarily an exercise in regulatory capture.
Good doesn't mean moral in this case, it means valuable. Capitalism, or whatever the fuck we have right now, doesn't create much real value, but instead it creates a lot of fake value that we just proxy.
And I say "or whatever the fuck" because, as you point out, it's not really capitalism. And maybe it never was - after all, the US Golden Era was when we had the most central planning, the most social services, and the highest taxes.
But everybody right now is exploiting one teensy little flaw of the economy - humans don't live very long. There's no reason to make stuff good for later when you can take a cash advance and get rich now. Everything is always someone else's problem.
I think one fun case study is superstar CEOs. They're so highly desirable, and they work 5 years at a company and "turn it around" before moving onto the next. But if you look at the company after they leave, it's in shambles. And yet, they are the most sought after CEOs. You don't want the Arizona Green Tea guy, no, you want the guy who ran Chipotle into the ground. But hey, at least he increased their stock price for, like, a little bit.
Arizona comes to mind because it's the outlier that everyone knows about, the company that bucks the capitalist pressure. Your choice to use it basically proves my point.
Capitalism outside regulatory capture looks like the East India company. You are basically giving me 'no REAL communism has ever been tried'.
* Almost. Anti-cheat remains a big hole.
** No, I'm not going to use a keyboard or do Windows admin crap from my couch.
reply