IMO Go is more like C people took a stab at making a Java. I really like go, and it’s ethos, even if I haven’t used it much in production. Go is not however a replacement for C in the way C++ and Rust can be. Of course Rust and C++ aren't a replacement for C in some key ways, so maybe I don't have a point here?
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.
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.
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.
>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.
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.
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.
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,....
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...
