9 ms·

Doesn't it? Why do people seem to compare them all the time...

by aplummer 11y ago

TazeTSchnitzel 11y ago
Rust is a systems-level programming language. Go isn't: it's garbage-collected.
- sacado2 11y ago
  Lisp is garbage collected. Yet Lisp machines existed, and they were invented at the same time as UNIX.
  - nickpsecurity 11y ago
    And some's details were published for other people to learn from. Anyone wanting to see how they implemented it can google LISP and Scheme machines, hardware, processors, and similar search terms. I recall one implemented cons directly while hiding GC behind memory interface. The programs didn't even know there was collection and it happened in parallel with execution without stopping execution. Great stuff. Many of these give software and hardware implementation details where they could be copied in FPGA's. Closest thing I've seen in a modern product is Azul Systems' Java processors with concurrent GC's. So, at least one company is benefiting from the old wisdom.
- pjmlp 11y ago
  Besides the sibling post. Xomb, Mesa/Cedar, Oberon, SPIN, Singularity were all written in GC enabled system programming languages.
  - steveklabnik 11y ago
    Yeah, but at least with XOmB, we weren't actually _using_ the GC, as you can turn it off in D.
    - pjmlp 11y ago
      Thanks for the heads up. Although given my Oberon knowledge, I would say that was more a consequence of D's GC implementation quality than anything else, right? On Oberon and all the derived OS, the Kernel module was the only one where GC wasn't used, as it needed to be implemented somewhere. All the other modules enjoyed access to an OS wide GC.
      - steveklabnik 11y ago
        Well, it was really just that we didn't get that far, I guess. Mind you, my friends did much more of the work than I did, but like most student hobby projects, at some point, you just stop working on things.
  - nickpsecurity 11y ago
    Good points. People often forget GC languages were often used to write OS's and system software even on constrained devices. A number of languages, such as Modula-2 and Ada, offered the ability to go unsafe in certain modules out of necessity but with safe interfaces. So, where Go or Rust can't cut it, language developers can just use a feature like that (or inline assembler) to solve those problems until the language itself can. Additionally, they can do what PL/S and certain Ada's did where specific modules were transformed by the compiler differently based on their needs. One might have total safety, one no safety, one a GC'd runtime, one a non-GC runtime, and one no runtime at all. Still using the same language and tools for everything, albeit subsets in some modules with extra worries.
learc83 11y ago
Go gets compared to Rust because go was originally labeled a "systems" language. But the designers had a different older view of what "systems" meant than what is commonly used to day. People heard systems and thought they meant low level/operating system/embedded systems. That is not what Go is good for because it's garbage collected. They also planned to attract C++ programmers, but they've basically been attracting dynamic language programmers instead. Why that was a surprise is beyond me--I can't imagine that anyone currently using C++ would be OK switching to a garbage collected language. Rust on the other hand, is shaping up to be a C++ replacement.
- mcgirr 11y ago
  Yeah, additionally it would be unwise to use Go in embedded systems because it is so reliant on heap memory for dynamic allocation. In certain situations where things could fail if an operation takes too long - rocketry and robots - it would be difficult to tell how long something would take in Go with any degree of certainty because allocating and freeing memory on the heap is highly non-deterministic.
  - tracker1 11y ago
    If you can do robots with Node.js, I'm pretty sure Go may well be acceptable here.
    - learc83 11y ago
      No one is arguing that you absolutely can't use Go to build a robot, just that it's probably not a good idea. Just because someone uses Node.js to build a hobby robot, doesn't mean that many people are using it for production embedded systems. If your systems has hard real time requirements, which many systems do (even many hobby robots), a stop the world garbage collector is out of the question. Let's say you have a legged robot that depends on interpreting sensor feedback to keep from failing over. What happens to your balance when the garbage collector pauses your code for 10ms?
  - pjmlp 11y ago
deleted 11y ago
[deleted]

Doesn't it? Why do people seem to compare them all the time...

TazeTSchnitzel 11y ago

Rust is a systems-level programming language. Go isn't: it's garbage-collected.

sacado2 11y ago
Lisp is garbage collected. Yet Lisp machines existed, and they were invented at the same time as UNIX.
- nickpsecurity 11y ago
  And some's details were published for other people to learn from. Anyone wanting to see how they implemented it can google LISP and Scheme machines, hardware, processors, and similar search terms. I recall one implemented cons directly while hiding GC behind memory interface. The programs didn't even know there was collection and it happened in parallel with execution without stopping execution. Great stuff. Many of these give software and hardware implementation details where they could be copied in FPGA's. Closest thing I've seen in a modern product is Azul Systems' Java processors with concurrent GC's. So, at least one company is benefiting from the old wisdom.
pjmlp 11y ago
Besides the sibling post. Xomb, Mesa/Cedar, Oberon, SPIN, Singularity were all written in GC enabled system programming languages.
- steveklabnik 11y ago
  Yeah, but at least with XOmB, we weren't actually _using_ the GC, as you can turn it off in D.
  - pjmlp 11y ago
    Thanks for the heads up. Although given my Oberon knowledge, I would say that was more a consequence of D's GC implementation quality than anything else, right? On Oberon and all the derived OS, the Kernel module was the only one where GC wasn't used, as it needed to be implemented somewhere. All the other modules enjoyed access to an OS wide GC.
    - steveklabnik 11y ago
      Well, it was really just that we didn't get that far, I guess. Mind you, my friends did much more of the work than I did, but like most student hobby projects, at some point, you just stop working on things.
- nickpsecurity 11y ago
  Good points. People often forget GC languages were often used to write OS's and system software even on constrained devices. A number of languages, such as Modula-2 and Ada, offered the ability to go unsafe in certain modules out of necessity but with safe interfaces. So, where Go or Rust can't cut it, language developers can just use a feature like that (or inline assembler) to solve those problems until the language itself can. Additionally, they can do what PL/S and certain Ada's did where specific modules were transformed by the compiler differently based on their needs. One might have total safety, one no safety, one a GC'd runtime, one a non-GC runtime, and one no runtime at all. Still using the same language and tools for everything, albeit subsets in some modules with extra worries.

learc83 11y ago

Go gets compared to Rust because go was originally labeled a "systems" language. But the designers had a different older view of what "systems" meant than what is commonly used to day. People heard systems and thought they meant low level/operating system/embedded systems. That is not what Go is good for because it's garbage collected. They also planned to attract C++ programmers, but they've basically been attracting dynamic language programmers instead. Why that was a surprise is beyond me--I can't imagine that anyone currently using C++ would be OK switching to a garbage collected language. Rust on the other hand, is shaping up to be a C++ replacement.

mcgirr 11y ago
Yeah, additionally it would be unwise to use Go in embedded systems because it is so reliant on heap memory for dynamic allocation. In certain situations where things could fail if an operation takes too long - rocketry and robots - it would be difficult to tell how long something would take in Go with any degree of certainty because allocating and freeing memory on the heap is highly non-deterministic.
- tracker1 11y ago
  If you can do robots with Node.js, I'm pretty sure Go may well be acceptable here.
  - learc83 11y ago
    No one is arguing that you absolutely can't use Go to build a robot, just that it's probably not a good idea. Just because someone uses Node.js to build a hobby robot, doesn't mean that many people are using it for production embedded systems. If your systems has hard real time requirements, which many systems do (even many hobby robots), a stop the world garbage collector is out of the question. Let's say you have a legged robot that depends on interpreting sensor feedback to keep from failing over. What happens to your balance when the garbage collector pauses your code for 10ms?
- pjmlp 11y ago

deleted 11y ago

[deleted]