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

761–770 of 816 posts

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

#761

Post by aragilar »

Something1234 wrote: post #650
aragilar wrote: post #572

Earlier quoted context omitted.

It's likely because it's a pain to call Fortran or C (I'd be suspicious of anyone trying to reimplement openblas in go).

Why would you be suspicious?

Because more likely than not, they're going to screw it up, and the choice to use go was not made for sound engineering reasons (go is not the only language this would apply to, but because of the lack of good FFI, its more likely to happen). The exception would be if said person had a solid background in numerical computing and was up-to-date with the state of the field, but that's pretty easy to find out.

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

#762

Post by icholy »

tuetuopay wrote: post #525
icholy wrote: post #169

Earlier quoted context omitted.

Not sure what you're comparing to, but Go modules are probably the best dependency management system in any language.

Between conflating imports and URLs, the weird go.mod syntax, and the nonsense that are GOPROXY, GOPRIVATE and such, yes, it’s a mess. Honestly, aside from left-pad stuff, even npm is much better. I personally find cargo to be the best one I’ve tried yet. Feature flags, declarative, easy overrides, easy private registry, easy mixing and matching of public/private repos through git, etc. And like go it properly handle…

Dealing with private repositories does suck, I'll give you that.

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

#763

Post by sanderjd »

Something1234 wrote: post #650
aragilar wrote: post #572

Earlier quoted context omitted.

It's likely because it's a pain to call Fortran or C (I'd be suspicious of anyone trying to reimplement openblas in go).

Why would you be suspicious?

There is no good reason to pursue a project like this (or if there is, it would be very surprising to me), so it would reek suspiciously of "not invented here".

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

#764

Post by aragilar »

BiteCode_dev wrote: post #748
aragilar wrote: post #566

Earlier quoted context omitted.

I would think the best option is to always be suspicious of hype, unless you understand why something is being hyped? I'd also argue its worth understanding where your stack falls down, so you know when you need to look for alternative stacks. The other bit is it's worth understanding how your stack interacts with related stacks (to use your examples, does uv and pydantic using rust vs. being pure python cause issues…

First, you don't have to follow hype, but listening to it is how you know where your ecosystem is heading. Second, there is way more to an ecosystem that hype. Api, compat, deprecation, new features... If you never created an web api and have to do it now, you still have to make a choice, hype or not. This choice will have very different consequences if you know only about flask and drf, if you heard of fastapi, or i…

Sure, languages have depth, and there is at some level some need to keep up with the Joneses (though to mix metaphors, different ecosystems have their red queens running at very different paces, and is it wise to be in or try to join the fastest paced race?), but I feel there is a distinction between following the latest hype blindly (and using the latest tool because of hype), and evaluating tools based on some criteria (and choosing the latest tool because it actually solves the problem on hand best). The latter is a skill that can be gained and taught in one ecosystem, and applied in another (and the former causes issues far too often).

I think this skill is very similar to what highly productive academics have, they evaluate and examine ideas, techniques and concepts from a wide variety of fields, and combine them to build new ones.

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

#765

Post by sanderjd »

AnimalMuppet wrote: post #560
drdaeman wrote: post #370

Earlier quoted context omitted.

I can totally agree that Go is good enough for most projects, to the extent it's a go-to choice for many. However, it's not always the best tool - frequently it wins just because it allows to prototype quicker. YMMV, but for me, it's not a love relationship, it's a love-hate relationship. > The language is extremely simple. Simplicity is a double-edged sword. It didn't even have basic generics for a long while, and i…

"Good enough" plus "I already know it" almost always beats the perfect tool that I don't already know.

There is obviously truth in this, but I think it is more often the case than many people think it is that it is more efficient to learn the better tool "good enough" than to use the worse "I already know it" tool.

For instance, I've seen lots of people not want to learn sql and instead write complicated imperative implementations of relational primitives in the "I already know it" programming languages that are clearly "good enough" (because they are turing complete after all). But sql is usually a much better way to do this, and isn't hard to learn "good enough" to do most things.

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

#766

Post by sanderjd »

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.

Absolutely, it's my least favorite prototyping environment. It forces me to think about a bunch of stuff I don't want to think about up front.

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

#767

Post by sevensor »

tekknik wrote: post #760
rkangel wrote: post #556

Earlier quoted context omitted.

This is true, and it makes the people who do actually know the language in depth extra valuable.

Not so much. I know quite a few languages very well, more than the average programmer, and more often than not a senior programmer overrides your recommendation and don’t know the language as well as you or some other red tape. What has never happened is getting an increase in pay for knowing a language well. So I share the sentiment that learning a language well is valuable. It’s not, and with the newer AI tools com…

I think you have that exactly backwards. LLM-based tools do best on shallow-knowledge tasks. It’s depth where they struggle. Show me the syntax for constructing a lazy sequence in your language? LLM. Reason about its performance characteristics and interactions with other language features? Human, for the foreseeable future.

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

#768

Post by theshrike79 »

bb88 wrote: post #710
thrwaway1985882 wrote: post #583

Earlier quoted context omitted.

Even the most ardent of Go-haters have to be fair and admit it makes cross-compilation really nice. GOOS=linux GOARCH=amd64 go build && scp executable user@host:direc/tory/ Out of the box, no toolchains to manage.

Sure, it's nice in that regard. But honestly running poetry install for python is not bad either.

Except in 3 years when poetry is bad for some reason and now there's a new better(?) tool again :D

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

#769

Post by commodoreboxer »

bb88 wrote: post #386
shepherdjerred wrote: post #360

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…

Needing to cast nil to a type was weird. C/C++/Java/Python don't do that. They also take on the weird Java-ish culture that everything is better if it's written in Go. They also had this weird take on the C++ vtable, so they eschewed anything class like to keep everything statically linked for speed. It also took them a long time to figure out their loop variable syntax was broken. So ... hrm.

C++ and Java do make you cast null/nullptr, if you need to resolve an ambiguous overload based on pointer type.

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

#770

Post by whateveracct »

ratorx wrote: post #733
whateveracct wrote: post #628

Earlier quoted context omitted.

> I used to work for a Go shop. We dealt with financial data. Hopefully you never forgot to initialize a numeric field and had it default to 0!

I think you are implying that this is incorrect behaviour. Could you explain why? The alternative would be to have it be undefined, which seems clearly worse. Or do you mean that it should be a compiler warning/error instead?

> Or do you mean that it should be a compiler warning/error instead?

Yes - it's pretty trivial to enforce that all fields be initialized.

Post reply on HN