5 ms·

So I am a C++ dev by day and I write some go and rust for side projects or smaller projects at work. Go is SOOOOOO much simpler to write (unless you get into cr

So I am a C++ dev by day and I write some go and rust for side projects or smaller projects at work. Go is SOOOOOO much simpler to write (unless you get into crazy threading data race stuff) than rust. I like rust (a lot), but the mental load is a lot more to take on than go.

steveklabnik 8y ago
An interesting comparison between experiences is that people describe Rust as having a lot of mental load at first, but eventually as having way less, since the compiler does so much for you. On the topic of the original thread, I wonder why Rust wasn’t included; maybe it’s because our first release that’s achieving similar goals is happening six weeks from now, and they wanted to see how things played out in practice, not in theory.
- rhodysurf 8y ago
  Yeah I agree that as I learned rust I got used to it and became slowly more productive. But I am still nowhere near as fast to accomplish things with it as I am with modern C++ or go or swift.
- Scarbutt 8y ago
  people describe Rust as having a lot of mental load at first, but eventually as having way less. Well that's true for most not-so-semi-trivial stuff one has to learn, it doesn't mean is always a good idea though. Just giving a different perspective to beginners.
  - steveklabnik 8y ago
    Sure! You should use whatever tools you prefer. Rust isn’t the best programming language of all times, it has pros and cons like everything else.
- apta 8y ago
  > maybe it’s because our first release that’s achieving similar goals is happening six weeks from now What's happening in the next release? Any backward compatible breaking changes?
  - steveklabnik 8y ago
    https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html
ilovecaching 8y ago
I've found that Go works well for small code bases where duplication isn't too much of a worry. It makes sense. The authors of Go are the same people who advocate for small, focused tools: the unix philosophy. When you grow to a certain size though, it becomes very messy. Go has very little facility for abstraction despite being a higher level language with a GC and a substantial runtime. I also personally find the error handling frustrating. Most of the time all you want to do with an error is send it to the caller, who has more context on how to handle it. I still write Go alongside Rust, but I use it as a scripting language, for all the things I used to use Python for. Rust just has the tools I need to build abstractions, and lets me avoid continually rewriting data structures.
Quekid5 8y ago
Yes, but it's also much more likely to result in a run-time failure. I'm not talking about memory safety here -- just the fact that Rust has (Algebraic Data)/Sum Types[1]. Of course these kind of "want" pattern matching, but it's not an absolute requirement. Having ADTs/Sum types will improve the reliability of your software immensely just by being available. It's truly absurd just how much work they can do: They can replace "null", they can ensure that there are no surprises in a state machine where some state carries over unexpectedly, etc. etc. [1] Not higher-kinded, but that's probably a distraction for the point I'm making.
- ilovecaching 8y ago
  Agreed. You could encode valid state transitions phantom types, for example. Go's weaker type system means it has less power to encode was is and is not correct program behavior.
- rhodysurf 8y ago
  Yes I know. I love Sum types, and I love Trait oriented programming. And I definitely miss sum types in Go and C++. If C++ had sum types and no header files that would probably hit my (very subjective) sweetspot. Tangent: I wish Rust had optional chaining like swift, which I know is a limitation due to Option just being a normal sum type. Having to pattern match every optional is burdensome
  - Quekid5 8y ago
    Heh, I was actually alluding to C++ with the pattern matching thing. Std::variant<> is actually a bona fide sum type, but using it is horrendous because of the lack of pattern matching. You can use the the "cppreference overloaded"[1] trick to sort-of do basic pattern matching of the outer constructor, but it's still not particularly well supported by compilers. [1] I'm using this as a proxy name for a trick I saw on cppreference where you can (via template tricks, why not?) write code very similar to pattern matching, but it's ultimately quite simplistic and brittle.
    - rhodysurf 8y ago
deckarep 8y ago
Yes there is much more mental load you pay upfront during development but once you get code working and satisfy the borrow checker you now have significantly stronger runtime guarantees about your application in terms of safe and proper concurrency. This is the trade off.
- rhodysurf 8y ago
  I understand that, I posted my response becasue the OC was presenting Rust as a replacement for Go but they are very different languages with different tradeoffs
  - ilovecaching 8y ago
    Actually, the Go team even bills Go as a systems language. I think if you're going to consider Go, you should also consider what you could get with Rust. Sure the upfront investment in Rust higher, Go is almost too small, but the upfront cost of Rust is amortized via the hours you save with all the abstractions and performance you get right out of the box.
    - steveklabnik 8y ago
      They’ve moved away from “systems” as a moniker, and Rust slowly is too. It’s just too confusing of a term these days, and nobody knows what it actually means, so it’s not useful.
      - pjmlp 8y ago
        I would say if one can write OSes, device drivers, debuggers, compilers, target bare metal deployments on language X, then it is a systems language, regardless of what label people put on it.
        pvg 8y ago
        The problem with that is it's a narrowing of the 'historical' use of the term and just confuses things further. The Go (and now Rust, it seems) people are right to move away from it.

steveklabnik 8y ago

An interesting comparison between experiences is that people describe Rust as having a lot of mental load at first, but eventually as having way less, since the compiler does so much for you. On the topic of the original thread, I wonder why Rust wasn’t included; maybe it’s because our first release that’s achieving similar goals is happening six weeks from now, and they wanted to see how things played out in practice, not in theory.

rhodysurf 8y ago
Yeah I agree that as I learned rust I got used to it and became slowly more productive. But I am still nowhere near as fast to accomplish things with it as I am with modern C++ or go or swift.
Scarbutt 8y ago
people describe Rust as having a lot of mental load at first, but eventually as having way less. Well that's true for most not-so-semi-trivial stuff one has to learn, it doesn't mean is always a good idea though. Just giving a different perspective to beginners.
- steveklabnik 8y ago
  Sure! You should use whatever tools you prefer. Rust isn’t the best programming language of all times, it has pros and cons like everything else.
apta 8y ago
> maybe it’s because our first release that’s achieving similar goals is happening six weeks from now What's happening in the next release? Any backward compatible breaking changes?
- steveklabnik 8y ago
  https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html

ilovecaching 8y ago

I've found that Go works well for small code bases where duplication isn't too much of a worry. It makes sense. The authors of Go are the same people who advocate for small, focused tools: the unix philosophy. When you grow to a certain size though, it becomes very messy. Go has very little facility for abstraction despite being a higher level language with a GC and a substantial runtime. I also personally find the error handling frustrating. Most of the time all you want to do with an error is send it to the caller, who has more context on how to handle it. I still write Go alongside Rust, but I use it as a scripting language, for all the things I used to use Python for. Rust just has the tools I need to build abstractions, and lets me avoid continually rewriting data structures.

Quekid5 8y ago

Yes, but it's also much more likely to result in a run-time failure. I'm not talking about memory safety here -- just the fact that Rust has (Algebraic Data)/Sum Types[1]. Of course these kind of "want" pattern matching, but it's not an absolute requirement. Having ADTs/Sum types will improve the reliability of your software immensely just by being available. It's truly absurd just how much work they can do: They can replace "null", they can ensure that there are no surprises in a state machine where some state carries over unexpectedly, etc. etc. [1] Not higher-kinded, but that's probably a distraction for the point I'm making.

ilovecaching 8y ago
Agreed. You could encode valid state transitions phantom types, for example. Go's weaker type system means it has less power to encode was is and is not correct program behavior.
rhodysurf 8y ago
Yes I know. I love Sum types, and I love Trait oriented programming. And I definitely miss sum types in Go and C++. If C++ had sum types and no header files that would probably hit my (very subjective) sweetspot. Tangent: I wish Rust had optional chaining like swift, which I know is a limitation due to Option just being a normal sum type. Having to pattern match every optional is burdensome
- Quekid5 8y ago
  Heh, I was actually alluding to C++ with the pattern matching thing. Std::variant<> is actually a bona fide sum type, but using it is horrendous because of the lack of pattern matching. You can use the the "cppreference overloaded"[1] trick to sort-of do basic pattern matching of the outer constructor, but it's still not particularly well supported by compilers. [1] I'm using this as a proxy name for a trick I saw on cppreference where you can (via template tricks, why not?) write code very similar to pattern matching, but it's ultimately quite simplistic and brittle.
  - rhodysurf 8y ago

deckarep 8y ago

Yes there is much more mental load you pay upfront during development but once you get code working and satisfy the borrow checker you now have significantly stronger runtime guarantees about your application in terms of safe and proper concurrency. This is the trade off.

rhodysurf 8y ago
I understand that, I posted my response becasue the OC was presenting Rust as a replacement for Go but they are very different languages with different tradeoffs
- ilovecaching 8y ago
  Actually, the Go team even bills Go as a systems language. I think if you're going to consider Go, you should also consider what you could get with Rust. Sure the upfront investment in Rust higher, Go is almost too small, but the upfront cost of Rust is amortized via the hours you save with all the abstractions and performance you get right out of the box.
  - steveklabnik 8y ago
    They’ve moved away from “systems” as a moniker, and Rust slowly is too. It’s just too confusing of a term these days, and nobody knows what it actually means, so it’s not useful.
    - pjmlp 8y ago
      I would say if one can write OSes, device drivers, debuggers, compilers, target bare metal deployments on language X, then it is a systems language, regardless of what label people put on it.
      - pvg 8y ago
        The problem with that is it's a narrowing of the 'historical' use of the term and just confuses things further. The Go (and now Rust, it seems) people are right to move away from it.