5 ms·

I predict exactly the opposite. Baking ownership into the type system makes API design and refactoring hard, while having GC makes memory management entirely o

by titzer 6y ago

I predict exactly the opposite. Baking ownership into the type system makes API design and refactoring hard, while having GC makes memory management entirely orthogonal and easy to change. Go is already over 10 years old and designed by people who have worked on software for 30, sometimes 40, years. Go changes slowly and Rust is still evolving.

guscost 6y ago
If your opinion is as simple as “Go will be more better than Rust”, or the opposite, it is far too simple to be correct. Rust is unbeatable for services you want to deploy, stabilize, and forget about forever. Go is pretty darn good for building out complicated/messy services in an iterative process.
- throwaway09223 6y ago
  Go is the optimal language for a company that wants one (or more) microservice per engineer. It's a great language for padding out bulletpoints for a promo packet.
- dnautics 6y ago
  > Rust is unbeatable for services you want to deploy, stabilize, and forget about forever. Erlang.
  - guscost 6y ago
    More expensive, and not always necessary. But great point.
    - dnautics 6y ago
      You will never have a stabilized system unless you are multinode. Hardware will fail. Rust is not good at this.
gpm 6y ago
> and refactoring hard The opposite, it makes refactoring really easy, because it's so hard to screw up mechanical changes. The memory management aspect of refactoring is slightly more tedius in rust (compared to go), because you have to update lifetime annotations sometimes. This is a mechanical process and not hard. The trade off is that the existence of lifetimes and ownerships means that many of the rest of refactoring tasks (getting locks right, not introducing data races, making sure you're not doing something dumb like accessing a freed fd, etc) are much simpler. Rust is also better than go at refactoring because go's ducktyping (and reflection) means that there is frequently action at a distance that is hard to track down. Changing the name of a field of a struct can change behavior in another file that never mentions the field by name. Go is in the middle of adding generics to the language, I don't think Rust has made a change of that magnitude since it hit 1.0...
- rowchain 6y ago
  > The memory management aspect of refactoring is slightly more tedius in rust (compared to go), because you have to update lifetime annotations sometimes. It is much more complicated. You sometimes have to implement clone, pin/project, box etc to satisfy new trait bounds for example. Also, build times can make refactoring and iterating really painful. I like and use both languages; I think they are complimentary, and I think things need to be weighted more honestly than what I see in this discussion.
  - titzer 6y ago
    I am by no means a Golang developer, so don't construe my OP to be a particular endorsement of Go. But after 25 years writing C/C++, Java, Javascript, and working on language implementations, garbage collectors, JITs, VMs--what most people consider "system software"--I feel strongly that requiring programmers to reason about ownership for memory management is a complete waste of everyone's time. It's more mental load than programmers should not be burdened with, no matter how good the tools for it are. The performance costs of GC are routinely overstated by C/C++/Rust advocates to the point that GC implementation experts have pretty much become cut off from the conversation. No one really measures properly, anyway. My honest opinion is that it is 2021 and it's about time we let computers manage memory already. Rust can have their ownership for race conditions if they want, but I am so tired of being gaslighted about how important it is that I be hounded to track every solitary byte of memory when I am busy thinking about more important things.
afiori 6y ago
GC and tracking ownership are orthogonal; the lifetimes of GC references and normal references would be different, but rust could perfectly well have a GC by default
- simiones 6y ago
  It could, but it won't. If we're talking about real-world use, this makes all the difference. C or C++ could have a GC as well (in fact, they do - you can use Boehm for any C or C++ program), but there are approximately 0 programs that do.
  - pjmlp 6y ago
    C++/CLI, C++/CX and Unreal C++ are example of C++ programs that do use some form of GC, just not Boehm.
    - simiones 6y ago
      I didn't know about Unreal C++ using a GC, but the others have extremely little use. So little, that C++/CLR (at the time) had a bug for at least 2 years where doing something like initializing a CLR List (CLR, not std::) with an initializer list (I have forgotten the exact syntax, but it is similar to `auto lst = new List<int>{a, b}`) would allocate millions of elements on the heap (if I remember correctly, it would create a List of size 0xC0FFEE, or maybe it was 0xDEADBEEF - either way, obvious debug code, then set list[0]=a and list[1]=b).
kaba0 6y ago
And in what aspect is Go a better than the million other language with GC? Like, it is C level bad at expressivity, way too verbose because hardly any abstraction can be made there. Concurrency is the only thing going for it. But how is it any better than Java or C#? And Rust is a low level language, so it has to get away with rare cases where a GC is not applicable. And being low level of course imposes the memory layout of the program on APIs as well, but that is a known trade off when one goes low level.

by titzer 6y ago

guscost 6y ago

If your opinion is as simple as “Go will be more better than Rust”, or the opposite, it is far too simple to be correct. Rust is unbeatable for services you want to deploy, stabilize, and forget about forever. Go is pretty darn good for building out complicated/messy services in an iterative process.

throwaway09223 6y ago
Go is the optimal language for a company that wants one (or more) microservice per engineer. It's a great language for padding out bulletpoints for a promo packet.
dnautics 6y ago
> Rust is unbeatable for services you want to deploy, stabilize, and forget about forever. Erlang.
- guscost 6y ago
  More expensive, and not always necessary. But great point.
  - dnautics 6y ago
    You will never have a stabilized system unless you are multinode. Hardware will fail. Rust is not good at this.

gpm 6y ago

> and refactoring hard The opposite, it makes refactoring really easy, because it's so hard to screw up mechanical changes. The memory management aspect of refactoring is slightly more tedius in rust (compared to go), because you have to update lifetime annotations sometimes. This is a mechanical process and not hard. The trade off is that the existence of lifetimes and ownerships means that many of the rest of refactoring tasks (getting locks right, not introducing data races, making sure you're not doing something dumb like accessing a freed fd, etc) are much simpler. Rust is also better than go at refactoring because go's ducktyping (and reflection) means that there is frequently action at a distance that is hard to track down. Changing the name of a field of a struct can change behavior in another file that never mentions the field by name. Go is in the middle of adding generics to the language, I don't think Rust has made a change of that magnitude since it hit 1.0...

rowchain 6y ago
> The memory management aspect of refactoring is slightly more tedius in rust (compared to go), because you have to update lifetime annotations sometimes. It is much more complicated. You sometimes have to implement clone, pin/project, box etc to satisfy new trait bounds for example. Also, build times can make refactoring and iterating really painful. I like and use both languages; I think they are complimentary, and I think things need to be weighted more honestly than what I see in this discussion.
- titzer 6y ago
  I am by no means a Golang developer, so don't construe my OP to be a particular endorsement of Go. But after 25 years writing C/C++, Java, Javascript, and working on language implementations, garbage collectors, JITs, VMs--what most people consider "system software"--I feel strongly that requiring programmers to reason about ownership for memory management is a complete waste of everyone's time. It's more mental load than programmers should not be burdened with, no matter how good the tools for it are. The performance costs of GC are routinely overstated by C/C++/Rust advocates to the point that GC implementation experts have pretty much become cut off from the conversation. No one really measures properly, anyway. My honest opinion is that it is 2021 and it's about time we let computers manage memory already. Rust can have their ownership for race conditions if they want, but I am so tired of being gaslighted about how important it is that I be hounded to track every solitary byte of memory when I am busy thinking about more important things.

afiori 6y ago

GC and tracking ownership are orthogonal; the lifetimes of GC references and normal references would be different, but rust could perfectly well have a GC by default

simiones 6y ago
It could, but it won't. If we're talking about real-world use, this makes all the difference. C or C++ could have a GC as well (in fact, they do - you can use Boehm for any C or C++ program), but there are approximately 0 programs that do.
- pjmlp 6y ago
  C++/CLI, C++/CX and Unreal C++ are example of C++ programs that do use some form of GC, just not Boehm.
  - simiones 6y ago
    I didn't know about Unreal C++ using a GC, but the others have extremely little use. So little, that C++/CLR (at the time) had a bug for at least 2 years where doing something like initializing a CLR List (CLR, not std::) with an initializer list (I have forgotten the exact syntax, but it is similar to `auto lst = new List<int>{a, b}`) would allocate millions of elements on the heap (if I remember correctly, it would create a List of size 0xC0FFEE, or maybe it was 0xDEADBEEF - either way, obvious debug code, then set list[0]=a and list[1]=b).

kaba0 6y ago

And in what aspect is Go a better than the million other language with GC? Like, it is C level bad at expressivity, way too verbose because hardly any abstraction can be made there. Concurrency is the only thing going for it. But how is it any better than Java or C#? And Rust is a low level language, so it has to get away with rare cases where a GC is not applicable. And being low level of course imposes the memory layout of the program on APIs as well, but that is a known trade off when one goes low level.