Hacker News Reader

Comment by cookiengineer | Hacker News Reader

What I still don't understand is why golang has exceptions for "language constructs" like make() and append()... while those are unimplementable in golang.

It's pretty annoying that golang embraces static and functional patterns in its core, but it doesn't even have map/filter/reduce/forEach as generic implementations for all data types.

The lack of a "new" keyword and default values for struct's property syntax is also pretty annoying. Let alone the "hack" with annotations for decoding/encoding everywhere, just so that you can use reflect API in the encoder implementations.

For loop fatigue in golang makes it so unreadable in practice, and leads everybody to offloading manipulation of arrays/slices to helper methods, just to have the for loop there.

The library that fixes this as good as possible with generics is the "lo" library (inspired by lodash) [1]. It's worth taking a look at it if you're curious how to implement it for your structs.

[1] https://github.com/samber/lo

View on HN

> but it doesn't even have map/filter/reduce/forEach as generic implementations for all data types.

Generics landed in the latest stable version, 4 months ago. Before doing too many too early additions in the stdlib they want to observe how generics are used in the wild. I don't have the link handy, but it was mentioned in one of the generics discussions (issue on GitHub).

In these cases (another case was error wrapping prior Go 1.13) they start with experimental libraries in `golang.org/x/exp/...`, which they did here as well:

https://pkg.go.dev/golang.org/x/exp/slices

https://pkg.go.dev/golang.org/x/exp/maps

So while the stdlib doesn't have the functions you're looking for yet, this might change over time.

>they want to observe how generics are used in the wild. I don't have the link handy, but it was mentioned in one of the generics discussions (issue on GitHub).

The rationale can be found here:

https://github.com/golang/go/issues/48918

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?

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.

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.

Can’t hate on generics, so we need to find something else.

Go takes away type system fidget spinners and leave devs with nothing to do but the actual job, which they hate, and thus they hate Go.

Generics are useless when there is no way to integrate them with your rest of the code.

As golang has no instanceof or typeof keyword, you practically you cannot use a method that uses multiple types as arguments without having to use the reflect API, just to have an if/else branch on what to do with that argument.

The things that I mentioned are from another point of view where language designers and implementers decided to implement the interactions with their data types in a different way, by providing overloadable methods with different function signatures for the same function name whereas in golang everything must be "namespaced" in a sub sub sub package.

Good luck finding the right methodology where to sort in a method that can handle two different structs. If they're nested it's not even possible cause golang's dependency resolver doesn't allow cyclic dependencies.

Parsing html5 in golang is a nightmare, and I've realized that this language is not made for such a use case.

>As golang has no instanceof or typeof keyword, you practically you cannot use a method that uses multiple types as arguments without having to use the reflect API

You don't have to use reflection, there are typecasts:

"value, ok := arg.(MyType)"

You can also switch on a type. How is it different from instanceof in practice?

The point of described scenario was to have a _different_ if/elseif branch, and not the identical behaviour for one struct type.

If item instanceof HouseStruct {}

Elseif item instanceof ContainerStruct {}

With your suggested solution you end up with OOP fatigue and GenericBuildingImplementationStruct which is probably not what golang wanted to embrace with their type system.

I'm not sure I follow what you mean. In Go the equivalent to your example is:

  switch val := item.(type) {
    case HouseStruct:
    case ContainerStruct:
  }

Doesn’t type switch require an interface value? Go tries not to add boxing-like overhead to generics.

Go helps devs by creating extra work like checking for inner nil and outer nil, hitting the "if err != nil { return nil, err }" button on their keyboard, using reflection to instantiate unexported structs written by library authors who decided nobody should ever be able to make an interface-compatible wrapper that adds capabilities to their library, and relying on the language to enforce the checking of error return values, which it won't actually do if you don't assign any of the return values to variables.

Library authors not exporting their fundamental data structures is very painful, but this happens in many other languages too.

There is no “inner/outer nil”. People just need to understand how interfaces work (they’re a reference type and sometimes they reference another reference type, so just like any language with nullable pointers/references, either the pointer or the pointee can be nil). 101 level stuff. There are valid criticisms of Go (I’m not a fan of nil in the first place, for example), but this inner/outer nil myth needs to die.

Sure, if any method anywhere takes a pointer receiver, then anyone can declare an interface that matches that method, and that interface is (among other things) like an Option<Option<T>> in Rust or a ??T in Zig. It's weird to post "There is no inner/outer nil" since the most straightforward interpretation of that claim is that there is no None/Some(None) distinction, and this is straightforwardly not true.

For some reason, most languages do not encourage the users to create types that are similar to Option<Option<T>>.

Have you actually taken this stuff to a group of first-semester CS students and had them understand it and think it was a good design?

In the stdlib there's this function:

  // String returns the source text used to compile the regular expression.
  func (re *Regexp) String() string {
   return re.expr
  }

which takes a pointer-to-struct receiver and does not check it for nil before using it. So any program that declares a Stringable interface, diligently checks Stringables to make sure they are non-nil, then calls String() only on the non-nil ones is allowed to panic on this line from the stdlib because re == nil. The wonderful tutorial[0] teaches beginning go programmers to write the same sort of bug in the first lesson about interfaces.

[0]: https://go.dev/tour/methods/9

> the most straightforward interpretation of that claim is that there is no None/Some(None) distinction, and this is straightforwardly not true.

That’s not the most straightforward interpretation, since it would invalidate the original criticism that I responded to (that Go more-or-less uniquely requires you to check inner/outer nil).

> For some reason, most languages do not encourage the users to create types that are similar to Option<Option<T>>.

Lots of languages “encourage” references to reference types (including Rust), but many of the ML family including Rust have non-nilable references. Go’s error (and that of many others including Python, Java, C, JS, etc) isn’t that it supports/encourages references to references, but rather that all references are nilable.

A difference between Go and Java is that a null Regex in Java will not be implicitly converted to a non-null Stringable containing a null Regex.

If you'd like, I can post about "implicit conversion from nil pointers to non-nil interfaces containing nil pointers that can only be checked for nil using reflection, combined with interfaces that work by duck typing and an existing body of code that pervasively uses struct pointer receivers in methods that panic when passed a nil pointer, even if it was a nil pointer contained in a non-nil interface" but that's a bit of a mouthful.

> A difference between Go and Java is that a null Regex in Java will not be implicitly converted to a non-null Stringable containing a null Regex.

You have it exactly backwards--you're arguing that Go should implicitly convert a not-nil interface (that is implemented by a nil pointer) to a nil interface so that Go interfaces behave more like Java interfaces, but Go isn't doing any implicit conversions (unless you consider "assigning a concrete value to an interface" to be an "implicit conversion", but Java does this too).

> implicit conversion from nil pointers to non-nil interfaces containing nil pointers

Again, Go doesn't do any such implicit conversion, and you're arguing the position that it should. An interface is just a tuple containing a pointer to the data and a pointer to the type `(pdata, ptype)`. A nil interface is `(nil, nil)`, and an interface that is implemented by a nil pointer is `(nil, <pointer-to-concrete-type>)`. You're arguing the position that the latter should be implicitly converted to the former, but this would break code that uses nil as a valid value.

The root cause of the problem isn't how Go handles nil pointers in interfaces, but rather that Go has nil pointers, interfaces, etc at all. Go gives you no way to express that a reference type can't be nil, but ideally it would have an enum system like Rust's that makes optionality an opt-in property via `Option<T>`. If an interface `Bar` is implemented by `*Foo` and neither `*Foo` nor `Bar` can be nil, then this problem largely goes away. If `Bar` is implemented by `Option<*Foo>`, then `Option<*Foo>`'s methods need to handle both the `Some(*Foo)` and `None` (i.e., nil) cases.

> that can only be checked for nil using reflection

You don't need reflection:

    i, ok := (iface).(*int)
    if !ok {
        fmt.Println("`iface` is not an `*int`")
    }
    if i == nil {
        fmt.Println("`iface` contains a nil pointer")
    }
    fmt.Printf("`iface` contains a pointer to `%d`", i)**

> Go isn't doing any implicit conversions

What do you call it when you assign a value of one type to a variable of another type and the language creates a new value, different from the one you were assigning, and stores that new value in the variable? In C++ this is called "implicit conversion." Here's the tutorial again:

  var a Abser
  f := MyFloat(-math.Sqrt2)
  v := Vertex{3, 4}
  
  a = f  // a MyFloat implements Abser
  a = &v // a *Vertex implements Abser

The last two lines involve constructing a new value for the LHS of a type that differs from the type on the RHS without any function calls, constructors, "make" keywords, etc. What word would you like to use for this?

You could just as well have a patch that changes the type of a single variable from *Vertex to Abser or changes the return type of a single function from a type that matches an interface to the interface, and that would also create an assignment that creates a new value of the new type that will panic in contexts the old one would not have panicked, even though the programmer has not added any code saying "please construct an Abser (type, pointer) tuple from my pointer."

> Go should implicitly convert a not-nil interface (that is implemented by a nil pointer) to a nil interface

I am not arguing for that.

> unless you consider "assigning a concrete value to an interface" to be an "implicit conversion", but Java does this too

I guess, but this is much less of a conversion than Go is performing because the runtime value does not change at all. It's the same pointer, not a tuple containing the pointer. Unlike in Go, this assignment may very often be correctly implemented by a sequence of 0 instructions! Importantly, the meaning of "foo == null" is unchanged. This is not because Java performs implicit conversions of interface types to specific pointer types at the null check. It's because in Java interfaces are unable to express having a concrete value of a specific class which is null, because they are just pointers. One might say "Java interfaces do not have inner and outer nil values" as a shorthand for this.

> Go gives you no way to express that a reference type can't be nil

I agree that this would solve the problem.

> You don't need reflection:

You don't need reflection if you statically build an exhaustive list of all pointer types that match the interface in the whole program but don't actually match the interface in the sense that the methods don't handle nil, then generate code to handle each of them. This just doesn't seem like a reasonable option because sometimes people make libraries so they can't necessarily do static analysis of the whole program at the point where they are writing the code. It also sort of defeats the purpose of interfaces, I guess.

> What do you call it when you assign a value of one type to a variable of another type and the language creates a new value, different from the one you were assigning, and stores that new value in the variable? In C++ this is called "implicit conversion."

Right, I addressed this when I said:

> unless you consider "assigning a concrete value to an interface" to be an "implicit conversion", but Java does this too

So let's just skip to your reply to that bit:

> I guess, but this is much less of a conversion than Go is performing because the runtime value does not change at all. It's the same pointer, not a tuple containing the pointer. Unlike in Go, this assignment may very often be correctly implemented by a sequence of 0 instructions!

Yes, Java and Go have different implementations/conceptions of "interface". I don't see what bearing this has. From the programmer's perspective, Java's interface assignment isn't more explicit than Go's even though the underlying mechanisms differ. In particular, Go needs to create a new "header" value because its interfaces are polymorphic across any type (including primitives and value types!) whereas Java's are polymorphic only across objects and Java attaches a header to every object.

> Importantly, the meaning of "foo == null" is unchanged.

Go's `foo == nil` isn't changed either. It behaves like it does for all reference types. The difference between Java and Go is conceptual, but the `==` operator is coherent within each of them.

> This is not because Java performs implicit conversions of interface types to specific pointer types at the null check.

Agreed, and to be clear, I didn't claim it did. Nor does Go, so I'm not quite sure what you're responding to here.

> It's because in Java interfaces are unable to express having a concrete value of a specific class which is null, because they are just pointers.

> One might say "Java interfaces do not have inner and outer nil values" as a shorthand for this.

Right, but we were debating whether or not Go interfaces have inner or outer nils. Consider `var x interface{} = 0`. What's the outer value? And what's the inner value? The whole point of my comment is that you're conceiving of Go interfaces as having inner and outer values, but Go interfaces are just a fat pointer. As such, you can have pointers to pointers with Go interfaces. And while you can't have pointers to pointers with Java interfaces, you can elsewhere in Java so a Java programmer should be able to reason about Go interfaces because they can understand the concept of a nullable pointer to a nullable pointer.

Ultimately, it seems that you're criticizing Go for having a different interface mechanism than Java, and you get bugs when you treat Go interfaces like Java interfaces. And Go made the right choice here, because it can express polymorphism over a wider range of types than just objects (contra Java interfaces) and indeed it doesn't have any sort of object/primitive bifurcation--from the perspective of Go interfaces, all concrete types are just data.

> Go's `foo == nil` isn't changed either

This is incorrect. The value of "foo == nil" in function A can be changed by a patch that only changes the return type of function B from *Vertex to Abser. If you would like to say that this is not because of implicit conversion from pointer to interface and it is not because of any semantic difference between comparing the vertex pointer to nil and comparing the Abser interface to the nil interface value, I would like to know what you think causes it.

> Right, but we were debating whether or not Go interfaces have inner or outer nils

I haven't been debating this since it's obviously true. You seem to agree that an Option<Option<T>> may take on the values None and Some(None) separately. You can debate about what to call things, but I'm still not sure what you would like me to call the difference that exists between Java and Go which causes code that does not throw NullPointerExceptions in Java to panic in Go because the inner value is nil and the user has failed to use reflection (or generate an exhaustive list of all possible pointer types that could match the interface but whose method does not handle nil and check each of them individually).

> Consider `var x interface{} = 0`. What's the outer value? And what's the inner value?

What do you mean? That's a (int, 0) tuple. The type tag is int. The inner value is 0. interface{} expresses outer-nil-ness using a special value of the type tag, so that's (nil, nil) which a different value from (*Vertex, nil).

> And while you can't have pointers to pointers with Java interfaces, you can elsewhere in Java so a Java programmer should be able to reason about Go interfaces because they can understand the concept of a nullable pointer to a nullable pointer.

Please demonstrate by declaring a pointer to a pointer in Java. Ideally, you could also show how in Java to convert a pointer to a pointer to that pointer using a single assignment, without calling any constructors or functions or making any explicit casts.

> Ultimately, it seems that you're criticizing Go for having a different interface mechanism than Java, and you get bugs when you treat Go interfaces like Java interfaces. And Go made the right choice here, because it can express polymorphism over a wider range of types than just objects (contra Java interfaces) and indeed it doesn't have any sort of object/primitive bifurcation--from the perspective of Go interfaces, all concrete types are just data.

No, I'm criticizing Go for being fundamentally broken in a novel way that no language had come up with previously. It should seriously not be possible to cause a panic in a method call that is guarded by a nil check by changing the return type of some other function from a pointer-to-struct to an interface and making 0 other changes.

If you ask the language designers on the mailing list why it's like this, they'll tell you that it's important to make the zero values of types useful, including nil pointers of specific types. They also decided to ship a stdlib in which like half of the methods with pointer receivers immediately panic when passed nil, and they would like to tell you that the right way to avoid panicking is to not store such pointers in such interfaces. The language will do nothing to help you to avoid storing these pointers in these interfaces. Even if you successfully avoid storing these pointers in these interfaces in your code, if you store them in any interface at all, other code may use "interface upgrades" to find out that the methods that panic exist and call them. Wow!

No it's simpler than that, they hate Go cause it's a half-assed language. The creators didn't respect developers enough to make it consistent and complete cause "devs are not smart enough". The argument about "getting things done" is like saying the language is Turing complete.

That’s actually a brilliant assertion (sorry for the crap pun).

The majority of developers I work with are only aware of the success paths of their code. That means we’re knee deep in exception corpses because they avoided doing part of their job.

Go makes them deal with it.

Not really.

Rust, Haskell, Kotlin, yes. They force you to consider the error path.

Go makes it all too easy to just ignore errors and produce crashy code.

Go makes it explicit where the error was ignored so you can go and wring the neck of the bastard who ignored it :)

Sure, but the compiler doesn't care, and that's the problem.

Sure, Go makes you write code to do something in the case of an error - over and over again at every level in the chain. Which tends towards programmers putting in minimal effort each time, often meaning when some low level error occurs in the resulting application little information is forthcoming to the user as to why it's just aborted on them. Good and bad error handling can be done in any language. I've not seen any evidence that Go apps and libraries generally do it better than those written in exception-enabled languages.

When we were rewriting a module in our backend from PHP to Go, explicit error handling helped us find and fix bugs due to edge cases we weren't even aware of. The usual idiom in PHP was to just catch exceptions at the top level and show an error (I think that's what exception handling usually devolves to). Since in Go we were explicitly handling errors at every level in the chain, it forced us to reason about error conditions more carefully and made us more aware of potential edge cases, which didn't happen when we were writing in PHP because you only saw the happy path when looking at the code (i.e. little mention that something can go awry because exceptions are hidden from control flow). I remember in one such case, we found out you couldn't just bubble up an exception, you had to process it immediately, otherwise data could end up in an inconsistent state.

However, repetition can introduce bugs, too, for example a very common mistake is to write this:

  if err != nil {
    return nil
  }

instead of this:

  if err != nil {
    return err
  }

which is pretty serious because you essentially ignore the error.

This particular pattern is so common your brain often ends up completely skipping it and it's pretty hard to detect during code review.

Now I don't know how your PHP code was structured, but in my experience there usually three types of mistakes done with error handling in PHP code

1) not properly checking return values from standard library functions

2) not checking correct last error level function after use of standard library function, e.g. json_last_error(), curl_errno() etc

3) different handling of old style errors vs exceptions

This is an unfortunate legacy of PHP, it is messy and error prone.

I'm not a golang programmer but to my understanding is that the golang compiler does not enforce strict error handling, if a function changes its signature to start returning an error when it previously didn't is not something the compiler will warn about. This is unfortunate too.

I never really been a huge fan of exceptions either, but the good thing about exceptions is that they are not silent by default whereas return values can be ignored and therefore errors can missed.

What I'm trying to say is that we need stricter compilers.

My personal style of coding in PHP to avoid hidden bugs is to code in defensive style, where the unhappy path is as important as the happy path, combined with strict type handling where I try to use the type system to detect bugs.

>if a function changes its signature to start returning an error when it previously didn't is not something the compiler will warn about.

This is why we use linters, they can catch this kind of problem.

What is for loop fatigue?

Seems like a fake problem that one would only feel if they buy too much into functional programming.

Some ideas in fuctional programming are useful, but overall, for loops are much more preferable to map/filter/reduce.

For loops are much more easily amenable to incremental changes.

"reduce" is particularly bad. It obfuscates control flow for no benefit at all.

>but overall, for loops are much more preferable to map/filter/reduce

I strongly disagree on this one. A .map or a .filter are clear and concise while filtering or mapping, particularly in a streaming situation where you're only iterating the collection once.

You can trivially write code using this paradigm that's easily readable, performant, and takes up a handful of lines that would take dozens in Go.

Reply on news.ycombinator.com