What's about CSP (channels/goroutines), static duck typing (Go interfaces) and a very practical standard library?
I had taken a look at Oberon back in 1999 and found it so much worse than Delphi for writing real programs. (which was a precursor of C#/Windows Forms, not Go).
> What's about CSP (channels/goroutines), static duck typing (Go interfaces) and a very practical standard library?
CSP and static duck typing belong to the missing 10% I noted.
Still there are available in other languages that also support native code generation with modules.
> I had taken a look at Oberon back in 1999 and found it so much worse than Delphi for writing real programs. (which was a precursor of C#/Windows Forms, not Go).
Go method definitions are taken from Component Pascal, an extension to Oberon.
Actually I find Delphi much more powerful than Go for large scale development in the enterprise world.
Paulo, I'm very sorry if my question looks a bit rude. The only goal I had is to understand if your opinion is theoretical or based on the real experience.
I don't share your opinion on Go syntax, although, I like Pascal family much more than C and had been using Pascal/Delphi almost exclusively for all my projects until 2003. After that, Delphi became too outdated and I had to switch to other languages.
Also, as I have said before, my knowledge about Oberon and Component Pascal is theoretical, so it might be that you're actually right. Given that these languages are effectively dead (by github criteria: it does not recognize Oberon or Component Pascal, but supports DCPU16 assembly), I don't have a chance to improve this situation (any program written on dead language is theoretical, because it would not be used in prod)
I did contribute the initial version of the os.user package for Windows, which was then picked up by the core team. Also started to add Windows to the exp.gui/draw packages, but gave up on them when they were dropped from Go 1.
I find github criteria a bad one, as many people I know don't even care about it.
I still lurk in the Go mailing list as a language geek, but lost interest, as the language feels too minimalist to my taste, given my experience with other languages.
In a way I belong to the group Rob recently described as C++ programmers. Given my experience in language design, using Go makes me feel I am back in high school with Turbo Pascal 6.0.
But Google's weight might nevertheless help Go become mainstream, who knows.
Something that's said a lot about Go is that it's not that it brings a lot of new things to the table but that it it brings together many great features in to a clean and well thought out language.
The batteries-included toolchain including gofmt and the go command are another pleasure while developing.
As far as languages I've dabbled with in the last few years Go was definitely the easiest to get started with in terms of the development toolchain.
As a compiled language, Go gets usually compared to the experiences people have with C and C++.
The reality is that 90% of Go features are available in the Pascal family branch of programming languages since the early 80's.
So most features that people enjoy in Go are all features that would already be mainstream, if the Pascal branch had won over C to become mainstream.
Even the ability to use a language like Go for systems programming has been proven in the Native Oberon OS and its descendents (A2) at ETHZ.