Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go is my hammer, and everything is a nail

maragu.dev

Post reply on HN
Print view View original

391–400 of 816 posts

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

#391

Post by Escapado »

scubbo wrote: post #384
WuxiFingerHold wrote: post #381

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…

Amen. I was unreasonably opposed to TypeScript at first after lots of bad experiences with messy JavaScript when I was first learning development - but after immersing myself in it for a year or so at $NEW_JOB, I absolutely love it. The only ways in which I can see that Go outperforms TypeScript is in performance, but frankly I don't care and most developers shouldn't - unless you're writing truly low-level high-perf…

I have been using typescript as my primary language for years and since I am used to it I actually enjoy it (much more than I enjoyed Java or Python in the past). And depending on what you built I agree, especially for one off scripts or if you plan on hosting just one or two things somewhere. On the other hand I recently saw a video by webdev Cody that got me thinking, where he was comparing a dead simple api server in go and in bun hosted on railway and their memory usage was different by an order of magnitude in favour of go plus you can compile your program down to a few megabytes instead of bundling a ~100megabyte runtime. So if you have a couple dozen of side projects where you host servers/apis that difference can end up in a noticeable operating cost differential. He made a few other points such as throughput, the more complete standard library and tooling such as go fmt and that writing the equivalent server in go wasn’t really all that different from the typescript code. You’re right that rewriting is always an option but for all over the place folks like me the next 3 projects are half done before I even think about optimising my hosting bill. But as I said, strongly depends on what you build.

I guess there are no winners, just tradeoffs.

I wonder if one use case for llms in the future could be feeding a sizeable typescript/python codebase into it and then have it spit out an equivalent in idiomatic rust/zig/c. I am aware that transpilers and assembly script and static Hermes exist but what I mean is more of a result that produces a maintainable rewritten version making use of the idiomatic libraries and coding conventions of the target language.

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

#392

Post by [deleted] »

neonsunset wrote: post #283
arp242 wrote: post #262

Earlier quoted context omitted.

Also: interfaceiritus. Someone saw "accept interfaces, return structs" somewhere and now EVERYTHING accepts an interface, whether or makes sense or not. Many (sometimes even all) of these interfaces have just one implementation.

Can't Go compiler statically prove that such single implementation interfaces are indeed that and devirtualize the callsites referring to them? Either way, the problem seems to happen in most languages of today, if they (or their community) ever happen to accidentally encourage passing an opaque type abstraction over a concrete one.

[deleted]

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

#394

Post by randomdata »

tengbretson wrote: post #350
hellcow wrote: post #271

Earlier quoted context omitted.

Doing this allows you to mock out that implementation in unit tests.

A lot of times you want to be able to cmd+click on something and actually see what the hell the code actually does and not get dead-ended at an interface declaration.

Sounds like a UI bug more than anything.

The compiler certainly knows how to determine if there is only one implementation of an interface and remove the interface indirection when so. There is nothing really stopping the cmd+click tooling from doing the same.

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

#395

Post by eweise »

RandomThoughts3 wrote: post #138
lairv wrote: 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…

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.

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

#397

Post by pjmlp »

dartos wrote: post #268
pjmlp wrote: post #267

Earlier quoted context omitted.

Sure, if everything one does is either CLI stuff, or UNIX daemons, containers, .... Because in the reign of graphics , GUI, GPGPU, HPC, HFT, ML, game engines,numeric analysis, ... there is hardly any library that really stands out.

Or servers, and about anything that really benefits from concurrency. Even a lot of games could be made with go. The gc wouldn’t really kill the frame rate of a game unless you really push it.

That is what "UNIX daemons, containers means" on my comment.

Gamedev in Go only for those that rather spend their time doing engines from scratch.

Additionally Go's lack of support for dynamic linking is a no Go (pun intended) for big A game studios.

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

#398

Post by pjmlp »

tacticus wrote: post #382
dartos wrote: post #268

Earlier quoted context omitted.

Or servers, and about anything that really benefits from concurrency. Even a lot of games could be made with go. The gc wouldn’t really kill the frame rate of a game unless you really push it.

both unity and unreal have GC these days.

And dynamic linking, plugins....

Which Go doesn't do really well, and there is no interest in improving.

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

#400

Post by pants2 »

eweise wrote: post #351
daghamm wrote: 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…

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.
Post reply on HN