6 ms·

If you're frustrated by the lack of a strong type system in Go then check out Rust. Rust has type parameters and type constraints that let you write generic cod

If you're frustrated by the lack of a strong type system in Go then check out Rust. Rust has type parameters and type constraints that let you write generic code. The authors have also been super attentive to the good parts of Go. Rust has great tooling through Cargo, it has rustfmt for formatting, rls for language server support. Rust also adds real sum types and a tuple type. Multi-value returns are just tuples, they aren't a special case of the semantics. Result types let you avoid writing if err != nil everywhere, but we still believe in the mantra of not panicking for things that are not truly exceptional. Rust is also closer to C++s performance, and it's a strongly community driven project. We also have great concurrency primitives. We have channels, but we also have futures, which can be scheduled on green threads in a CSP style just like Go, or can be run behind the Actor model, using async/await syntax with polling... there's a lot more flexibility there to align the language to your business needs.

rhodysurf 8y ago
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.
noncoml 8y ago
Two very important things for me that Go offers are the garbage collection and the stackful co-routines (i.e. go-routines). Makes code so much easier to read and write. If they would give me generics and ADT, I don't think I would ever use any other language.
- ilovecaching 8y ago
  Rust has the borrow checker, which gives you the safety of garbage collection coupled with the power of manual memory management. As of Rust 2018, Rust also has async and await, and futures can be cooperatively scheduled on a green thread model (but you're not limited to that model).
  - noncoml 8y ago
    Rust is a great language, and has its uses, but it's not a cure all. IMHO stackful co-routines are superior to stackless (i.e. async-await). Also if I am not mistaken the futures library is still in the nursery and subject to change. When I write code that is going to run on the customer’s device, I choose Rust for the guarantees it offers me, (I know it will not crash because of my mistake). For server side code on the other hand, something easy going as Go is much preferred.
    - steveklabnik 8y ago
      Futures are subject to some more change, though it’s getting close! FWIW, async/await does produce a “stack full” coroutine: you get a single, exactly sized stack for each task, every time. This is made possible by coroutines being fundamentally stackless, but in the end, tasks still have stacks.
      - noncoml 8y ago
        > FWIW, async/await does produce a “stack full” coroutine: you get a single, exactly sized stack for each task, every time. This is made possible by coroutines being fundamentally stackless, but in the end, tasks still have stacks. I see, thanks for the info. I wasn't talking so much about the implementation but the difference between the program control flow differences between the two models, go-routines vs async/await.
the_clarence 8y ago
What do you mean Go doesn't have a strong type system? Are you refering that it allows for interface{}?
- int_19h 8y ago
  I think it's more that it requires it in many cases, due to the lack of generics.
  - the_clarence 8y ago
    I always find work arounds or just write more code. I feel like it's annoying sometimee but when reading code I feel blessed that generics are not supported.
    - erik_seaberg 8y ago
      Reading redundant code is always more work than letting the computer handle those low-payoff details. And nobody's going to provide their data structures specialized to every type you could possibly want. Case in point: container/heap from the standard library takes and returns interface{}.
      - the_clarence 8y ago
        Oh no. Believe me reading code full of templates is not a pleasure. There is a reason Go is so pleasant to read.
        int_19h 8y ago
        C++ templates are hardly the best example of generics out there, and certainly not what you should be looking at from a Go perspective, seeing how Go is a higher-level language that doesn't concern itself with zero-cost abstractions anywhere near as much as C++ does. Look at C# or D generics instead.
Thaxll 8y ago
Why do people feel the need to promote Rust on many Go topics? Also can someone explain the "lack" of strong type system in Go, I don't use interface{} so where is the problem?
- Scarbutt 8y ago
  Why do people feels the need to promote rust on many Go topics? Its more fun for some to do so, for ex: the Go2 proposal might be too boring to discuss.
- everybodyknows 8y ago
  One limitation is that although "int" can be sub-typed, such a variable cannot directly index a slice.
  - zeeboo 8y ago
    I’m confused. First, there’s no notion of sub-typing in Go. Second, the closest thing I can think of what you mean does work: https://play.golang.org/p/IE9sg4CwCd_C https://play.golang.org/p/IE9sg4CwCd_C
  - JohnStrangeII 8y ago
    Rust doesn't have proper integer subtypes either. Ada has.
    - steveklabnik 8y ago
      Aren’t ada’s runtime checked? You can do that in Rust.
      - pjmlp 8y ago
        Only if it cannot be proven at compile time.
        steveklabnik 8y ago
runn1ng 8y ago
Rust and Go are very different languages for very different use-cases and with very different goals at every level of design. Rust is a C replacement, Go is a replacement for everything else ;)
- throwaway487548 8y ago
  But simple reality checks reveal that Go is an evolution of C and Rust grow out of frustration with C++.
  - JohnStrangeII 8y ago
    Rust is not a good replacement for C++, though. It doesn't even have inheritance, let alone multiple inheritance and/or multiple dispatch. It's kind of in-between C and C++ in terms of capabilities, and neither a subset nor a superset of Ada's features in terms of safety. Some of Rust's memory safety features are only now being added to Ada and not yet in the forthcoming standard, whereas Ada has many features that Rust still lacks (e.g. integer range subtypes, OOP with inheritance). Rust is less secure than Ada/Spark, though, and clearly not intended for high integrity systems. It seems that the niche Rust is aiming for is "safe general system's programming for people who primarily use C and C++ but have never used much Ada or Haskell", and in that area it's quite successful. Both Rust and Go are odd, because they have less features of C++ (plus added safety) and attempt to sell a lack of features as advantages, whereas in reality no one forces you to use a feature and their developers are merely pushing their own, personal agenda about "what's the right thing to do". I personally don't like C++, but one of its benefits is that it leave its users the choice of what's the right thing to do and offer as many zero-cost abstractions as possible. Rust and Go are way more patronizing.
tptacek 8y ago
I'm sure this was well-intentioned but it had the effect of turning half the comments on an otherwise interesting thread into a Go vs. Rust language battle, which is not the topic of the story we're commenting on.
- ilovecaching 8y ago
  I'm commenting on the pain points specifically being addressed in Go v2, so I feel it's appropriate to talk about the alternatives here. I also tried to focus on specifics.
  - tptacek 8y ago
    This document is in fact not about the features in Go 2, but rather on the migration path between two languages, whose features are (in the piece) an abstraction. Please don't start language wars.
optionalparens 8y ago
Is there a reason this guy keeps posting about Rust, especially on articles about other programming languages (ex: also a recent Elixir post)? Overall across posts, I sometimes agree with this guy, but it's getting really obnoxious that people continue to leave such replies every language post. I really like Rust and use it for major projects, but I fail to see how it's much on topic. I agree with other comments that it gets compared to Go all the time, often without prompting or relationship to articles. Want to do that, why not write an article or do a separate post? Hijacking the comments and/or shilling Rust is getting old. I have to say that although I love Rust and somewhat despise Go, if it works for you, use it. Go is good at a lot of things - identify what they are and use it because it solves your problem. If another language does that better, use that instead. If you don't know what those things are, you probably need to spend some time not only reading, but writing actual code in that language. Don't pick one language to solve all your problems and don't look for problems because you like a language or some specific features of a language. Consider the entire scope of your issues, both technical and non-technical. In that sense, I can see why a lot of people choose Go and it is just as valid as any other language choice.
dang 8y ago
You took this thread on an offtopic tangent. When people do that by baiting the discussion into being about some hot generic controversy (Rust vs. Go! type system wars!), thread quality suffers. The generic baity discussions are all the same, and usually become flamey too. Other users have started to complain about you doing this repeatedly, so we need to ask you to stop. No more of this, please, regardless of how much you like Rust.

rhodysurf 8y ago

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.

noncoml 8y ago

Two very important things for me that Go offers are the garbage collection and the stackful co-routines (i.e. go-routines). Makes code so much easier to read and write. If they would give me generics and ADT, I don't think I would ever use any other language.

ilovecaching 8y ago
Rust has the borrow checker, which gives you the safety of garbage collection coupled with the power of manual memory management. As of Rust 2018, Rust also has async and await, and futures can be cooperatively scheduled on a green thread model (but you're not limited to that model).
- noncoml 8y ago
  Rust is a great language, and has its uses, but it's not a cure all. IMHO stackful co-routines are superior to stackless (i.e. async-await). Also if I am not mistaken the futures library is still in the nursery and subject to change. When I write code that is going to run on the customer’s device, I choose Rust for the guarantees it offers me, (I know it will not crash because of my mistake). For server side code on the other hand, something easy going as Go is much preferred.
  - steveklabnik 8y ago
    Futures are subject to some more change, though it’s getting close! FWIW, async/await does produce a “stack full” coroutine: you get a single, exactly sized stack for each task, every time. This is made possible by coroutines being fundamentally stackless, but in the end, tasks still have stacks.
    - noncoml 8y ago
      > FWIW, async/await does produce a “stack full” coroutine: you get a single, exactly sized stack for each task, every time. This is made possible by coroutines being fundamentally stackless, but in the end, tasks still have stacks. I see, thanks for the info. I wasn't talking so much about the implementation but the difference between the program control flow differences between the two models, go-routines vs async/await.

the_clarence 8y ago

What do you mean Go doesn't have a strong type system? Are you refering that it allows for interface{}?

int_19h 8y ago
I think it's more that it requires it in many cases, due to the lack of generics.
- the_clarence 8y ago
  I always find work arounds or just write more code. I feel like it's annoying sometimee but when reading code I feel blessed that generics are not supported.
  - erik_seaberg 8y ago
    Reading redundant code is always more work than letting the computer handle those low-payoff details. And nobody's going to provide their data structures specialized to every type you could possibly want. Case in point: container/heap from the standard library takes and returns interface{}.
    - the_clarence 8y ago
      Oh no. Believe me reading code full of templates is not a pleasure. There is a reason Go is so pleasant to read.
      - int_19h 8y ago
        C++ templates are hardly the best example of generics out there, and certainly not what you should be looking at from a Go perspective, seeing how Go is a higher-level language that doesn't concern itself with zero-cost abstractions anywhere near as much as C++ does. Look at C# or D generics instead.

Thaxll 8y ago

Why do people feel the need to promote Rust on many Go topics? Also can someone explain the "lack" of strong type system in Go, I don't use interface{} so where is the problem?

Scarbutt 8y ago
Why do people feels the need to promote rust on many Go topics? Its more fun for some to do so, for ex: the Go2 proposal might be too boring to discuss.
everybodyknows 8y ago
One limitation is that although "int" can be sub-typed, such a variable cannot directly index a slice.
- zeeboo 8y ago
  I’m confused. First, there’s no notion of sub-typing in Go. Second, the closest thing I can think of what you mean does work: https://play.golang.org/p/IE9sg4CwCd_C https://play.golang.org/p/IE9sg4CwCd_C
- JohnStrangeII 8y ago
  Rust doesn't have proper integer subtypes either. Ada has.
  - steveklabnik 8y ago
    Aren’t ada’s runtime checked? You can do that in Rust.
    - pjmlp 8y ago
      Only if it cannot be proven at compile time.
      - steveklabnik 8y ago

runn1ng 8y ago

Rust and Go are very different languages for very different use-cases and with very different goals at every level of design. Rust is a C replacement, Go is a replacement for everything else ;)

throwaway487548 8y ago
But simple reality checks reveal that Go is an evolution of C and Rust grow out of frustration with C++.
- JohnStrangeII 8y ago
  Rust is not a good replacement for C++, though. It doesn't even have inheritance, let alone multiple inheritance and/or multiple dispatch. It's kind of in-between C and C++ in terms of capabilities, and neither a subset nor a superset of Ada's features in terms of safety. Some of Rust's memory safety features are only now being added to Ada and not yet in the forthcoming standard, whereas Ada has many features that Rust still lacks (e.g. integer range subtypes, OOP with inheritance). Rust is less secure than Ada/Spark, though, and clearly not intended for high integrity systems. It seems that the niche Rust is aiming for is "safe general system's programming for people who primarily use C and C++ but have never used much Ada or Haskell", and in that area it's quite successful. Both Rust and Go are odd, because they have less features of C++ (plus added safety) and attempt to sell a lack of features as advantages, whereas in reality no one forces you to use a feature and their developers are merely pushing their own, personal agenda about "what's the right thing to do". I personally don't like C++, but one of its benefits is that it leave its users the choice of what's the right thing to do and offer as many zero-cost abstractions as possible. Rust and Go are way more patronizing.

tptacek 8y ago

I'm sure this was well-intentioned but it had the effect of turning half the comments on an otherwise interesting thread into a Go vs. Rust language battle, which is not the topic of the story we're commenting on.

ilovecaching 8y ago
I'm commenting on the pain points specifically being addressed in Go v2, so I feel it's appropriate to talk about the alternatives here. I also tried to focus on specifics.
- tptacek 8y ago
  This document is in fact not about the features in Go 2, but rather on the migration path between two languages, whose features are (in the piece) an abstraction. Please don't start language wars.

optionalparens 8y ago

Is there a reason this guy keeps posting about Rust, especially on articles about other programming languages (ex: also a recent Elixir post)? Overall across posts, I sometimes agree with this guy, but it's getting really obnoxious that people continue to leave such replies every language post. I really like Rust and use it for major projects, but I fail to see how it's much on topic. I agree with other comments that it gets compared to Go all the time, often without prompting or relationship to articles. Want to do that, why not write an article or do a separate post? Hijacking the comments and/or shilling Rust is getting old. I have to say that although I love Rust and somewhat despise Go, if it works for you, use it. Go is good at a lot of things - identify what they are and use it because it solves your problem. If another language does that better, use that instead. If you don't know what those things are, you probably need to spend some time not only reading, but writing actual code in that language. Don't pick one language to solve all your problems and don't look for problems because you like a language or some specific features of a language. Consider the entire scope of your issues, both technical and non-technical. In that sense, I can see why a lot of people choose Go and it is just as valid as any other language choice.

dang 8y ago

You took this thread on an offtopic tangent. When people do that by baiting the discussion into being about some hot generic controversy (Rust vs. Go! type system wars!), thread quality suffers. The generic baity discussions are all the same, and usually become flamey too. Other users have started to complain about you doing this repeatedly, so we need to ask you to stop. No more of this, please, regardless of how much you like Rust.