Live data from Hacker News

Go is my hammer, and everything is a nail

maragu.dev

421–430 of 816 posts

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

#421

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…

I am planning a switch to Kotlin just because it seems more readable. As someone who has done both how do you rate Kotlin's STL?

The standard library plus the growing number of multi platform libraries covers a lot of stuff at this point. There are still some things that are a bit lacking but most of those things have people working on them.

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

#422
post #415

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…

But you also need the GUI part. Flutter seems to be the main competitor here. What's the current situation with Kotlin? Is there a decent Compose for Web yet?

With browser dom support and CSS, that would be doable. Compose web is in alpha currently; it renders to a canvas.

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

#423

Earlier quoted context omitted.

I feel this way... very often. * Init functions * Top-level variables being shared between all files in a package * For-loop sharing (fixed in 1.22 [0]) * ldflags (this is more of build behavior, but it took me a while to figure out how some variables were being set [1]. Note: Go does embed some data by default, but an app I was working on introduced more metadata) * Go build directives prevent IDEs/linters from anal…

First three are clearly documented in language reference, which could be read in several hours (at least before generics were introduced).

I like to read language references (not just Go's, for example I have also fully read the ECMAScript standard as a part of my research in the past) and yet I will never say I can remember everything from those references. "Documented" isn't same as "easy to remember or recall".

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

#424

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…

For loops? Dang that’s some clever syntax you have there. Personally I prefer a big standard while loop. /s

That gives me the impression you've never written in go. Certainly not a while loop.

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

#425
post #94

People always under-estimate the cost of properly learning a language. At any given time I tend to have a "main go-to language". I typically spend 2-4 years getting to the point where I can say I "know" a language. Then I try to stick to it long enough for the investment to pay off. Usually 8-10 years. A surprising number of people think this is a very long time. It isn't. This is typically the time it takes to under…

One of the most important qualities of Go is that it is actually possible to fully understand the language -- in the sense that you never see a snippet of Go code and think "wtf, you can do that?" or "hang on, why does that work?" Getting to that point takes many years, to be sure. But the language is simple enough, and changes slowly enough, that it is not an unrealistic goal -- the way it would be in C++, or Rust,…

Why is that important?

Let's say one language has me find a weird rabbit hole every 50 hours of use, and I spend half an hour learning about it.

Let's say another language has no rabbit holes, but I'm 5% slower at coding in it.

Why would I not prefer the first language?

(And 5% is supposed to be an intentional lowball. I'm confident I can find language pairs where my productivity differs by significantly more.)

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

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

Agreed on all points except #3 re the core libraries. Coming from the Java ecosystem, it was a bit of a shock to see how small the standard libraries are. For example, the minuscule collections library, among others.

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

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

> The author lists multiple reasons for this, but for me the biggest one is the first one: Go is good for almost everything.

I'd nuance that claim.

I haven't found Go to be _particularly good_ at any specific task I've undertaken, but Go was _good enough_ for many of these tasks. Which makes Go a reasonable general programming language.

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

#428
post #400
post #351

Earlier 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.

The requirement to define at least one function by itself is a boilerplate. Also IDE doesn't fully solve the inability to compile and run a partially written program (in fact, Go compiler is even more pedantic than rustc in some aspect), which happens a lot when working with dynamically typed languages and their strongest use cases.

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

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

I do programming interviews and I found candidates struggling a lot in doing http request and parsing response json in Go while in Python its a breeze, what makes it particularly hard, is it lack of generics or dict data type?

There is a dict-equivalent data type in Go for JSON (it's `map[string]any`), it's just rather counter-intuitive.

However, as a Go developer, I'm one of the people who consider that JSON support in Go should be burnt down and rebuilt from scratch. It's both limited, annoying, full of nasty surprises, hard to debug and slow.

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

#430

That's why Typescript is my hammer, unless I need a jack hammer, which is Rust. With Deno and Typescript I get an even more versatile toolbox than with Go. And what's even more important to me, Typescript is safer and more ergonomic than Go, but slightly slower. Rust is safer, more ergonomic and faster than Go, but much harder to learn. Especially strict (which is a must) Typescript is underrated. Compared to Go, we…

- Typescript doesn't protect you at all against external data.

- A Go program runs single-threaded, unless you explicitly tell it not too, so I don't quite see that as a plus for Typescript.

- Go is quite a bit faster than Typescript.

- I haven't had a versioning problem in Go, and I can still compile and run old code. Typescript still beats Python in that respect, but Go wins stability.

And I say this as someone who really likes Typescript. It's a blessing for frontend browser work.

Post reply on HN