[mrkgnao]

Go is a lesson in how complexity can't be eliminated, only distributed properly from the beginning so that one doesn't have to hack it in later with messy special-casing that needs you to know how the compiler represents things under the hood.

What happened to "lightweight typesystem that reduces cognitive load"?

[ghthor]

It's really easy to criticize where mistakes were made. The intention was to make a simple language and it worked. The idea resonates with many many engineers even ones such as I that love writing powerful pure fn code.

The intention was great and the result wasn't that great, but it still works pretty dann well. Go is an open language and they are asking for well thought out proposals on where & why the problems exist. Followed by ideas and/or examples to make it better so let's all try.

I think Maybe Types would be an amazing feature to add. Closed types would also be an outstanding win from a UX perspective. Neither of those concepts would add more cognitive load then they remove in my opinion.

[mrkgnao]

> Go is an open language

From what I've seen, this holds only as long as you keep the proposals minimal and restricted to aforesaid hacking around the limitations built into the language. I'm happy to be shown evidence to the contrary: have there ever been any proposals, reacted to in a not-completely-negative way, that were like "uh, maybe we didn't have the right idea about <something basic>, let's do this instead"?

I'll argue there won't be. Every community has a culture: Go's is delightfully warm, friendly, and inclusive, but also surprisingly distrustful of learning that there are easy-to-understand but powerful language features they could be using to write maintainable code without "getting a PhD in type theory from the nearest university" (to strawman a certain [type of] person [I've often encountered when arguing about these things]).

Go has done many things right (aside from the community, good concurrency and really fast compiles come to mind) but language design is not one of them.

[pjmlp]

Go has done nothing new for fast compile times, like any old timer coder will remember from Algol linage of compilers, with Turbo Pascal for MS-DOS being a good example of how long ago those fast compile times are known.

[mrkgnao]

I'm sadly too young and ignorant of CS/technology history to be well-acquainted with the "old times". (It's something I intend to fix.)

Even so, I'm all for praising the good things that Go does: if nothing, because of the tremendous mindshare it's getting and the number of people it reaches.

[pjmlp]

Codegear has kept some of the Turbo Pascal stuff on their museum site.

For example, Turbo Pascal 5.5 targeting MS-DOS was released in 1989 and was compiling 34,000 lines/minute.

https://edn.embarcadero.com/article/20803

This is just one example, there are plenty of other languages to choose from with a module based compilation model, only C and C++ toolchains have lousy build times given their textual inclusion model.

http://www.drdobbs.com/cpp/c-compilation-speed/228701711

So the only achievement of Go's compilation speed was making younger generations think it is something extraordinary.

[mcsofake]

Not to mention that there are modern languages with fast compilers too. D is an example.

[eknkc]

> Go is an open language

Is it, really? I haven't seen a more hostile open source project to outside ideas / requests regarding to language itself.

It's just open source.

[augustk]

> What happened to "lightweight typesystem that reduces cognitive load"?

Oberon is an example of a true lean programming language. The complete language reference takes up only sixteen A4 pages. The compiler OBNC implements the latest version of the language:

http://miasap.se/obnc/