Where I feel go is lacking is for data wrangling.
Group by, filter, map, join. It is just very error prone, inconvenient and slow to implement with for loops.
Go is my hammer, and everything is a nail
71–80 of 816 posts
Re: Go is my hammer, and everything is a nail
#72Earlier quoted context omitted.
I wasn't aiming for that. My point is more: I know Go already, it's good enough for my purposes, so I'm using that as my hammer. I could just as well have been Java or C# I learned eight years ago and used that for everything. :)
Just looking at Go after having experience with Erlang and Crystal, does it still have a narrow-minded view of what features language won't support? Like I remember there was a whole drama about generics, errors being simple strings and always returned without being able to raise them, is this attitude still there or have things changed?
That attitude is still there because there is no compelling reason to move away from that. A lot of languages have been diseased by bolting on features for no other reason than different languages have them, and it's overcomplicated the languages and fragmented the codebases.
Example, if you ask ten Scala developers to solve a problem, you'll get ten different solutions. That number drops quickly for less feature-rich and more opinionated languages like Go.
Re: Go is my hammer, and everything is a nail
#73I grew up writing C/C++ and I could write this same blog post but about Python for the same reasons that the author cites :-)
Sometimes I wonder if I am just being lazy and justifying not learning new stuff but then I look at the new stuff that keeps landing in the Python ecosystem and conclude otherwise.
Re: Go is my hammer, and everything is a nail
#74Earlier quoted context omitted.
I wasn't aiming for that. My point is more: I know Go already, it's good enough for my purposes, so I'm using that as my hammer. I could just as well have been Java or C# I learned eight years ago and used that for everything. :)
Just looking at Go after having experience with Erlang and Crystal, does it still have a narrow-minded view of what features language won't support? Like I remember there was a whole drama about generics, errors being simple strings and always returned without being able to raise them, is this attitude still there or have things changed?
No, that attitude is core to the design of Go and one of the key reasons people pick it for projects.
Generics were eventually added. But not until they thought through very carefully performance and compilation time implications.
Re: Go is my hammer, and everything is a nail
#75If all you know is a Hammer… I was searching for reasons why to use the Go-Hammer when there are comparable ones such as Java, C#, etc. but the article left me wanting. It strikes me that Go is riding the peak of hype languages, succeeding Rust and Node.js (which are all good pieces of technology and absolutely have their merit). And like with most hype driven decisions there is little (self) awareness of context and…
How can you call Go hype driven?
It was literally designed to be "boring".
Re: Go is my hammer, and everything is a nail
#76Earlier quoted context omitted.
Protobuf is not the default in Go the default is REST. What tools are a mess? Go tooling ( runtime ) and IDE integration is very good. Go is not a hyped language, we're past that cycle, some critical and widely used software are built in Go, millions of people rely on it.
Go tooling was relatively very good a decade ago but other languages have improved a lot since then, significantly because of its influence, and it's now about average. It's still better than python, and C or C++ of course. But about even with typescript, ruby, shit even php and ocaml have nearly caught up with their tooling. Go's is significantly worse than rust god help us and elixir has always made good excellent…
I consider that a win too tbh; JS land has improved a lot with e.g. Prettier and now Biome, and those were inspired by Go's formatter and stance saying "shut the fuck up about code formatting already, this is how it's formatted, end of story, go worry about more important things".
Re: Go is my hammer, and everything is a nail
#77If all you know is a Hammer… I was searching for reasons why to use the Go-Hammer when there are comparable ones such as Java, C#, etc. but the article left me wanting. It strikes me that Go is riding the peak of hype languages, succeeding Rust and Node.js (which are all good pieces of technology and absolutely have their merit). And like with most hype driven decisions there is little (self) awareness of context and…
> It strikes me that Go is riding the peak of hype languages. Very much so. Also it seems to be a strange choice as a solo developer when its strengths are explicitly targeted at large organizations. And I think the tooling is actually a bit of a mess compared to some other options. God help you if as a solo developer you start building on top of protobufs (another basically default choice in the Golang world...). I…
Faster on what axis?
Go has maybe the fastest compile times, for example. Which is very important when you are iterating on a project.
What do you dislike about the tool chain? Seems better than most languages to me.
Re: Go is my hammer, and everything is a nail
#78Earlier quoted context omitted.
What about the absence of exception handling? Plus OO has its own advantages, even if you don't use it all that much, its one of the best ways to fit problems into neat design patterns. Go seems to be missing those features.
This is my first time working with a language that exclusively uses errors as values, and I haven't had time to develop any strong feelings about it. So far it feels nice because it makes error handling crystal clear, but I could also see it becoming cumbersome over time.
I mean to this end, Go is more closer to Perl(C/Unix family) than to Python(Pascal? family).
But by now most programers are so very used to making the language do a lot of error handling kind of chores that having to do them manually kind of feels doing work that shouldn't be done(Like doing what the language should have been doing).
Of course you could bolt OO onto Go. In a way similar to how Perl provides kind of bare bones means assemble a OO system. But that is not the point, having syntax to this baked into the language just makes it easier and standardised to learn and use well.
Perhaps Go is Perl done right? Than a replace for Python.
But one has to see for how long it can maintain its minimalism. On the longer run code turns to be as complicated as the problem you are trying to solve. Removing the features doesn't make the code simple, it simply make it explicit(a.k.a Verbose)
Re: Go is my hammer, and everything is a nail
#79Earlier quoted context omitted.
I didn't mean faster in terms of execution time but in terms of development time. And more expressive is doing more with less code. We're at complete opposite ends of the spectrum here -- how that indicated to you that I meant assembly...
Go might not be the most concise or expressive language, but it's quite fast in terms of development time, IMO/IME.
Yeah, you just write code without worrying about whether it can be done more concise or clever, it's a very pragmatic language.
The downside is code volume, but honestly that is rarely the problem in software.
Re: Go is my hammer, and everything is a nail
#80I can't really disagree with the points the article makes in favor of Go, and it's not selling it over some other language/framework/tool but just celebrating how great of an ecosystem Go has. And it's true -- Go's ecosystem has matured into something very pleasant to work with.
By the same token I know professors who still write their simulation scripts in QBASIC because that's what they are familiar with and they can solve their problems quickly. You can use all sorts of tools to drive a nail.
On Go, it's almost a footnote in the context of the post, but I think a seriously underrated feature is its C-interoperability. Here [0] is an example. It's not unique of course -- tons of languages have some FFI solution for C libraries -- but Go's is I believe one of the most straightforward to use if you're already familiar with the language. And while there are portability/stability sacrifices you make when you call a native library, it does also expand the available dependencies even beyond "basically infinite."