Live data from Hacker News

Go is my hammer, and everything is a nail

maragu.dev

211–220 of 816 posts

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

#211
post #120

Earlier quoted context omitted.

Go is the only language I've ever felt highly productive working in. Oftentimes in other stacks I find myself in analysis paralysis on meta things that don't matter: - what design patterns/language features make sense to use - what is the best lib to accomplish X - how do you keep things up to date With Go, the language is so simple that it's pretty difficult to over engineer or write terse code. Everything you need…

Yep.. say you wanted to make a simple http service that needs to * request a json.gz file from another HTTP service * decompress it * deserialize the json, transform it a bit That's net/http (and maybe crypto/tls), compress/gzip, encoding/json. I need to make zero decisions to get the thing off the ground. Are they the best libraries in the world for those things? no.. but will they work just fine for almost every us…

Sounds like

    curl ... | jq ...
to me!

Not saying you shouldn't use Go for that problem, in a particular context, but it does drive home how much of programming is glue ... there is combinatorial amounts of glue, which is why JSON, HTTP, compression, etc. end up being part of so many problems

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

#212
post #129
post #95

Earlier quoted context omitted.

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

IME, there are two main differences between go and java: 1) go is more "batteries included". Modules, linting, testing, and much more are all part of the standard cli. Also, the go stdlib has a ton of stuff; in java, there is almost always a well-built third party library, but that requires you to find and learn more things instead of just reaching for stdlib every time. 2) golang is "newer" and "more refined". this…

Eh, imo the go libraries still aren't up to par with out of the box java libraries. Like there's still no Set class, nor the equivalent of Map.keys. yeah they're easy to write but that's still not an included battery.

Also, while the cli to add stuff is useful, there's still nothing to the level of maven or gradle for dependency management, and I usually find myself doing some fun stuff with `find -execdir` for module management.

Different strokes for different folks though. Java (really, kotlin) still makes a ton of sense for backend to me given how the jvm is architecture independent and you don't have to make tradeoffs/switch to graal if it's a long lived service.

Golang is nice, love it, but it's still got a bit to grow. I'm just happy they added modules and generics. I don't think it's a matter of being 'well thought out' as much as it's a simple language that cares a lot about simplicity and backwards compatibility and has iterated ever since. For my the killer app isn't go routines so much as you can produce a binary that's resilient even to shared/dynamically linked libraries in all platforms, which is awesome for portability independent of environment. No more gcc vs clang vs msvc headaches, no more incompatible shared libraries, no more wrong version of jvm or a bad python modules path etc.

Oh, also java had like a 15 year headstart on golang, and it wasn't until java 8 that many of my biggest complaints were addressed. And yeah stuff like apache commons +log4j+mockito/junit are pretty much required dependencies, and maven/gradle aren't language native.

The best STL is probably python imo but even that doesn't support a proper heap/priority queue inplementation. For data structures specifically I think java/kotlin has the best STL. All of this ignoring .NET or apple platforms.

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

#213
post #162

Earlier quoted context omitted.

> Not sure what you mean by "no generics on interfaces"? I didn't word this very well. You can have a generic interface, and functions on that interface can refer to generic types. But you can't have a generic method on an interface that uses a different generic type. For example you can't have: ``` type YieldThing[T any] interface { Yield() T DoOperation[U any](U) } ```

There are good reasons for not allowing generic methods: https://go.googlesource.com/proposal/+/refs/heads/master/des...

Realistically the reasons are this:

> So while parameterized methods seem clearly useful at first glance, we would have to decide what they mean and how to implement that.

They just didn't want to decide what they mean or how to implement them.

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

#214
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…

I'm asking this earnestly but is Go suitable for native GUI apps (not web)? 3D graphics/Games? Audio processing?

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

#216
I really like most aspects of Go, but as someone who writes a lot of numerical code, no operator overloading is a deal breaker. It's so hard to accept something like Add(Scale(s1, vec1), Scale(s2, vec2)) over s1 * vec1 + s2 * vec2. So I stick with Python and C++ for now.

Rust is really appealing as a C++ replacement, but it has too many rules to replace Python for one-off scripts. Still need to try Nim and Swift, I guess...

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

#217

Earlier quoted context omitted.

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…

Take a look at a JSON parser or ORM written in Go. It's god awful the things they have to do to work around Go's type system. The average developer won't see these things, they're typically just writing glue code between Go's great stdlib (which also contains wild things if you take a look) and other 3rd party dependencies.

> The average developer won't see these things, they're typically just writing glue code between Go's great stdlib (which also contains wild things if you take a look) and other 3rd party dependencies.

This is what most of us are doing every day, and exactly what Go excels at.

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

#218
post #214
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…

I'm asking this earnestly but is Go suitable for native GUI apps (not web)? 3D graphics/Games? Audio processing?

For games potentially Ebiten, I believe it has some audio processing support too.

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

#219

Life is barely long enough to get good at one thing so you should choose your thing wisely. That's wisdom I've held for quite some time. Coincidentally, I chose Go as my language of choice as well. The factors that led me to that choice were many, but to highlight some: - incredible standard library - simple to read and write - single static binary builds (assets included, like html/images, etc) - don't need a contai…

What game engines use Go?

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

#220
post #120

Earlier quoted context omitted.

Go is the only language I've ever felt highly productive working in. Oftentimes in other stacks I find myself in analysis paralysis on meta things that don't matter: - what design patterns/language features make sense to use - what is the best lib to accomplish X - how do you keep things up to date With Go, the language is so simple that it's pretty difficult to over engineer or write terse code. Everything you need…

> it's pretty difficult to over engineer I don't know about that. Every programmer's first Go program seems to like to go to channel city. Perhaps more accurately: Over-engineering your Go program is going to quickly lead to pain. It doesn't have the escape hatches that help you paper over bad design decisions like some other languages do.

Yeah too much concurrency and too many channels definitely hit home hard...
Post reply on HN