111–120 of 318 posts
Earlier quoted context omitted.
This is a conscious decision. I believe the reasoning was readability. Ternary operators have a habit of being used in some really nasty nesting. https://golang.org/doc/faq#Does_Go_have_a_ternary_form
Nesting if/then/else don't make code more readable either.
Earlier quoted context omitted.
I miss generics, not because I would write new generic functions all the time, but because a few key generics provide infrastructure that increases the beauty of programs dramatically. The tupled (T, error) return types are a key area I think generics would help. The error-tuples themselves aren't the problem, but rather Go's inability to cleanly handle them. Threading error state around requires repetitive glue code…
I don't mind the repetitive glue code. It might be nice to clean it up a bit, but it's the least of my concerns with Go. When I miss generics, it's usually for some tree-like structure, but the cases where I need a high-performance tree structure and can't take the performance hit of `interface{}` are few and far between.
Earlier quoted context omitted.
I've taken a very similar path recently myself and started looking into Rust. > 2. Proper error handling. I love error checking Hugely agree here. I can get behind Go's overall mentality of returning errors instead of throwing exceptions, but in my mind there are not enough primitives in the language to keep this style of coding safe and sustainable. Rust's `Result` type, `try!` macro, and pattern matching are an inc…
> Overall though, Go is probably still the more practical choice between the two languages (due to Rust's incredibly high barrier to entry). It depends a lot on your use case. I wouldn't say that Go is unconditionally more practical: there are cases in which you just can't use it.
So, i was a Go developer for ~4 years, then for the last 4 months or so i've been learning and using Rust. The pure joy of some things with Rust was astounding. Now, i joined a new job and they're in need of a new language for some backend tasks - the choice was mine. Rust or Go? The backend tasks were heavy API servers - nothing amazing, we don't do groundbreaking work. Python was their existing language, but they w…
"Channels without panics. Channels are awesome, but Go's design of them means that you have to learn special ways to design your usage of channels so that it does not crash your program. This is asinine to me. So much type safety exists in Go, and yet it's so easy for a developer to trip over channels and crash their program." I've solved this in my programming by finally coming to grips with the fact that channels a…
The only corner case is multi-producer channels, which either need additional synchronization or could be left open and garbage-collected.
seven years of go and they still don't have a ternary operator.
This is a conscious decision. I believe the reasoning was readability. Ternary operators have a habit of being used in some really nasty nesting. https://golang.org/doc/faq#Does_Go_have_a_ternary_form
a = flag ? b : c
if flag {
a = b
} else {
a = c
}
Go is really getting to a point that is not just the new cool thing in town, but a language that makes sense to use in production.
Earlier quoted context omitted.
Choosing Rust in a shop where no one knows Rust is indeed a big mistake where in Go it's pretty easy to pick up the language quickly.
My experience is the exact opposite. Most of the people who I work with now using Rust did not know any Rust at the time they were hired. There haven't been any major problems at all. Do you have experience that shows otherwise?
Earlier quoted context omitted.
This is a conscious decision. I believe the reasoning was readability. Ternary operators have a habit of being used in some really nasty nesting. https://golang.org/doc/faq#Does_Go_have_a_ternary_form
a = flag ? b : c is much more readable and concise than if flag { a = b } else { a = c } battling habits by making useful code inconvenient is just sad
Earlier quoted context omitted.
> what it does couldn't possibly be done in e.g. Python What can you do in Go that you can't do in other languages? I can't think of anything. The only major benefits over, say, C++ or Java (which I don't think are very impressive languages) are a few convenient threading primitives, but you also lose a lot of expressive power.
Efficient concurrent programming. I'm not aware of any cross-platform C/C++ or Python libraries that give you async I/O + multi-threaded coroutines. Such a library exists for the Java ecosystem (quasar), but IIRC, it's enabled by clever bytecode tricks, so it's not built with vanilla Java. Further, you still have to take care not to use any libraries that are incompatible with this concurrency model (e.g., anything t…
99% of projects don't need green threads. But for those that do, I'd much rather use a language better suited to the purpose, like Haskell or Erlang. This isn't a very convincing argument for Go.