151–160 of 296 posts
It is probably a bit misleading when so many say: 'golang is easy', it is not, it is as difficult as Java or other language, probably easier than c++ and rust, but definitely not an easy language. it makes great sense for network with concurrency, not so with real time or low resource devices to me.
I found it much easier than java, and a bit harder than python, for reference
Earlier quoted context omitted.
Async code is way nicer in Go than it is in Rust. It makes up for a lot for me when writing web services. Also Go is much easier to read vs Rust.
And much more error prone.
I really like the engineering principles in general that the Go team uses, however, I just don't like Go. That isn't meant as a slight or anything other than simply my opinion. That said, I really like the idea of a simple language based on the sort of principles demonstrated here. The runtime seems really nice, I just wish I liked the language better (IMO: not expressive enough, needs better error handling, needs mu…
First it would need to add error handling before it could look to improve upon it.
I'm not entirely convinced it should. I spend my days in a variety of other languages that have added error handling in various ways and, in my experience, it always ends up making errors unnecessarily difficult to do deal with. I regularly wish the idioms of those languages recognized errors as being core to your application as any other value, not something to treat differently. Go really got things right for the type of software I write.
But not all software is solving the same problems. There are a lot of programs where you don't need to think about errors; where stopping the world is fine if you encounter one. Go is not at all a good fit for these situations. However, I think it is okay for Go to not try to be all things to all people. We already have plenty of other good languages that serve other niches. Right tool for the job and all that.
I really like the engineering principles in general that the Go team uses, however, I just don't like Go. That isn't meant as a slight or anything other than simply my opinion. That said, I really like the idea of a simple language based on the sort of principles demonstrated here. The runtime seems really nice, I just wish I liked the language better (IMO: not expressive enough, needs better error handling, needs mu…
I also personally like Go a lot. It's filling the gap between C++ and Python for me. If I need something compiled with proper threading support, but C++ would be an overkill, I reach for Go.
Go is designed with a human centric view, IMHO: "Make writing great programs easier rather than design a language with novel/cutting edge features, but with a high cognitive load", and I find it as a noble aim as Rust's guarantees and aspirations.
I understand why people love Rust, but I don't think it's the only one, or the proverbial silver bullet that we finally achieved. Yes, it's nice. Yes, it brings many things to the table, but it's not the final solution for once and for all.
You like Rust? Great, Go for it (unintended pun alert), but I think we need all languages from all paradigms and perspectives.
I find this talk [0] very informative and useful while interacting with other languages and communities. I'm not sharing this with any insinuations towards you, but just find it generally perspective broadening.
[0]: https://www.youtube.com/watch?v=YX3iRjKj7C0 - What Killed Smalltalk could Kill Ruby.
I really like the engineering principles in general that the Go team uses, however, I just don't like Go. That isn't meant as a slight or anything other than simply my opinion. That said, I really like the idea of a simple language based on the sort of principles demonstrated here. The runtime seems really nice, I just wish I liked the language better (IMO: not expressive enough, needs better error handling, needs mu…
> needs better error handling First it would need to add error handling before it could look to improve upon it. I'm not entirely convinced it should. I spend my days in a variety of other languages that have added error handling in various ways and, in my experience, it always ends up making errors unnecessarily difficult to do deal with. I regularly wish the idioms of those languages recognized errors as being core…
varFoo, err := GetFoo()
if err != nil {
return err
Can be written as:
varFoo := GetFoo()?
Just like Rust, everyone would stop complaining about Go error handling. But they have this absolutist position on syntactic sugar, even for something like this that would make the language that much nicer to look at and work with.
I really like the engineering principles in general that the Go team uses, however, I just don't like Go. That isn't meant as a slight or anything other than simply my opinion. That said, I really like the idea of a simple language based on the sort of principles demonstrated here. The runtime seems really nice, I just wish I liked the language better (IMO: not expressive enough, needs better error handling, needs mu…
> needs better error handling First it would need to add error handling before it could look to improve upon it. I'm not entirely convinced it should. I spend my days in a variety of other languages that have added error handling in various ways and, in my experience, it always ends up making errors unnecessarily difficult to do deal with. I regularly wish the idioms of those languages recognized errors as being core…
I'm not sure what the better way to do it is tbh.
Earlier quoted context omitted.
> needs better error handling First it would need to add error handling before it could look to improve upon it. I'm not entirely convinced it should. I spend my days in a variety of other languages that have added error handling in various ways and, in my experience, it always ends up making errors unnecessarily difficult to do deal with. I regularly wish the idioms of those languages recognized errors as being core…
Just make it so: varFoo, err := GetFoo() if err != nil { return err } Can be written as: varFoo := GetFoo()? Just like Rust, everyone would stop complaining about Go error handling. But they have this absolutist position on syntactic sugar, even for something like this that would make the language that much nicer to look at and work with.
I'm used to a question mark being around null handling, but you know, JVM languages lol, null is thought about a lot.
Quoted post unavailable.
Overreacting much? I hope you don't work with other people