4 ms·

I have no problem with people rewriting their projects in whatever language they see fit. What stood out for me in the article is him saying that it's difficul

I have no problem with people rewriting their projects in whatever language they see fit. What stood out for me in the article is him saying that it's difficult getting developers with experience in both Python and C++. So, I wonder, if his in-house devs could pick up Rust that they previously couldn't write, why does he think he can not hire a good programmer and charge him to learn the stack the company uses. Why must they employ someone that already writes Python or C++. Is Rust such a straight-forward language that people new to the language can write a very performant programme

arriu 4y ago
I agree, rust has a difficult learning curve. I’ve often heard at least a year is required to really feel confident.
- gotts 4y ago
  6 months is what I heard. I'm currently at ~2 and 6 sounds like a pretty good estimate.
- heavyset_go 4y ago
  It takes a relatively short time to be proficient enough to make useful contributions, maybe half a year to a year to be confident. You can give an experienced developer the Rust book and have them contributing to a Rust codebase quickly.
- nicoburns 4y ago
  For me it was ~2 weeks to get out of "learning mode" and into actually writing production code. 3 months to feel proficient. Maybe a year to feel that I had reached parity of fluency with languages I already knew.
- tialaramex 4y ago
  People really vary, it felt natural to me almost immediately but Rust's surveys indicate that some noticeable proportion of respondents report not being comfortable after more than a year. This is seen as an important thing to improve because of the slogan "A language empowering everyone to build reliable and efficient software". If Rust isn't empowering everyone because say, 10% of people who try to pick it up can't get anywhere that's not good enough.
pornel 4y ago
Despite Rust's steep learning curve, it's also paradoxically easy to add novice Rust programmers to a project. This is because inexperienced Rust programmers are relatively harmless. Noob mistakes won't compile, rather than running into dangerous gotchas. You can tell noobs not to use `unsafe` (and there are ways to enforce that), and mostly they'll just write inefficient or non-idiomatic code, but the code will be free from data races and memory corruption. The strictness of the Rust compiler is quite the opposite of something like the C++ Core Guidelines where the majority of the rules aren't enforced by the compiler, and have to be in the programmers' head first. Noobs make lifetime errors and fight the Rust compiler, but imagine working with a compiler that doesn't tell you when you have lifetime errors.
- krona 4y ago
  Memory sanitizers, address sanitizers, leak sanitizers, threading sanitizers, undefined behaviour sanitizers. The visual studio core guidelines checker. The clang-tidy core guideline checker. I could go on but my point is, the landscape does not really look like how you've painted it.
  - abc_lisper 4y ago
    Yeah, but Rust guarantees sanity by design. Sanitizers are a patch, and hence not comprehensive.
  - lijogdfljk 4y ago
    They painted it like reality, though, no? You seem to paint the landscape as full of tools and imply that they're used. Either they're insufficient or they're often under utilized, simply due to the number of bugs we see. No?
  - pornel 4y ago
    I know about these, but there is a marked difference between Rust and these tools. Static analysis tools have much harder job analyzing C++ (aliasing and escape analysis are way harder, and static analysis of thread-safety is basically impossible due to lack of thread-safety info in the type system). The results are a trade-off between being sparse or having false positives. The sanitizers only catch issues they can observe at run time, and that relies on having sufficient test and fuzz coverage. Some data races are incredibly hard to reproduce, and might depend on a timing difference that won't happen in your test harness. OTOH Rust proves absence of these issues by construction, at compile time. It's like a difference between dynamically-typed and statically-typed languages. Sure, you can fuzz type errors out of JS or Python, but in statically-typed languages such errors are eliminated entirely at compile time. Rust extends this experience to more classes of errors.
dymk 4y ago
It takes longer to learn how to use C++ to the same level of proficiency and correctness compared to Rust, in my experience. It's harder to write an incorrect program in Rust.
- lupire 4y ago
  What are the main correctness risks in C++ if you just never use a raw pointer?
  - mamcx 4y ago
    Well... UNSAFE { // TODO: Verify all the lines, all the time, are ok // Just like you do testing, documentation, security and all that // ok? #include <iostream> using namespace std; int main() { // YOUR CODE } }
    - lupire 4y ago
      What are you saying?
      - mamcx 4y ago
        Well if the questions is: > What are the main correctness risks in C++ if you just never use a raw pointer? All the code on C/C++ IS a correctness "risks". Only constant, manual inspection could(maybe) say otherwise. What Rust gives is significant reduction of the risks.
  - bcrosby95 4y ago
    One thing off the top of my head, from experience: std::string s(s); To be fair, compilers will warn you about this nowadays. But when I converted a C codebase to C++ 20 years ago they didn't. IIRC, references can also refer to de-allocated memory. Also, if you don't pass-by-reference or pointer, you can literally "slice" the dynamic doohickies off your instance so your AlbinoCat behaves like a Cat because all that extra special stuff is gone as far as the function is concerned. This is just off the top of my head after not working with C++ for 20 years. I'm sure with all the new features it's gained over the past 20 years theres whole new exciting ways to blow your leg off.
ekidd 4y ago
I've written quite a bit of production code in C++, Python and Rust, and currently work on a hybrid Rust/Python system. Here's my experience: - C++ is an unusually large language. And it has many historic footguns, requiring a higher level of vigilance and code review. If I were starting a brand new project today, I wouldn't try to build a team of C++ programmers. - Untyped Python becomes more difficult to refactor and maintain once you reach 50k to 80k lines on a group project. Typed Python, however, scales nicely beyond this size. - Rust is a "medium-sized" language. It requires developers to learn more than Go or Python does, but less than C++. And Rust has far fewer traps for the unwary and the reckless than C++. Rust's tooling is also very good in many areas. - It's tempting to split a project into a fast "core" language, and high-level "glue" language. There are real advantages to this. (Which is why I've done it on one recent project!) But this also comes with costs: everyone needs to be fairly good at two languages, and switch back and forth. And you pay a tax at the boundary. If I were building a brand new database (and a team to maintain it), I'd actually be strongly tempted to use Rust exclusively. But this is partly because databases rarely have a "business logic" layer that changes constantly, so there's less need for a high level scripting language. But with a different team or different constraints, C++ could also be the right choice.
- hutzlibu 4y ago
  "But this also comes with costs: everyone needs to be fairly good at two languages, and switch back and forth." Why does everyone needs to be good at both languages? You can seperate and have the core people writing efficient low level code - and you have higher level scripting/gluing code.
  - pornel 4y ago
    You will have Conway's law in your codebase. Coordination between teams is hard, so teams will prefer to implement features entirely in their language, even where that is technically suboptimal. You will get hot loops in Python, because a Rust programmer wasn't around, and Rust programmers implementing whole complex business logic in Rust behind a single `do_it()` Python call.
heavyset_go 4y ago
The footgun-to-appropriate-feature ratio is higher with C++ than Rust. Rust also has some excellent Python integration options that are relatively easy to use.
MisterTea 4y ago
> What stood out for me in the article is him saying that it's difficult getting developers with experience in both Python and C++. More like they had difficulty finding cheap experienced c++/python devs.
nicoburns 4y ago
> Is Rust such a straight-forward language that people new to the language can write a very performant programme Yes. At least that was my experience coming to Rust from a primarily JavaScript background. My first Rust program wasn't as fast as it could have been (I know a lot more about optimising programs now than I did then), but it was still ~30x faster than the JavaScript and Pythons versions my company had attempted to write first. That's without putting all that much effort into optimising it.
LarsDu88 4y ago
I'm 3 weeks into Rust, and I've found it easy to get over an initial hump. I think where it becomes difficult is in thinking about smart pointers like Rc, RefCell, Arc, etc -- stuff I haven't even encountered yet. For things like certain popular leetcode questions, these concepts become more valuable.
SleepyMyroslav 4y ago
>a very performant programme You might need to define what is "very performant". I come from C++ performance work side in games. Typical C++ is ~10 times slower than optimized C++. And optimized C++ is sometimes ~2-10 times slower than what game hardware can do. What limits many projects is that cost of going to 'next level' of performance is also nonlinear. Where is on this scale Rust code written by new to the language?

arriu 4y ago

I agree, rust has a difficult learning curve. I’ve often heard at least a year is required to really feel confident.

gotts 4y ago
6 months is what I heard. I'm currently at ~2 and 6 sounds like a pretty good estimate.
heavyset_go 4y ago
It takes a relatively short time to be proficient enough to make useful contributions, maybe half a year to a year to be confident. You can give an experienced developer the Rust book and have them contributing to a Rust codebase quickly.
nicoburns 4y ago
For me it was ~2 weeks to get out of "learning mode" and into actually writing production code. 3 months to feel proficient. Maybe a year to feel that I had reached parity of fluency with languages I already knew.
tialaramex 4y ago
People really vary, it felt natural to me almost immediately but Rust's surveys indicate that some noticeable proportion of respondents report not being comfortable after more than a year. This is seen as an important thing to improve because of the slogan "A language empowering everyone to build reliable and efficient software". If Rust isn't empowering everyone because say, 10% of people who try to pick it up can't get anywhere that's not good enough.

pornel 4y ago

Despite Rust's steep learning curve, it's also paradoxically easy to add novice Rust programmers to a project. This is because inexperienced Rust programmers are relatively harmless. Noob mistakes won't compile, rather than running into dangerous gotchas. You can tell noobs not to use `unsafe` (and there are ways to enforce that), and mostly they'll just write inefficient or non-idiomatic code, but the code will be free from data races and memory corruption. The strictness of the Rust compiler is quite the opposite of something like the C++ Core Guidelines where the majority of the rules aren't enforced by the compiler, and have to be in the programmers' head first. Noobs make lifetime errors and fight the Rust compiler, but imagine working with a compiler that doesn't tell you when you have lifetime errors.

krona 4y ago
Memory sanitizers, address sanitizers, leak sanitizers, threading sanitizers, undefined behaviour sanitizers. The visual studio core guidelines checker. The clang-tidy core guideline checker. I could go on but my point is, the landscape does not really look like how you've painted it.
- abc_lisper 4y ago
  Yeah, but Rust guarantees sanity by design. Sanitizers are a patch, and hence not comprehensive.
- lijogdfljk 4y ago
  They painted it like reality, though, no? You seem to paint the landscape as full of tools and imply that they're used. Either they're insufficient or they're often under utilized, simply due to the number of bugs we see. No?
- pornel 4y ago
  I know about these, but there is a marked difference between Rust and these tools. Static analysis tools have much harder job analyzing C++ (aliasing and escape analysis are way harder, and static analysis of thread-safety is basically impossible due to lack of thread-safety info in the type system). The results are a trade-off between being sparse or having false positives. The sanitizers only catch issues they can observe at run time, and that relies on having sufficient test and fuzz coverage. Some data races are incredibly hard to reproduce, and might depend on a timing difference that won't happen in your test harness. OTOH Rust proves absence of these issues by construction, at compile time. It's like a difference between dynamically-typed and statically-typed languages. Sure, you can fuzz type errors out of JS or Python, but in statically-typed languages such errors are eliminated entirely at compile time. Rust extends this experience to more classes of errors.

dymk 4y ago

It takes longer to learn how to use C++ to the same level of proficiency and correctness compared to Rust, in my experience. It's harder to write an incorrect program in Rust.

lupire 4y ago
What are the main correctness risks in C++ if you just never use a raw pointer?
- mamcx 4y ago
  Well... UNSAFE { // TODO: Verify all the lines, all the time, are ok // Just like you do testing, documentation, security and all that // ok? #include <iostream> using namespace std; int main() { // YOUR CODE } }
  - lupire 4y ago
    What are you saying?
    - mamcx 4y ago
      Well if the questions is: > What are the main correctness risks in C++ if you just never use a raw pointer? All the code on C/C++ IS a correctness "risks". Only constant, manual inspection could(maybe) say otherwise. What Rust gives is significant reduction of the risks.
- bcrosby95 4y ago
  One thing off the top of my head, from experience: std::string s(s); To be fair, compilers will warn you about this nowadays. But when I converted a C codebase to C++ 20 years ago they didn't. IIRC, references can also refer to de-allocated memory. Also, if you don't pass-by-reference or pointer, you can literally "slice" the dynamic doohickies off your instance so your AlbinoCat behaves like a Cat because all that extra special stuff is gone as far as the function is concerned. This is just off the top of my head after not working with C++ for 20 years. I'm sure with all the new features it's gained over the past 20 years theres whole new exciting ways to blow your leg off.

ekidd 4y ago

I've written quite a bit of production code in C++, Python and Rust, and currently work on a hybrid Rust/Python system. Here's my experience: - C++ is an unusually large language. And it has many historic footguns, requiring a higher level of vigilance and code review. If I were starting a brand new project today, I wouldn't try to build a team of C++ programmers. - Untyped Python becomes more difficult to refactor and maintain once you reach 50k to 80k lines on a group project. Typed Python, however, scales nicely beyond this size. - Rust is a "medium-sized" language. It requires developers to learn more than Go or Python does, but less than C++. And Rust has far fewer traps for the unwary and the reckless than C++. Rust's tooling is also very good in many areas. - It's tempting to split a project into a fast "core" language, and high-level "glue" language. There are real advantages to this. (Which is why I've done it on one recent project!) But this also comes with costs: everyone needs to be fairly good at two languages, and switch back and forth. And you pay a tax at the boundary. If I were building a brand new database (and a team to maintain it), I'd actually be strongly tempted to use Rust exclusively. But this is partly because databases rarely have a "business logic" layer that changes constantly, so there's less need for a high level scripting language. But with a different team or different constraints, C++ could also be the right choice.

hutzlibu 4y ago
"But this also comes with costs: everyone needs to be fairly good at two languages, and switch back and forth." Why does everyone needs to be good at both languages? You can seperate and have the core people writing efficient low level code - and you have higher level scripting/gluing code.
- pornel 4y ago
  You will have Conway's law in your codebase. Coordination between teams is hard, so teams will prefer to implement features entirely in their language, even where that is technically suboptimal. You will get hot loops in Python, because a Rust programmer wasn't around, and Rust programmers implementing whole complex business logic in Rust behind a single `do_it()` Python call.

heavyset_go 4y ago

The footgun-to-appropriate-feature ratio is higher with C++ than Rust. Rust also has some excellent Python integration options that are relatively easy to use.

MisterTea 4y ago

> What stood out for me in the article is him saying that it's difficult getting developers with experience in both Python and C++. More like they had difficulty finding cheap experienced c++/python devs.

nicoburns 4y ago

> Is Rust such a straight-forward language that people new to the language can write a very performant programme Yes. At least that was my experience coming to Rust from a primarily JavaScript background. My first Rust program wasn't as fast as it could have been (I know a lot more about optimising programs now than I did then), but it was still ~30x faster than the JavaScript and Pythons versions my company had attempted to write first. That's without putting all that much effort into optimising it.

LarsDu88 4y ago

I'm 3 weeks into Rust, and I've found it easy to get over an initial hump. I think where it becomes difficult is in thinking about smart pointers like Rc, RefCell, Arc, etc -- stuff I haven't even encountered yet. For things like certain popular leetcode questions, these concepts become more valuable.

SleepyMyroslav 4y ago

>a very performant programme You might need to define what is "very performant". I come from C++ performance work side in games. Typical C++ is ~10 times slower than optimized C++. And optimized C++ is sometimes ~2-10 times slower than what game hardware can do. What limits many projects is that cost of going to 'next level' of performance is also nonlinear. Where is on this scale Rust code written by new to the language?