You may complain that programmers have a professional obligation to learn those new paradigms. You may complain that programmers should consider "learning a new paradigm" a smaller strike against a language, especially if it brings other good things with it. But that won't change observed reality, in which programmers do want to not have to risk several months to a year on something they aren't sure will pay off. By contrast, if you know any of the existing manifestly-typed languages at all (Java, C, C++), which most programmers do to some extent, you'll be writing fancy concurrent code in Go next week. Possibly even "tomorrow". You can be shipping production code in a month.

The language nerd in me really wishes Go had isolated its goroutines from each other and only passed things by value. (While I like Rust's much finer-grained handling of that for a lot of other reasons, you can get a lot of the benefits in a language where the threads aren't supposed to be that large by isolating to small threads, and it's way easier to implement.) The pragmatist in me is forced to reluctantly admit that had it done so it probably wouldn't have succeeded as much, because while that may not have been a "full" paradigm shift if the rest of the language was still imperative, it still would have been at least half of one. That affects how you design larger programs. In a lot of good ways, I think, but still, change with an unknown prospect of payoff.

So... it depends on your point of view. It's not revolutionary in the sense that there's anything new in it. But it is a somewhat revolutionary combination of concepts.

You're even free to join me in being a bit sad that fusing your concepts to an Algol-descended language is basically mandatory for success right now. But, one step at a time. We are slowly creeping away from it. As I've often observed, programming as a profession does not move anywhere near as quickly as some people think; there's a constant surface churn of technologies and languages, but deep paradigm shifts take decades.

Go is popular because it is accessible. The cognitize load of the language is in effect ammortized by being spread over the life cycle of the dev process (i.e. run vet to do x) instead at localized in cycle/space of code-time/source-code, so even professionals not bothered by complexity can see an incentive to using the language.

But I am not aware of the language enabling a class of software systems, etc., that have become more feasable because of the language.

As has been pointed out by many, at some point even the novice programmer has to get serious given the mix of pointers and channels and sync constructs which demands a degree of sophistication, so the accessibility aspect degrades over time.

And then -- and here is why I feel there is pushback regarding Go koolaid -- this somewhat on 'the fence' approach of the language towards concurrency (originally "communicate don't share memory") gives this impression of a glorious hack but a hack aspect to this "revolutionary mix" that you refer to. At some point, the ala cart type system of Go presents issues to people who have invested the time to get serious about these matters but find that their favorite light-weight language is not fully up to the task of keeping up with our conceptual models of thinking about our software.

One of those runtimes is Ruby (Ruby uses lightweight threads, not OS threads), and Ruby is not a new paradigm.

Up through 1.8.x, Ruby used N:1 lightweight threads (multiple lightweight threads on one OS threads.)

Go uses M:N threading (multiple lightweight threads, which may be distributed among 1 or more OS threads.)

M:N threading is a different model than either the Ruby 1.9+ model (1:1 threading on OS threads with a global lock) or the older Ruby approach (N:1 threading), or even the JRuby approach (1:1 threading on OS threads with no global lock.)

For further proof of my point, I submit the fact that you are basically correct, yet those technologies never took off, even in their own communities. The dominant way all the scripting languages are written are as single threaded code, and the second most popular way is as event-based code. It's not easy to bolt that stuff on ten years after the fact, which is what most of those technologies did.

Lua would probably be the better thing to cite as the possible counterexample, in that it does seem like a lot of the people using it are at least using coroutines, though I believe it is not possible/feasible to get them threading in any nontrivial way.

(I'm not taking the out of claiming dynamic typing counts as a "new paradigm"... probably the single largest true programming change in the last 20 years is the mainstreaming of dynamically-typed programming languages. Which I think was still a good thing for static languages because it raised the competitive bar for them; I've personally swung back over to static typing, but the easy of the dynamic world has pushed the static world to greatly improve its cost/benefit proposition, in both categories. If my only choice was dynamic typing or what we had in the 1990s, I'd still be in the dynamic world.)

As a final postscript, may I observe that while I think that Go was a modestly revolutionary combination of concepts, I consider it an indictment of the programming community that it did not happen sooner. I don't see Go as if it somehow won a big race by being the best... I see it as a situation where it's the first thing that bothered to show up, years late, somewhat desultorily.

I'm ok with the Algol part as it pertains to syntax.

Semantics and expression though, is another thing...

By offering simplicity. Taking a step back to before C++. And providing a better C. C + strings + GC + map + slice(array) + json/xml parsing + http transport layer (server & client). What else do you need? Ideal for minimalists. That's its beauty. Programs are very stable. Takes less memory than Java (some amount more than C/C++). Faster compilation time compared to C++. A convenient C. For minimalists, who like to cut down all the jargon, and solve the problem. Looking at it that way, you see its beauty.

edit: typo

I keep seeing this come up and I wonder if people have actually used C in the domains where it matters.

Go is not a C replacement/better C. You don't have control over what goes on the stack/heap which means you can't control memory layout. If you can't do that you're throwing away one of the key reasons you'd use C. Memory layout is critical to getting that 10-50x performance that you can't get in a managed language.

There's a bunch of domains where Go excels but if you're on constrained hardware where you really need the last bit of perf/memory it would not be the tool I reach for.

Its not a replacement for C in most of the places where C is far and away the best existing choice for a whole project, it is a replacement for C in the zone where C's performance and static typing are attractive and would decided the choice in its favor, but Python's expressiveness, batteries-included stdlib, etc. also make it attractive and make it a little bit painful that the other factors weigh in C's favor. For a system that you might be otherwise do polyglot Python (or some similar dynamic language)/C development for that reason (or where you might do C-only somewhat reluctantly for that reason), Go could be a reasonable replacement for C (and, in the case where the alternative would be polyglot, Python or whatever else.)

If your primary concern is performance(which is the only reason I'd reach for C today, esp w/ security concerns) then Go is not going to replace C in that domain.

Well, Swift certainly wasn't when Go was introduced, but, yes, Java and C# were competitors in that role when Go was introduced (Java, even moreso at the time, tended to fall short on expressiveness -- which some argue Go does too, though in different ways -- and C# was deeply tied to .NET, which only had a first-class implementation on Windows; both of those have improved somewhat since Go was introduced.)

https://github.com/dotnet/corert

Many of us are actually mostly working on Windows, so NGEN, RyuJIT and .NET Native are all very good nice toolchain features.

And if I compare Go with the whole .NET stack and tooling, there are lots of things I see missing, in spite of better AOT support across the board.

I'm not really a fan of Go, but being able to write small tools in it without pulling in a huge runtime is a big drawback.

Once upon a time, on the PC we only had static compilation, regardless of the language.

.NET Core would help with the runtime dependencies (XCopy Deploy), but currently it is also WIP for those of us that care about desktop applications.

In any case, when choosing a language for a project which doesn't fit your requirements because maybe the tooling will get there someday, I think you're going to pretty consistently end up in a sticky situation. I like C# a lot more than Go for most things, and some of the reasons are things you listed, but the goalpost shifting is getting ridiculous.

Was C's "static" typing ever attractive as a static type system?

Nothing prevents you to make use of statically allocated data structures, hands off from the GC if really needed.

In spite of lacking a few features that I consider any modern language should have, ability to create memory friendly data structures isn't one them.

Only if you give up closures, interfaces, defer, strings, the entire standard library, and all sorts of other things that don't immediately come to mind.

Programming without the GC in Go is technically possible, but impractical. The language just wasn't designed for that (and this isn't a knock against the language--it just was a non-goal).

We can use the GC for the 90% of the code that isn't performance critical, enjoying the programming productivity of using a GC enabled language.

After profiling the application and find out where those 10% performance/memory critical hotspots are, re-architect the data structures to use static allocation, either via the stack (compiling with escape analysis validation) or the global memory. Or even doing off-GC Heap allocation via syscalls.

Then make use of pointers or array indexes to access the static allocated data.

Plenty of examples in Modula-3, Oberon, Mesa/Cedar research papers.

There are plenty of languages that I would rather use for systems programming instead of Go, but the language is certainly capable of being used in the same scenarios as Oberon.

For example Astrobe, which sells bare metal Oberon compilers for ARM Cortex-M4, Cortex-M3 and Xilinx FPGA Systems.

If anything, comparing Oberon's SYSTEM with Go's unsafe packages, Go could use a few more intrinsics like CPU register access, but those as also doable with a bit of Assembly help. Which ANSI C also doesn't support.

My goal is just creating awareness that alternatives are possible, it doesn't need to be always C.

You do have this control. There is escape analysis, but I've never had to dance with it to make it put things on the stack when I need them to. I can get very close to C speeds with Go without much effort.

There are lots of cases in which escape analysis falls down. In particular, higher order control flow (closures/interfaces) will always cause it to fail, until Go implements some sort of higher order control flow analysis (which I doubt it will). Go uses interfaces a lot.

I never meant to imply escape analysis was somehow perfect; only that it is (mostly) easy to reason about.

Your compiler doesn't know your data access patterns, dataset size or a myriad of other factors that you need to tune if you really want to get full utilization from your hardware. To be clear I'm talking about ~5% of software out there, but when you need it you really need it.

But how things are going regarding Java releases, Go could even get generics before Java 10 gets released.

What I meant was taking a step back to a point before C++ was created. And looking ahead, and choosing what works and is essential (strings, GC,... and some modern Internet usage things...concurrency...etc), and getting rid of all the bloat, which actually comes in the way, especially the opinionated bloat on how software should be done e.g. OO. And making a language based on that.

For some reason, this discussion reminds me of Linus Torvald's angry defense of using C, for git[1] :-)

[1] http://harmful.cat-v.org/software/c++/linus

A quote from "Java in a Nutshell", from (I believe, 2002):

"Because Java is a simple and elegant language with a well-designed, intuitive set of APIs, programmers write better code with fewer bugs than for other platforms, again reducing development time."

Reads pretty similar to your argument for Go. I remember similar quotes for Modula-2, ML, (a lot of versions of) LISP, C itself, and I'm sure there's many more. It seems to me pretty likely that we're seeing the same evolution : Go currently is a simple, easy language that matches the current hotness (microservices) pretty well, because it was directly written to support that. The current hotness will go away and Go will have effectively-mandatory bloated libraries to support the next hotness, just like today it's becoming close to embarassing to use Go's standard library's http server for anything non-trivial.

Additionally, many of the criticisms of C apply to Go. It's looooooooooooooooooong simple code doing "a; if error { ... }; b; if error { ... }; c; if error { ... } ...". Many abstractions just don't work, and have to be "fixed" with crutches (like sorting, logging, ...)

So, I agree with you a lot. There are no guarantees that Go will remain good for ever. It would be a challenge and need effort on the part of the language developers.

That said, I believe, when a language evolves over a period of 20 years. You get the benefit of hindsight to introduce the good things in a new language. So, Java's garbage collection is a big success. And Go developers incorporated it. Its a tradeoff with extreme (C like) performance, and devs went with convenience and security. Good call, in my opinion.

But the object oriented part of Java, in my opinion, is just a C++ inheritance, as at that point of time (mid 1990s). OO was the silver bullet, to all your sofware spaghetti problems. But as it turns out, it got more complex, if the design/architecture was bad. And good engineers design good enough without the OO.

So Go has taken that approach, which gels with me and lot other developers.

Your comment regarding the error handling part. Yes, it is cumbersome. But surprisingly, it seems to look better than exception handling when you write couple of modules with it. And for some reason, which others have articulated better than I can at this time, your programs are more stable as a result.

So overall what I like about Go, is the minimalist approach of just having the proven things which are good. And avoiding which are grey area or bad.

Language consistency (no magical functions like "make" or magical items like slices), DRYness (generics), better type-safety than C (interface{} is the void * of the 21st century), would be a good start.

Due to the mandatory GC, it's also not a C replacement where C is good at. Hence the backtrack on "systems", etc.

I tend to complain on Go's design decisions and don't have any actual use for it, but given my experience with Oberon, I do believe there are use cases where it would be possible to use Go as systems language.

For sure not in when targeting 8 or 16 bit CPUs with a few KBs, or timing constraints that cannot deal with possible GC pauses.

But for more beefy micro-computers like the original PI, it can certainly be an option.

This would a good starting point for anyone trying to attempt it

http://wiki.osdev.org/Go_Bare_Bones

Also I consider the ability to write compilers to be systems programming use cases and Go is already bootstrapped.

Having said this, yes there are better options to do systems programming with less need of Assembly help.

After posting, I realized its concurrent programming model, is another thing which I (and many others) am a fan of. I found the channel and go based approach, much better compared to explicit spawning of threads in languages like Java and C++.

Really? A lot of copy/pasted code, generics replaced with casts on empty interfaces, poor support for collections, only very primitive concurrency tools, and so on...

I can understand that simplicity is good for small CLI/network tools, but it is hardly an alternative for really big applications where Java is vastly used

Most actual engineering is very far from writing a dumb server for yet another CRUD app :)

Go is supposed to be a systems programming language. That means a very, very wide range of possible domains, where for many of them even network latency is unacceptable. For example, Photoshop would have a terrible user experience if it wasn't the monolith it is. A game engine wouldn't go above ~20FPS (even 60FPS games have a network loop that is capped around 20FPS).

If I can't do systems-level programming in Go, what's its advantage over real systems languages or higher-level languages then? Especially when you consider what Go offers (CSP) comes in opt-in libraries in many other languages.

I feel like Go should be put in the same category as C# and Java. They're just above systems languages but just below scripting languages; giving you the worst of both worlds. Not bare-metal, but also not that productive.

PTC is one such those vendors,

http://www.ptc.com/developer-tools/perc

Go might eventually be used in such scenarios, but the toolchain is not yet there.

The same path that is being followed by those that rely on libraries to reduce error handling boilerplate and go generate, just as two examples.

Can confirm (well, add another point of anecdote), I played with it a bit in order to get some experience with static stuff before diving into the whole C ecosystem.

Next thing I build that needs that kind of development will probably be C though.