Go’s Type System Is An Embarrassment

https://functionwhatwhat.com/go%E2%80%99s-type-system-is-an-embarrassment/

by mikeevans • 13 years ago

109 109 13 years ago

functionwhatwhat.com

letstryagain• 13 years ago

Are we complaining about generics again?

alok-g2• 13 years ago

I see nothing wrong with that. I would like to keep on complaining till they listen! :-)

kisielk• 13 years ago

It's not that "they" aren't listening. There's a limited number of developers working on the language, there are many other problems being solved.

So far despite all the people lamenting the lack of generics in Go I've yet to have seen someone propose a viable (eg: backwards compatible, realistic to achieve with the current compilers and runtime, etc.) way to implement, nevermind someone who's produced a prototype.

Maybe that sort of thing will be easier once more of the toolchain is rewritten in Go later this year.

I don't think anyone is denying that generics make writing certain types of code easier, but it's worth getting them right since major language additions are something you need to support for a long time.

frou_dh3• 13 years ago

This masterclass in clickbait titling pulled in 735 comments and counting on /r/programming. Watch and learn, bloggers!

dkuntz22• 13 years ago

It did something similar here before the outage.

jjsz• 13 years ago

Was it cached?

thinxer• 13 years ago

What's wrong with leaking un-exported element? Your code wants it to be exported. If you care about it, please return an interface type.

rfw• 13 years ago

As I posted before the outage, I don't think leaking un-exported elements is actually that broken either -- Haskell gets by fine with it (you can omit the type and its constructor in the module export list and have types "leak" into the code importing said module). It can be a useful way to keep types opaque and not allow users to construct instances directly.

The actual issue, in my opinion, is the weird behavior of the reflect package which allegedly cannot reflect on the leaked element despite its members being publicly accessible anyway.

DrJokepu• 13 years ago

Author here. What I’ve written regarding the reflect behaviour isn’t entirely true and I should probably update the article to reflect that. It’s possible to get (but not set) the value of unexported fields as long as they are of a built in type (e.g. int). What’s not possible is to get access to unexported fields as empty interfaces, which means you cannot type assert them to structs or other types. This seems like an arbitrary limitation (although I’m sure there is a reason for it) and somewhat limits the usefulness of the reflect package.

colin_mccabe4• 13 years ago

What's embarrassing is that people are still evaluating programming languages like they were bags of features. The more features you stuff in the bag, the better it must be!

The reality is that generics aren't free. They result in difficult-to-understand error messages and more cognitive complexity.

To quote Yossi Krenin, "You may think it's a StringToStringMap, but only until the tools enlighten you - it's actually more of a... std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >"

Of course, it would be nice to have generics, or something like them, for writing typesafe containers. But there are other goals in the language like fast compilation, easy-to-understand error messages, and overall simplicity. I hope they can come up with an implementation of generics that can keep those good properties of the language. But if they can't, it shouldn't be added just to get a feature bullet point. Use the right tool for the job.

alok-g2• 13 years ago

I am not convinced that C++ examples are valid as a generalization of the failures of generics for other languages. C++ libraries are often overly generalized with means to "configure" the generics by passing additional type arguments. I do not think it has to be like that.

davidcuddeback• 13 years ago

C++ templates are also latently typed. The bad error messages arise from the fact that C++ templates behave more like a duck-typed language than a strongly-typed language. Look at the error messages that arise from C++ template errors and a lot of them are about missing functions, just like you get at runtime when you have a type error is a dynamically-typed language. I think C++ concepts will improve this when they're standardized, because they will allow C++ compilers to type-check template arguments. (See bounded polymorphism.)

AnthonyMouse• 13 years ago

Some of it is also the fault of the compilers for being too explicit in their default error messages. You get that horrible output because string is really a typedef to "basic_string<char>" and basic_string takes two more template arguments with defaults. But why is the compiler resolving the typedef in the error message by default? At least let it be "std::map<std::string, std::string, std::less<std::string>, std::allocator<std::pair<std::string const, std::string> > >" instead of that inscrutable noise.

And if you really need to provide the information that "std::string" is "std::basic_string<char, std::char_traits<char>, std::allocator<char> >" then put it on a separate line in the output, once, instead of repeating it internally within every recursive template instantiation.

kerkeslager• 13 years ago

The reality is that generics aren't free. They result in difficult-to-understand error messages and more cognitive complexity.
To quote Yossi Krenin, "You may think it's a StringToStringMap, but only until the tools enlighten you - it's actually more of a... std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >"

The Kreinin quote is in relation to C++. For historical reasons (reverse compatibility with C) and interoperability with other parts of the language (manual memory management), C++ types are way more complicated than types in a more recent language such as C#, where a Map<string,string> is really not much more complicated than you would think it would be. One might be able to argue that generics make things more complicated, but they certainly don't have to make them as complicated as C++ does.

colin_mccabe4• 13 years ago

You can't blame C++ generics on compatibility with C, because C doesn't have them. The culprit isn't manual memory management either.

The issue is just that the complexity of the type grows exponentially as you compose more generic types together. The string was templated on three things: the character type (usually char), the traits, and the allocator. Fair enough, but now the map is templated on the key type, the value type, the comparator, and the alocator. So that's 4 x 3 x 3 = 36 different parts in the StringToStringMap. Java has similar "russian doll" types where you have many different layers of generics within generics. You need to read all of them to fully understand the behavior.

To be honest, overuse of generics is a code smell in both C++ and Java. One of the early warning signs that your code might have this problem is if you feel the urge to template on bool. I do think that generics may come to Go some day, but I think it will require a lot of thought, and it may not come in quite the same form as it did for Java and C++. No doubt there will be many angry posts about how Go "has" to do it the C++/Java way at that point.

stinos• 13 years ago

What's embarrassing is that people are still evaluating programming languages like they were bags of features. The more features you stuff in the bag, the better it must be!

well in some cases your platform only support one language, or maybe to. So it makes a lot of sense to then evaluate tha language as a whole. Even then, I don't see much wrong with evalulating a language as abag of features as long as you don't simply consider the amount of features but rather it's quality.

The reality is that generics aren't free.

No, but I noticed that the end, once you know how to use them properly and become used to them, they tend to become invaluable, even to a point that programmers coming from years of C++ background are struggling in other languages when they lack generics. Sure, right tool for the job. But in case of generics I'd say they're much too broad to speak of a single tool and they can be used for multiple jobs. So I'm with the author and feel go lacks on that point.

To quote Yossi Krenin

aka the guy who doesn't want to write std::map< std::string, std::string > :P

codygman• 13 years ago

Please see the simple implementations of generics in ocaml and C# (added later).

nostrademons5• 13 years ago

My biggest beef with the Go typesystem is that they didn't get rid of nil. Tony Hoare (the guy who invented null) has acknowledged they were his "billion dollar mistake" [1], common practice in Java and Haskell is moving away from them, and yet Go included them anyway - in a language that's supposed to be robust because you're supposed to handle every case. The Maybe (or @Nullable) type is a much better idea, because it flips the default from "any variable may be null" to "only variables explicitly declared as such may be null".

[1] http://www.infoq.com/presentations/Null-References-The-Billi...

frou_dh3• 13 years ago

It's exacerbated by nil being reused as a value for things that aren't even pointer types, like the slices, channels and especially interface "pairs"[1]

[1] (<NoType> . nil) vs (T . nil) is pretty weird: http://play.golang.org/p/fmk-72OYkO

shurcooL2• 13 years ago

There is no such thing as a Go variable with no type. They all have a type (could be interface{}) and a value (could be nil).

    package main
    
    import (
    	"fmt"
    
    	"github.com/davecgh/go-spew/spew"
    )
    
    func main() {
    	var x interface{}
    	var y chan (int)
    	spew.Dump(x)
    	spew.Dump(y)
    
    	var z interface{} = y
    	spew.Dump(z)
    
    	fmt.Println(x == z)
    	fmt.Println(y == z)
    }
    
    // Output:
    (interface {}) <nil>
    (chan int) <nil>
    (chan int) <nil>
    false
    true

kkowalczyk• 13 years ago

Hoare didn't invent 0-valued pointer. It was there since the beginning of time. Or at least the beginning of the CPUs.

People talk about getting rid of nil like it's actually possible.

It's not.

If you have pointers, they sometimes have to start the life uninitialized (i.e. with a value of 0) hence nil pointers.

As you admit yourself, the proposed solutions don't actually get rid of anything. At best they can force you to handle nil value by wrapping it in some wrapper.

Guess what - if you have that kind of discipline, you can do the same in C++.

Why aren't people doing that?

Because it comes at a cost. There's a cost to the wrapper and when it comes down to it, you still have to write the code to handle the nil pointer whether you're using a wrapper or a raw pointer.

It just doesn't buy you much.

Finally, fixing crashes caused by referencing a null pointer is downright trivial. Spend a few weeks chasing a memory corruption caused by multi-threading and you'll come to a conclusion that fixing a null pointer crashes (which can be done just by looking at the crashing callstack most of the time) is not such a big deal after all.

JoshTriplett• 13 years ago

If you have pointers, they sometimes have to start the life uninitialized (i.e. with a value of 0) hence nil pointers.

Right, and those pointers must then be declared as potentially null. Or more generally, potentially non-present values of any type need a type like Maybe T.

As you admit yourself, the proposed solutions don't actually get rid of anything. At best they can force you to handle nil value by wrapping it in some wrapper.

That's exactly the point: you can tell from a glance at any type whether it can be null or not, and you can only look at the value of something that's guaranteed to not be null; otherwise, you have to handle the null case first. Forcing that to happen at compile time via the type system is far better than dereferencing a null pointer at runtime.

eru3• 13 years ago

If you have pointers, they sometimes have to start the life uninitialized (i.e. with a value of 0) hence nil pointers.

Why do your variables have to start life uninitialized?

Why aren't people doing that? Because it comes at a cost. [...]

Not a runtime cost, though. This can be handled purely by the typesystem at compile time.

jdmichal3• 13 years ago

If you have pointers, they sometimes have to start the life uninitialized (i.e. with a value of 0) hence nil pointers.

Maybe at the machine level. But there's nothing that stops a programming language a few levels above machine from requiring that every pointer be initialized with a reference.

As you admit yourself, the proposed solutions don't actually get rid of anything. At best they can force you to handle nil value by wrapping it in some wrapper.

The entire point is that a large majority of APIs don't WANT to accept or handle NIL, but have to, because the default is to allow it. And in some languages, such as Java, the only way to extend the type system is with reference types, making it impossible to ever not have to handle NIL. By reversing this decision, it becomes possible to specify both allowance and disallowance of NIL-valued parameters. Why you would ever argue against such expression is beyond me.

nostrademons5• 13 years ago

As others have pointed out, I'm not talking about nil as the zero-valued pointer at the hardware level. I'm talking about nil as the additional member of every type in the language's typesystem. A typesystem is an abstraction over the hardware, designed to catch programmer errors and facilitate communication among programmers. There's no reason it has to admit every possible value that the hardware can support.

And people are applying that sort of discipline - see the NullObject pattern in any OO language, or the @Nullable/@NotNull annotations in Java, or !Object types in Google Closure Compiler. The thing is, they have to apply it manually to every type, because the type system assumes the default is nullable. That makes it an inconvenience, which makes a number of programmers not bother.

I'll agree that null pointers are comparatively easy to track down compared to memory corruption caused by multi-threading. Threads are a broken programming model too, and if you want a sane life working with them you'll apply a higher-level abstraction like CSP, producer-consumer queues, SEDA, data-dependency graphs, or transactions on top of them.

derekchiang• 13 years ago

I'm surprised no one has mentioned Rust[1] yet. It's a systems programming language that has managed to get rid of null pointers by carefully controlling the ways in which a a value can be constructed[2].

[1] http://www.rust-lang.org/

[2] https://github.com/mozilla/rust/wiki/Doc-language-FAQ#how-do...

Sharlin3• 13 years ago

Guess what - if you have that kind of discipline, you can do the same in C++.

Well, ironically, C++ already has non-nullable pointers. They're called references and they work extremely well.

AYBABTME• 13 years ago

In 97.5% of case, the `nil` value of Go types follows the NullObject pattern.

There's really just nil pointers that are still equivalent to `null`, and their absence would be an abnormality, as there's no reason why a pointer couldn't have a nil representation.

lmm3• 13 years ago

If one is to write robust programs it is useful to automatically enforce that there are no execution paths that set particular pointers to null.

skrebbel• 13 years ago

Just because "NullObject pattern" ends with "pattern" doesn't mean that it's usually a good idea.

kristianp• 13 years ago

Go is designed to be a small, simple language, it's not hard to release that. If you want a fully featured type system, go program in Ocaml, Haskell or another 'big' language.

TylerE• 13 years ago

That falls flat on it's face as a cop out when you look at a language like nimrod that manages to be practically as simple as go while including full generics. Oh, it's faster too.

http://nimrod-lang.org/tut2.html#generics

rdtsc5• 13 years ago

Nimrod is a gem. Just needs a big company to host release parties and sponsor it.

I am convinced, a good part of Go's popularity is Google. As a language it is ok. Has good stuff in it. Quite often the argument for adoption is "Google is behind it, and it is becoming really popular". Which, is not completely irrational -- it is nice to have a large company throwing away perhaps years of quality full-time dev work at a language.

lucian19002• 13 years ago

Both ML and Haskell are really tiny languages syntactically and have very simple core type systems.

Go has both crappy syntax (excusable for appealing to C programmers) and a pathetic type system.

namelezz• 13 years ago

Maybe Go is a small and simple language now because it's still missing some features that potentially make it a complicated language. :)

bsaul• 13 years ago

Type system power really is the only question i have left relative to go. I've always seen go being used for low level very technical stuff, where you don't need lots of abstraction, but rather powerful primitives and libs. I've always wondered how it scales to business process modeling, and the lack of generics always worried me.

On another aspect, 2013 was the year of Go being unanimously praised, and i've got the feeling 2014 is going to be the year of the backlash.

Still, i don't see any other languages able to take the crown back. Rust looks way too unpolished and has not only one but multiple pointer types.

TheCoelacanth• 13 years ago

Rust really doesn't target the same uses that Go targets. Go basically targets people who need a faster Python or a simpler Java. It doesn't have enough low-level control to be used for most of the things that C is still used for.

Rust targets the low-level uses where a high degree of control over memory management is necessary. One of it's main goals is to make it possible to statically reason about memory ownership.

You would never try to implement something like a modern browser or a production-quality language runtime in Go. On the other hand, Rust is targeted directly at that kind of thing, and the multiple pointer types are absolutely necessary for those use cases.

pkroll• 13 years ago

Nothing I've seen on Hacker News would lead me to the conclusion that 2013 was the year of Go being unanimously praised. It gets flack every time a story shows up.

pcwalton3• 13 years ago

Rust looks way too unpolished and has not only one but multiple pointer types.

This is overstated. There is just one pointer type in the language, the unique pointer, and there are also references.

That said, the distinction between unique pointers and references is there for a reason. You need this power for low-level programming. A pervasive global GC is not appropriate for all applications.

vectorpush• 13 years ago

I love go, but my personal gripe with the type system is that there is no way to pass type information around without using a zero valued (or fully populated, it makes no difference) instance. For example, I have a factory struct with a New method that returns interface{MySignatures()}, but I cannot inform the factory of the concrete type I want it to produce without passing in something like new(ConcreteStructWithMySignatures). Some have suggested I pass in a string, but what is the point of a type system if I have to use strings to reason about my types?

puppetmaster3• 13 years ago

Are we trying to make Go into Java or JavaScript as it relates to dynamic or static?

Go’s Type System Is An Embarrassment

Related Stories