10 ms·

Someone once told me a benefit of staffing a project for Haskell was it made it easy to select for the types of programmers that went out of their way to become

by glaslong 10mo ago

Someone once told me a benefit of staffing a project for Haskell was it made it easy to select for the types of programmers that went out of their way to become experts in Haskell. Tapping the Rust community is a decent reason to do a project in Rust.

steve_adams_86 10mo ago
I'm my experience this is definitely where rust shined. The language wasn't really what made the project succeed so much as having relatively curious, meticulous, detail-oriented people on hand who were interested in solving hard problems. Sometimes I thought our teams would be a terrible fit for more cookie-cutter applications where rapid development and deployment was the primary objective. We got into the weeds all the time (sometimes because of rust itself), but it happened to be important to do so. Had we built those projects with JavaScript or Python I suspect the outcomes would have been worse for reasons apart from the language choice.
- zahlman 10mo ago
  > having relatively curious, meticulous, detail-oriented people on hand who were interested in solving hard problems.... Had we built those projects with JavaScript or Python I suspect the outcomes would have been worse for reasons apart from the language choice. I genuinely can't understand why you suppose that has to do with the implementation language at all.
  - KPGv2 10mo ago
    > I genuinely can't understand why you suppose that has to do with the implementation language at all. Languages that attract novice programmers (JS is an obvious one; PHP was one 20 years ago) have a higher noise to signal ratio than one that attracts intermediate and above programmers. If you grabbed an average Assembly programmer today, and an average JavaScript programmer today, who do you think is more careful about programming? The one who needs to learn arcane shit to do basic things and then has to compile it in order to test it out, or the one who can open up Chrome's console and console.log("i love boobies") How many embedded systems programmers suck vs full stack devs? I'm not saying full stack devs are inferior. I'm saying that more inferior coders are attracted to the latter because the barriers to entry are SO much easier to bypass.
    - zahlman 10mo ago
      Sure, but that kind of incompetence is already filtered out (in the https://www.lesswrong.com/w/screening-off-evidence https://www.lesswrong.com/w/screening-off-evidence sense) by the task of creating a package installer.
      - IgorPartola 10mo ago
        You would think so, yet here I am sitting with a node_modules full of crud placed there by npm, waiting for the next supply chain attack.
        zahlman 10mo ago
        That argument is FUD. The people who created the NPM package manager are not the people who wrote your dependencies. Further, supply chain attacks occur for reasons that are entirely outside NPM's control. Fundamentally they're a matter of trust in the ecosystem — in the very idea of installing the packages in the first place.
        firesteelrain 10mo ago
        Lack of stronger trust controls are part of the larger issue with npm. Pip, Maven and Go are not immune either but they do things structurally better to shift the problem. Go: Enforces global, append-only integrity via a checksum database and version immutability; once a module version exists, its contents cannot be silently altered without detection, shifting attacks away from artifact substitution toward “publish a malicious new version” or bypass the proxy/sumdb. Maven: Requires structured namespace ownership and signed artifacts, making identity more explicit at publish time; this raises the bar for casual impersonation but still fundamentally trusts that the key holder and build pipeline were not compromised.
        Mawr 10mo ago
        For Go, there are more impactful features: minimal version selection and the culture of fewer, but larger dependencies. Your average Go project likely has 10x fewer deps than a JS project. Those deps will not get auto-updated to their latest versions either. Much lower attack surface area.
  - tikhonj 10mo ago
    Different programming languages come with different schools of thought about programming and different communities of practice around programming. If you take a group of people who are squarely in the enterprise Java school of thought and have them write Rust, the language won't make much of a difference. They will eventually be influenced by the broader Rust community and the Rust philosophy towards programming, but, unless they're already interested in changed approaches, this will be a small, gradual difference. So you'll end up with Enterprise Java™ code, just in Rust. But if you hire from the Rust community, you will get people who have a fundamentally different set of practices and expectations around programming. They will not only have a stronger grasp of Rust and Rust idioms but will also have explicit knowledge based on Rust (eg Rust-flavored design patterns and programming techniques) and, crucially, tacit knowledge based on Rust (Rust-flavored ways of programming that don't break down into easy-to-explain rules). And, roughly speaking, the same is going to be true for whatever other language you substitute for "Rust". (I say roughly because there doesn't have to be a 1:1 relationship between programming languages, schools of thought and communities of practice. A single language can have totally different communities—just compare web Python vs data scientist Python—and some communities/schools can span multiple languages. But, as an over-simplified model, seeing a language as a community is not the worst starting point.)
    - LtWorf 10mo ago
      Since currently 0% of developers started with rust, it would be interesting to know from which language these developers are actually migrating.
- IgorPartola 10mo ago
  Rust is also a systems language. I am still wrapping my mind around why it is so popular for so many end projects when its main use case and goals were basically writing a browser a maybe OS drivers. But that’s precisely why it is good for developer tools. And it turns out people who write systems code are really damn good at writing tools code. As someone who cut my teeth on C and low level systems stuff I really ought to learn Rust one of these days but Python is just so damn nice for high level stuff and all my embedded projects still seem to require C so here I am, rustless.
  - webstrand 10mo ago
    I write scripts in rust as a replacement for bash. Its really quite good at it. Aside from perl, its the only scripting language that can directly make syscalls. Its got great libraries for: parsing, configuration management, and declarative CLIs built right into it. Sure its a little more verbose than bash one-liners, but if you need any kind of error handling and recovery, its way more effective than bash and doesn't break when you switch platforms (i.e. mac/bsd utility incompatibilities with gnu utilities). My only complaint would be that dealing with OsString is more difficult than necessary. Way to much of the stdlib encourages programmers to just do "non-utf8 paths don't exist" and panic/ignore when encountering one. (Not a malady exclusive to rust, but I wish they'd gotten it right) Example I had handy: <https://gist.github.com/webstrand/945c738c5d60ffd7657845a6546901b3 https://gist.github.com/webstrand/945c738c5d60ffd7657845a654...>
    - SAI_Peregrinus 10mo ago
      Paths are hard because they usually look like printable text, but don't have to be text. POSIX filenames are octet strings not containing 0x2F or 0x00. They aren't required to contain any "printable" characters, or even be valid text in any particular encoding. Most of the Rust stdlib you're thinking of is for handling text strings, but paths aren't text strings. Python also has the same split between Pathlib paths & all other strings.
      - webstrand 10mo ago
Calavar 10mo ago
Paul Graham said the same thing about Python 20 years ago [1], and back then it was true. But once a programming langauge hits mainstream, this ceases to be a good filter. [1] https://paulgraham.com/pypar.html https://paulgraham.com/pypar.html
- jghn 10mo ago
  This is important. The benefit here isn't the language itself. It's the fact that you're pulling from an esoteric language. People should not overfit and feel that whichever language is achieving that effect today is special in this regard.
- discreteevent 10mo ago
  That was bullshit then and it's bullshit now but it sells very well to people who know a few programming languages (a lot of the people on this site)
- mkoubaa 10mo ago
  He was right. Python programmers are still the most likely to prioritize getting things done quickly.
  - tyre 10mo ago
    This is a pretty broad generalization! The fastest iterating people engineers I’ve worked with often have a deep user focus rather than a language affiliation.
  - rgoulter 10mo ago
    Eh. I think the cultural context has changed. In "python paradox", 'knows python' is an indication that the developer is interested in something technically interesting but otherwise impractical. Hence, it's a 'paradox' that you end up practically better off by selecting for something impractical. These days, Python is surely a practical choice, so doesn't really resemble the "interested in something technically interesting but impractical".
bri3d 10mo ago
It's an interesting debate. The flip side of this coin is getting hires who are more interested in the language or approach than the problem space and tend to either burn out, actively dislike the work at hand, or create problems that don't exist in order to use the language to solve them. With that said, Rust was a good language for this in my experience. Like any "interesting" thing, there was a moderate bit of language-nerd side quest thrown in, but overall, a good selection metric. I do think it's one of the best Rewrite it in X languages available today due to the availability of good developers with Rewrite in Rust project experience. The Haskell commentary is curious to me. I've used Haskell professionally but never tried to hire for it. With that said, the other FP-heavy languages that were popular ~2010-2015 were absolutely horrible for this in my experience. I generally subscribe to a vague notion that "skill in a more esoteric programming language will usually indicate a combination of ability to learn/plasticity and interest in the trade," however, using this concept, I had really bad experiences hiring both Scala and Clojure engineers; there was _way_ too much academic interest in language concepts and way too little practical interest in doing work. YMMV :)
- mannycalavera42 10mo ago
  Clojure engineers not interested in doing work? That's surprising
  - lll-o-lll 10mo ago
    When people say things like: > there was way too much academic interest in language concepts and way too little practical interest in doing work. They are communicating something real, but perhaps misattributing the root cause. The purely abstract ‘ideal’ form of software development is unconstrained by business requirements. In this abstraction, perfect software would be created to purely express an idea. Academia allows for this, and to a lesser extent some open source projects. In the real world, the creation of software must always be subordinate to the goals of the business. The goals are the purpose, and the software is the means. Languages that are academically interesting, unsurprisingly, attract a greater preponderance of academically minded individuals. Of these, only a percentage have the desire or ability to let go of the pure abstract, and instead focus on the business domain. So it inevitably creates a management challenge; not an insurmountable one, but a challenge. Hence the simplified ‘these people won’t do the work!’.

steve_adams_86 10mo ago

I'm my experience this is definitely where rust shined. The language wasn't really what made the project succeed so much as having relatively curious, meticulous, detail-oriented people on hand who were interested in solving hard problems. Sometimes I thought our teams would be a terrible fit for more cookie-cutter applications where rapid development and deployment was the primary objective. We got into the weeds all the time (sometimes because of rust itself), but it happened to be important to do so. Had we built those projects with JavaScript or Python I suspect the outcomes would have been worse for reasons apart from the language choice.

zahlman 10mo ago
> having relatively curious, meticulous, detail-oriented people on hand who were interested in solving hard problems.... Had we built those projects with JavaScript or Python I suspect the outcomes would have been worse for reasons apart from the language choice. I genuinely can't understand why you suppose that has to do with the implementation language at all.
- KPGv2 10mo ago
  > I genuinely can't understand why you suppose that has to do with the implementation language at all. Languages that attract novice programmers (JS is an obvious one; PHP was one 20 years ago) have a higher noise to signal ratio than one that attracts intermediate and above programmers. If you grabbed an average Assembly programmer today, and an average JavaScript programmer today, who do you think is more careful about programming? The one who needs to learn arcane shit to do basic things and then has to compile it in order to test it out, or the one who can open up Chrome's console and console.log("i love boobies") How many embedded systems programmers suck vs full stack devs? I'm not saying full stack devs are inferior. I'm saying that more inferior coders are attracted to the latter because the barriers to entry are SO much easier to bypass.
  - zahlman 10mo ago
    Sure, but that kind of incompetence is already filtered out (in the https://www.lesswrong.com/w/screening-off-evidence https://www.lesswrong.com/w/screening-off-evidence sense) by the task of creating a package installer.
    - IgorPartola 10mo ago
      You would think so, yet here I am sitting with a node_modules full of crud placed there by npm, waiting for the next supply chain attack.
      - zahlman 10mo ago
        That argument is FUD. The people who created the NPM package manager are not the people who wrote your dependencies. Further, supply chain attacks occur for reasons that are entirely outside NPM's control. Fundamentally they're a matter of trust in the ecosystem — in the very idea of installing the packages in the first place.
        firesteelrain 10mo ago
        Lack of stronger trust controls are part of the larger issue with npm. Pip, Maven and Go are not immune either but they do things structurally better to shift the problem. Go: Enforces global, append-only integrity via a checksum database and version immutability; once a module version exists, its contents cannot be silently altered without detection, shifting attacks away from artifact substitution toward “publish a malicious new version” or bypass the proxy/sumdb. Maven: Requires structured namespace ownership and signed artifacts, making identity more explicit at publish time; this raises the bar for casual impersonation but still fundamentally trusts that the key holder and build pipeline were not compromised.
        Mawr 10mo ago
        For Go, there are more impactful features: minimal version selection and the culture of fewer, but larger dependencies. Your average Go project likely has 10x fewer deps than a JS project. Those deps will not get auto-updated to their latest versions either. Much lower attack surface area.
- tikhonj 10mo ago
  Different programming languages come with different schools of thought about programming and different communities of practice around programming. If you take a group of people who are squarely in the enterprise Java school of thought and have them write Rust, the language won't make much of a difference. They will eventually be influenced by the broader Rust community and the Rust philosophy towards programming, but, unless they're already interested in changed approaches, this will be a small, gradual difference. So you'll end up with Enterprise Java™ code, just in Rust. But if you hire from the Rust community, you will get people who have a fundamentally different set of practices and expectations around programming. They will not only have a stronger grasp of Rust and Rust idioms but will also have explicit knowledge based on Rust (eg Rust-flavored design patterns and programming techniques) and, crucially, tacit knowledge based on Rust (Rust-flavored ways of programming that don't break down into easy-to-explain rules). And, roughly speaking, the same is going to be true for whatever other language you substitute for "Rust". (I say roughly because there doesn't have to be a 1:1 relationship between programming languages, schools of thought and communities of practice. A single language can have totally different communities—just compare web Python vs data scientist Python—and some communities/schools can span multiple languages. But, as an over-simplified model, seeing a language as a community is not the worst starting point.)
  - LtWorf 10mo ago
    Since currently 0% of developers started with rust, it would be interesting to know from which language these developers are actually migrating.
IgorPartola 10mo ago
Rust is also a systems language. I am still wrapping my mind around why it is so popular for so many end projects when its main use case and goals were basically writing a browser a maybe OS drivers. But that’s precisely why it is good for developer tools. And it turns out people who write systems code are really damn good at writing tools code. As someone who cut my teeth on C and low level systems stuff I really ought to learn Rust one of these days but Python is just so damn nice for high level stuff and all my embedded projects still seem to require C so here I am, rustless.
- webstrand 10mo ago
  I write scripts in rust as a replacement for bash. Its really quite good at it. Aside from perl, its the only scripting language that can directly make syscalls. Its got great libraries for: parsing, configuration management, and declarative CLIs built right into it. Sure its a little more verbose than bash one-liners, but if you need any kind of error handling and recovery, its way more effective than bash and doesn't break when you switch platforms (i.e. mac/bsd utility incompatibilities with gnu utilities). My only complaint would be that dealing with OsString is more difficult than necessary. Way to much of the stdlib encourages programmers to just do "non-utf8 paths don't exist" and panic/ignore when encountering one. (Not a malady exclusive to rust, but I wish they'd gotten it right) Example I had handy: <https://gist.github.com/webstrand/945c738c5d60ffd7657845a6546901b3 https://gist.github.com/webstrand/945c738c5d60ffd7657845a654...>
  - SAI_Peregrinus 10mo ago
    Paths are hard because they usually look like printable text, but don't have to be text. POSIX filenames are octet strings not containing 0x2F or 0x00. They aren't required to contain any "printable" characters, or even be valid text in any particular encoding. Most of the Rust stdlib you're thinking of is for handling text strings, but paths aren't text strings. Python also has the same split between Pathlib paths & all other strings.
    - webstrand 10mo ago

Calavar 10mo ago

Paul Graham said the same thing about Python 20 years ago [1], and back then it was true. But once a programming langauge hits mainstream, this ceases to be a good filter. [1] https://paulgraham.com/pypar.html https://paulgraham.com/pypar.html

jghn 10mo ago
This is important. The benefit here isn't the language itself. It's the fact that you're pulling from an esoteric language. People should not overfit and feel that whichever language is achieving that effect today is special in this regard.
discreteevent 10mo ago
That was bullshit then and it's bullshit now but it sells very well to people who know a few programming languages (a lot of the people on this site)
mkoubaa 10mo ago
He was right. Python programmers are still the most likely to prioritize getting things done quickly.
- tyre 10mo ago
  This is a pretty broad generalization! The fastest iterating people engineers I’ve worked with often have a deep user focus rather than a language affiliation.
- rgoulter 10mo ago
  Eh. I think the cultural context has changed. In "python paradox", 'knows python' is an indication that the developer is interested in something technically interesting but otherwise impractical. Hence, it's a 'paradox' that you end up practically better off by selecting for something impractical. These days, Python is surely a practical choice, so doesn't really resemble the "interested in something technically interesting but impractical".

bri3d 10mo ago

It's an interesting debate. The flip side of this coin is getting hires who are more interested in the language or approach than the problem space and tend to either burn out, actively dislike the work at hand, or create problems that don't exist in order to use the language to solve them. With that said, Rust was a good language for this in my experience. Like any "interesting" thing, there was a moderate bit of language-nerd side quest thrown in, but overall, a good selection metric. I do think it's one of the best Rewrite it in X languages available today due to the availability of good developers with Rewrite in Rust project experience. The Haskell commentary is curious to me. I've used Haskell professionally but never tried to hire for it. With that said, the other FP-heavy languages that were popular ~2010-2015 were absolutely horrible for this in my experience. I generally subscribe to a vague notion that "skill in a more esoteric programming language will usually indicate a combination of ability to learn/plasticity and interest in the trade," however, using this concept, I had really bad experiences hiring both Scala and Clojure engineers; there was _way_ too much academic interest in language concepts and way too little practical interest in doing work. YMMV :)

mannycalavera42 10mo ago
Clojure engineers not interested in doing work? That's surprising
- lll-o-lll 10mo ago
  When people say things like: > there was way too much academic interest in language concepts and way too little practical interest in doing work. They are communicating something real, but perhaps misattributing the root cause. The purely abstract ‘ideal’ form of software development is unconstrained by business requirements. In this abstraction, perfect software would be created to purely express an idea. Academia allows for this, and to a lesser extent some open source projects. In the real world, the creation of software must always be subordinate to the goals of the business. The goals are the purpose, and the software is the means. Languages that are academically interesting, unsurprisingly, attract a greater preponderance of academically minded individuals. Of these, only a percentage have the desire or ability to let go of the pure abstract, and instead focus on the business domain. So it inevitably creates a management challenge; not an insurmountable one, but a challenge. Hence the simplified ‘these people won’t do the work!’.