5 ms·

This! Tooling ease of use matters! A lot of interesting tech died off or never took off because the tooling was just too cumbersome to setup and use.

zilti 3y ago
Ah yes, when using your package manager is too cumbersome...
dijit 3y ago
Honestly I think a lot of the Rust zealotry is because the tools are amazing. If it was just rustc on it's own I doubt it would have people chest-thumping like they do. I say this, as a lover of Rust: precisely because of Cargo, rustup and the crate system.
- hu3 3y ago
  Eve more so in Go where the single standalone executable can: - run code - build code - format code - generate code - profile code including flame graphs - run tests and report performance down to allocations - benchmark code - manage packages - manage workspaces - scan and vet suspicious code It's amazing how much a 2 character command can do.
  - jchook 3y ago
    And yet, the number of times 3rd party Go code has died on my macOS machine due to a segfault...
  - jrockway 3y ago
    gofmt is actually a separate command.
    - hu3 3y ago
      Indeed! And it can be called from go command too: go fmt main.go https://pkg.go.dev/cmd/go#hdr-Gofmt__reformat__package_sources https://pkg.go.dev/cmd/go#hdr-Gofmt__reformat__package_sourc...
  - hyperman1 3y ago
    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.
- andrewflnr 3y ago
  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?
  - flakes 3y ago
    > investment-induced loyalty Would generally refer to this as a sunk cost dilemma
    - andrewflnr 3y ago
      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.
  - sammoe13 3y ago
    I often use the phrase "[I/he/she/they/we] have already sunk so much time into ..." Not dissimilar to "sunk cost".
- bluGill 3y ago
  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.
  - dijit 3y ago
    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.
- ithkuil 3y ago
  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.
  - kevlar700 3y ago
    They have improved go modules since but if you didn't use github gos tooling wasn't so great. I actually dropped Go for Ada and prefer Adas packaging.
    - ithkuil 3y ago
      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)
- zamalek 3y ago
  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.
  - deleted 3y ago
    [deleted]
  - randomdata 3y ago
    > 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.
    - zamalek 3y ago
      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.
      - tome 3y ago
        Why are people afraid of functional languages?
        randomdata 3y ago
        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.
- IshKebab 3y ago
  Part of it is, but the language is also great. It isn't Zealotry. Rust really is that great. Not flawless (async is a big wart), but still fantastic. I would say that applies much more for Go, where the language is decidedly meh, but the tooling is fantastic. Arguably even better than Rust.

zilti 3y ago

Ah yes, when using your package manager is too cumbersome...

dijit 3y ago

Honestly I think a lot of the Rust zealotry is because the tools are amazing. If it was just rustc on it's own I doubt it would have people chest-thumping like they do. I say this, as a lover of Rust: precisely because of Cargo, rustup and the crate system.

hu3 3y ago
Eve more so in Go where the single standalone executable can: - run code - build code - format code - generate code - profile code including flame graphs - run tests and report performance down to allocations - benchmark code - manage packages - manage workspaces - scan and vet suspicious code It's amazing how much a 2 character command can do.
- jchook 3y ago
  And yet, the number of times 3rd party Go code has died on my macOS machine due to a segfault...
- jrockway 3y ago
  gofmt is actually a separate command.
  - hu3 3y ago
    Indeed! And it can be called from go command too: go fmt main.go https://pkg.go.dev/cmd/go#hdr-Gofmt__reformat__package_sources https://pkg.go.dev/cmd/go#hdr-Gofmt__reformat__package_sourc...
- hyperman1 3y ago
  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.
andrewflnr 3y ago
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?
- flakes 3y ago
  > investment-induced loyalty Would generally refer to this as a sunk cost dilemma
  - andrewflnr 3y ago
    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.
- sammoe13 3y ago
  I often use the phrase "[I/he/she/they/we] have already sunk so much time into ..." Not dissimilar to "sunk cost".
bluGill 3y ago
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.
- dijit 3y ago
  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.
ithkuil 3y ago
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.
- kevlar700 3y ago
  They have improved go modules since but if you didn't use github gos tooling wasn't so great. I actually dropped Go for Ada and prefer Adas packaging.
  - ithkuil 3y ago
    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)
zamalek 3y ago
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.
- deleted 3y ago
  [deleted]
- randomdata 3y ago
  > 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.
  - zamalek 3y ago
    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.
    - tome 3y ago
      Why are people afraid of functional languages?
      - randomdata 3y ago
        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.
IshKebab 3y ago
Part of it is, but the language is also great. It isn't Zealotry. Rust really is that great. Not flawless (async is a big wart), but still fantastic. I would say that applies much more for Go, where the language is decidedly meh, but the tooling is fantastic. Arguably even better than Rust.