It's been mentioned from time to time that Go is a successor of C. As I recently had a look into the Pascal/Oberon family. It looks that Go is no less influenced by Oberon than C. The CSP paradigm likely comes from Rob Pike's previous works. And the syntactical elements, such as the operators and punctuations, also follow the C tradition. But the overall program structure (including the approach to OOP and probably the 'evolving-by-reduction-rather-than-addition' philosophy) makes it seem closer to the Oberon linage.

Active Oberon also had co-routines in the form of active objects.

Also note that 'evolving-by-reduction-rather-than-addition' philosophy is only part of Wirth's Oberon linage.

Oberon-2 (which Go got its method syntax from), Active Oberon, Component Pascal and Zonnon, are all Oberon descendents from ETHZ as well, which go into the direction of mainstream languages, including support for generics or more low level programming capabilities.

> The CSP paradigm likely comes from Rob Pike's previous works

"The CSP paradigm" comes from CSP: https://en.wikipedia.org/wiki/Communicating_sequential_proce... which predates the vast majority of Rob Pike's work (eg: before he went to Bell Labs).

Yes, that's the original inspiration. But Rob Pike has been implementing CSP ideas in different languages for a few decades now, and all that work has highly influenced the implementation in Go.

Obviously what OP meant is the implementation of it. Rob Pike mentioned Tony Hoare‘s work in almost every talk he gave about Go‘s concurrency.

C++ has had decades to replace C, but it’s really stalled and even lost ground in embedded systems. I can’t see Rust faring much better. C might end up being an eternal language until there is a dramatic enough shift in operating systems to merit replacing it.

In my opinion, there are two main factors driving this:

- Lower spec devices have a hard cap on overall code complexity imposed both by available ROM or flash constraints (big projects literally won't fit on the chip), and by time constraints (if your chip is running at <= XX MHz when it's active, you don't have time to run very many functions between events or interrupts). Most projects for these devices won't grow to the point where you really need the code organization benefits that C++ provides.

- It's a lot less effort to port or implement a C toolchain for your chip than it is to port or implement a toolchain for a more complex language like C++, Rust, or even Ada. It's not just the compiler - you also have to have a working standard library (even if some functions are just stubs), an interactive debugger, and integrations with IDEs (if you already provide that for C). All that software engineering is expensive, and you have a much smaller market of developers to amortize that cost over.

These constraints aren't as binding for high-production, higher-spec devices like popular families of ARM Cortex-M chips, so usage of C++ seems to be relatively more popular for those devices. Even then, embedded work normally requires more of a "C with classes" or "C plus the std::algorithm library" approach, which is different from C++ projects you'd see that target servers.

Mostly because embedded C isn't ISO C, rather MISRA C, TI C, Microchip C,...

> IMO Go is more like C people took a stab at making a Java.

And in a way it is :) given who worked on it, and where it was created.

That was Limbo actually, and the attempt was at Java 1.0 apparently.

Despite my opinion regarding its design, Go was definitely a C replacement for F-Secure TamaGo, Google's gVisor, Android GPGPU and CoreBoot projects.

>IMO Go is more like C people took a stab at making a Java.

I haven't used Go beyond tutorials and some very basic programs, but I am pretty comfortable with Java. What about Go makes you feel it's relatable to Java? From what I've read the lack of generics is a hot topic in the Go community, but they're pretty crucial to most programs written in Java. Is this still true?

As a side note, Java also didn't ship with generics. Java was released in the mid 90s and didn't have generics until about 10 years later with version 5. This timing should feel familiar - Go first appeared ~10 years ago in 2009.

You may remember that in Java 1.4, `get`ting from collections (e.g. ArrayList) always returned Object, which you were expected to cast to their runtime type (or a class that their runtime type inherits from). I was young at the time, correct me if I'm wrong. Contrast this with Go's solution, which seems to be user-inaccessible compiler magic. I much prefer Go's solution to Java's, but I also like generics.

I really hate user-inaccessible compiler magic. Java had its fair share of that, but Go seems to take it even further :(

I think compiler magic is pretty great. Hotspot is a pretty magical compiler. Go is less magical IMO because it is AOT compiled.

By compiler magic I really mean syntax reserved to the language itself; for example, Java's String having extra operator superpowers or Go's generics that are only available to a chosen set of standard collections.

I think you can do the same in Go, using the empty interface (that can represent any type) and then having the user cast it to the correct type. Unfortunately this is not type safe, and type safe generics in go, such as maps is only available to the compiler.

Java didn't have generics before version 5, I think. It was a hell of casting back and forth Object, much like Go and interface{} today.

The language and tooling is designed for development at scale. Lots of pragmatic trade offs were made. Its not flashy at all, and could even be accused of being a bit boring. It is also appropriate for a similar domain.

yep, there Go was labeled as a replacement for C or Python, and while it in no way replaces C and and as for Python it generally only does when the Python wasn't the right choice from the start.

In reality Go can fully take over Java's problem space.

> In reality Go can fully take over Java's problem space.

Or, when Project Loom releases, Java will be able to fully take over Go's problem space.

Sorry, my previous post sounded like I was picking a favorite, what I meant is that Go and Java pretty much has identical problem space.

Not really, unless it provides generics, JEE and Spring like frameworks, supports all embedded CPUs, Oracle/SQL Server/DB2, mainframes, has an OS of its own, a GUI half as good as Swing,....

Not without generics it can't. I know a lot of people seem to think that generics aren't necessary in Go, but I vehemently disagree with them.

there is no way that's happening, outside of silicon valley practically no one is using Go, there are millions Java developers who are quite content with language...

Garbage Collector?

Go's GC is quite different to Java's though - deliberately not as many knobs to twiddle.