3 ms·

There are plenty of reasons why Rust could win outside of requiring safe manual memory management. It is an expression based language with ad-hoc polymorphism,

There are plenty of reasons why Rust could win outside of requiring safe manual memory management. It is an expression based language with ad-hoc polymorphism, algebraic data types, hygienic macros, first class functions, and race-free concurrency. I don't use rust because I don't need manual memory management and I require subtype polymorphism for a lot of things, but I choose Scala over D.

jacques_chirac 10y ago
Neither Rust nor Scala hold a candle to D in terms of compile-time introspection. You can do things with it that are near unbelievable - "you must ask yourself if some law of nature was broken" quoted from memory in http://dconf.org/2015/talks/alexandrescu.html http://dconf.org/2015/talks/alexandrescu.html
- interestingemu 10y ago
  Scala developers can do whatever they want or need at compile-time.
smitherfield 10y ago
> race-free concurrency Rust's thread model is free from data races (a thread must have exclusive access to a variable in order to write to it), but not from race conditions in general.
- GreenWinters 10y ago
  Could you give an example of a kind of race conditions allowed in Rust? (Sorry for a naive question, just thought that a data race and a race condition are synonyms. What else is there to race over if not shared data?)
  - dbaupp 10y ago
    The "data race" term is jargon (i.e. means more than just "race on data") that specifically refers to unsynchronised concurrent accesses to a piece of memory/resource (where at least one of the accesses is a write), while a race condition is a higher level thing, where things aren't ordered the way one intends, even if they have the appropriate "low-level" synchronisation to avoid data races. http://blog.regehr.org/archives/490 http://blog.regehr.org/archives/490 Rust can't prevent one from doing all the right low-level synchronisation in the wrong order. In fact, I don't think any language can, without somehow being able to understand the spec of a program: something that's a race condition in one case, may not be a race condition elsewhere (this differs to a data race, which isn't context dependent).
  - leshow 10y ago
    Rust does not prevent all race conditions because doing so would be impossible. It would be akin to solving the halting problem. Deadlocks, and other synchronization issues are just some 'general race conditions' Rust can't solve. Rust's prevents 'data races' defined as: -two or more threads concurrently accessing a location of memory -one of them is a write -one of them is unsynchronized https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html
hydromet 10y ago
I recently (past few years) invested in learning Clojure, enough to get some practical things deployed, but I am far from being a Clojure advanced developer. I wanted to learn a Lisp dialect and am glad I chose Clojure. Rich Hickey is a guru. I don't have any gripes with Clojure but I'm not too deeply invested. Several years ago I was also enamored with Julia, which I was investigating for CPU intensive programs, but never had the time to commit and I was concerned about Julia being too youthful and possibly not getting enough traction. Should I learn D for CPU intensive programs? Also, with Clojure I can make use of the many Java libraries for I/O due to Clojure's good Java interop. Does D have the analogous benefit of tried and tested I/O libraries? Thanks for any suggestions, D has my intrigued.

jacques_chirac 10y ago

Neither Rust nor Scala hold a candle to D in terms of compile-time introspection. You can do things with it that are near unbelievable - "you must ask yourself if some law of nature was broken" quoted from memory in http://dconf.org/2015/talks/alexandrescu.html http://dconf.org/2015/talks/alexandrescu.html

interestingemu 10y ago
Scala developers can do whatever they want or need at compile-time.

smitherfield 10y ago

> race-free concurrency Rust's thread model is free from data races (a thread must have exclusive access to a variable in order to write to it), but not from race conditions in general.

GreenWinters 10y ago
Could you give an example of a kind of race conditions allowed in Rust? (Sorry for a naive question, just thought that a data race and a race condition are synonyms. What else is there to race over if not shared data?)
- dbaupp 10y ago
  The "data race" term is jargon (i.e. means more than just "race on data") that specifically refers to unsynchronised concurrent accesses to a piece of memory/resource (where at least one of the accesses is a write), while a race condition is a higher level thing, where things aren't ordered the way one intends, even if they have the appropriate "low-level" synchronisation to avoid data races. http://blog.regehr.org/archives/490 http://blog.regehr.org/archives/490 Rust can't prevent one from doing all the right low-level synchronisation in the wrong order. In fact, I don't think any language can, without somehow being able to understand the spec of a program: something that's a race condition in one case, may not be a race condition elsewhere (this differs to a data race, which isn't context dependent).
- leshow 10y ago
  Rust does not prevent all race conditions because doing so would be impossible. It would be akin to solving the halting problem. Deadlocks, and other synchronization issues are just some 'general race conditions' Rust can't solve. Rust's prevents 'data races' defined as: -two or more threads concurrently accessing a location of memory -one of them is a write -one of them is unsynchronized https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html

hydromet 10y ago

I recently (past few years) invested in learning Clojure, enough to get some practical things deployed, but I am far from being a Clojure advanced developer. I wanted to learn a Lisp dialect and am glad I chose Clojure. Rich Hickey is a guru. I don't have any gripes with Clojure but I'm not too deeply invested. Several years ago I was also enamored with Julia, which I was investigating for CPU intensive programs, but never had the time to commit and I was concerned about Julia being too youthful and possibly not getting enough traction. Should I learn D for CPU intensive programs? Also, with Clojure I can make use of the many Java libraries for I/O due to Clojure's good Java interop. Does D have the analogous benefit of tried and tested I/O libraries? Thanks for any suggestions, D has my intrigued.