9 ms·

Go and Rust are actually a great combo with only a little overlap. What’s great is that they are both C family and have some shared principles and flow. When y

Go and Rust are actually a great combo with only a little overlap. What’s great is that they are both C family and have some shared principles and flow. When you need a decent concurrency story, moderate speed, and have a problem that is concrete, choose Go. It’s a good candidate for replacing Python, Ruby, JavaScript, and smaller Java projects. Rust is better if you need maximum performance, are building a large project where more abstraction where parametric polymorphism can help, or need thread safety. It’s a replacement for larger Java projects, C++, and C. Generally I write more Go projects, but my Rust projects tend to be bigger and are doing very complex things like user space networking or wringing maximum performance out of a kernel subsystem or running in a very low resource environment. Both languages have made my teams enjoy their work more. We also have empirically measured a decrease in time spent fixing bugs and other production issues, as well as reduced resource consumption (mostly from getting rid of Python for Go) and snappier cli tools that are saving us $$$$$$ in terms of time and hardware). Both languages are built for modern problems and getting stuff done. Also Go and Rust position us to hit Wasm hard. I can’t understate how important Wasm support is and how both of these languages are already miles ahead of the competition. This is containers right before Docker. Your company should be pivoting or have a strategy to get on deck with these languages.

rlander 8y ago
> Your company should be pivoting or have a strategy to get on deck with these languages. That’s a bold blanket statement. Besides the fact that I would die inside a little if I had to use Go every day of my life, Go is in no position to replace any of the aforementioned languages (Python, Js, Ruby, C++), let alone all of them, not by a mile.
- hu3 8y ago
  I don't think your parent meant that a language broadly replaces another but rather that Go and Rust lend themselves well for some types of projects typically done in other languages.
- ilovecaching 8y ago
  Not C++, but definitely the other languages outside of some non standard SWE domains like ML, where Python is going to be an obvious winner. Otherwise Go beats them by having a type system but still supporting duck typing through interfaces, having a modern concurrency story, being easier to learn (the Go spec can be read in one evening), having less features to abuse, faster development loops with lightning fast compile times and catching more errors at compile time, and just generally being faster and having a garbage collector that is tuned for low latency (a good fit for web services). We can also start faster which is really important for container workloads, idle with less memory which is important for horizontal scaling, and use less CPU which means smaller machines and more colo. Go also favors libraries over frameworks and is super thoughtful about using too many untested dependancies which means we don’t get stuck in frameworks that become legacy (rails) or use stuff that has security holes or that will change out from under us (npm).
  - treis 8y ago
    >Go also favors libraries over frameworks and is super thoughtful about using too many untested dependancies which means we don’t get stuck in frameworks that become legacy (rails) The Go standard library doesn't come close to replicating the functionality of Rails, let alone the gem ecosystem of Ruby/Rails. If you don't need it, great! Otherwise, you're spending time re-implementing what already exists and probably doing a worse job of it.
    - ilovecaching 8y ago
      > The Go standard library doesn't come close to replicating the functionality of Rails Why would it? It's the standard library. Go has a massive ecosystem of third parties libraries, and unlike Ruby, which was a one trick pony, Go has libraries for pretty much anything you could want to do. It's exceedingly versatile and it has better integration into modern infra. Why? Because it's all written in Go. Prometheus, Kubernetes, etcd, terraform, docker, caddy, fleet, influxDB, synthing, coachroachDB, gogs, mino... all written in Go. Go is cloud first, and has first class support for multicloud abstractions written by the go team. It's got great support for rpc through grpc and protocol buffers both of which are much easier to use in a statically compiled C like language that resembled the protocol buffers primitives. Rails literally offers nothing you can't get from Go, and it doesn't make you pay for the stuff you aren't using. With Go you don't write in a DSL based on the language, you just write regular Go code. You aren't a rails developer, you're a Go developer.
chmln 8y ago
It's a bit ridiculous to reduce Rust to the requirement of "performance" or parametric polymorphism. Go doesn't have a proper, complete type system. This means entire classes of preventable bugs are not prevented by the compiler. Yeah, its fast, but you can pass in null instead of object references and the compiler won't even bat an eye. Not to mention the extremely verbose error handling and the lack of abstractions all around (no sum types, no iterators, no array filter/map, etc) despite being more "high-level" than Rust in layman terms.
- ilovecaching 8y ago
  > Go doesn't have a proper, complete type system. This is nonsense. There's no definition or checklist that defines what a complete type system is. In that vein, Haskell doesn't have a proper type system because it lacks dependent types, and a bunch of other features that are only available through language extensions. We are still not at a place yet where the from first principles, type driven approach is going to always be the right choice over the hack out code approach. Rust simply takes more investment to learn, and more time to master, and while I agree that investment pays off 1000x, and that Java and C++ should stop existing, Go is a better fit for the people who just want a productive, reasonably efficient language that can get stuff done. Having a very simple hammer like Go that limits what people can do and sticks to what people already know is useful and beneficial.
  - chmln 8y ago
    > This is nonsense. There's no definition or checklist that defines what a complete type system is The Go programming language and the compiler have too many soundness holes, therefore I call the type system incomplete. When you can pass in a null literal in place of an object and the compiler doesn't stop you, it goes against any common sense. Not to mention the pervasive use of reflection (interface{}) due to lack of generics. Allowing null pointers to exist in a new programming language is a decision to ignore decades of progress in pl theory and type system research. It makes sense for google knowing the motivation behind Go, but telling people to avoid Rust unless they need polymorphism or performance is disingenuous at best. > We are still not at a place yet where the from first principles, type driven approach is going to always be the right choice over the hack out code approach. Why not?
zaphirplane 8y ago
There is a strong narrative around rust being suitable for “extracting/wringing/squeezing” the last drop of performance. Why do people pushing those claims think a go program compiled down to native executable is slower then rust Is it the rust compiler is better ? Is the go stdlib slower ? Is it the gc The GC is going to add some overhead is it that bad for most uses except for real time critical large s/w
- brrt 8y ago
  No horse in the race, but: - The Rust compiler uses the LLVM backend, which is generally more aggressive about optimizations and code generation. The Go compiler is a custom compiler (I think plan 9 inherited) and as of fairly recently didn't do some optimizations that are fairly common otherwise (non-leaf inlining). - Rust as a language heavily favors automatic (stack) allocation, and does not favor complex object graphs, so that will often help make algorithms more cache-friendly. In go, stack allocation is strictly an optimization. This is somewhat defeated by the common use of 'smart' pointer types. - Due to using segmented stacks, the function prologue/epilogue is a bit more involved in go, than it is in a language like rust. So with rust, it is - with some work - possible to have code that executes as the equivalent C code would. I guess in go you could too, but it'd be quite a bit harder, and go against the grain of the language. Compared to the performance of a typical interpreted dynamic language, this is a fairly marginal difference however.
otabdeveloper1 8y ago
Rust is a nice idea, but as of 2019 C++17 is simply better in every way. Yes, there's can be benefit to starting from scratch with a different language w.r.t. training new teams with good habits and skills from the start. But going into Rust just because it's fashionable at the moment is a recipe for pain several years down the line. If you want a working pain-free solution learn C++17 instead.
- bschwindHN 8y ago
  > If you want a working pain-free solution learn C++17 instead A solution to what, exactly? I'll admit I haven't worked with C++ in awhile, but I'm skeptical of C++AnyYear being "pain-free". What do you like in C++17 that you feel is lacking in Rust?
- ilovecaching 8y ago
  This is a really bold statement that sounds like it’s coming from someone who is afraid that their knowledge of C++ is going to be obsoleted in a few years. C++ 17 is still a mess. You still lack a proper package manager, type constraints, modules, sane lookup rules for function calls, thread safety, a proper monastic future type, I could go on. Also most people won’t see C++ 17 or 14 for another decade. Even if the language decides to start bolting on more features the ecosystem is still very slow.
  - pjmlp 8y ago
    Those same people are less likely to throw their company jewels away and rewritte everything from scratch, specially if they are using UI toolkits, graphical debuggers, game engines or GPGPU.
  - otabdeveloper1 8y ago
    > C++ 17 is still a mess. No, it is not. > proper package manager, modules That's an OS usability issue, not a language problem. Personally, Nix solved this for me. > type constraints C++ has type constraints, and ones that actually work. I suspect what you call 'type constraints' is something that can't exist if you understand the difference between 'run-time' and 'compile-time'. > sane lookup rules for function calls A very minor issue. If you don't like function overloads, then don't use them. > thread safety, a proper monastic future type Please no. The kind of 'thread safety' you want destroys the benefit of using threads in the first place. C++ threading is perfect as it is. > Also most people won’t see C++ 17 or 14 for another decade. Frankly, I don't care about these twisted people stuck in enterprise hell.

rlander 8y ago

> Your company should be pivoting or have a strategy to get on deck with these languages. That’s a bold blanket statement. Besides the fact that I would die inside a little if I had to use Go every day of my life, Go is in no position to replace any of the aforementioned languages (Python, Js, Ruby, C++), let alone all of them, not by a mile.

hu3 8y ago
I don't think your parent meant that a language broadly replaces another but rather that Go and Rust lend themselves well for some types of projects typically done in other languages.
ilovecaching 8y ago
Not C++, but definitely the other languages outside of some non standard SWE domains like ML, where Python is going to be an obvious winner. Otherwise Go beats them by having a type system but still supporting duck typing through interfaces, having a modern concurrency story, being easier to learn (the Go spec can be read in one evening), having less features to abuse, faster development loops with lightning fast compile times and catching more errors at compile time, and just generally being faster and having a garbage collector that is tuned for low latency (a good fit for web services). We can also start faster which is really important for container workloads, idle with less memory which is important for horizontal scaling, and use less CPU which means smaller machines and more colo. Go also favors libraries over frameworks and is super thoughtful about using too many untested dependancies which means we don’t get stuck in frameworks that become legacy (rails) or use stuff that has security holes or that will change out from under us (npm).
- treis 8y ago
  >Go also favors libraries over frameworks and is super thoughtful about using too many untested dependancies which means we don’t get stuck in frameworks that become legacy (rails) The Go standard library doesn't come close to replicating the functionality of Rails, let alone the gem ecosystem of Ruby/Rails. If you don't need it, great! Otherwise, you're spending time re-implementing what already exists and probably doing a worse job of it.
  - ilovecaching 8y ago
    > The Go standard library doesn't come close to replicating the functionality of Rails Why would it? It's the standard library. Go has a massive ecosystem of third parties libraries, and unlike Ruby, which was a one trick pony, Go has libraries for pretty much anything you could want to do. It's exceedingly versatile and it has better integration into modern infra. Why? Because it's all written in Go. Prometheus, Kubernetes, etcd, terraform, docker, caddy, fleet, influxDB, synthing, coachroachDB, gogs, mino... all written in Go. Go is cloud first, and has first class support for multicloud abstractions written by the go team. It's got great support for rpc through grpc and protocol buffers both of which are much easier to use in a statically compiled C like language that resembled the protocol buffers primitives. Rails literally offers nothing you can't get from Go, and it doesn't make you pay for the stuff you aren't using. With Go you don't write in a DSL based on the language, you just write regular Go code. You aren't a rails developer, you're a Go developer.

chmln 8y ago

It's a bit ridiculous to reduce Rust to the requirement of "performance" or parametric polymorphism. Go doesn't have a proper, complete type system. This means entire classes of preventable bugs are not prevented by the compiler. Yeah, its fast, but you can pass in null instead of object references and the compiler won't even bat an eye. Not to mention the extremely verbose error handling and the lack of abstractions all around (no sum types, no iterators, no array filter/map, etc) despite being more "high-level" than Rust in layman terms.

ilovecaching 8y ago
> Go doesn't have a proper, complete type system. This is nonsense. There's no definition or checklist that defines what a complete type system is. In that vein, Haskell doesn't have a proper type system because it lacks dependent types, and a bunch of other features that are only available through language extensions. We are still not at a place yet where the from first principles, type driven approach is going to always be the right choice over the hack out code approach. Rust simply takes more investment to learn, and more time to master, and while I agree that investment pays off 1000x, and that Java and C++ should stop existing, Go is a better fit for the people who just want a productive, reasonably efficient language that can get stuff done. Having a very simple hammer like Go that limits what people can do and sticks to what people already know is useful and beneficial.
- chmln 8y ago
  > This is nonsense. There's no definition or checklist that defines what a complete type system is The Go programming language and the compiler have too many soundness holes, therefore I call the type system incomplete. When you can pass in a null literal in place of an object and the compiler doesn't stop you, it goes against any common sense. Not to mention the pervasive use of reflection (interface{}) due to lack of generics. Allowing null pointers to exist in a new programming language is a decision to ignore decades of progress in pl theory and type system research. It makes sense for google knowing the motivation behind Go, but telling people to avoid Rust unless they need polymorphism or performance is disingenuous at best. > We are still not at a place yet where the from first principles, type driven approach is going to always be the right choice over the hack out code approach. Why not?

zaphirplane 8y ago

There is a strong narrative around rust being suitable for “extracting/wringing/squeezing” the last drop of performance. Why do people pushing those claims think a go program compiled down to native executable is slower then rust Is it the rust compiler is better ? Is the go stdlib slower ? Is it the gc The GC is going to add some overhead is it that bad for most uses except for real time critical large s/w

brrt 8y ago
No horse in the race, but: - The Rust compiler uses the LLVM backend, which is generally more aggressive about optimizations and code generation. The Go compiler is a custom compiler (I think plan 9 inherited) and as of fairly recently didn't do some optimizations that are fairly common otherwise (non-leaf inlining). - Rust as a language heavily favors automatic (stack) allocation, and does not favor complex object graphs, so that will often help make algorithms more cache-friendly. In go, stack allocation is strictly an optimization. This is somewhat defeated by the common use of 'smart' pointer types. - Due to using segmented stacks, the function prologue/epilogue is a bit more involved in go, than it is in a language like rust. So with rust, it is - with some work - possible to have code that executes as the equivalent C code would. I guess in go you could too, but it'd be quite a bit harder, and go against the grain of the language. Compared to the performance of a typical interpreted dynamic language, this is a fairly marginal difference however.

otabdeveloper1 8y ago

Rust is a nice idea, but as of 2019 C++17 is simply better in every way. Yes, there's can be benefit to starting from scratch with a different language w.r.t. training new teams with good habits and skills from the start. But going into Rust just because it's fashionable at the moment is a recipe for pain several years down the line. If you want a working pain-free solution learn C++17 instead.

bschwindHN 8y ago
> If you want a working pain-free solution learn C++17 instead A solution to what, exactly? I'll admit I haven't worked with C++ in awhile, but I'm skeptical of C++AnyYear being "pain-free". What do you like in C++17 that you feel is lacking in Rust?
ilovecaching 8y ago
This is a really bold statement that sounds like it’s coming from someone who is afraid that their knowledge of C++ is going to be obsoleted in a few years. C++ 17 is still a mess. You still lack a proper package manager, type constraints, modules, sane lookup rules for function calls, thread safety, a proper monastic future type, I could go on. Also most people won’t see C++ 17 or 14 for another decade. Even if the language decides to start bolting on more features the ecosystem is still very slow.
- pjmlp 8y ago
  Those same people are less likely to throw their company jewels away and rewritte everything from scratch, specially if they are using UI toolkits, graphical debuggers, game engines or GPGPU.
- otabdeveloper1 8y ago
  > C++ 17 is still a mess. No, it is not. > proper package manager, modules That's an OS usability issue, not a language problem. Personally, Nix solved this for me. > type constraints C++ has type constraints, and ones that actually work. I suspect what you call 'type constraints' is something that can't exist if you understand the difference between 'run-time' and 'compile-time'. > sane lookup rules for function calls A very minor issue. If you don't like function overloads, then don't use them. > thread safety, a proper monastic future type Please no. The kind of 'thread safety' you want destroys the benefit of using threads in the first place. C++ threading is perfect as it is. > Also most people won’t see C++ 17 or 14 for another decade. Frankly, I don't care about these twisted people stuck in enterprise hell.