Live data from Hacker News

Go is my hammer, and everything is a nail

maragu.dev

131–140 of 816 posts

Re: Go is my hammer, and everything is a nail

#131
post #105

Go is everything I don’t want in a language for my personal projects. It’s verbose, every simple task feels like a lot to write. It’s not expressive, what would be a one-liner in Python makes you write three for loops in Go. I constantly need to find workarounds for the lack of proper enums, lack of sum types, no null safety etc. I’m sure these are the exact reasons why Go is good for enterprise software, but for per…

I would rather go had real enums, and I would _prefer_ if there were sum types. I agree it's more verbose, but I don't find that that verbosity really bothers me most of the time. Is res= [x for x in foo if "banned" in x] really actually more readable than var result []string for _, x := range foo { if strings.Contains(x, "banned") { result = append(result, x) } } ? I know it's 6 lines vs 1, but in practice I look at…

The new lines were eaten so it does make the python version more readable but I agree with you.

Re: Go is my hammer, and everything is a nail

#132
post #108

Earlier quoted context omitted.

Go was explicitly designed for fast compile times, especially compared to C++, and I haven't heard anything to suggest that's no longer the case. It was also designed as a more modern and mature replacement for C, and I can't think of many application domains where C is still the better choice. Python is at such a different point in the design space I don't think you can really compare the two. Same with PHP, Ruby, J…

> Go was explicitly designed for fast compile times, especially compared to C++, and I haven't heard anything to suggest that's no longer the case Well, it’s quite easy to be fast if you are just spewing out barely optimized machine code. Compilers aren’t slow just for the sake of it.

My understanding is there are more fundamental reasons for why Go compiles faster, like how it handles "includes". And not supporting the C++ templating system.

And some things that slow down compiles are not to improve optimization. But to support complex, higher level language features. Go seems to hit a sweet spot of being highly expressive without slow compile times.

Re: Go is my hammer, and everything is a nail

#133
post #105

Go is everything I don’t want in a language for my personal projects. It’s verbose, every simple task feels like a lot to write. It’s not expressive, what would be a one-liner in Python makes you write three for loops in Go. I constantly need to find workarounds for the lack of proper enums, lack of sum types, no null safety etc. I’m sure these are the exact reasons why Go is good for enterprise software, but for per…

So you're ok with Python, which doesn't have sum types or null safety, 2 out of 3 things you say are missing in Go.

In fact, Python didn't have any compile-type type until recently and compared to Go is slow and bloated.

So maybe the issue is not Go's lacking some features but something entirely different.

Re: Go is my hammer, and everything is a nail

#134
post #105

Go is everything I don’t want in a language for my personal projects. It’s verbose, every simple task feels like a lot to write. It’s not expressive, what would be a one-liner in Python makes you write three for loops in Go. I constantly need to find workarounds for the lack of proper enums, lack of sum types, no null safety etc. I’m sure these are the exact reasons why Go is good for enterprise software, but for per…

I would rather go had real enums, and I would _prefer_ if there were sum types. I agree it's more verbose, but I don't find that that verbosity really bothers me most of the time. Is res= [x for x in foo if "banned" in x] really actually more readable than var result []string for _, x := range foo { if strings.Contains(x, "banned") { result = append(result, x) } } ? I know it's 6 lines vs 1, but in practice I look at…

Go has real enums. All an enum does is count.

You're probably thinking of value constraints? Or, perhaps, exhaustive case analysis? Go certainly lacks those future.

And, indeed, they sound like nice features, but, to be fair, not well supported in any popular programming language. At best we get some half-assery. Which always questions if the popular languages are popular because of their lacking type systems?

Re: Go is my hammer, and everything is a nail

#135
post #95
post #47

The author lists multiple reasons for this, but for me the biggest one is the first one: Go is good for almost everything . I have extremely good productivity when using Go. Once your project exceeds 100 lines it is usually even better than python. And yes, I am aware that Rustians did a survey where Rust was crowned as the most efficient language but in my reality (which may differ from yours) Go is simply the best…

How is it different than, say, java for this generalist purpose?

Dependencies in Java are a pain in the ass.

Publishing libraries for your own consumption is even harder.

Publishing libraries for world consumption means now you also need to be a PKI expert.

Re: Go is my hammer, and everything is a nail

#136
post #95
post #47

The author lists multiple reasons for this, but for me the biggest one is the first one: Go is good for almost everything . I have extremely good productivity when using Go. Once your project exceeds 100 lines it is usually even better than python. And yes, I am aware that Rustians did a survey where Rust was crowned as the most efficient language but in my reality (which may differ from yours) Go is simply the best…

How is it different than, say, java for this generalist purpose?

As someone who isn't super proficient in Java I usually find Java daunting to get started with full of buckets of "meta" issues like in my other comment.

What JVM do I use? Does it matter?

Does it matter what version I install, what if I have to install/manage multiple versions?

If I want to write a web service can I use vanilla Java stdlib or do I have to use Spring or some framework? If I use Spring, do I have to get into the weeds of dependency injection and other complexity to actually get my app off the ground?

With Go, none of those questions exist. I install the latest Go, create a main.go file, I use net/http and I'm off to the races.

Re: Go is my hammer, and everything is a nail

#137
post #105

Go is everything I don’t want in a language for my personal projects. It’s verbose, every simple task feels like a lot to write. It’s not expressive, what would be a one-liner in Python makes you write three for loops in Go. I constantly need to find workarounds for the lack of proper enums, lack of sum types, no null safety etc. I’m sure these are the exact reasons why Go is good for enterprise software, but for per…

Damn, everything new really is old again. Everyone said the same thing about Java. Yet it still works and gets the job done. Go does as well. I'd rather poke my eyes out with a nail than use Python.

Do you write Go for fun as hobby, or do you agree with the OP?

Re: Go is my hammer, and everything is a nail

#138
post #105

Go is everything I don’t want in a language for my personal projects. It’s verbose, every simple task feels like a lot to write. It’s not expressive, what would be a one-liner in Python makes you write three for loops in Go. I constantly need to find workarounds for the lack of proper enums, lack of sum types, no null safety etc. I’m sure these are the exact reasons why Go is good for enterprise software, but for per…

That's why I love Go so much.

You want to write a very clever library using elegant abstraction and generics to have a cool innovative interface to solve your problem? Tough luck, you can't. So instead, you will just have to write a bog standard implementation with for-loops and good old functions which you will have to copy and tweak as needed where you really need something more complicated. It will work perfectly fine and end up being very readable for you and for the other persons reading your code.

Go is basically anti-Haskell. It forces you to be less clever and that's great.

Re: Go is my hammer, and everything is a nail

#139
I understand the sentiment. My goto hammer is Kotlin, which I like a bit better than Go. But that's a highly subjective thing of course. And I use plenty of other languages as well (including very occasionally some Go).

It's not about what is better in general but about what is better for you. Better here means less time wasted with figuring out syntax, tools, APIs, frameworks, etc. Once you know how to do a certain thing in one language, having to relearn to do the same things in another is slightly annoying. Although, LLMs are actually hugely helpful for this these days.

IMHO we're about to see a minor renaissance in web development. I was playing with the Kotlin WASM compiler a few weeks ago just to verify that I could use existing web APIs. As it turns out, it's are all there. Using them might not be the fastest right now but I'm sure that will get improved over time. Garbage collection is already in (and coming soon to Safari as well). There are some inefficiencies with making calls into js that need some attention. But that's not really a show stopper unless you are doing this many times per second.

What that means is that you can just do web application in wasm; use all the stuff from the browser that you normally use but without any javascript (except for a tiny wrapper that loads the wasm). I actually use kotlin-js so it's not a big leap for me. But wasm loads a bit faster and probably compiles a bit faster too. No more webpack uglification needed (which is actually slower than the kotlin compiler). So that's 2x compiler performance right there.

The point here is not kotlin or javascript but that this now works with any language that you can get going with wasm. Including Go if you want. Javascript becomes completely optional. I'm sure some will be upset about that. But that would be mainly because it's their preferred hammer.

Re: Go is my hammer, and everything is a nail

#140

I've been coding in Go for over five years. I like Go, but I don't love it. It's never my first choice, although I don't advocate for rewrites just to move away from it. The tooling is a mess. Go modules still feel like a 'first pass' implementation that never got finished. There's no consistency in formatting or imports (even though Go claims there is). Generics are a good step but are still very primitive (no gener…

Not sure what you mean by "no generics on interfaces"? https://go.dev/play/p/jGINeUt1JTE

Also echoing not sure what you mean by "no consistency in formatting or imports". It is increasingly difficult to use Go without gofmt getting run, since I have to imagine fewer and fewer people nowadays are using an editor that has neither custom support for their language nor LSP integration, and integration with gopls automatically runs goimports on save.

Post reply on HN