3 ms·

So can Java, Javascript, there is nothing fundamentally new here. As I said, I’m all for managed languages, and I believe they should be the default choice, onl

by kaba0 3y ago

So can Java, Javascript, there is nothing fundamentally new here. As I said, I’m all for managed languages, and I believe they should be the default choice, only seldom “overwritten” by going lower level in very specific circumstances. Nonetheless, Rust is an interesting, novel language for this very reason - it is memory safe without having a GC. You are the one who always mention stuff like gcj - how is that, available at Java 1.2 times, any different than Go, in a fundamental way?

pjmlp 3y ago
I seldom mention gcj, it was half baked, only supported Red-Hat's case of AOT compiling Eclipse and little else, it was abandoned in 2009. What I quote are production quality compilers for embeeded space like ExcelsiorJET (also creators of Modula-2 and Oberon compilers, now out of business), PTC, Aonix (acquired by PTC), Aicas, WebSphere Real Time (AOT technology nowadays lives on OpenJ9), and microEJ. As for the differences they aren't, that is the point, we should open our minds to use managed systems programming languages, like Xerox PARC, ETHZ and Microsoft Research did. Rust is interesting in being the language that brought affine types into mainstream, although with a productivity cost. As shown by Haskell, OCaml, Swift, Chapel, D, Roc, Hylo (nee Val) efforts, the best is being able to combine automatic memory management with linear/affine types for a low level language subset, with the benefit of not having to type ".clone()" all over the place. As for Go versus Rust, definitly Rust, only because I am not a big fan of Go's language design, and love ML derived languages since Caml Light, nevertheless better Go than C.
- kaba0 3y ago
  We agree here on everything, I just find it dishonest to put Go next to Rust all the time, and not all the millions of managed languages that compile AOT, like you list quite a few. Go is not any lower level than they are, it is just catering to the kind of people that will believe it is somehow a “modern C”.
  - pjmlp 3y ago
    From the point of view of Limbo's role in Inferno, it kind of is, even if only for the userspace side. Which ironically, the closest we got there in modern computing, in tortuous ways, is Android.

by kaba0 3y ago

pjmlp 3y ago

I seldom mention gcj, it was half baked, only supported Red-Hat's case of AOT compiling Eclipse and little else, it was abandoned in 2009. What I quote are production quality compilers for embeeded space like ExcelsiorJET (also creators of Modula-2 and Oberon compilers, now out of business), PTC, Aonix (acquired by PTC), Aicas, WebSphere Real Time (AOT technology nowadays lives on OpenJ9), and microEJ. As for the differences they aren't, that is the point, we should open our minds to use managed systems programming languages, like Xerox PARC, ETHZ and Microsoft Research did. Rust is interesting in being the language that brought affine types into mainstream, although with a productivity cost. As shown by Haskell, OCaml, Swift, Chapel, D, Roc, Hylo (nee Val) efforts, the best is being able to combine automatic memory management with linear/affine types for a low level language subset, with the benefit of not having to type ".clone()" all over the place. As for Go versus Rust, definitly Rust, only because I am not a big fan of Go's language design, and love ML derived languages since Caml Light, nevertheless better Go than C.

kaba0 3y ago
We agree here on everything, I just find it dishonest to put Go next to Rust all the time, and not all the millions of managed languages that compile AOT, like you list quite a few. Go is not any lower level than they are, it is just catering to the kind of people that will believe it is somehow a “modern C”.
- pjmlp 3y ago
  From the point of view of Limbo's role in Inferno, it kind of is, even if only for the userspace side. Which ironically, the closest we got there in modern computing, in tortuous ways, is Android.