It is interesting how many of these newer languages clearly try to improve upon a specific older, established language (at least imho) (take with a grain of salt).
Most of C's use cases, Go can't even remotely be used for. It's basically limited to the "network server" use case. It's not portable, it's not a linga franca (via FFI for non-C languages), it's not low-overhead, it's not runtime-less, ...
> Erlang -> (Go or Scala)
Yeah... no, especially not Go. In Erlang's inception, concurrency was first and foremost a tool for reliability (from its telecom roots where 1 = 0, so 1 server means the same as not having a server). Just about none of Erlang's reliability mechanisms are present in Go.
> It's basically limited to the "network server" use case.
I've been using it to perform research. I also used it to build an X window manager. Neither are remotely close to a "network server" use case. In years past, I would have used C for both projects.
> Just about none of Erlang's reliability mechanisms are present in Go.
I certainly agree that Go shouldn't be viewed as a "better" Erlang, but Go does have green threads with M:N scheduling, which is a significant feature of Erlang. (As argued by Joe Armstrong himself.)
> Go does have green threads with M:N scheduling, which is a significant feature of Erlang.
And Go also has integers, a significant feature of C...
Goroutine's semantics and implementation are nothing like Erlang's processes: the latter are shared-nothing, preempted, monitorable and messageable whereas goroutines are shared-memory cooperative black holes.
Basically, the one and only commonality is that they're mapped M:N on OS threads, which is on par with comparing a wheelie bin and a CAT 797F on grounds that they both have 4 wheels.
> And Go also has integers, a significant feature of C...
So does every other language. Perhaps I need to be more explicit for you: Go does have green threads with M:N scheduling, which is a powerful feature of Erlang that most other languages do not have.
> Basically, the one and only commonality is that they're mapped M:N on OS threads, which is on par with comparing a wheelie bin and a CAT 797F on grounds that they both have 4 wheels.
I'm more convinced by Armstrong's argument [1] (and my own experience). Green threads enable a concurrent style of programming that is not viable in most other programming languages. (See also: Concurrent ML and Concurrent Haskell, although the former is not parallel.)
> Goroutine's semantics and implementation are nothing like Erlang's processes: the latter are shared-nothing, preempted, monitorable and messageable whereas goroutines are shared-memory cooperative black holes.
I have drawn on an important similarity between goroutines and Erlang processes. I did not dispute their differences, although I think your comparison is overly simplistic.
Also, you ignored my rebuttal to your claim that Go's "basically only use case is network servers." Any particular reason why?
I thought about Lua, but figured that javascript would be a more compelling disproof by counterexample (the common wisdom being that "nobody" uses Lua).
edit: yes, I just edited this comment quickly in succession.
The JavaScript one has stuck with me because it's another good example of the various camouflaged toe-stubbing obstacles left scattered about the design.
As much as I like Golang, it is not a replacement for C. The major reason C is so popular because it's the only portable medium for performant code which can be shared across many languages because it doesn't impose any runtime on you.
Go comes with a VM. It lives in its own world, it cannot live in the worlds of other VMs like C can. It's more like high-performance Python (or simpler+slower C++) optimized for concurrent network services.
I'd say that Rust and probably D are good candidates for replacing C.
Isn't libc just a set of libraries and therefore not considered a runtime environment? C does have a small runtime environment, but I'd say it's the existence of the function call stack, as well as the on_exit system that's built into the core language.
I think your parent comment means runtimes in the sense of a garbage collector or other services that run concurrently with user code or are scheduled periodically, which will put you in a world of hurt if you touch one of their objects without asking its permissions and/or playing by its rules.
To expand upon that point, Rust is designed to allow the programmer to avoid garbage collection altogether, if the programmer chooses. I believe that makes feasible the idea of using a runtime-less subset of Rust in any application where C would have been traditionally used.
In one sense, Assembly does have a runtime, provided by the kernel's system call interface, not to mention all the magic that the loader has to do to make libraries work.
Even the kernel has a runtime, in a less strict sense, provided by the BIOS and whatever CPU interrupts support it.
The only thing that a program can do without any "runtime" at all is warm up your desk.
>The only language that does not have a runtime is called Assembly. And even in the case of CISC processors there might be microcode playing the role of a runtime. Why don't people learn about compiler design nowadays?!
Because the C kind of runtime isn't what people regularly mean with the word "runtime" -- much less cpu microcode.
It depends if you mean one of those Forth CPUs there were common in the 80's or the more standard Forth environment, both of which have nontheless runtimes.
Because in the end, you will be using a set of words besides the basic stack manipulation ones, those words are the runtime.
I wish the Vala folks would get going. 18 months ago, Vala, Go, and Rust were all possible native language successors to C++. (D was the fourth prospect.) But Vala has advanced so little, it's becoming an afterthought.
The web site is an afterhought that sits like an interloper on the GNOME site. The Windows distros are years old, etc. It's too bad. They had a good idea; they just failed to execute.
I agree. People mistake the fact "Some C people really like Go, for some of the same reasons they like C" for the falsehood "Go is a good candidate to replace C in the domains C it typically best for".
As someone already mentioned, -1 on Erlang-> (Go or Scala)
They didn't try to improve they removed features such as error handling, distribution, all which are very important for building fault tolerant system.
I was referring to how Scala copied the actor model (though it is was not invented for Erlang either) and several other Erlang-ideas while adding new features and running on the JVM. In some direction similar with Go; You're right though, it wasn't the best of comparisons.
The Mozilla/Rust/Servo developers talked about why they continue developing Rust and not considering Go for the job. It has absolutely nothing to do with a turf war because Mozilla is actually using Go for some server side things. But one major reason for not using it to implement Servo (the next-gen browser engine) is the mandatory GC. For a lowlevel performance and memory critical application such as a browser engine you don't want a GC.
This is just one example from many I can pick up, this one is Java, but there are systems done in other GC languages as well.
But I do agree it is a matter of hardware resources and if hard or soft real time guarantees are to be expected, just that not all embedded systems require real time processing.
IIRC, in the "real time java" world though, they don't use Java as is though. They mostly fight with the language, statically allocating all things in advance etc.
In that sense, one could also use Go. But that is a bleak argument.
What? I never disagreed that Java is used for realtime embedded systems.
I'm aware of the existence of "real time Java". There can be such a thing because of specifications like " areas of memory that are not subject to garbage collection, along with threads that are not preemptable by the garbage collector" [1]. Like I said... guarantees....
Yes, Ada needs more love here. I think that Rust's main goals are already implemented with Ada (low-level, reliable, strong typing etc.). Plus that Ada is a proven work horse with existing tools and best practices. It just hasn't the C feeling they want in Rust.
My heart has a sweet spot for the Pascal family of languages and their strong typing, in regard to C and C++.
Ada suffered from lack of available cheap compilers back in the 80's, and like Turbo Pascal and Modula-2 it was a victim of UNIX's success, which had the sad side effect of promoting C for systems programming, with all security issues we have nowadays.
Now with the work of GNAT Core, and more security conscious developers, Ada seems to be getting new users, at least here in Europe as more universities adopt it. It is already a constant presence at FOSDEM in the last few years.
Yes, I wish that GNAT gets more adoption. Where appropriate I recommend Ada. It would be helpful to have some impressive and successful applications outside the high-integrity/reliability niche.
Where does C imply embedded only? The Go authors spent years writing non-embedded programs and operating systems in C, after Ken Thompson laid the groundwork to create C.
There is no single "Lisp", but many dialects including Common Lisp, Scheme (and its bazillion variants), Clojure, Emacs Lisp, Arc...
> Java -> Scala
Except for the fact that Scala is based on the JVM and partly reuses the Java standard library (for interoperability reasons), the language is the product of many influences, including ML, Haskell, Java, Scheme, Eiffel... The syntax and the "feel" of the language is actually quite far from Java thanks to its functional side.
C++ -> Rust
C -> Go
Java -> Scala
Lisp -> Closure
Erlang -> (Go or Scala)
Javascript -> (Too Many; Dart, et al)
(Edit: Formatting)