6 ms·

There are already several decent GC languages. If Rust was just another GC language, I don't think it would have attracted such a strong community required to d

by pornel 8y ago

There are already several decent GC languages. If Rust was just another GC language, I don't think it would have attracted such a strong community required to develop all of these things and break out of obscurity. It'd be another Go with generics, or Elixir-native, or Swift with uglier syntax. In the no-GC no-runtime niche for a very long time there was nothing viable besides C and C++. For programmers who want C-like level of control, performance and low-level compatibility there are very few alternatives, and if you want non-crash-prone parallelism on top of that, there's nothing but Rust.

wyatwerp 8y ago
Taking nothing away from the Rust community that has managed such a complex language so well so long, I have to say that there never was anything viable in the no-GC no-runtime niche (that is why it is a niche - otherwise why would anybody be using GC'd languages). We were/are just gritting and bearing C++. If it is a typical program, i.e. not a device driver or OS kernel running on low-memory hardware, having a GC + runtime doesn't preclude performance, for a long-running program. Of course, for short-running programs, just malloc, don't free, is the fastest.
- pimeys 8y ago
  Having a GC also kind of makes it nasty to write libraries to other GC'd languages. In Rust all of this is very easy, and you can get the speed bump to your Ruby/Python/JavaScript libraries using a modern and safe language.
  - wyatwerp 8y ago
    Is the speed bump for other-language libraries or for other-language applications? For speeding up other-language libraries, D has a -betterC mode, which prevents you from using the subset of the language and the libraries (standard & user-defined) that relies on GC. The remaining language is a very clean C that simply works on the other language's GC'd memory (using the other language's C interface), and can use stack allocation or any heap allocation strategy of your choice for its working set (reference counting ala C++ shared_ptr could be the obvious choice, but it is your party). For other language applications, it is a valid option to speed up the entire application by writing it in D, as it has "all" the features of those other languages + all the convenience that is afforded by a GC + threads if you don't want a multi-process design. I quote "all" because I mean useful things like blocks/closures, generic data structures, etc. - of course, neither Rust nor D give you runtime devices like monkey-patching/meta-class hackery/prototype changes.
    - pimeys 8y ago
      We've been rewriting a big Scala code base to Rust now since January and the team is advancing in a nice pace. Our plan was: - Take one part of the system to rewrite over JNA - Run a massive amount of Scala tests against the new code - When green, take another part - Meanwhile the other part of the team writes the user-facing code base, connecting it to the new Rust crates - The test suit works also over an integration layer, so the other team can test their code and the backend with the same test suite We're quite far already. Originally I was the only person with Rust experience. Now there's five of us.
      - hopscotch 8y ago
        Why are you migrating from Scala?
        pimeys 8y ago
        The company wants much lower resource usage per node and easy integration with other languages.
- jandrewrogers 8y ago
  The use case for non-GC languages go significantly beyond low-level OS kernel type code. Most of our backend infrastructure software and servers (e.g. database engines) are also poor fits for a GC languages, and this is what Rust is targeting. For this type of software, a GC has a large negative performance impact, so it isn't really an option. Operational cost efficiency is often a key factor in platform selection -- being able to reduce hardware requirements by an integer factor is compelling. To me, Rust is a cleaner and stricter but also more narrow systems programming language than C++, and can be used as a sensible replacement for many C++ code bases, particularly as Rust adds features. Rust still has some challenges. For example, the DMA-driven, schedule-based memory safety models that have become fashionable in high-performance database kernels are not compatible with Rust's memory model. You'd have to make most of the code "unsafe" (in a Rust sense, it is actually an alternative memory safety model designed around a different set of assumptions).
  - wyatwerp 8y ago
    Off-hand, Mirage OS comes to mind - it completely upends how you would "build" and "run" back-end services, and it is written solely in a GC'ed language - OCaml. And all GC'ed languages are not equal; see https://roscidus.com/blog https://roscidus.com/blog about a Linux package manager ported from Python to OCaml for performance reasons (followed by an OCaml reimplementation of a component in a virtualized OS). Some infrastructure, e.g. database engines, is ubiquitous, but all instances are of the same few software products written in C/C++/Java. Those ubiquitous instances have banged most bugs out of those codebases, so it is an uphill battle there to convince incumbents and upstarts alike, of the value of a new implementation. But Rust & Pony are marvelously positioned to march up that hill, especially if you throw in multi-threading. My impression is that only a minority of widely-programmed back-end infrastructure that suits Rust is written in C/C++ (say, map-reduce kernels). The code-base size & the data flow complexity inside those components is pretty limited, and Rust should be tractable at that scale. Most widely-programmed infrastructure software - in the back-end and on cell phone OS'es - have been merrily using Java/Python/Ruby/Erlang. OCaml is quoted as being used in the management component of VMware. These are much larger applications; is there any evidence or hint that Rust isn't onerous to develop larger systems in? Without that evidence, I feel (not think) that a disciplined GC'ed language (D? Pony?) has a better chance there.
- buckminster 8y ago
  > Of course, for short-running programs, just malloc, don't free, is the fastest. A custom malloc that knew free would never be called would be faster still. I wonder if any short-running utilities do this?
  - pornel 8y ago
    AFAIK the D compiler is basically this.
    - wyatwerp 8y ago
      And it is a short-running utility :-)
rudedogg 8y ago
> It'd be another Go with generics, or Elixir-native, or Swift with uglier syntax. I just want to point out that the Swift package management situation is currently bad. SPM (https://github.com/apple/swift-package-manager https://github.com/apple/swift-package-manager) can't be used within Xcode, and is basically not used for anything outside of server-side swift / Linux. It also doesn't look like SPM will be integrated with Xcode this WWDC, so you're stuck with CocoaPods or Carthage. I'm really jealous of cargo. And RLS (Swift LSP doesn't really work well because it doesn't know about your dependencies - back to the package manager issue).
dpc_pw 8y ago
I don't really understand why people would want a GC over deterministic destruction like in Rust. GC is [neither necessary nor sufficient](https://ruudvanasseldonk.com/2015/10/06/neither-necessary-nor-sufficient https://ruudvanasseldonk.com/2015/10/06/neither-necessary-no...). Ownership model in practice is much more convenient precisely because objects can act like resources and implement their cleanup logic, and the business logic can rely on it. It's a great improvement in any imperative PL. I have (re-)implemented couple of real-life projects, and each time Rust was much better higher-level language than eg. Java, Python or JS. Borrow checker fights are non-issue in practice: just avoid references, pass messages as copies and when you have to share data use `Arc` and copy on write (or just add `Mutex`). There's a reason why Rust is most loved PL for 4 years in a row. Once you try it, and get past initial adjustments (mosty: what owns what relationship) everything clicks, and I guarantee that you won't miss GC at all.
- njepa 8y ago
  I think mainly because mastering new concepts increases the barrier to entry, overhead and scope. Which in turn affects creativity. There are many brilliant programming languages, used by brilliant programmers, yet, most really useful software tends to be produced by whatever. It would be awesome if Rust could overcome that, but I don't really see how currently.
  - wyatwerp 8y ago
    In the no-GC no-runtime niche, you probably need brilliant programmers anyway. Most of them are banging their heads against the C++ wall right now; they would love to get back some of their lost creativity via mastering of new concepts (Rust borrow checker, or Pony's deny capabilities - https://pony-lang.io https://pony-lang.io ).
    - njepa 8y ago
      In my experience C++ programmers aren't necessarily great programmers as such. Because low levels things usually requires domain knowledge and experience more so than programming brilliance.

by pornel 8y ago

wyatwerp 8y ago

Taking nothing away from the Rust community that has managed such a complex language so well so long, I have to say that there never was anything viable in the no-GC no-runtime niche (that is why it is a niche - otherwise why would anybody be using GC'd languages). We were/are just gritting and bearing C++. If it is a typical program, i.e. not a device driver or OS kernel running on low-memory hardware, having a GC + runtime doesn't preclude performance, for a long-running program. Of course, for short-running programs, just malloc, don't free, is the fastest.

pimeys 8y ago
Having a GC also kind of makes it nasty to write libraries to other GC'd languages. In Rust all of this is very easy, and you can get the speed bump to your Ruby/Python/JavaScript libraries using a modern and safe language.
- wyatwerp 8y ago
  Is the speed bump for other-language libraries or for other-language applications? For speeding up other-language libraries, D has a -betterC mode, which prevents you from using the subset of the language and the libraries (standard & user-defined) that relies on GC. The remaining language is a very clean C that simply works on the other language's GC'd memory (using the other language's C interface), and can use stack allocation or any heap allocation strategy of your choice for its working set (reference counting ala C++ shared_ptr could be the obvious choice, but it is your party). For other language applications, it is a valid option to speed up the entire application by writing it in D, as it has "all" the features of those other languages + all the convenience that is afforded by a GC + threads if you don't want a multi-process design. I quote "all" because I mean useful things like blocks/closures, generic data structures, etc. - of course, neither Rust nor D give you runtime devices like monkey-patching/meta-class hackery/prototype changes.
  - pimeys 8y ago
    We've been rewriting a big Scala code base to Rust now since January and the team is advancing in a nice pace. Our plan was: - Take one part of the system to rewrite over JNA - Run a massive amount of Scala tests against the new code - When green, take another part - Meanwhile the other part of the team writes the user-facing code base, connecting it to the new Rust crates - The test suit works also over an integration layer, so the other team can test their code and the backend with the same test suite We're quite far already. Originally I was the only person with Rust experience. Now there's five of us.
    - hopscotch 8y ago
      Why are you migrating from Scala?
      - pimeys 8y ago
        The company wants much lower resource usage per node and easy integration with other languages.
jandrewrogers 8y ago
The use case for non-GC languages go significantly beyond low-level OS kernel type code. Most of our backend infrastructure software and servers (e.g. database engines) are also poor fits for a GC languages, and this is what Rust is targeting. For this type of software, a GC has a large negative performance impact, so it isn't really an option. Operational cost efficiency is often a key factor in platform selection -- being able to reduce hardware requirements by an integer factor is compelling. To me, Rust is a cleaner and stricter but also more narrow systems programming language than C++, and can be used as a sensible replacement for many C++ code bases, particularly as Rust adds features. Rust still has some challenges. For example, the DMA-driven, schedule-based memory safety models that have become fashionable in high-performance database kernels are not compatible with Rust's memory model. You'd have to make most of the code "unsafe" (in a Rust sense, it is actually an alternative memory safety model designed around a different set of assumptions).
- wyatwerp 8y ago
  Off-hand, Mirage OS comes to mind - it completely upends how you would "build" and "run" back-end services, and it is written solely in a GC'ed language - OCaml. And all GC'ed languages are not equal; see https://roscidus.com/blog https://roscidus.com/blog about a Linux package manager ported from Python to OCaml for performance reasons (followed by an OCaml reimplementation of a component in a virtualized OS). Some infrastructure, e.g. database engines, is ubiquitous, but all instances are of the same few software products written in C/C++/Java. Those ubiquitous instances have banged most bugs out of those codebases, so it is an uphill battle there to convince incumbents and upstarts alike, of the value of a new implementation. But Rust & Pony are marvelously positioned to march up that hill, especially if you throw in multi-threading. My impression is that only a minority of widely-programmed back-end infrastructure that suits Rust is written in C/C++ (say, map-reduce kernels). The code-base size & the data flow complexity inside those components is pretty limited, and Rust should be tractable at that scale. Most widely-programmed infrastructure software - in the back-end and on cell phone OS'es - have been merrily using Java/Python/Ruby/Erlang. OCaml is quoted as being used in the management component of VMware. These are much larger applications; is there any evidence or hint that Rust isn't onerous to develop larger systems in? Without that evidence, I feel (not think) that a disciplined GC'ed language (D? Pony?) has a better chance there.
buckminster 8y ago
> Of course, for short-running programs, just malloc, don't free, is the fastest. A custom malloc that knew free would never be called would be faster still. I wonder if any short-running utilities do this?
- pornel 8y ago
  AFAIK the D compiler is basically this.
  - wyatwerp 8y ago
    And it is a short-running utility :-)

rudedogg 8y ago

> It'd be another Go with generics, or Elixir-native, or Swift with uglier syntax. I just want to point out that the Swift package management situation is currently bad. SPM (https://github.com/apple/swift-package-manager https://github.com/apple/swift-package-manager) can't be used within Xcode, and is basically not used for anything outside of server-side swift / Linux. It also doesn't look like SPM will be integrated with Xcode this WWDC, so you're stuck with CocoaPods or Carthage. I'm really jealous of cargo. And RLS (Swift LSP doesn't really work well because it doesn't know about your dependencies - back to the package manager issue).

dpc_pw 8y ago

I don't really understand why people would want a GC over deterministic destruction like in Rust. GC is [neither necessary nor sufficient](https://ruudvanasseldonk.com/2015/10/06/neither-necessary-nor-sufficient https://ruudvanasseldonk.com/2015/10/06/neither-necessary-no...). Ownership model in practice is much more convenient precisely because objects can act like resources and implement their cleanup logic, and the business logic can rely on it. It's a great improvement in any imperative PL. I have (re-)implemented couple of real-life projects, and each time Rust was much better higher-level language than eg. Java, Python or JS. Borrow checker fights are non-issue in practice: just avoid references, pass messages as copies and when you have to share data use `Arc` and copy on write (or just add `Mutex`). There's a reason why Rust is most loved PL for 4 years in a row. Once you try it, and get past initial adjustments (mosty: what owns what relationship) everything clicks, and I guarantee that you won't miss GC at all.

njepa 8y ago
I think mainly because mastering new concepts increases the barrier to entry, overhead and scope. Which in turn affects creativity. There are many brilliant programming languages, used by brilliant programmers, yet, most really useful software tends to be produced by whatever. It would be awesome if Rust could overcome that, but I don't really see how currently.
- wyatwerp 8y ago
  In the no-GC no-runtime niche, you probably need brilliant programmers anyway. Most of them are banging their heads against the C++ wall right now; they would love to get back some of their lost creativity via mastering of new concepts (Rust borrow checker, or Pony's deny capabilities - https://pony-lang.io https://pony-lang.io ).
  - njepa 8y ago
    In my experience C++ programmers aren't necessarily great programmers as such. Because low levels things usually requires domain knowledge and experience more so than programming brilliance.