3 ms·

> The biggest barrier to adoption, in my opinion, is that people are scared of learning Rust because it has a reputation as being difficult. I would say the bi

> The biggest barrier to adoption, in my opinion, is that people are scared of learning Rust because it has a reputation as being difficult. I would say the biggest barrier is developers not wanting to jump on yet another "this language will solve all your problems, trust me" train. My experience in my 15 years in software, is that good developers solve problems, not languages or tools.

zozbot234 5y ago
The languages available today are a vast improvement over what was around 15 years ago. This isn't even all that specific to Rust, even many languages which existed back then have improved massively.
- pjmlp 5y ago
  Many of which still have some catchup to do regarding Delphi, C++ Builder, Eiffel, Smalltalk and Common Lisp.
layoutIfNeeded 5y ago
>I would say the biggest barrier is developers not wanting to jump on yet another "this language will solve all your problems, trust me" train. Never underestimate what a team of overly enthusiastic junior engineers are capable of :-)
- krapht 5y ago
  There's got to be a middle ground somewhere. I've worked in many places where the tech stack fossilizes because the ROE of learning how to use new, more productive tooling is too much effort for the senior devs compared to their existing responsibilities, many of which are non-technical in nature. Meanwhile the junior-intermediate devs spend most of their working hours writing code, so they are extremely sensitive to the 5-10% productivity bump that could be gotten by using {nicer language, better build system, static analysis tooling/sanitizers, ${TOOLING_IMPROVEMENT}. I'm talking real advances in productivity. Imagine working on a C++98 codebase today in 2021 because you're working on a very large industrial product that's been around for decades. It can be demoralizing, like having to write COBOL or FORTRAN.
Ar-Curunir 5y ago
Right, it’s not like Rust has already influenced improvements in other languages and package managers. Definitely a fad
- pjmlp 5y ago
  Making other languages take affine times more seriously, I agree. Package managers, which ones? Perl was the very first, almost every language has their own, and even the growing C++ ones are able to use binary libraries on their package managers.
  - iudqnolq 5y ago
    Rust's package manager has many great features, but it went the other way around. Mozilla hired one of the authors of rubygems and yarn to re-implement their better ideas.
    - steveklabnik 5y ago
      This is true, but so is the grandparent. Poetry, for example, cites Cargo as an inspiration. build2 describes itself as something "that aims to approximate Rust Cargo's convenience for developing and packaging C/C++ projects." I believe Go's "dep" was Cargo inspired as well, though that didn't work out.
    - monoideism 5y ago
      Yarn came after cargo was started, I'm fairly sure.
  - staticassertion 5y ago
    > Package managers, which ones? Python's Poetry comes to mind.
  - monoideism 5y ago
    Among package manager + build tool devs I know, cargo is considered by most I know (maybe 2-3) to be best-of-class. In terms of influences, here's an OCaml attempt to replicate cargo (I wish them well): https://github.com/OCamlPro/drom https://github.com/OCamlPro/drom Klabnik also mentioned Python's poetry below. Yarn as well, since Yehuda Katz was involved. Note: I seem to recall you're an Ada dev, so I should mention that as far as build tools go, I've always really appreciated gprbuild, which is far superior to other build tools of its vintage. If it had a built-in package manager like cargo, it could compete with cargo.
carlhjerpe 5y ago
Languages and tools have helped people write better software over the years, no?
staticassertion 5y ago
I really like Tony Hoare's quote on this topic: ... a programming language designer should be responsible for the mistakes that are made by the programmers using the language. [...] It's very easy to persuade the customers of your language that everything that goes wrong is their fault and not yours. I rejected that... http://blog.mattcallanan.net/2010/09/tony-hoare-billion-dollar-mistake.html http://blog.mattcallanan.net/2010/09/tony-hoare-billion-doll... If anyone is unfamiliar with Tony Hoare he's the creator of quicksort, Hoare Logic, CSP, worked on Algol, created null, holds a turing award, and much more.
phkahler 5y ago
>> My experience in my 15 years in software, is that good developers solve problems, not languages or tools. At 15 years I thought the same. At 25 years I have come to really appreciate some tools ability to help. There are a lot of tools that claim to help but don't. Beware of tools that try to manage complexity - what you probably need is to reduce complexity. I'm looking at Eclipse and Matlab in particular, and anything similar (think enterprise software). Git - awesome. Using it on 1-man projects too. Sanitizers for C++ I've seen these identify bugs that hadn't manifested visibly yet. Rust - well I want to write more because it doesnt require additional tooling to write correct code. Remember reducing complexity.
- kortex 5y ago
  >>> good developers solve problems, not languages or tools >> At 25 years I have come to really appreciate some tools ability to help. I've come to find there is a bidirectional connection between good developers and their tools. Good devs recognize and gravitate towards systems that help them thrive, and away from painful ones. Good tools draw in good devs, and the community gets stronger as a result. IMHO, One hallmark of less-than-stellar devs is a tendency to stick with tools they are familiar with, because "it works." Great devs could get by with a magnetized needle and a steady hand, but they know there is better out there.

zozbot234 5y ago

The languages available today are a vast improvement over what was around 15 years ago. This isn't even all that specific to Rust, even many languages which existed back then have improved massively.

pjmlp 5y ago
Many of which still have some catchup to do regarding Delphi, C++ Builder, Eiffel, Smalltalk and Common Lisp.

layoutIfNeeded 5y ago

>I would say the biggest barrier is developers not wanting to jump on yet another "this language will solve all your problems, trust me" train. Never underestimate what a team of overly enthusiastic junior engineers are capable of :-)

krapht 5y ago
There's got to be a middle ground somewhere. I've worked in many places where the tech stack fossilizes because the ROE of learning how to use new, more productive tooling is too much effort for the senior devs compared to their existing responsibilities, many of which are non-technical in nature. Meanwhile the junior-intermediate devs spend most of their working hours writing code, so they are extremely sensitive to the 5-10% productivity bump that could be gotten by using {nicer language, better build system, static analysis tooling/sanitizers, ${TOOLING_IMPROVEMENT}. I'm talking real advances in productivity. Imagine working on a C++98 codebase today in 2021 because you're working on a very large industrial product that's been around for decades. It can be demoralizing, like having to write COBOL or FORTRAN.

Ar-Curunir 5y ago

Right, it’s not like Rust has already influenced improvements in other languages and package managers. Definitely a fad

pjmlp 5y ago
Making other languages take affine times more seriously, I agree. Package managers, which ones? Perl was the very first, almost every language has their own, and even the growing C++ ones are able to use binary libraries on their package managers.
- iudqnolq 5y ago
  Rust's package manager has many great features, but it went the other way around. Mozilla hired one of the authors of rubygems and yarn to re-implement their better ideas.
  - steveklabnik 5y ago
    This is true, but so is the grandparent. Poetry, for example, cites Cargo as an inspiration. build2 describes itself as something "that aims to approximate Rust Cargo's convenience for developing and packaging C/C++ projects." I believe Go's "dep" was Cargo inspired as well, though that didn't work out.
  - monoideism 5y ago
    Yarn came after cargo was started, I'm fairly sure.
- staticassertion 5y ago
  > Package managers, which ones? Python's Poetry comes to mind.
- monoideism 5y ago
  Among package manager + build tool devs I know, cargo is considered by most I know (maybe 2-3) to be best-of-class. In terms of influences, here's an OCaml attempt to replicate cargo (I wish them well): https://github.com/OCamlPro/drom https://github.com/OCamlPro/drom Klabnik also mentioned Python's poetry below. Yarn as well, since Yehuda Katz was involved. Note: I seem to recall you're an Ada dev, so I should mention that as far as build tools go, I've always really appreciated gprbuild, which is far superior to other build tools of its vintage. If it had a built-in package manager like cargo, it could compete with cargo.

carlhjerpe 5y ago

Languages and tools have helped people write better software over the years, no?

staticassertion 5y ago

I really like Tony Hoare's quote on this topic: ... a programming language designer should be responsible for the mistakes that are made by the programmers using the language. [...] It's very easy to persuade the customers of your language that everything that goes wrong is their fault and not yours. I rejected that... http://blog.mattcallanan.net/2010/09/tony-hoare-billion-dollar-mistake.html http://blog.mattcallanan.net/2010/09/tony-hoare-billion-doll... If anyone is unfamiliar with Tony Hoare he's the creator of quicksort, Hoare Logic, CSP, worked on Algol, created null, holds a turing award, and much more.

phkahler 5y ago

>> My experience in my 15 years in software, is that good developers solve problems, not languages or tools. At 15 years I thought the same. At 25 years I have come to really appreciate some tools ability to help. There are a lot of tools that claim to help but don't. Beware of tools that try to manage complexity - what you probably need is to reduce complexity. I'm looking at Eclipse and Matlab in particular, and anything similar (think enterprise software). Git - awesome. Using it on 1-man projects too. Sanitizers for C++ I've seen these identify bugs that hadn't manifested visibly yet. Rust - well I want to write more because it doesnt require additional tooling to write correct code. Remember reducing complexity.

kortex 5y ago
>>> good developers solve problems, not languages or tools >> At 25 years I have come to really appreciate some tools ability to help. I've come to find there is a bidirectional connection between good developers and their tools. Good devs recognize and gravitate towards systems that help them thrive, and away from painful ones. Good tools draw in good devs, and the community gets stronger as a result. IMHO, One hallmark of less-than-stellar devs is a tendency to stick with tools they are familiar with, because "it works." Great devs could get by with a magnetized needle and a steady hand, but they know there is better out there.