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

Just Use Go

blainsmith.com

Post reply on HN
Print view View original

151–160 of 238 posts

Re: Just Use Go

#151

Post by cloudfudge »

kevinmgranger wrote: post #138
cloudfudge wrote: post #135

Earlier quoted context omitted.

> that also compiles to a binary "compiles to a binary" is not a useful criterion. The criterion Go is winning on is "compiles to a single, completely self-contained binary," meaning it does not depend on libc or any external runtime. You can't say that about .NET. You can't say that about damn near any other programming language. It's extremely rare. The fact that .NET uses a binary packaging format is, like... well…

.Net can compile to a self-contained binary: https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

That isn't truly self-contained. It still relies on libc.

Re: Just Use Go

#153

Post by chuckadams »

ptman wrote: post #144
Lvl999Noob wrote: post #124

Earlier quoted context omitted.

What if Go went all the way? Referencing a zero pointer (nil) gives you the zero value of the pointed to type. If you try to access a zero map, it tries to deference the zero pointer to the underlying buffer. The zero pointer gives you the zero slice with zero length. The presence check fails without crashing and you get some pretension of reasonable behaviour.

So what happens when you write through the nil pointer?

Nil of course (nothing happens). Not saying it’s a good idea, it would just be consistent.

Re: Just Use Go

#154

Post by chuckadams »

MintPaw wrote: post #131
a012 wrote: post #80

Earlier quoted context omitted.

Why the Null handling and in Go is worse than others?

I think there's a large subset of programmers now who consider null checking (or even the existence of null) to be bad, and prefer something else like exceptions or option types. I don't get it personally.

The existence of null is not the problem, it’s when null populates every single non-primitive type, making every access into a logic bomb unless explicitly checked. When null is a distinct type, there’s no problem at all.

Re: Just Use Go

#155

Post by oconnor663 »

a012 wrote: post #80
treis wrote: post #12

There's a lot of merit in this. I call Go the Honda Odyssey Minivan of the programming world. It doesn't do anything exceptionally well but it does lots really well and in a way that's simple and reliable. Especially for the backend serving react front end niche. But it's also a pig to write and comes with a lot of foot guns. Especially the Null handling. Somehow they made it worse than every other language.

Why the Null handling and in Go is worse than others?

Some weird nils don't compare equal to other nils. It's surprisingly easy to construct the weird kind by accident, because the conversion is automatic and invisible.

Re: Just Use Go

#156

Post by ameliaquining »

cloudfudge wrote: post #151
kevinmgranger wrote: post #138

Earlier quoted context omitted.

.Net can compile to a self-contained binary: https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

That isn't truly self-contained. It still relies on libc.

You can make it statically linked using musl. (This is underdocumented because Microsoft thinks it's usually a bad idea: https://github.com/dotnet/sdk/issues/37643#issuecomment-1873...)

Re: Just Use Go

#157

Post by Einenlum »

perarneng wrote: post #7

With agentic coding you can just use Rust. AI agents are really good at Rust and the good error message the compiler and or borrow checker gives makes it easy for the AI agent to adjust its code and fix it. For non agentic coding Go has terrible error handling. It does not have exceptions or monadic error handling. Some call that a feature but many avoid Go or that specific reason. This will not change because that d…

I personally avoid Go because if the if err != nil But I love the fact they have no exceptions. Rust handles this very well but it's way more complicated in general. I feel like we miss a middle ground. Maybe when Gleam becomes really popular, it could be the one?

Re: Just Use Go

#158

Post by jaen »

cloudfudge wrote: post #151
kevinmgranger wrote: post #138

Earlier quoted context omitted.

.Net can compile to a self-contained binary: https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

That isn't truly self-contained. It still relies on libc.

Nah. Go also relies on libc if you do anything non-trivial, like look up a the IP address of localhost.

    $ go build -o hello main.go
    $ file hello && ldd hello
    hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go
        linux-vdso.so.1 (0x00007f9c7b404000)
        libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f9c7b1ce000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f9c7b406000)

Re: Just Use Go

#159

Post by therealdrag0 »

nick_ wrote: post #128
thomascgalvin wrote: post #21

I like go, but a lot of little things stop me from loving it. Like, enums. I get a lot out of the box when I use an enum in Java or Kotlin. Converting to/from a String is trivial. Type safety ... exists. I can do that in Go, but I have to hack it in, for every single enum type I want to represent. Enums are not a thing in the language, which means its easier to keep the language in your brain all at once, but at the…

The convention of explicit error handling after every method call is absolutely bonkers to me. I would never use it for anything serious.

I recently vibe coded a large app in Go, it’s so mind-numbing to read. Like half the code base is error handling.

Re: Just Use Go

#160

Post by therealdrag0 »

vhodges wrote: post #66
twic wrote: post #6

> The boring choice is the right choice. It always was. Right, absolutely correct, Java is a great choice, so why does this post keep going on about Go?

EJB, Spring, Ant, Struts (I'm getting old - Like Hot Java Alpha 3 and Java applets old), maven, pom files, etc. I used to love Java but the complexity merchants showed up and ruined the party. 1.5 was just coming out when I stopped doing Java dev. Kotlin might pull me back into the fold though for when I can't use Go.

You can write apps without that stuff? Sure you should have 1 dependency management system, but otherwise you can write clean JVM apps in many languages, without DI or much else.
Post reply on HN