8 ms·

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 sal

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). C++ -> Rust C -> Go Java -> Scala Lisp -> Closure Erlang -> (Go or Scala) Javascript -> (Too Many; Dart, et al) (Edit: Formatting)

Kototama 14y ago
It's Clojure, not Closure. Google Closure is an optimizing JavaScript to JavaScript compiler. I'm not sure Go try to replace C. Most (all?) embedded systems need to control memory allocations.
- jff 14y ago
  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.
  - Kototama 14y ago
    I didn't want to imply that. Just that some use of C won't be covered by Go.
- pjmlp 14y ago
  > I'm not sure Go try to replace C. Most (all?) embedded systems need to control memory allocations. Are you aware that there are embedded systems coded in GC enabled languages? It is all a matter of the available resources.
  - abraininavat 14y ago
    It is all a matter of the available resources. I'd say, it's all a matter of the guarantees. Guarantees are everything in embedded systems.
    - deleted 14y ago
      [deleted]
    - pjmlp 14y ago
      What about ballistic missile tracking? http://www.militaryaerospace.com/articles/2009/03/thales-chooses-aonix-perc-virtual-machine-software-for-ballistic-missile-radar.html http://www.militaryaerospace.com/articles/2009/03/thales-cho... 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.
      - abraininavat 14y ago
        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.... [1] http://en.wikipedia.org/wiki/Real_time_Java http://en.wikipedia.org/wiki/Real_time_Java
        pjmlp 14y ago
        As I mentioned, Java was just the first example that came to my mind. There are embedded systems being coded in Basic, Oberon, Lisp, Scheme and .NET. Although those systems are usually 32 bit based. 8 and 16 bit systems are too small for those languages.
        pkhagah 14y ago
        Also Ada, my favourite language.
        jk4930 14y ago
        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.
- mtgx 14y ago
  Could we see a brand-new Chrome browser written in Go, though? Or would it better for Google to use Rust, too, for that?
  - fafner 14y ago
    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.
- terhechte 14y ago
  Sorry, typo regarding Clojure. Can't edit it anymore though :(
kenko 14y ago
Go or Scala attempt to improve on Erlang? Elixir attempts to improve on Erlang---that I can see.
old-gregg 14y ago
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.
- steveklabnik 14y ago
  Currently, Rust cannot go without its runtime either. The plan is that it eventually will be able to. (EDIT: VM -> runtime)
  - abraininavat 14y ago
    The plan is that it eventually will be able to. 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.
    - pcwalton 14y ago
      Yes, you can use a freestanding Rust in many domains. Freestanding is still a WIP, but we have examples like embedding Rust in Ruby that work today: http://brson.github.com/2013/03/10/embedding-rust-in-ruby/ http://brson.github.com/2013/03/10/embedding-rust-in-ruby/
  - mseepgood 14y ago
    Neither Go nor Rust have a VM.
    - steveklabnik 14y ago
      Yes, I meant 'runtime.' That's what I get for commenting without coffee... the parent's usage of 'VM' infected my comment.
steveklabnik 14y ago
To be fair, with Rust it's more like C++ ----- \ OCaml ------> Rust / Erlang --
- gcr 14y ago
  What does the language family tree look like with Go at the root?
  - steveklabnik 14y ago
    I'm not as familiar with Go, so I can't comment on that, specifically.
  - mseepgood 14y ago
    C --------------- \ \ (CSP) --> Limbo ----> Go / Modula ----------
masklinn 14y ago
> C -> Go 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.
- burntsushi 14y ago
  > 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.)
  - masklinn 14y ago
    > 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.
    - burntsushi 14y ago
      > 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? [1] - http://www.guug.de/veranstaltungen/ffg2003/papers/ffg2003-armstrong.pdf http://www.guug.de/veranstaltungen/ffg2003/papers/ffg2003-ar...
rdtsc 14y ago
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. Paradoxically perhaps, I see it inverted: (Go + Scala) -> Erlang Temporal sequencing doesn't necessarily imply strict improvement.
- terhechte 14y ago
  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.
pjscott 14y ago
That's definitely not a new trend. http://www.paulgraham.com/fix.html http://www.paulgraham.com/fix.html
epsylon 14y ago
> Lisp -> Closure 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.

Kototama 14y ago

It's Clojure, not Closure. Google Closure is an optimizing JavaScript to JavaScript compiler. I'm not sure Go try to replace C. Most (all?) embedded systems need to control memory allocations.

jff 14y ago
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.
- Kototama 14y ago
  I didn't want to imply that. Just that some use of C won't be covered by Go.
pjmlp 14y ago
> I'm not sure Go try to replace C. Most (all?) embedded systems need to control memory allocations. Are you aware that there are embedded systems coded in GC enabled languages? It is all a matter of the available resources.
- abraininavat 14y ago
  It is all a matter of the available resources. I'd say, it's all a matter of the guarantees. Guarantees are everything in embedded systems.
  - deleted 14y ago
    [deleted]
  - pjmlp 14y ago
    What about ballistic missile tracking? http://www.militaryaerospace.com/articles/2009/03/thales-chooses-aonix-perc-virtual-machine-software-for-ballistic-missile-radar.html http://www.militaryaerospace.com/articles/2009/03/thales-cho... 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.
    - abraininavat 14y ago
      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.... [1] http://en.wikipedia.org/wiki/Real_time_Java http://en.wikipedia.org/wiki/Real_time_Java
      - pjmlp 14y ago
        As I mentioned, Java was just the first example that came to my mind. There are embedded systems being coded in Basic, Oberon, Lisp, Scheme and .NET. Although those systems are usually 32 bit based. 8 and 16 bit systems are too small for those languages.
        pkhagah 14y ago
        Also Ada, my favourite language.
        jk4930 14y ago
        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.
mtgx 14y ago
Could we see a brand-new Chrome browser written in Go, though? Or would it better for Google to use Rust, too, for that?
- fafner 14y ago
  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.
terhechte 14y ago
Sorry, typo regarding Clojure. Can't edit it anymore though :(

kenko 14y ago

Go or Scala attempt to improve on Erlang? Elixir attempts to improve on Erlang---that I can see.

old-gregg 14y ago

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.

steveklabnik 14y ago
Currently, Rust cannot go without its runtime either. The plan is that it eventually will be able to. (EDIT: VM -> runtime)
- abraininavat 14y ago
  The plan is that it eventually will be able to. 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.
  - pcwalton 14y ago
    Yes, you can use a freestanding Rust in many domains. Freestanding is still a WIP, but we have examples like embedding Rust in Ruby that work today: http://brson.github.com/2013/03/10/embedding-rust-in-ruby/ http://brson.github.com/2013/03/10/embedding-rust-in-ruby/
- mseepgood 14y ago
  Neither Go nor Rust have a VM.
  - steveklabnik 14y ago
    Yes, I meant 'runtime.' That's what I get for commenting without coffee... the parent's usage of 'VM' infected my comment.

steveklabnik 14y ago

To be fair, with Rust it's more like C++ ----- \ OCaml ------> Rust / Erlang --

gcr 14y ago
What does the language family tree look like with Go at the root?
- steveklabnik 14y ago
  I'm not as familiar with Go, so I can't comment on that, specifically.
- mseepgood 14y ago
  C --------------- \ \ (CSP) --> Limbo ----> Go / Modula ----------

masklinn 14y ago

> C -> Go 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.

burntsushi 14y ago
> 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.)
- masklinn 14y ago
  > 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.
  - burntsushi 14y ago
    > 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? [1] - http://www.guug.de/veranstaltungen/ffg2003/papers/ffg2003-armstrong.pdf http://www.guug.de/veranstaltungen/ffg2003/papers/ffg2003-ar...

rdtsc 14y ago

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. Paradoxically perhaps, I see it inverted: (Go + Scala) -> Erlang Temporal sequencing doesn't necessarily imply strict improvement.

terhechte 14y ago
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.

pjscott 14y ago

That's definitely not a new trend. http://www.paulgraham.com/fix.html http://www.paulgraham.com/fix.html

epsylon 14y ago

> Lisp -> Closure 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.