Hacker News Reader

Comment by throwaway894345 | Hacker News Reader

There’s a whole lot wrong about this comment, but the most obvious is the claim that Go lacks a new keyword. Firstly, Go has a new keyword and secondly who makes a big deal about whether or not a language has a new keyword?

View on HN

I believe what the commenter is complaining about is that you can't specify default values through a constructor that is invoked with the new keyword. I personally don't see this as a huge concern, since you can just make a constructor function, but it's definitely a valid concern because you could still allow people to shoot themselves in the foot when using a struct literal.

Go's paradigm of making the zero-value something meaningful is great, but it isn't always viable unfortunately. Even in the stdlib there are a couple of structs where you're better off changing those values.

Sure, allowing struct initialization without explicitly setting fields is a foot gun. Ideally Go wouldn’t assign meaning to zero values and instead require each field to be explicitly initialized a la Rust. This is one of the things Go got wrong and Rust got right.

in Go ‘new’ is a function, not a keyword

I think that parent probably refers to the lack of something like this:

x := new MyType

This requires an exception mechanism to handle allocation failure. This issue pervades C++ when exceptions are disabled. Important error handling goes unhandled.

How does Go handle allocation failure? In my understanding objects may be allocated on the stack or heap per the compiler's whims. If a heap allocation fails, you just get "fatal error: runtime: out of memory" and an abort.

Your understanding is correct. That's also what you will effectively get with C or C++ on Linux anywhere you would have had a choice between C++ and Go to behind with.

Since when do heap allocation failures on Linux result in an abort? In C, malloc(3) will return NULL on failure and set errno accordingly. Sure, if overcommit is enabled, you might get a fault if you try to access memory that was allegedly allocated, but there is no strict "malloc failure === fatal error" relationship.

malloc never fails on normal Linux configurations except in very rare instances not applicable to this discussion (e.g. allocating a single structure larger than your virtual memory space).

> if overcommit is enabled

This is the case on ~all systems.

Reply on news.ycombinator.com