4 ms·

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 an

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.
      - steveklabnik 8y ago
        Cool cool. Both have advantages and drawbacks; I think both languages have made the right choice given their contstraints.
- pjmlp 8y ago
  While it gives the safety of a GC, it still doesn't give the ergonomics, specially when doing GUIs.
- 13415 8y ago
  I personally prefer having a good GC because I need the speed of manual management in only a minuscule percentage of my code and it's much simpler to use a GC instead of constantly fiddling around with manual memory management, let alone the borrow checker and lifetimes. It's a matter of productivity and fun.
  - courtf 8y ago
    In addition, it's pretty easy to avoid heap allocations in Go, so you can do some basic (but effective) management without breaking a sweat.
alehander42 8y ago
Another quite fast language with GC(actually you can choose between several), generics and ADT(also pattern matching with libraries) is Nim. People also use it for concurrent code, but I don't have so much experience in that aspect

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.
    - steveklabnik 8y ago
      Cool cool. Both have advantages and drawbacks; I think both languages have made the right choice given their contstraints.
pjmlp 8y ago
While it gives the safety of a GC, it still doesn't give the ergonomics, specially when doing GUIs.
13415 8y ago
I personally prefer having a good GC because I need the speed of manual management in only a minuscule percentage of my code and it's much simpler to use a GC instead of constantly fiddling around with manual memory management, let alone the borrow checker and lifetimes. It's a matter of productivity and fun.
- courtf 8y ago
  In addition, it's pretty easy to avoid heap allocations in Go, so you can do some basic (but effective) management without breaking a sweat.

alehander42 8y ago

Another quite fast language with GC(actually you can choose between several), generics and ADT(also pattern matching with libraries) is Nim. People also use it for concurrent code, but I don't have so much experience in that aspect