Hacker News Reader

Comment by lederhosen | Hacker News Reader

You can not have a custom collection class containing objects _only_ of a certain type. For example ConcurrentHashTable<Int, String>. That is something that is used every single day. It is used so frequently that Go has generic slice and map built into the language. That is, they created a language with lots of special datatypes that can not be created in normal Go because of its lack of generics instead of creating generics.

It is a bit like asking a Java-programmer to use Java 1.4.

When you ask a Java programmer, or C# programmer or Haskell programmer or Swift programmer or... what they would change in the language you do not get the answer: remove generics.

View on HN

Not without either implementing it yourself or wrapping interface methods.

Go generate is like a manual step for having generics, I imagine one day soon its functionality or something similar will be part of go build.

In response to your particular example, a map plus a mutex seems sufficient.

I dig that it's a few extra lines of code, but I guess I'm looking for a really mean example.

I can not create a really mean example because Go is Turing complete. That means that everything can (with a few extra lines) be expressed in Go.

The problem with your mutex solution is at least two:

1) it is more complex

* more lines to type and read and check and thus harder to understand

* you can forget the mutex

* if you have data structures of hastables, you will have to pass mutexes around or store them together with the tables.

2) it is not nearly as performent as a lock free hash table

(edit indentation)

>I dig that it's a few extra lines of code, but I guess I'm looking for a really mean example.

Well, if you don't care about repeating yourself, mistakes by omission, needless boilerplate, and/or loss of type safety, then, sure, everything is possible in "a few extra lines of code" in a turing complete language...

Back when Borland C++ 2.0 came out for MS-DOS, templates were still being designed.

So the first version of BIDS, Borland's C++ data structures library, used pre-processor tricks where one defined the types before including the respective data structure.

So go generate as workaround feels quite old.

Oddly, I have pushed back on many devs introducing generic interfaces. For library writers, they can be nice. For everyone else, they typically just get you in trouble.

So, I don't want to remove them from the language. However, I do question a large percentage is their use in everyday programming.

Generics are useful all the time. That is why Go has generic Maps and slices. The question is why I am not allowed to use other generic collections.

No, generic collections are pretty much useful all of the time. Other generic things are useful when done well.

> You can not have a custom collection class containing objects _only_ of a certain type. For example ConcurrentHashTable<Int, String>.

I'll start by saying - I largely agree with you. Libraries, particularly of data structures, are the biggest weakness of Go as a language.

However, this bit is not really fair:

> When you ask a Java programmer, or C# programmer or Haskell programmer or Swift programmer or... what they would change in the language you do not get the answer: remove generics.

Much like values, language features need to be compared to each other, not evaluated in isolation.

Everyone likes loyalty, but some people value it over honesty and some value the reverse.

Everyone likes generics, but some people value faster compile times, a more simple language implementation and a lower learning curve more. Some people value it less.

If you value compile times (and you actually think generics make a difference, I do not) you would not make slices and hash tables generic like in Go, would you?

If you wanted a simpler language, you would not make slices and hash tables generic, would you?

If you wanted lower learning curve, you would not make special case generics would you?

If you wanted to wait, to get the perfect generic solution because a sub-optimal one is not good enough, you would not create a sub-optimal non-perfect temporal solution with special-cased generics for certain data types would you?

If you argue that I am loyal and not honest, and therefore like generics because it is used in my favorite language, I think you are wrong.

The languages I use most of the time have a huge design flaw. It is called null. But when they created Go they chose to (except in special cases) get rid of (useful) generics instead of the disaster that is null.

The problem is that Go has not learnt from other languages. It is too imperative, not expressive enough, lacking in static typing and horrible at fault handling.

>(and you actually think generics make a difference, I do not)

It's pretty difficult for generics not to adversely affect compile times. This is especially so if you actually emit specialized code for each type.

>It's pretty difficult for generics not to adversely affect compile times.

Compared to what? Non having type-specific code?

Because if you manually write (or use code generation madness as some propose) that type specific code you need yourself, then the compiler will take the same time to compile it as if generics were a language feature.

The compiler also has to generate the specialized code. But I suspect that the main factor here is just that the presence of generics in a language encourages the use of generic programming to an extent that wouldn't be practical in a language without generics. Take e.g. the boost geometry library (C++). Theoretically you could write a similarly generic library in Go using code generation, and it would probably take ages to build too. Of course, no-one would actually do this.

I bet CLU generics as designed in 1971 hardware would compile quite fast on modern hardware.

Maybe. I don't know. It is pretty difficult to find examples of languages with generics that have compile times comparable to those of Go.

Easy, CLU (1971), ML (1973), Ada (1983), .NET (2003), Delphi (2007), D (2007).

Not every implementation needs to be turing complete C++ style.

I don't know anything about CLU. ML compilers are a mixed bag. OCaml (which is a different dialect, of course), has an acceptably fast compiler, but it's not near-instant like Go. Ada compilers are famous for being slow, at least historically. C# is, again, acceptably quick to compile, but not as quick as Go. I don't know about D. I've heard good things about Delphi's compile times, but no-one uses it now.

In that comparison you forgot the part of turning off optimizations so that the code quality is similar to what Go standard compiler spends time doing.

The compilation speed drop is easily seen when using gccgo instead.

A side note for Delphi, it is still relatively used in European enterprises, with an yearly conference in Germany.

And I could have mentioned other languages like Eiffel, with their mixed JIT for development and AOT via C compilers for final delivery.

The Go compiler is still faster than most of the competition, even when you compare with optimizations turned off.

So you hardly know the languages, never used some of them, but Go compiler is faster.

Very scientific.

>So you hardly know the languages

No, I know all of the languages that you mentioned except CLU. And since I don't think there are even any practical CLU implementations available for modern hardware, I'm not sure how you are able to compare CLU compile times to Go compile times. Are you maintaining a legacy CLU codebase or something?

Now, if there are scientific comparisons available, I'll happily defer to those. But unless you spend inordinate amounts of your time comparing compile times between languages, I doubt that you have any scientific info to go on either.

> I don't know about D. I've heard good things about Delphi's compile times

Doesn't look like actually knowing them to me.

> Are you maintaining a legacy CLU codebase or something?

No, just you are apparently stating that a CLU compiler developed to be usable in 1971 hardware will run slower than Go on 2018 hardware, which doesn't make much sense.

Talking numbers, D was taking 1.24s to compile its complete standard library in 2010, (too lazy to try out the latest version) including the piles of template code that it has.

https://digitalmars.com/d/archives/digitalmars/D/D_compilati...

> Talking numbers, D was taking 1.24s to compile its complete standard library in 2010, (too lazy to try out the latest version) including the piles of template code that it has.

I followed in the instructions for building Phobos on the wiki here at https://wiki.dlang.org/Building_under_Posix:

    real	0m12.269s
    user	0m12.896s
    sys	        0m2.150s

Quite a lot of that time appears to be spent linking. I wonder if the post on the mailing list was reporting the literal compile time, rather than the build time?

It was a bit difficult to find a go project of similar size that was easy to build. The backend component of limetext is about 10k LOC compared to 35k for Phobos. When I do a ‘time go build -o foo’ in go/src/github.com/limetext/backend, I get the following:

    real	0m0.163s
    user	0m0.140s
    sys	0m0.207s

Multiply that by 3 plus a bit to compensate for the LOC difference, and it's still pretty good.

Still no idea what you are on getting with regard to CLU. We don't have any info on how fast it compiled.

Reply on news.ycombinator.com