11–20 of 79 posts
Will someone with familiarity with both Rust and D talk a bit about the similarities and differences?
[1] https://www.quora.com/Which-language-has-the-brightest-futur...
I think it'd be really interesting if someone tried rewriting the Linux kernel in D (or Rust for that matter) and then compared the performance, lines-of-code, etc. Maybe it could even be done with just one small but critical portion and linked, so it isn't such a monumental task.
I would rather see someone take D, Rust, Swift, whateverX and implement something modern, following the concepts explored at Xerox PARC, ETHZ and MSR in terms of OS architectures and development environments.
Will someone with familiarity with both Rust and D talk a bit about the similarities and differences?
I think it'd be really interesting if someone tried rewriting the Linux kernel in D (or Rust for that matter) and then compared the performance, lines-of-code, etc. Maybe it could even be done with just one small but critical portion and linked, so it isn't such a monumental task.
We don't need more POSIX copies. I would rather see someone take D, Rust, Swift, whateverX and implement something modern, following the concepts explored at Xerox PARC, ETHZ and MSR in terms of OS architectures and development environments.
Supporting POSIX is necessary if the designer wants the OS to run real software.
Will someone with familiarity with both Rust and D talk a bit about the similarities and differences?
I've used both, but can't claim to be much of an expert in either.
Similarities:
• Compile to fast, easy-to-deploy native code
• Abstraction continuum ranging from very low-level C-like style to a high-level more functional style
• Very easy to call C libraries from
• Type inferred and generally less syntactically noisy than C++
Neutral differences:
• D is garbage collected; Rust has a novel memory management system based on linear types. This means D can never compete with Rust in performance and real-time or soft-real-time systems. On the other hand, it means with Rust you will spend more time thinking about memory ownership and other important-but-eliminated-by-GC concerns. Both are easier to deal with than C or C++.
• Syntax: Rust's syntax is not-quite-C-like; D's is very C-like. It comes down to personal preference. I prefer Rust's.
D advantages:
• Metaprogramming: D's metaprogramming is more or less unmatched, though I haven't experimented with Rust compiler plugins at all. You can probably do some funky stuff with Rust, but it doesn't feel as integrated into the language as with D.
• Compiles super fast.
Rust advantages:
• Type system. Rust's type system is ML-esque and generally much more powerful. I suppose this might not be an advantage to everyone, but personally I love how ML-y Rust feels.
• Concurrency.
• Ecosystem?
I think ultimately my choice is that if I'm going to use a compiled GC language, I may as well just use OCaml. D's memory management, or lack thereof, kills it for me personally, but it's a well designed language otherwise IMO.
Earlier quoted context omitted.
We don't need more POSIX copies. I would rather see someone take D, Rust, Swift, whateverX and implement something modern, following the concepts explored at Xerox PARC, ETHZ and MSR in terms of OS architectures and development environments.
It sounds you like you asking for more toy OSes. Supporting POSIX is necessary if the designer wants the OS to run real software.
Or are you suggesting more of an 'embrace and extend' thing, where a new OS supports POSIX for backwards compatibility but adds whatever new API(s) and then tries to grow adoption of those slowly?
Will someone with familiarity with both Rust and D talk a bit about the similarities and differences?
I think this is a valid question. They're pretty different languages in terms of design, but they're definitely worth comparing—their problem domains do overlap in spite of design differences. I've used both, but can't claim to be much of an expert in either. Similarities: • Compile to fast, easy-to-deploy native code • Abstraction continuum ranging from very low-level C-like style to a high-level more functional sty…
Rust, for example, can be used to write a C-like loadable or linkable module for some other system (JNI, Ruby, Python, etc) with a very tiny or nonexistent runtime required.
Having a GC makes this a little less seamless.
Will someone with familiarity with both Rust and D talk a bit about the similarities and differences?
I think this is a valid question. They're pretty different languages in terms of design, but they're definitely worth comparing—their problem domains do overlap in spite of design differences. I've used both, but can't claim to be much of an expert in either. Similarities: • Compile to fast, easy-to-deploy native code • Abstraction continuum ranging from very low-level C-like style to a high-level more functional sty…
You can write programs in D that have ZERO garbage collection.
In fact, the core libraries (phobos) are being actively rewritten to remove GC altogether.
Will someone with familiarity with both Rust and D talk a bit about the similarities and differences?
I think this is a valid question. They're pretty different languages in terms of design, but they're definitely worth comparing—their problem domains do overlap in spite of design differences. I've used both, but can't claim to be much of an expert in either. Similarities: • Compile to fast, easy-to-deploy native code • Abstraction continuum ranging from very low-level C-like style to a high-level more functional sty…
I think an important wrinkle here is that Rust's ownership model helps prevent many runtime-errors other than memory safety. I'm not sure how D handles problems like iterator invalidation, but I've found it really nice to always know what's able to mutate the state when in a given variable.