Hacker News Reader

Comment by zer00eyz | Hacker News Reader

This is a terrible take.

It's like one of those people who buys a massive over priced knife block with 48 knives in it that they never use.

Most go devs have lived through bloated java/php/python/ruby/js projects that become a pile of dependencies.

Go is to coding what brutalism is to architecture. Simple, functional, efficient. Dont build a massive dependency chain, dont build magic, repeating yourself is OK. Be an adult and deal with your errors (it's a feature)... That minimalist no bullshit language semantics that force you not to be lazy is a feature not a bug.

View on HN

I don’t think any of that is contradicted by what this seems to be trying to do. In fact, Go doesn’t make you deal with your errors (you’re free to ignore the returns) whereas this would (via exhaustive pattern match).

> In fact, Go doesn’t make you deal with your errors

Your right, it does not. I will _ =: an error in a throw away script all the time.

I see that in a code review, in production code... Big red flag. This is a departure from an exception, that might be thrown in one place and handled far far away from the code you're looking at.

I'm not an expert in Go, and my experience is somewhat limited, however, a few years back I fixed a really subtle bug in a project that was related to the fact that errors _weren't_ being handled correctly. As a relative newbie to Go, the code in the diff[0] didn't appear to be doing anything wrong, until I added some print statements and realized that the numbers were not adding up correctly. IMO, if the returned value had been more like a Rust optional or result type, I think this issue would have either not been a bug in the first place, or it would have been easier to spot the bug.

[0]: https://github.com/semilin/genkey/commit/fafed6744555c5a81fd...

EDIT: The fact that this was a bug at all makes me fear for the rest of the code base. If this one slipped through the cracks, how can I know that the rest of the code base is correct?

> The fact that this was a bug at all makes me fear for the rest of the code base.

The fact that the commit was accepted into a release without any changes to accompanying tests is what is most concerning. You should be afraid.

Is the wrong code in the new part of the diff or in the old one?

Generally getting zero value from a map is a feature, but the code that the diff replaces did look overly complex and fragile to me already tbh

Rust does not enforce error checking either.

You can ignore errors in Rust.

Ignoring errors is a thing you can do whether you're checking them or not. Rust does enforce error checking, every Result<T, E> is required to be checked before the value can be accessed. The only exception for this is if you don't need to access the Result's value, for which there's at least a built-in warning. And of course `unsafe`.

> Result<T, E> is required to be checked before the value can be accessed.

Which is a flaw in Borgo, at least when interfacing with Go code, as in Go both T and E should independently valid states.

Basic has

    on error goto next

If Rust was already matured by the time Docker was rewriten from Python, and Kubernetes from Java, I bet that Go wouldn't have been the lucky candidate.

I like rust, I write go.

There was a thread here the other day where a rust dev pointed out that "Rust is the language tokio ate"... https://nullderef.com/blog/rust-async-sync/

Rust is a lot of overhead when go is "good enough" for 99% of what needs to get done. That doesn't mean go is good for everything. I would still rather write Rust than C or C++ or bunch of other languages. Look at a project like Pingora, from cloud flair. Perfect Rust project, bad Go project. Rust is in the kernel, rust is what im looking at for a USB driver. I would not shove go in either of these places.

Go could have been like Modula-3, D or C#, instead they decided to revamp Oberon and Limbo, the version 1.0 of those languages from the 1990's, not what was latter done from their learnings, e.g. Active Oberon.

Now thanks to Docker and Kubernetes adoption success, we're stuck with it.

At least now generics are supported, unless one needs gccgo, maybe in 10 years we get Pascal enumerations.

It whooshed right past your head.

Go is stone cold simple to pick up. ITs simple to reason about. I can decompose a project and spoon feed it to a JR engineer and they can get through it.

Rust is none of those things.

Its great for low level stuff, it is in the kernel right next to C and go will NEVER be there. Why, because that is what rust is good at.

> At least now generics are supported, unless one needs gccgo, maybe in 10 years we get Pascal enumerations.

Again I like rust. Crates being colored (as in functions), the shitty compile and tests times... these are things that are holding back rusts adoption in more places... None of this stuff is on the road map to get fixed, it's quite the glass house you have.

Go is going to replace a fair bit of python/ruby in the next few years... Is it going to be rust or zig that eats into c/c++? If the rust community keeps on the way it has been, zig will eat all the core apps we depend on.

Looking forward for AI research in Go taking over the world.

Zig is a Modula-2 (1978), with C like syntax, with added compile time, still has use-after-free, and a community that seems ideologically against binary libraries.

Good luck making it relevant, I am not buying into Bun ever taking over node.

I'm not sure why you included php in your list of examples of things that become bloated with dependencies. I've never seen that be the case.

Look at your list of built-in modules though :)

So stdlib counts as dependencies now?

Well stdlib normally doesn't have stuff like Oracle drivers and such. I think one of the reasons why PHP tends to need so few external dependencies is because it has so many extensions to cover basically anything that you don't need PHP libraries all that much. I don't personally see it as a bad thing but it's something worth considering.

Reply on news.ycombinator.com