9 ms·

Not sure if rust is significantly harder to learn than Go, but as a Java dev I was able to pickup go and make contributions in around a week or so. Yeah I was s

Not sure if rust is significantly harder to learn than Go, but as a Java dev I was able to pickup go and make contributions in around a week or so. Yeah I was slower, but we had some really good Go devs who had all of the tooling and packages laid out with best practices. This made it easy for new devs to jump into it. I think the issue happens when you have a new rust/go/javascript/etc. dev trying to setup a project for the first time.

moonchrome 4y ago
Yes Rust is significantly harder than go. It's diametrically opposite if there was a circle of complexity. I honestly have no clue how someone without low level experience (eg. never did systems level programming) even approaches Rust. The ownership model makes sense to me but if I had to grok manual memory management and rust abstractions on top of it at the same time I think I would be unable to contribute even trivial stuff for a month. Oh and coming from a dynamic language background at that ? Not saying can't be done just saying time till contributing is probably weeks-months. With go it's probably days.
- iudqnolq 4y ago
  > I honestly have no clue how someone without low level experience (eg. never did systems level programming) even approaches Rust. In my personal experience you do this by writing your programs in such a way as not to require complex ownership. I had an easy time writing web services where the only cross-request shared state was a database handle. I had a hard time when I had to write a websocket document sync serverwhere I needed per-document global state shared between all the handlers, and I eventually gave up and moved to a model where a language with an easier concurrency story called rust code.
  - phamilton 4y ago
    This. Implementing an http endpoint is pretty straightforward. Newcomers may struggle with copy vs reference semantics (and that just takes time), but otherwise it's not too different from other statically typed http work. You define your input/output structs, you grab a database connection, you perform a query, and return it. No lifetimes. No Arcs or Mutexes or Rc or RefCell. We generally consider our rust backend as two parts: application code and library code. We intend for our application code to be approachable by full stack developers and not require deep rust expertise to use. Our library code can be a bit more complicated, and there we see a bigger ramp up and frankly some self selection among our team and that's fine.
- nicoburns 4y ago
  > I honestly have no clue how someone without low level experience (eg. never did systems level programming) even approaches Rust. I started by reading the Rust Book. It explains most of the low-level concepts. It took me about a week of mostly just learning and experimenting, and another ~3 weeks until I had an MVP of my system. But from there it was just another 2 months until I had a full system written and in production, which it would probably have taken in another language anyway (as the project involved a lot of trial and error reversing a (simple but) only partially documented format). Perhaps it helps that I came from JavaScript where a lot of the abstractions are similar.
- molodec 4y ago
  Curious what modern schools teach in Computer Science programs. I went to Salisbury State University 17 years ago, and we had classes on assembly language, system programming and operating systems where we used C, algorithms classes with assignments in C++, computer graphics, which of course also C++. My professional experience working in industry was primarily in Java, but also some C, Python, Ruby. Learning Rust was not without a challenge, but having a lot of programming in C/C++ in school more than 10 years ago helped a lot. My assumption that all software engineers who have university degree should have some experience in system programming.
  - sophiabits 4y ago
    At my university the language used for teaching was predominantly Java, with Python or C# used in some papers. There was an optional operating systems paper which had you writing some assembly to run on an in-house RISC system [1], but a small % of CS+SE students took that paper. I think they’re trending towards using Python for most papers now. Not unreasonable for a paper on data mining or web development, but there’s definitely something being lost where students don’t /need/ to understand how the computer’s working in order to get a passing grade, so there’s no real incentive to dig deeper for the average student. [1] https://wramp.wand.nz/ https://wramp.wand.nz/
  - tialaramex 4y ago
    The University I work for teaches Java in Programming I (the mandatory introductory language) for Computer Scientists, and teaches them some C in Programming II and then a functional language, typically Haskell, and potentially some Rust, Typescript, whatever by the third year as some of the students will be pursuing Theory. The Electronics students learn C at the beginning meanwhile. Students elsewhere in the university learn mostly Python and R.
- coldtea 4y ago
  >I honestly have no clue how someone without low level experience (eg. never did systems level programming) even approaches Rust. Far easier than the way anyone without low level experience (which meant almost everybody starting out) approached learning C and C+, back when Java, C#, Python, Perl etc were not yet a thing, and you got either got directly into C/C++ or started with PASCAL and BASIC if you were lucky. Oh, and no IDES, internet, stack overflow, or forums either...
  - moonchrome 4y ago
    I mean I wouldn't recommend anyone do that either. Doubt you'll find many C++ roles taking people without experience either.
tptacek 4y ago
Go is garbage collected. It is significantly easier to write than Rust --- it's not just easier to learn, but easier for experts to write, because it's doing a bunch of work for the developer that Rust doesn't. On the other hand, if you need manual memory management (for performance reasons, or because you're doing something bare-metal), you'll be fighting Go's garbage collector, and Rust has conveniences for manual memory management that Go doesn't.
- DominoTree 4y ago
  Go is quite arguably a worse language though, including certain fundamental cornerstones of modern web development. Ever tried to see what fields a JSON payload contains in an "idiomatic" way before casting it to a type in Go? It's all interface{} (now Any) and reflection. If we're talking about developers new to a language, I'd argue that Rust's type system is easier to grok than the cases you may need to account for in Go.
  - tptacek 4y ago
    I'm not interested in the language war. It's just the case that Rust is both more difficult to learn --- especially if you've never worked in an unmanaged runtime before --- and more difficult to write. Which language is "better" is undecidable.
    - yumraj 4y ago
      Harder than C++? Harder to use than C? Above is a question, not a snark. I like learning languages and haven’t dabbled in Rust so am curious.
      - tptacek 4y ago
        C++ vs. Rust is a tricky question. C++ is easier to write in, but it's harder to get programs working in it. Rust is harder to write, but it's much more likely that your first execution is going to do something useful. But they're of comparable complexity.

moonchrome 4y ago

Yes Rust is significantly harder than go. It's diametrically opposite if there was a circle of complexity. I honestly have no clue how someone without low level experience (eg. never did systems level programming) even approaches Rust. The ownership model makes sense to me but if I had to grok manual memory management and rust abstractions on top of it at the same time I think I would be unable to contribute even trivial stuff for a month. Oh and coming from a dynamic language background at that ? Not saying can't be done just saying time till contributing is probably weeks-months. With go it's probably days.

iudqnolq 4y ago
> I honestly have no clue how someone without low level experience (eg. never did systems level programming) even approaches Rust. In my personal experience you do this by writing your programs in such a way as not to require complex ownership. I had an easy time writing web services where the only cross-request shared state was a database handle. I had a hard time when I had to write a websocket document sync serverwhere I needed per-document global state shared between all the handlers, and I eventually gave up and moved to a model where a language with an easier concurrency story called rust code.
- phamilton 4y ago
  This. Implementing an http endpoint is pretty straightforward. Newcomers may struggle with copy vs reference semantics (and that just takes time), but otherwise it's not too different from other statically typed http work. You define your input/output structs, you grab a database connection, you perform a query, and return it. No lifetimes. No Arcs or Mutexes or Rc or RefCell. We generally consider our rust backend as two parts: application code and library code. We intend for our application code to be approachable by full stack developers and not require deep rust expertise to use. Our library code can be a bit more complicated, and there we see a bigger ramp up and frankly some self selection among our team and that's fine.
nicoburns 4y ago
> I honestly have no clue how someone without low level experience (eg. never did systems level programming) even approaches Rust. I started by reading the Rust Book. It explains most of the low-level concepts. It took me about a week of mostly just learning and experimenting, and another ~3 weeks until I had an MVP of my system. But from there it was just another 2 months until I had a full system written and in production, which it would probably have taken in another language anyway (as the project involved a lot of trial and error reversing a (simple but) only partially documented format). Perhaps it helps that I came from JavaScript where a lot of the abstractions are similar.
molodec 4y ago
Curious what modern schools teach in Computer Science programs. I went to Salisbury State University 17 years ago, and we had classes on assembly language, system programming and operating systems where we used C, algorithms classes with assignments in C++, computer graphics, which of course also C++. My professional experience working in industry was primarily in Java, but also some C, Python, Ruby. Learning Rust was not without a challenge, but having a lot of programming in C/C++ in school more than 10 years ago helped a lot. My assumption that all software engineers who have university degree should have some experience in system programming.
- sophiabits 4y ago
  At my university the language used for teaching was predominantly Java, with Python or C# used in some papers. There was an optional operating systems paper which had you writing some assembly to run on an in-house RISC system [1], but a small % of CS+SE students took that paper. I think they’re trending towards using Python for most papers now. Not unreasonable for a paper on data mining or web development, but there’s definitely something being lost where students don’t /need/ to understand how the computer’s working in order to get a passing grade, so there’s no real incentive to dig deeper for the average student. [1] https://wramp.wand.nz/ https://wramp.wand.nz/
- tialaramex 4y ago
  The University I work for teaches Java in Programming I (the mandatory introductory language) for Computer Scientists, and teaches them some C in Programming II and then a functional language, typically Haskell, and potentially some Rust, Typescript, whatever by the third year as some of the students will be pursuing Theory. The Electronics students learn C at the beginning meanwhile. Students elsewhere in the university learn mostly Python and R.
coldtea 4y ago
>I honestly have no clue how someone without low level experience (eg. never did systems level programming) even approaches Rust. Far easier than the way anyone without low level experience (which meant almost everybody starting out) approached learning C and C+, back when Java, C#, Python, Perl etc were not yet a thing, and you got either got directly into C/C++ or started with PASCAL and BASIC if you were lucky. Oh, and no IDES, internet, stack overflow, or forums either...
- moonchrome 4y ago
  I mean I wouldn't recommend anyone do that either. Doubt you'll find many C++ roles taking people without experience either.

tptacek 4y ago

Go is garbage collected. It is significantly easier to write than Rust --- it's not just easier to learn, but easier for experts to write, because it's doing a bunch of work for the developer that Rust doesn't. On the other hand, if you need manual memory management (for performance reasons, or because you're doing something bare-metal), you'll be fighting Go's garbage collector, and Rust has conveniences for manual memory management that Go doesn't.

DominoTree 4y ago
Go is quite arguably a worse language though, including certain fundamental cornerstones of modern web development. Ever tried to see what fields a JSON payload contains in an "idiomatic" way before casting it to a type in Go? It's all interface{} (now Any) and reflection. If we're talking about developers new to a language, I'd argue that Rust's type system is easier to grok than the cases you may need to account for in Go.
- tptacek 4y ago
  I'm not interested in the language war. It's just the case that Rust is both more difficult to learn --- especially if you've never worked in an unmanaged runtime before --- and more difficult to write. Which language is "better" is undecidable.
  - yumraj 4y ago
    Harder than C++? Harder to use than C? Above is a question, not a snark. I like learning languages and haven’t dabbled in Rust so am curious.
    - tptacek 4y ago
      C++ vs. Rust is a tricky question. C++ is easier to write in, but it's harder to get programs working in it. Rust is harder to write, but it's much more likely that your first execution is going to do something useful. But they're of comparable complexity.