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

221–230 of 238 posts

Re: Just Use Go

#221

Post by lanstin »

azangru wrote: post #95
lanstin wrote: post #79

Earlier quoted context omitted.

Upper case symbols in a module are exported. Everything else should be lower case.

Oh; in that case the lowly Javascript/typescript does this so much cleaner with the explicit `export` keyword. "Explicit is better than implicit."

I find “locality of scope” to be extremely significant fact about a variable, and so I like seeing signs of it at one glance. The . as well for everything tied in a class and the go convention of shorter names for function locals also support this awarenes.

Re: Just Use Go

#222

Post by za3faran »

bccdee wrote: post #208
za3faran wrote: post #185

Earlier quoted context omitted.

> Everything is nullable Only reference types, the same as in golang (which also has nullable pointers, and its interfaces interact weirdly with null). Java is getting value types, which can be declared as non-nullable. > There's no module system to speak of. https://dev.java/learn/modules/ > It's so IDE-dependant. Modern Java has been simplified that you can run a hello world program as follows: $ cat Hello.java voi…

> Only reference types, the same as in golang Everything's a reference in Java except primitives, and even primitives get object wrappers. In Java, String, Long, and Bool can all be null. Go isn't like that—only explicit pointer types and interfaces can be nil. In practice it really cuts down on NPEs. > https://dev.java/learn/modules/ Ok, granted, but I have never seen these in actual use. Java's ecosystem is big eno…

> Everything's a reference in Java except primitives

Value types will have the ability not to be nullable, which is the same as golang.

Primitive wrappers are used to denote nullability, which golang also has in its sql package for example.

> I can get by fine with vim + LSP regardless of project size

Getting by is one thing, having strong introspection offered by sophisticated IDEs is another.

Re: Just Use Go

#223

Post by Lvl999Noob »

clausecker wrote: post #213
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.

Really bad idea. Silently returning some (the wrong) value is always worse than catching the error right then and their and panicking. A panic is a noticeable symptom of something just having go wrong that is easy to chase after and debug. A silently returned wrong value just causes data corruption down the line, at great pain. It is very annoying to debug, in particular if people start to some times rely on this beh…

I agree. I prefer Optionals over Nulls in any case. This was just a thought of what if Go went all the way instead of just halfway. In my ideal language, you would have explicit assignments and compiler checked (runtime checked if absolutely necessary) pointer validity (with allowed length) at construction. As far as I know, the only time you need to make a pointer and say "trust me" is when doing MMIO so that can given its own mechanism. If it exists in the program state, it's valid.

Re: Just Use Go

#224

Post by ptdorf »

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?

Go probably wouldn't exist if Java devs went easy on overengineering design patterns.

But overall Java, like Go, IS a boring language. And that's a compliment.

Re: Just Use Go

#225

Post by cloudfudge »

jaen wrote: post #158
cloudfudge wrote: post #151

Earlier quoted context omitted.

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 (0x…

Lol well I don't know what the trigger is for pulling in libc there, because I've built massive scale services that did a lot of nontrivial stuff and then the deployment was a single-binary docker container that did not have libc. The only thing needed to be put in the container was a directory full of root certs so it could do TLS.

(full disclosure, I don't think I ever had my service look up the address of localhost)

edit: seems like you probably have CGO_ENABLED=1, which is now the default and will cause simple networking things to use libc. Set CGO_ENABLED=0 and you won't have libc.

Re: Just Use Go

#226

Post by cloudfudge »

ameliaquining wrote: post #156
cloudfudge wrote: post #151

Earlier quoted context omitted.

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... )

Oh that's good to know. I happen to think Microsoft is chasing a bad philosophy with that declaration, and there is no more danger in statically linking ssl if you're continuously rebuilding and deploying your statically linked scratch image, but then again, the Microsoft approach to a lot of things isn't what I want in my datacenter. To each their own, I guess. I happen to love how self-contained Go programs can be and do not consider that a liability but a strength.

Re: Just Use Go

#227

Post by cloudfudge »

potato-peeler wrote: post #196
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...

I suppose you are missing the point. Go had support for self contained binaries since its introduction in ~2009. This was not the case with dotnet, if i am not wrong. But nevertheless , if any language provides something like that, win-win for entire ecosystem.

Agreed. The fact that .NET has a way to do true static linking is great and I didn't know it existed. The fact that they apparently think it's a weird and undesirable thing is less great and would make me worried that they're going to undermine the ability at some point. Golang has had this ability since way back and they think it's a strength.

Re: Just Use Go

#228

Post by binaryturtle »

Milpotel wrote: post #97
binaryturtle wrote: post #83

Earlier quoted context omitted.

The post was about Go and uses the "The boring choice is the right choice." point at the end. But a compiler that's so quick to abandoned previously perfectly fine supported systems, and basically is bleeding edge, is anything but the "boring right choice". I personally prefer long term stability in the toolchains I use for my projects at least.

What language/toolchain/platform are you talking about because C/C++/Python/... all have the same issues?

Bootstrapping a modern/ up-to-date C/C++ compiler works, getting an up-do-date Python onto the system works too. No such issues with either of those. But try the same with Go or Rust and you hit nasty roadblocks (in both cases the older OS was previously supported just fine.)

Re: Just Use Go

#229

Post by sliken »

dadoum wrote: post #53

I would like someone to explain me Go. Really, I will use strong words but that's really what I feel. The syntax changes a lot from the C one, and I can't see any reason for it. To me, it looks unstructured, with the lack of colons for example. It ignores memory safety, it feels like it ignored all of the typing system research since C, no discriminated union, and structures and types in general are heavy to write. I…

C, for better or worse, is like a high level assembly language. You can do anything, which pretty much means you are going to have many security and correctness issues. Double free, use after free, off by one errors, buffer overflows, etc. Thus numerous CVEs.

Go has less flexibility, no pointer arithmetic, a healthy package system, and a smaller domain. Mostly consuming or providing network services. My favorite feature is channels. For me they make levering the performance of multi-core CPUs straight forward, and dramatically nicer than the C approaches I've tried like pthreads and mutexes.

I wouldn't rate go as secure as rust, but has a pleasingly developer friendly approach. Seems way more secure than C.

Making a pipeline where each stage is 1 to N threads is pleasingly easy, reliable, and performant.

Re: Just Use Go

#230

Post by bccdee »

za3faran wrote: post #222
bccdee wrote: post #208

Earlier quoted context omitted.

> Only reference types, the same as in golang Everything's a reference in Java except primitives, and even primitives get object wrappers. In Java, String, Long, and Bool can all be null. Go isn't like that—only explicit pointer types and interfaces can be nil. In practice it really cuts down on NPEs. > https://dev.java/learn/modules/ Ok, granted, but I have never seen these in actual use. Java's ecosystem is big eno…

> Everything's a reference in Java except primitives Value types will have the ability not to be nullable, which is the same as golang. Primitive wrappers are used to denote nullability, which golang also has in its sql package for example. > I can get by fine with vim + LSP regardless of project size Getting by is one thing, having strong introspection offered by sophisticated IDEs is another.

> Getting by is one thing

Yeah, and it shouldn't be too much to ask for. So it drives me crazy that I can't get by in Java without a full IDE. All I want is "show docs" + "jump to definition" + "show references" + "show implementations". I should not need IntelliJ for this.

> Primitive wrappers are used to denote nullability, which golang also has in its sql package for example.

The nullability wrappers in go's sql package are one of my least favourite parts of the langauge, haha. I really wish Go had proper sum types.

> Value types will have the ability not to be nullable, which is the same as golang.

It's good that Java will eventually add that feature, but I was critical of Go for lacking generics all the way up until they added them. Java's backwards compatibility story isn't as strong as Go's, either. Generics, Go's biggest change ever, were fully non-breaking; meanwhile, some people are still using Java 8.

Go's attitude toward adding features is, "we don't have that & it's fine." If you want to dynamically load code in Java, you have the power to do all kinds of custom class loader magic. If you want to dynamically link code in Go, too bad. Now, I don't love this approach. My favourite language is Rust, which has features out the wazoo. It is beautiful and powerful and complicated. Go is none of those things, but it is austere and minimal and that has its own advantages. Java lacks the advantages of either.

Of course, Java is widely used no matter what I think of it, and it is boring (in the complimentary sense). At the end of the day, it's a fine choice for a project. But as I said earlier, thank god Go is boring enough that I don't have to write Java anymore.

Post reply on HN