3 ms·

I like this article and I agree with most of what was said there. Against that type of point-by-point criticism, fans of a language will usually use the argume

by pmilot 11y ago

I like this article and I agree with most of what was said there. Against that type of point-by-point criticism, fans of a language will usually use the argument: "but that language was not designed for that!". Then the question becomes: What was that language designed for? My impression was that Go was meant to be a slightly higher-level systems language with better constructs for concurrent programming. With that in mind, it seems to me that Rust is just a "better Go".

masklinn 11y ago
Rust's target of being a better C++ means it tends to be more verbose than Go, and less convenient in the short run (no built-in — let alone syntactic — support for evented IO and CSP)
- steveklabnik 11y ago
  > (no built-in — let alone syntactic — support for evented IO and CSP) Channels are in the standard library[1], while async io is in an external package, almost everything is in Rust, and it is one of the packages that will end up making that jump to be in the standard library fairly quickly. [1]: and, isn't as big of a deal in Rust since we make shared memory significantly safer in the first place.
Veedrac 11y ago
I can't really see a world in which Rust is a "better Go". Rust is one of the more complex languages in existence, largely because it competes with C++ and thus can't afford to lose many features nor do many things the easy way. Go is one of the simplest languages in existence. It's on the other side of the charts.
- masklinn 11y ago
  > Go is one of the simplest languages in existence. No, not even close.
- vvanders 11y ago
  Rust has many things that C++ doesn't have, and that's a good thing. I think you might want to spend a bit more time with Rust before considering it just another C++.
  - Veedrac 11y ago
    I know Rust has things C++ doesn't have, and vice-versa. I don't see how that changes my argument that it's competing, though. Consider inheritance vs. traits. Rust isn't able to stick with just traits because there are some things, though few, that are slightly faster with inheritance. So Rust is going to get some form of inheritance (in whatever form it might take). For every bit of functionality in C++, there is or will be some alternative in Rust, and that's by design. The same is not at all true for Go.
- wyager 11y ago
  > Go is one of the simplest languages in existence. By what metric? I can think of a lot of simpler languages. Lua, C, Forth, all the theoretical dead-simple combinator languages you don't want to use (Lambda Calculus, SKI calculus, etc.), etc...
  - Veedrac 11y ago
    > Lua, C, Forth Are all simple, yes. That C is on your list is kind'a the point - Go is explicitly a spiritual derivative of C. But go down on the TIOBE index[1] and tell me what fraction of languages there are as simple as Go. It's not a large fraction. [1]: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
- jbeja 11y ago
  > Go is one of the simplest languages in existence Are you saying that is simple because: 1) Is so anemic and have a relatively small specification? 2) Let you solve problems in the most simple ways? I could (maybe) kinda agree if you refer to 1...kinda.
tomekowal 11y ago
Argument "that language was not designed for that!" is valid almost anytime anyone tries to criticize a programming language. Go was designed within Google for Google. Where your system has millions of lines of code and thousands of developers work on them constantly. So they thought about three things: compilation speed, memory management and concurrency. Go compiles fast, so you can iterate quickly. This requires giving up most of the compilation safety checks. They can be done by static analysis tools in parallel. Explicit memory management means, you can sometimes optimize this 0.05% memory on your program. This means a lot, when you run your code on million machines. Concurrency isn't hard in Go, but explicit memory management makes it harder than in Erlang for example (in Erlang, you have "share nothing" policy). Go is also very simple, so one developer won't be surprised by other developer using some obscure feature. That being said. I wouldn't recommend using Go outside of Google, Facebook or Microsoft. It solves problems, that companies and developers usually don't have. If you need always running and quickly evolving software - there is Erlang and Elixir. If you need guarantees on correctness, use static typing from Haskell. If you can resign from some guarantees to have grater control on memory, there is Rust. If you are writing in browser, there is Elm. If you want to easily transition from OO to functional programming - try Scala. If you need to prototype app for your startup quickly - there is Ruby. Every popular language has its purpose and its trade-offs. Rust isn't strictly better than Go, but with high probability, it is better than Go for your problem.
- pmilot 11y ago
  Compilation speed is a very good argument for Go, yeah. That often seems disregarded in a lot of these sorts of comparisons, but it's a really important factor since it directly affects the level of complexity your language can have.

by pmilot 11y ago

masklinn 11y ago

Rust's target of being a better C++ means it tends to be more verbose than Go, and less convenient in the short run (no built-in — let alone syntactic — support for evented IO and CSP)

steveklabnik 11y ago
> (no built-in — let alone syntactic — support for evented IO and CSP) Channels are in the standard library[1], while async io is in an external package, almost everything is in Rust, and it is one of the packages that will end up making that jump to be in the standard library fairly quickly. [1]: and, isn't as big of a deal in Rust since we make shared memory significantly safer in the first place.

Veedrac 11y ago

I can't really see a world in which Rust is a "better Go". Rust is one of the more complex languages in existence, largely because it competes with C++ and thus can't afford to lose many features nor do many things the easy way. Go is one of the simplest languages in existence. It's on the other side of the charts.

masklinn 11y ago
> Go is one of the simplest languages in existence. No, not even close.
vvanders 11y ago
Rust has many things that C++ doesn't have, and that's a good thing. I think you might want to spend a bit more time with Rust before considering it just another C++.
- Veedrac 11y ago
  I know Rust has things C++ doesn't have, and vice-versa. I don't see how that changes my argument that it's competing, though. Consider inheritance vs. traits. Rust isn't able to stick with just traits because there are some things, though few, that are slightly faster with inheritance. So Rust is going to get some form of inheritance (in whatever form it might take). For every bit of functionality in C++, there is or will be some alternative in Rust, and that's by design. The same is not at all true for Go.
wyager 11y ago
> Go is one of the simplest languages in existence. By what metric? I can think of a lot of simpler languages. Lua, C, Forth, all the theoretical dead-simple combinator languages you don't want to use (Lambda Calculus, SKI calculus, etc.), etc...
- Veedrac 11y ago
  > Lua, C, Forth Are all simple, yes. That C is on your list is kind'a the point - Go is explicitly a spiritual derivative of C. But go down on the TIOBE index[1] and tell me what fraction of languages there are as simple as Go. It's not a large fraction. [1]: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
jbeja 11y ago
> Go is one of the simplest languages in existence Are you saying that is simple because: 1) Is so anemic and have a relatively small specification? 2) Let you solve problems in the most simple ways? I could (maybe) kinda agree if you refer to 1...kinda.

tomekowal 11y ago

Argument "that language was not designed for that!" is valid almost anytime anyone tries to criticize a programming language. Go was designed within Google for Google. Where your system has millions of lines of code and thousands of developers work on them constantly. So they thought about three things: compilation speed, memory management and concurrency. Go compiles fast, so you can iterate quickly. This requires giving up most of the compilation safety checks. They can be done by static analysis tools in parallel. Explicit memory management means, you can sometimes optimize this 0.05% memory on your program. This means a lot, when you run your code on million machines. Concurrency isn't hard in Go, but explicit memory management makes it harder than in Erlang for example (in Erlang, you have "share nothing" policy). Go is also very simple, so one developer won't be surprised by other developer using some obscure feature. That being said. I wouldn't recommend using Go outside of Google, Facebook or Microsoft. It solves problems, that companies and developers usually don't have. If you need always running and quickly evolving software - there is Erlang and Elixir. If you need guarantees on correctness, use static typing from Haskell. If you can resign from some guarantees to have grater control on memory, there is Rust. If you are writing in browser, there is Elm. If you want to easily transition from OO to functional programming - try Scala. If you need to prototype app for your startup quickly - there is Ruby. Every popular language has its purpose and its trade-offs. Rust isn't strictly better than Go, but with high probability, it is better than Go for your problem.

pmilot 11y ago
Compilation speed is a very good argument for Go, yeah. That often seems disregarded in a lot of these sorts of comparisons, but it's a really important factor since it directly affects the level of complexity your language can have.