3 ms·

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 make

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?

deleted 4y ago
[deleted]
tbarbugli 4y ago
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
- kevin_thibedeau 4y ago
  This requires an exception mechanism to handle allocation failure. This issue pervades C++ when exceptions are disabled. Important error handling goes unhandled.
  - petmon 4y ago
    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.
    - morelisp 4y ago
      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.
      - ericpruitt 4y ago
        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.
        morelisp 4y ago
        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.
leononame 4y ago
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.
- throwaway894345 4y ago
  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.

deleted 4y ago

[deleted]

tbarbugli 4y ago

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

kevin_thibedeau 4y ago
This requires an exception mechanism to handle allocation failure. This issue pervades C++ when exceptions are disabled. Important error handling goes unhandled.
- petmon 4y ago
  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.
  - morelisp 4y ago
    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.
    - ericpruitt 4y ago
      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.
      - morelisp 4y ago
        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.

leononame 4y ago

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.

throwaway894345 4y ago
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.