I want to use Go, but whenever I compile a small CLI tool using it and it comes out as a 10 MB executable, I just feel ashamed. Especially when Zig and many other tools can produce the same thing at a few KB.
Go is my hammer, and everything is a nail
601–610 of 816 posts
Re: Go is my hammer, and everything is a nail
#602Earlier quoted context omitted.
> Go and Node have some significant overlap, but Go and Rust are > barely even competitors. Among the people I know Go and Rust seem to be at the top of their list. Almost all people I know who program Rust also know Go. Not as many Go programmers I know program in Rust as well, but some know Rust and even more want to learn it. Which probably isn't too peculiar because Rust is more of a kerfuffle to program in. I'm…
That likely suggests the people you know are working on a specific kind of project.
Perhaps. Most people I work with do servers/backends, distributed systems and embedded systems.
I think it may have more to do with the kind of people I work with.
Re: Go is my hammer, and everything is a nail
#603Earlier quoted context omitted.
You can write abstractions in Go and it has generics. Its just that the abstraction aren't as good so you end up with harder to read code.
You're holding the phone wrong. Kubernetes does the same. So does Docker, and just about every Go project. You don't understand Go.
I've been coding full time in it on a large team for four years now. If Go is this difficult to comprehend, then maybe its not the simple language it claims to be.
Re: Go is my hammer, and everything is a nail
#604Earlier quoted context omitted.
> Instead of loading data into Pandas and doing a group by SQL can do `group by`. No need for overkill with "data science tools".
While definitely doable, using a SQL database to do data discovery is obtuse.
It's obtuse, but it's effective for some people. I know someone who hires devs from the .NET and Python space for finance. When asked to suggest a solution to any kind of data problem like this the interviewees split down the middle with the .NET ones almost entirely using a relational database and the Python ones using either the library du jour or suggesting something on the command line (since they often have Linux experience.)
In both parts of their org, the .NET area tends to use SQL exclusively for analysis and the Python folks use Pandas and bunch of other stuff. These departments are also in significantly different parts of their organization with their own mandates and culture.
Re: Go is my hammer, and everything is a nail
#605"Reason 1: Go can do basically anything"
So how do you build an OS kernel in Go? C folks have been doing it for decades. Rust guys are slowly catching up. And Go...?
Re: Go is my hammer, and everything is a nail
#606I want to use Go, but whenever I compile a small CLI tool using it and it comes out as a 10 MB executable, I just feel ashamed. Especially when Zig and many other tools can produce the same thing at a few KB.
In my case after hearing one of the main devs of Go (I forgot his name tbh) in an interview saying they'd NEVER implement generics, it just rubbed me the wrong way.
The other thing is, despite having touched Go since its early days (late 2000s) I don't have enough real world experience with it. I'm too self-critical to ever apply for jobs I don't feel confident in. So until someone just offers me work with it I probably wont use it as much as I could.
Re: Go is my hammer, and everything is a nail
#607Earlier quoted context omitted.
Personally I don't find it great for prototyping. There's just too much boilerplate, which is why I use other languages for fun/personal projects.
Is there much boilerplate aside from err checks and JSON tags? Even then, your IDE / copilot should automatically insert those along with imports and package names.
Err checks are a big one. I don't want to worry about error handling when prototyping. There are little things like having to prefix methods with the struct name and type, and bigger things like no default arguments and by name parameters, which makes setting up test fixtures cumbersome. Also, functions don't compose well because there can be more than one return value, so you end up just writing more intermediate values.
Re: Go is my hammer, and everything is a nail
#608Earlier quoted context omitted.
2012: Python is Awesome! 2014: Python is a great language, but there are a few pitfalls 2016: Python is a good language with the right IDE, tooling, and process. The people are pretty cool though. 2018: I like python, but I wish more people used type annotations. 2020: You know, metaclasses are freaking awesome! They saved me so much work! 2022: Why can't people code the most obvious solution in python? 2024: Celery!…
2012: Python is Awesome! 2014: Python is a pain in the butt to manage packages and dependencies, how the hell am I gonna deploy this? It's still a mess 10 years later unless you live deep in the ecosystem and know what third-party solutions du jour to manage that complexity. At least we have Docker now. Also let's not forget the Python 3 migration fiasco that lasted ~2008-2018 and I still find myself porting librarie…
Hah, even at Google, the Python 3 migration lasted well into 2020.
Re: Go is my hammer, and everything is a nail
#609Earlier quoted context omitted.
"Simple" is a cop-out word. Things can be simple along a lot of vectors. The vector you've chosen seems to be "does less for you" which taken ad absurdum would have you using assembly. Go does have elegant abstractions, and they aren't the simplest along this vector, nor would anyone want them to be. Coroutines, for example, are actually quite conceptually complicated in some ways. I prefer "understandable"--it appea…
> Attacking Haskell is sort of a straw man--so far I haven't seen anyone in this thread propose Haskell as a go alternative. I think we agree Haskell is far too dogmatic about its abstractions when it's impractical to be used as a general-purpose language (because I don't think it's intended as a general-purpose language). I'll be that guy. We like our stuff in Haskell. Watching the rest of the industry move forward…
The issue is not language semantic. The issue is readability. Having the best feature set in the world is useless if the code produced by others is a pain to decipher.
Haskell disqualified itself for general programming when its community decided that point-free was desirable despite the style being impossible to read and custom operators were a good thing. I personally hate every Haskell code base I have ever seen despite being relatively fluent in the language (an issue Ocaml never had amusingly mostly because its community used to be very pragmatic).
Re: Go is my hammer, and everything is a nail
#610Earlier quoted context omitted.
> and Java is shockingly bad too, although a lot of that is down to the way the JVM/language have been mismanaged This is interesting and not what I would expect. Generally to get a java app running from github you'd install the correct JDK and that should be about it. Many projects will use maven, which will know how to obtain dependencies. Could you describe a typical issue?
Dependencies requiring you edit some random XML file somewhere on your machine to get them working. That and the whole JVM fragmentation and not being able to touch Oracle because it's Oracle and they'll use it as an excuse to sue you (at least that's the impression I had, the entire lawsuits thing is why I left Java back in the day). You can say the same about other package managers, but it's not very often that I h…
Editing your dependencies in maven is not some "random XML file somewhere", come on. It's a standard file that is situated like any build declaration.