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

Go's Sweet 16

go.dev

Post reply on HN
Print view View original

271–280 of 280 posts

Re: Go's Sweet 16

#271

Post by sacado2 »

liveoneggs wrote: post #270
sacado2 wrote: post #258

Earlier quoted context omitted.

> "making a folder" and "putting a ... main() func" in it You can't do that with python for instance. First, you need a python interpreter on the target machine, and on top of that you need the correct version of the interpreter. If yours is too old or not old enough, things might break. And then, you need to install all the dependencies. The correct version of each, as well. And they might not exist on your system,…

You also need a version of the go compiler, possibly one new enough to handle some //go:magic:comments. I agree that static linking is great and that python sucks but I was trying to say I can, very easily, mkdir new-py-program/app.py and stick __main__ in it or mkdir new-perl-program/app.pl or mkdir my-new-c-file/main.c etc. For 2/3 of the above I can even make easy/single executable files go-style.

Nowadays, with uv (and probably some other tools too) it's pretty easy to ship a python program on a machine that doesn't even have python on it, so it's pretty much a solved problem today (in most cases). But 5 or 10 years ago it was a real hassle that go solved elegantly. Yes you can make python executables but they are like 100 Mb even for a simple hello world. It's a last resort solution.

I don't understand your comment on magic comments. You don't need them to cross-compile a program. I was already doing that routinely 10 years ago. All I needed is a `GOOS=LINUX GOARCH=386 go build myprog && scp myprog myserver:`

Re: Go's Sweet 16

#272

Post by ErroneousBosh »

benjiro wrote: post #267
ErroneousBosh wrote: post #255

Earlier quoted context omitted.

Exactly. "This is Go. You write it this way. Not that way. Write it this way and everyone can understand it." I wish I was better at writing Go, because I'm in the middle of writing a massive and complex project in Go with a lot of difficult network stuff. But you know what they say, if you want to eat a whole cow, you just have to pick and end and start eating.

Yep ... its like people never read some of the main dev's motivations. The ability for people to be able to read each others code was a main point. I don't know but for me a lot of attacks on Go, often come from non-go developers, VERY often Rust devs. When i started Go, it was always Rust devs in /r/programming pushing their agenda as Rust being the next best thing, the whole "rewrite everything in Rust"... About 10…

> I don't know but for me a lot of attacks on Go, often come from non-go developers, VERY often Rust devs.

I see it as a bit like Python and Perl. I used to use both but ended up mostly using Python. They're different languages, for sure, but they work in similar ways and have similar goals. One isn't "better" than the other. You hardly ever see Perl now, I guess in the same way there's a lot of technology that used to be everywhere but is now mostly gone.

I wanted to pick a not-C language to write a thing to deal with a complex but well-documented protocol (GD92, and we'll see how many people here know what that is) that only has proprietary software implementing it, and I asked if Go or Rust would be a good fit. Someone told me that Go is great for concurrent programming particularly to do with networks, and Rust is also great for concurrent processing and takes type safety very seriously. Well then, I guess I want to pick apart network packets where I need to play fast and loose with ints and strings a bit, so maybe I'll use Go and tread carefully. A year later, I have a functional prototype, maybe close to MVP, written in Go (and a bit of Lua, because why not).

The Go folks seem to be a lot more fun to be around than the Rust folks.

But at least they're nothing like the Ruby on Rails folks.

Re: Go's Sweet 16

#273

Post by catlifeonmars »

jiehong wrote: post #193
culebron21 wrote: post #87

To me, Go is like Rust oversimplified beyond reason. It edits your code when you don't ask, removing things you just started; it lacks iterators -- every time you must write a big cycle instead. It lacks simple things like check if a key exists in a map. Proponents say it has nothing under the hood. I see under-the-hood-magic happen every time. 1) The arrays append is one example. Try removing an element from an arra…

One thing Go took from C that I dislike: overly short variable names (like in interface names when implementing function are usually 1 or 2 letters, but also chan!). Other random things I hate: - first element in a struct, if unnamed, acts like extending a struct; - private/public fields of method based on capitalisation (it makes json mapping to a struct have so much boilerplate); - default json lib being so inept w…

> - first element in a struct, if unnamed, acts like extending a struct;

I’m not 100% sure what you’re referring to here. Struct embedding maybe? (FWIW struct embedding is not limited to the first field in a struct, hence my confusion)

> - error type being special, and not working well with chanels;

I don’t think the error type is special? Do you mean that it is the only interface implicitly defined in each package?

> - using internal proxy in companies for packages download is very fiddly, and sucks.

Yes this one is annoying. I ended up writing an entire go module proxy just so that it works with bearer tokens. It’s crazy that Go only supports http basic auth for proxy authentication in 2025.

Re: Go's Sweet 16

#274

Post by igouy »

vips7L wrote: post #269
deagle50 wrote: post #247

Earlier quoted context omitted.

ZGC? It should be on par or better than Go.

Java’s collectors vastly outperform Go’s. Look at the Debian binary tree benchmarks [0]. Go just uses less memory because it’s AOT compiled from the start and Java’s strategy up until recently is to never return memory to the OS. Java programs are typically on servers where it’s the only application running. [0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Also -- Java versus Java native-image

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Go's Sweet 16

#275

Post by catlifeonmars »

Mawr wrote: post #107
culebron21 wrote: post #87

To me, Go is like Rust oversimplified beyond reason. It edits your code when you don't ask, removing things you just started; it lacks iterators -- every time you must write a big cycle instead. It lacks simple things like check if a key exists in a map. Proponents say it has nothing under the hood. I see under-the-hood-magic happen every time. 1) The arrays append is one example. Try removing an element from an arra…

> it lacks iterators -- every time you must write a big cycle instead It has iterators - https://pkg.go.dev/iter . > It lacks simple things like check if a key exists in a map. What? `value, keyExists := myMap[someKey]` > Try removing an element from an array - you must rely on some magic and awkward syntax, and there's no clear explanation what actually happens under the hood (all docs just show you that a slice is…

> First of all, if you're removing elements from the middle of an array, you're using the wrong data structure 99% of the time. If you're doing that in a loop, you're hitting degenerate performance.

Sorry but that’s not categorically true. Rather it’s highly scale-dependent. 90% of the slices in a typical code base will be 10s of elements long, in which case the memory overhead and mutation overhead are comparable to, say, a map. Oh and also it’s ordered and (in the above case) can fit within a cache line.

Re: Go's Sweet 16

#276

Post by vips7L »

igouy wrote: post #274
vips7L wrote: post #269

Earlier quoted context omitted.

Java’s collectors vastly outperform Go’s. Look at the Debian binary tree benchmarks [0]. Go just uses less memory because it’s AOT compiled from the start and Java’s strategy up until recently is to never return memory to the OS. Java programs are typically on servers where it’s the only application running. [0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Also -- Java versus Java native-image https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

IIRC the native image GC is still the serial GC by default. Which would probably perform the worst out of all the available GCs.

I know on HotSpot they’re planning to make G1 the default for every situation. Even where it would previously choose the serial GC.

Re: Go's Sweet 16

#277

Post by cristaloleg »

jiehong wrote: post #193
culebron21 wrote: post #87

To me, Go is like Rust oversimplified beyond reason. It edits your code when you don't ask, removing things you just started; it lacks iterators -- every time you must write a big cycle instead. It lacks simple things like check if a key exists in a map. Proponents say it has nothing under the hood. I see under-the-hood-magic happen every time. 1) The arrays append is one example. Try removing an element from an arra…

One thing Go took from C that I dislike: overly short variable names (like in interface names when implementing function are usually 1 or 2 letters, but also chan!). Other random things I hate: - first element in a struct, if unnamed, acts like extending a struct; - private/public fields of method based on capitalisation (it makes json mapping to a struct have so much boilerplate); - default json lib being so inept w…

> - error type being special, and not working well with chanels;

what?

Re: Go's Sweet 16

#278

Post by dematz »

echelon wrote: post #26
Xeoncross wrote: post #15

Earlier quoted context omitted.

Yes, for me I've always pushed the limits of what kinds of memory and cpu usage I can get out of languages. NLP, text conversion, video encoding, image rendering, etc... Rust beats Go in performance.. but nothing like how far behind Java, C#, or scripting languages (python, ruby, typescript, etc..) are from all the work I've done with them. I get most of the performance of Rust with very little effort a fully contain…

Rust is the most defect free language I have ever had the pleasure of working with. It's a language where you can almost be certain that if it compiles and if you wrote tests, you'll have no runtime bugs. I can only think of two production bugs I've written in Rust this year. Minor bugs. And I write a lot of Rust. The language has very intentional design around error handling: Result , Option , match, if let, functio…

just be careful with unwrap :)

Re: Go's Sweet 16

#279

Post by jen20 »

nicodjimenez wrote: post #146
wanderlust123 wrote: post #48

Earlier quoted context omitted.

I think lack of classes is highly desirable. So much enterprise code is poorly put together abstractions. I think go needs some more functional aspects, like iterators and result type/pattern matching.

The solution to bad abstractions it not to make it very difficult to create abstractions at all. For systems code I think it's fine but for application code you probably want some abstractions or else it's very hard to scale a codebase.

It’s really not though. Plenty of systems are built in Go, Erlang etc that do not have the architectual monstrosities which commonly show up in object-oriented code, especially when a Java or C# expert beginner has been let loose.

Re: Go's Sweet 16

#280

Post by morshu9001 »

goranmoomin wrote: post #124
jchw wrote: post #25

Earlier quoted context omitted.

Just so we're on the same page, this is the current JS spec: https://262.ecma-international.org/16.0/index.html I don't agree. (And frankly don't like using JS without at least TypeScript.)

While I might not think that JS is a good language (for some definition of a good language), to me the provided spec does feel pretty small, considering that it's a language that has to be specified to the dot and that the spec contains the standard library as well. It has some strange or weirdly specified features (ASI? HTML-like Comments?) and unusual features (prototype-based inheritance? a dynamically-bounded thi…

Yeah, a lot of the quirks come from it being small
Post reply on HN