I would be slightly more cynical and suggest that the easy tooling enables people prone to cheap chest-thumping to get into the language, when otherwise those types would probably wander somewhere else. The difficulty of the borrow checker will already create investment-induced loyalty[0], but if the first difficulty isn't even unique to the project, then the interesting difficulty doesn't have a chance to work.
Speaking, myself, as someone who likes Rust but wishes people would be more clear-eyed and less obnoxious about it.
[0] Someone remind me what the standard term for this is? You know, the thing where people get really emotionally invested in things where they've invested a lot of time and effort, like Vi or Emacs or Dark Souls?
I thought about trying to use "sunk cost", but I usually see it written as "sunk cost fallacy" and that's a (closely related, but) slightly different thing.
Since I started programming, I see every generation of programming languages slowly raise the bar. From the top of my head, in the order I encountered them.
* C: make gave a standard way to compile/link a program.
* Perl: CPAN as standard library/repository location.
* Java: javadoc gave a standard format for low level documentation. Rules like 1 file=1 class, 1 folder=1 package gave a standard source tree layout.
* Java/maven gave standard way to download, install and upgrade dependencys
* Go: Built in formatter.
* rust: cargo combines the strengths of Go standardization and Java/maven repositorys
Every iteration provides extras that the previous tooling generation sees as trivial. They'll say you can add them to the mix yourself if you want to. Their company likes things in a different way, and are happy to have the option.
But that's missing the point. The whole language ecosystems standardizes on a reasonable (but not 100% perfect) way of working. This has a lot of secondary benefits:
* People move easily between organisations with minimal up-to-speed costs.
* Somewhere in the ecosystem, someone still has your ancient tooling version, and the upgrade path is clear(er).
* No discussion about in-house standards. (Try to get 2 C programmers agree on a coding style and watch the hours fly discussing what to take from ugly K&R vs ugly GNU.)
* Real pain-points get solved, because someone feels your pain.
I've seen the in-house stack developed by a Cobol company. It's finely tuned to that 1 company, yielding huge benefits. It's also a very non-trivial investment and maintenance cost.
I agree. Same with Go. When I started with Go, I quickly forgave it all little rough edges in the language itself because they were offset by a tooling that was just miles ahead the state if the art of the time.
The package management story before go.mod was sad but I have to plat devil's advocate and point out that GitHub did have special treatment by go get, you could use any domain name to host your code and you just had serve a <meta name="go-import"> tag in a html file and you could tell go where to fetch your code (several version control tools including Mercurial are supported)
I chest thump because more errors happen at compile time, and fewer at runtime. The tooling is what I would consider basic competency these days. Go has a similar tooling story and, while I do enjoy the language, it doesn't inspire chest thumping.
> I chest thump because more errors happen at compile time, and fewer at runtime.
Why Rust, then? It is not particularly good on this front. Hardly the worst, but is still pretty Mickey Mouse compared to the languages that excel here.
I expect the zealotry/chest thumping is entirely a product of fashion. There are some things about Rust that are truly great, but nobody would go out of their way to mention it if it wasn't what is in style.
People get pretty riled up about the likes of Haskell, Elm, and OCaml. Rust brings some of the virtues of functional into procedural code/average developer hands, and out of "monads are just a monoid in the category of endofunctors."
At the end of day, people are afraid of functional languages. It doesn't matter how amazing they are if almost everyone is too scared to use them.
I'm not afraid of functional programming. I just dislike it. I avoid recursion in Ada personally (others like it). I think OOP is over rated and the clarity of imperative is under rated. Though I do like how Ada provides object oriented design to imperative programs even without touching Adas OOP features (tagged types).
This sums it up pretty well (I disagree that "functional sucks"). https://youtu.be/nuML9SmdbJ4?si=DEBaHcAvvxO_Ez93 There is a lot of jargon, and that presents an extremely high hurdle for newcomers (especially for those without formal mathematical education). Bizarrely, C++ has a worse version of the same problem: the "modernization specs" are tribal jargon heavy.
Compare that with the likes of JS, people learn that in a few weeks bootcamp.
Rust absolutely has hurdles, but you can be largely successful without ever touching them (you can get a surprising amount done without ever worrying about lifetimes).
Great video! Are you saying that if functional programmers explained FP like the video (i.e. focusing on the benefits of simpler code) then fewer people would be scared of it?
People meaning him, which is why he won't "chest thump" anything related to functional programming. After all, chest thumping is a display of dominance. The others witnessing the chest thumping are meant to be scared. You wouldn't hold back because they are scared.
Which is to say that he is not actually afraid, it's just a roundabout way to say that the only reason he is on the Rust trumpeting bandwagon is because it what is in fashion.
I'm a hater of rust because of cargo and cargo - while it makes getting started easier, it is one of several opinions rust forces on me that are not compatible with my current code and so it make it more difficult to figure out how to incrementally start using rust in my code base. For small greenfields projects it is nice, but I'm not in that world and rust is fighting me.
That's fair, opinions are annoying when they don't align with your own (for me for example; I really hate that go-imports are URLs and the monorepo story for them is really bad... which I find ironic).
If you like rust, but hate Cargo, I'd suggest looking at building with Bazel :D
Bazel is a build system, but I don't use it as much as I'd like precisely because I'd have to manually write out all the DAG stuff.
A lot of interesting tech died off or never took off because the tooling was just too cumbersome to setup and use.