5 ms·

On the contrary. I’ve been recently writing a web service in Go… and omg what a terrible experience. Sure, I could prototype something very quickly, but now it’

by jmmv 4y ago

On the contrary. I’ve been recently writing a web service in Go… and omg what a terrible experience. Sure, I could prototype something very quickly, but now it’s almost impossible to refactor any of it without introducing subtle breakage. And it’s sooooo verbose and redundant and fragile. I’m currently rewriting what I wrote in Rust to see how the prototypes compare and… I just feel so much at peace knowing that the type system and the borrow checker have my back and that I won’t encounter unexpected nil pointers or zero values. And I write this quickly as well. (Yes, I do have experience with both languages, so none of these exercises were new to me. But I’ve been favoring Rust over the last couple of years.)

jmaker 4y ago
Quite the opposite here. Go is very easy to refactor if need be. What kind “breakages” are you talking about? Go being “verbose”? Or “fragile”? I doubt we’re talking about the same Go. In Go you have a garbage collector, no need for the borrow checker or reference counting on your side. What unexpected nil pointers or zeros? It’s all easy and straightforward in Go. If you’re referring to the handling of materialized interfaces, which one may encounter in form of concrete error types, and which is one of Go’s idiosyncrasies, then it might help to look deeper into learning how to handle Go’s interfaces.
- drogus 4y ago
  > Go being “verbose”? Or “fragile”? I doubt we’re talking about the same Go. Maybe compared to C, Go is quite concise, but Go is nowhere near Rust's level of expressiveness, especially with poor generics support, much more verbose error handling etc. > no need for the borrow checker or reference counting on your side. I think that people that mention borrow checker in context of backend dev haven't done much backend dev in Rust. The nature of a web backend is to (most of the time) get data from the client, process, return a response. In this context you very rarely have to think about borrow checker and almost never use explicit lifetimes. > What unexpected nil pointers or zeros? It’s all easy and straightforward in Go If you forget to initialize a struct, you may end up with a nil pointer and you might not catch it until runtime.
Patrickmi 4y ago
[dead]

by jmmv 4y ago

jmaker 4y ago

Quite the opposite here. Go is very easy to refactor if need be. What kind “breakages” are you talking about? Go being “verbose”? Or “fragile”? I doubt we’re talking about the same Go. In Go you have a garbage collector, no need for the borrow checker or reference counting on your side. What unexpected nil pointers or zeros? It’s all easy and straightforward in Go. If you’re referring to the handling of materialized interfaces, which one may encounter in form of concrete error types, and which is one of Go’s idiosyncrasies, then it might help to look deeper into learning how to handle Go’s interfaces.

drogus 4y ago
> Go being “verbose”? Or “fragile”? I doubt we’re talking about the same Go. Maybe compared to C, Go is quite concise, but Go is nowhere near Rust's level of expressiveness, especially with poor generics support, much more verbose error handling etc. > no need for the borrow checker or reference counting on your side. I think that people that mention borrow checker in context of backend dev haven't done much backend dev in Rust. The nature of a web backend is to (most of the time) get data from the client, process, return a response. In this context you very rarely have to think about borrow checker and almost never use explicit lifetimes. > What unexpected nil pointers or zeros? It’s all easy and straightforward in Go If you forget to initialize a struct, you may end up with a nil pointer and you might not catch it until runtime.

Patrickmi 4y ago

[dead]