9 ms·

Awesome to see the learning curve addressed with such high priority. I like Rust and I'd like to use it more, but I generally lean on Go or C for writing anyth

by fixxer 10y ago

Awesome to see the learning curve addressed with such high priority. I like Rust and I'd like to use it more, but I generally lean on Go or C for writing anything that needs performance. I can't quite get past the awkward, fumbling stage with Rust. Go, on the other hand, was really easy to get acquainted with and not too substantial of an effort to get to strong expertise. I've been able to teach Go to junior devs with no background and hand off projects within a couple weeks. Rust is awesome, but fits in a very different bracket IMO.

pcwalton 10y ago
It's important to note that Go and C have very different design goals from Rust. Go was never designed to have zero-cost abstractions (garbage collection being the most obvious outcome of this, but there are many others), and it has a runtime. C was never designed for safety and security, memory safety or otherwise. In short, Go sacrifices performance and C sacrifices safety, while Rust's goal is to sacrifice neither. Addressing the learning curve of Rust is important, but we aren't going to be able to do it by adopting concepts from Go or C. By and large, they just don't apply.
- cbHXBY1D 10y ago
  If syntax isn't going to be changed, is that really addressing the learning curve of the language? Edit: I'm going to answer my own question here: yes. I just sometimes think Rust is a victim of its own success when people expect to learn Rust quickly because they learned Python in two days. No one expects to master C++ in a weekend.
- yazaddaruvala 10y ago
  What are your thought on making `rustc` poly-lingual? Ideally, all libraries (i.e. should be written by experts) are written in Rust, but applications are allowed to be written in RustScript. RustScript would be optimized for lower learning curve. example[0]: - No `unsafe` allowed. - Everything is implicitly an `Arc<_>`. - All numerics are BigNum. - etc. This is inspired by the popularity of using Rust within other languages, like Ruby. The way this would differ from using another language: All the Rust tooling would be the same. Realistically it would just be a different parser for the Rust AST. Therefore no memory layout issues, or FFI involved. Like syntax-sugar to the extreme, the compiler (except the parser) wouldn't even know the difference. [0] I'm just listing simplifications, regardless of if they are a good idea.
  - leshow 10y ago
    not the OP, but i strongly disagree. you don't need to be an expert to write rust. Many of it's features are in a huge amount of other languages; parametric polymorphism, ad hoc polymorphism, type inference, etc. there's nothing new and groundbreaking besides ownership and lifetimes, from a language syntax perspective. it really just takes a little bit to get used to ownership and you're off to the races. the compiler helps you out in a big way with writing correct programs. i also feel fracturing the community would be terrible. i came from basically a dynamic programming background (had done java and c++ in soft. eng. in school and that's it) and I had no problem learning rust.
  - pcwalton 10y ago
    So I'm actually a big fan of writing apps in multiple languages, and I wholeheartedly support writing apps in higher-level languages that incorporate low-level components written in Rust. (This is, in fact, what Servo-based Web apps are!) But I'm not sure I agree that there would be benefits in introducing a new language as opposed to just using an existing one. I think a Rust that used automatic memory management would effectively be a new language. There would be all the costs that come with introducing a new language: new tooling (even if based on Rust tooling, it'd have to be heavily modified), bootstrapping an ecosystem and community, and so forth. While making new languages is awesome, we have our hands full with the one we have :)
  - Manishearth 10y ago
    https://github.com/jonathandturner/rhai https://github.com/jonathandturner/rhai ? It doesn't do exactly this, but it's similar I think.
  - fulafel 10y ago
    There are a few Rust hosted dynamic languages already, see: https://github.com/ruse-lang/langs-in-rust https://github.com/ruse-lang/langs-in-rust Dyon in particular sounds interesting for realtime apps as it uses a lifetime checker instead of GC.
- kjksf 10y ago
  It's also important to note that Go was designed for programmer productivity and Rust wasn't. GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management. Compile times in Go are a fraction of Rust compile times, which is another productivity boost. Go gives you one good way to do concurrency, Rust believes in tyranny of choice. Without mentioning that you don't paint the whole picture, just the parts that are favorable to Rust.
  - burntsushi 10y ago
    Arguably, programmer productivity is one consequence of safety (and productivity isn't necessarily only gained by increased safety either of course!). Are there different productivity levels between Go and Rust? Probably. But to say Rust wasn't "designed for programmer productivity" definitely isn't right from where I'm standing.
    - bluejekyll 10y ago
      Honestly, the more you program in rust, the more you get used to its mannerisms. I don't at this point find that I'm less productive in it than in Go, and with gennerics I'm generally able to reuse code more often meaning that I usually write less code. Similarly in C I lose time on screwing up basic things that I have to debug in testing, whereas in Rust I don't have to even worry about that. I'm actually not buying the productivity argument, after you've learned the language. Claiming that it is less productive when you barely know it isn't fair, it's similar to saying that Italian (as an English speaker) is much more complex and hard to communicate in than English, when you've only studied the language for a month. It does have a steep learning curve, so it's either worth it to you to learn it, or not. But once you know it, I think your overall productivity is higher or the same as other languages, and on top of that you end up with fewer production issues!
      - burntsushi 10y ago
        I'd say my experience matches this. I've written well over 50 KLOC of both Go and Rust in the last few years (I love both), and I don't personally experience a big productivity difference between them. There is one dimension where I feel like Rust makes me more productive though: when writing code that I want to go as fast as possible. I bet there are things that would be more productive in Go, maybe building web applications, but I haven't built any in Rust yet, so it's hard to compare. As a reference point, I feel much more productive in Rust/Go than I do in any unityped language. I suspect the same is true of C, but I've never been a heavy C practitioner. I'll stop here though, because this is all pretty subjective and wishy washy, and it will undoubtedly vary from person to person and be dependent on what kinds of problems you're solving most frequently.
- dysfunctor 10y ago
  Go outperforms rust on all kinds of benchmarks, has a larger community, better documentation, more third party libraries, and significantly better tooling. What's the value proposition for using rust over go?
  - fbender 10y ago
    Source? First Google result for "Rust vs Go speed": https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=go https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... Rust seems to perform significantly better on some workloads while Go outperforms it marginally in other ones (except reverse-complement where Go is almost 50% faster than Rust). Edit: As for the other points you make – they are often subjective and I've read the opposite to your statement at least as often.
    - steveklabnik 10y ago
      The ones where Go outperforms us currently are the ones with heavy SIMD use; explicit SIMD is still unstable in Rust, so you're at the whims of LLVM generating it. We'll get there...
      - igouy 10y ago
        Do those Go programs use explicit SIMD ? http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=rust http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
        steveklabnik 10y ago
        I assume that they're better about generating it implicitly. That is, it's about why Rust is slow, not about why Go is fast.
        pcwalton 10y ago
        I don't think Go emits SIMD at all. Their assembler doesn't even support parsing it. I think these are probably just bugs that we need to look at. The benchmarks where we do worse are the string benchmarks; perhaps it's our Unicode correctness that is hurting us, or something like that.
cm3 10y ago
The hard part doesn't go away with unless you pull in a GC or something similar to take care of lifetime bugs. In Go you always use a GC and circumvent the explicit lifetime management syntax of Rust. Some data structures are very hard to write without something akin to a GC, so my bets are on a few opcodes trickling down into mainstream cpus making GC easier to implement in optimal time and space. I'm surprised Android hasn't forced anything like that in their supported ARM designs, since such cpu support has been available in production systems in the 1970s and hence isn't anything revolutionary, just not on the radar like vector instructions have been.
- Cyph0n 10y ago
  Could you provide references for the claim that hardware support for GCs had been in CPUs for decades?
  - cm3 10y ago
    Burroughs line of machines and Intel iAPX 432 and it's derivative i960 (which is actually in use). The project for which the Intel CPU was designed together with Siemens would have given us a safer foundation due to using this processor in an Ada based operating system in the 1980s. But then UNIX won and gave us the hegemony of C and all the avoidable security bugs associated with it. Lisp machines had similar designs. These days there are RISC-V designs that have similar features. Just like DJB has been wishing for a few extra arithmetic instructions for crypto in x86 processors, I wish for instructions that would make garbage collectors more efficient and also provide support for memory safety features. https://en.wikipedia.org/wiki/Intel_iAPX_432 https://en.wikipedia.org/wiki/Intel_iAPX_432 https://en.wikipedia.org/wiki/Intel_i960 https://en.wikipedia.org/wiki/Intel_i960 https://en.wikipedia.org/wiki/Burroughs_large_systems#Tagged_architecture https://en.wikipedia.org/wiki/Burroughs_large_systems#Tagged... http://www.smecc.org/The%20Architecture%20%20of%20the%20Burroughs%20B-5000.htm http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr... I'm sure there were similar design in the 1990s, but I don't have references ready off the top of my head like the above.
    - Cyph0n 10y ago

by fixxer 10y ago

pcwalton 10y ago

It's important to note that Go and C have very different design goals from Rust. Go was never designed to have zero-cost abstractions (garbage collection being the most obvious outcome of this, but there are many others), and it has a runtime. C was never designed for safety and security, memory safety or otherwise. In short, Go sacrifices performance and C sacrifices safety, while Rust's goal is to sacrifice neither. Addressing the learning curve of Rust is important, but we aren't going to be able to do it by adopting concepts from Go or C. By and large, they just don't apply.

cbHXBY1D 10y ago
If syntax isn't going to be changed, is that really addressing the learning curve of the language? Edit: I'm going to answer my own question here: yes. I just sometimes think Rust is a victim of its own success when people expect to learn Rust quickly because they learned Python in two days. No one expects to master C++ in a weekend.
yazaddaruvala 10y ago
What are your thought on making `rustc` poly-lingual? Ideally, all libraries (i.e. should be written by experts) are written in Rust, but applications are allowed to be written in RustScript. RustScript would be optimized for lower learning curve. example[0]: - No `unsafe` allowed. - Everything is implicitly an `Arc<_>`. - All numerics are BigNum. - etc. This is inspired by the popularity of using Rust within other languages, like Ruby. The way this would differ from using another language: All the Rust tooling would be the same. Realistically it would just be a different parser for the Rust AST. Therefore no memory layout issues, or FFI involved. Like syntax-sugar to the extreme, the compiler (except the parser) wouldn't even know the difference. [0] I'm just listing simplifications, regardless of if they are a good idea.
- leshow 10y ago
  not the OP, but i strongly disagree. you don't need to be an expert to write rust. Many of it's features are in a huge amount of other languages; parametric polymorphism, ad hoc polymorphism, type inference, etc. there's nothing new and groundbreaking besides ownership and lifetimes, from a language syntax perspective. it really just takes a little bit to get used to ownership and you're off to the races. the compiler helps you out in a big way with writing correct programs. i also feel fracturing the community would be terrible. i came from basically a dynamic programming background (had done java and c++ in soft. eng. in school and that's it) and I had no problem learning rust.
- pcwalton 10y ago
  So I'm actually a big fan of writing apps in multiple languages, and I wholeheartedly support writing apps in higher-level languages that incorporate low-level components written in Rust. (This is, in fact, what Servo-based Web apps are!) But I'm not sure I agree that there would be benefits in introducing a new language as opposed to just using an existing one. I think a Rust that used automatic memory management would effectively be a new language. There would be all the costs that come with introducing a new language: new tooling (even if based on Rust tooling, it'd have to be heavily modified), bootstrapping an ecosystem and community, and so forth. While making new languages is awesome, we have our hands full with the one we have :)
- Manishearth 10y ago
  https://github.com/jonathandturner/rhai https://github.com/jonathandturner/rhai ? It doesn't do exactly this, but it's similar I think.
- fulafel 10y ago
  There are a few Rust hosted dynamic languages already, see: https://github.com/ruse-lang/langs-in-rust https://github.com/ruse-lang/langs-in-rust Dyon in particular sounds interesting for realtime apps as it uses a lifetime checker instead of GC.
kjksf 10y ago
It's also important to note that Go was designed for programmer productivity and Rust wasn't. GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management. Compile times in Go are a fraction of Rust compile times, which is another productivity boost. Go gives you one good way to do concurrency, Rust believes in tyranny of choice. Without mentioning that you don't paint the whole picture, just the parts that are favorable to Rust.
- burntsushi 10y ago
  Arguably, programmer productivity is one consequence of safety (and productivity isn't necessarily only gained by increased safety either of course!). Are there different productivity levels between Go and Rust? Probably. But to say Rust wasn't "designed for programmer productivity" definitely isn't right from where I'm standing.
  - bluejekyll 10y ago
    Honestly, the more you program in rust, the more you get used to its mannerisms. I don't at this point find that I'm less productive in it than in Go, and with gennerics I'm generally able to reuse code more often meaning that I usually write less code. Similarly in C I lose time on screwing up basic things that I have to debug in testing, whereas in Rust I don't have to even worry about that. I'm actually not buying the productivity argument, after you've learned the language. Claiming that it is less productive when you barely know it isn't fair, it's similar to saying that Italian (as an English speaker) is much more complex and hard to communicate in than English, when you've only studied the language for a month. It does have a steep learning curve, so it's either worth it to you to learn it, or not. But once you know it, I think your overall productivity is higher or the same as other languages, and on top of that you end up with fewer production issues!
    - burntsushi 10y ago
      I'd say my experience matches this. I've written well over 50 KLOC of both Go and Rust in the last few years (I love both), and I don't personally experience a big productivity difference between them. There is one dimension where I feel like Rust makes me more productive though: when writing code that I want to go as fast as possible. I bet there are things that would be more productive in Go, maybe building web applications, but I haven't built any in Rust yet, so it's hard to compare. As a reference point, I feel much more productive in Rust/Go than I do in any unityped language. I suspect the same is true of C, but I've never been a heavy C practitioner. I'll stop here though, because this is all pretty subjective and wishy washy, and it will undoubtedly vary from person to person and be dependent on what kinds of problems you're solving most frequently.
dysfunctor 10y ago
Go outperforms rust on all kinds of benchmarks, has a larger community, better documentation, more third party libraries, and significantly better tooling. What's the value proposition for using rust over go?
- fbender 10y ago
  Source? First Google result for "Rust vs Go speed": https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=go https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... Rust seems to perform significantly better on some workloads while Go outperforms it marginally in other ones (except reverse-complement where Go is almost 50% faster than Rust). Edit: As for the other points you make – they are often subjective and I've read the opposite to your statement at least as often.
  - steveklabnik 10y ago
    The ones where Go outperforms us currently are the ones with heavy SIMD use; explicit SIMD is still unstable in Rust, so you're at the whims of LLVM generating it. We'll get there...
    - igouy 10y ago
      Do those Go programs use explicit SIMD ? http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=rust http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
      - steveklabnik 10y ago
        I assume that they're better about generating it implicitly. That is, it's about why Rust is slow, not about why Go is fast.
        pcwalton 10y ago
        I don't think Go emits SIMD at all. Their assembler doesn't even support parsing it. I think these are probably just bugs that we need to look at. The benchmarks where we do worse are the string benchmarks; perhaps it's our Unicode correctness that is hurting us, or something like that.

cm3 10y ago

The hard part doesn't go away with unless you pull in a GC or something similar to take care of lifetime bugs. In Go you always use a GC and circumvent the explicit lifetime management syntax of Rust. Some data structures are very hard to write without something akin to a GC, so my bets are on a few opcodes trickling down into mainstream cpus making GC easier to implement in optimal time and space. I'm surprised Android hasn't forced anything like that in their supported ARM designs, since such cpu support has been available in production systems in the 1970s and hence isn't anything revolutionary, just not on the radar like vector instructions have been.

Cyph0n 10y ago
Could you provide references for the claim that hardware support for GCs had been in CPUs for decades?
- cm3 10y ago
  Burroughs line of machines and Intel iAPX 432 and it's derivative i960 (which is actually in use). The project for which the Intel CPU was designed together with Siemens would have given us a safer foundation due to using this processor in an Ada based operating system in the 1980s. But then UNIX won and gave us the hegemony of C and all the avoidable security bugs associated with it. Lisp machines had similar designs. These days there are RISC-V designs that have similar features. Just like DJB has been wishing for a few extra arithmetic instructions for crypto in x86 processors, I wish for instructions that would make garbage collectors more efficient and also provide support for memory safety features. https://en.wikipedia.org/wiki/Intel_iAPX_432 https://en.wikipedia.org/wiki/Intel_iAPX_432 https://en.wikipedia.org/wiki/Intel_i960 https://en.wikipedia.org/wiki/Intel_i960 https://en.wikipedia.org/wiki/Burroughs_large_systems#Tagged_architecture https://en.wikipedia.org/wiki/Burroughs_large_systems#Tagged... http://www.smecc.org/The%20Architecture%20%20of%20the%20Burroughs%20B-5000.htm http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr... I'm sure there were similar design in the 1990s, but I don't have references ready off the top of my head like the above.
  - Cyph0n 10y ago