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

381–390 of 816 posts

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

#381

Post by WuxiFingerHold »

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 get:

- null safety

- widely supported generics

- discriminated unions with either manually (some lines of code) or es-lint exhaustiveness checks

- much safer concurrency, as all Typescript code runs single-threaded. You need web workers, which are not as safe as Rust for concurrency, but much safer than Go.

- collection / iterator methods

So far, I see only few downside. I'd be happy if people could provide more. Currently I'm scratching my head why I didn't fall in love with Typescript (for backend and CLI) earlier. Maybe I haven't seen the dark sides yet. So, some points where Go is stronger than Typescript:

- Go is much more efficient in terms of size and memory usage

- Go's GC is better than V8s

- Go is faster on CPU bound tasks

- Go has a greater std lib, however, Deno's std lib is pretty nice as well.

- The ecosystem is smaller, but has not as much trash as NPM. The dependency trees with NPM are usually large. By the way, Rust has this problem as well, less than Typescript but more than Go. Still, many mainstream NPM packages are safe and rock solid.

What else could we say against Typescript (and preferably Deno or Bun)? I'm really eager to hear people having ditched it an why.

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

#382

Post by tacticus »

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.

both unity and unreal have GC these days.

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

#383

Post by zinodaur »

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.

yeah gotta use an IDE for that

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

#384

Post by scubbo »

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-performance utilities, you should (within reason) bias for being able to write (and iterate) fast over being able to execute fast. You can always re-write in Rust if you find that performance is a bottleneck.

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

#385

Post by randomdata »

kbolino wrote: post #375
randomdata wrote: post #340

Earlier quoted context omitted.

Did you miss "just one implementation"? A mock is literally defined by being another implementation. If the 'mock' is your sole implementation, we don't call it a mock, that's just a plain old regular implementation.

I think my comment was clear on the distinction between real and mock implementations. If the code was testable with no need for mocks then certainly remove the interface and devirtualize the method calls.

Your comment was clear about mocks, but not why mocks are relevant to the topic at hand. The original comment was equally clear that it was in reference to where there is only one implementation. In fact, just to make sure you didn't overlook that bit amid the other words, the author extracted that segment out into a secondary comment about that and that alone.

Mocks, by definition, are always a supplemental implementation – in other words, where there is two or more implementations. What you failed to make clear is why you would bring up mocks at all. Where is the relevance in a discussion about single implementations the other commenter has observed? I wondered if you had missed (twice!) the "one implementation" part, but it seems you deny that, making this ordeal even stranger.

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

#386

Post by bb88 »

shepherdjerred wrote: post #360
monkeywork wrote: post #348

Earlier quoted context omitted.

kind of hard for someone to prove a negative - feel free to find some Go code that meets that definition.

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.

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

#388

Post by randomdata »

arp242 wrote: post #266
randomdata wrote: post #176

Earlier quoted context omitted.

> being pedantic about the definition of an enum to say "actually go has them" isn't helpful. Incorrect. The term "real enums", where used to imply that enums are something other than the basic element of the same name, encompasses a number of distinct features that are completely independent of each other. In order to meaningfully talk about "real enums", we need to break it down into the individual parts. If you're…

Words can have more than one meaning. As far as I know, no one voted you to be arbiter of all terms and their One True Correct™ meaning. It's pretty clear what the previous poster intended to say.

Quite clear, in fact, which is why we are able – in theory – to have a discussion about all the distinct features at play. If it weren't clear, we wouldn't be able to go there.

I say in theory, because as demonstrated by the sibling comment, there apparently isn't much programming expertise around here. At least it was fascinating to see how a mind can go haywire when there isn't a canned response to give.

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

#389

Post by mseepgood »

jay_kyburz wrote: post #221
mapcars wrote: post #151

Earlier quoted context omitted.

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?

Hold on, did you just say Go doesn't have a Dictionary data type? I'm a Javascript, Lua, Python, and C# guy and Dict is my whole world.

It does (it's called a map) and Go does have generics, the previous poster clearly doesn't know what they're talking about.

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

#390

Post by dpkirchner »

maccard wrote: post #174
thornewolf wrote: post #161

Earlier quoted context omitted.

I argue: - The list comprehension is ever slightly more readable. (Small Positive) - It is a bit faster to write the code for the Python variant. (Small Positive) So this would be a small positive when using Python. Furthermore, I believe there is this "small positive" trade-off on nearly every aspect of Python, when compared to Go. It makes me wonder why someone might prefer Go to Python in almost any context. Some…

> The list comprehension is ever slightly more readable. I disagree - it's terse to the point of being hard to parse, particularly when you get smart ones like: [x for x in t if x not in s] > It is a bit faster to write the code for the Python variant. Code should be written to be read. Saving a few keystrokes vs time spent figuring out the `not in in not with` dance gives the the edge to Golang here. It's "high cont…

This is my (current) favorite list comprehension: https://github.com/huggingface/datasets/blob/871eabc7b23c27d... Someone was feeling awfully clever that day. (Not that I'm not occasionally guilty myself.)
Post reply on HN