15 ms·

> Not being hindered by the compiler telling you what you can and can't do; freeing yourself from the write-compile-debug cycle, reducing it to repl-done; etc.

> Not being hindered by the compiler telling you what you can and can't do; freeing yourself from the write-compile-debug cycle, reducing it to repl-done; etc. Yeah, I certainly understand various language trade-offs, but in my experience any of these early wins of interpreted languages come back to haunt you at significant cost. I saw someone use the analogy of a credit card on here before: purchases are very easy to make, but have to be repaid in full, and without perfect discipline you'll be paying interest on top. Now consider most development teams (who are generally strapped for resources) like middle-class earners who don't make quite enough to pay back that balance every month. It starts to accumulate, and the owed interest compounds. Compilers can do a lot to ensure high productivity and a good user experience: (1) be fast, (2) have great error messages, and (3) be easy to use (no makefiles or heavy build systems). Rust's compiler has learnt from the mistakes of its predecessors in other languages, and does all these for you.

omaranto 9y ago
Compiled languages can have REPLs too. Common Lisp and Haskell come to mind.
- steveklabnik 9y ago
  https://github.com/murarth/rusti https://github.com/murarth/rusti was the start of one; it's not particularly maintained these days.
- skariel123 9y ago
  and scala
- kccqzy 9y ago
  For Haskell, the GHC's compiler and interpreter are very different beasts. The former is well known to be fast, but the latter is fast.
- jleahy 9y ago
  Or ROOT for C++ (used by CERN) https://root.cern.ch/ https://root.cern.ch/
sillysaurus3 9y ago
Yeah, I certainly understand various language trade-offs, but in my experience any of these early wins of interpreted languages come back to haunt you at significant cost. If you understood the wins of untyped languages, you'd be aware that this is often the most optimal path for a startup to take. Get features done now + fix them later is, in hundreds of cases, the way that startups win. It's also a win for people who come home from work and want to get features done on their side projects rather than write perfect code. It's beginning to get tiresome to continually hear the Rust community go on and on about how amazing Rust is and say, with a straight face, that eventually there will be no reason to write anything in not-Rust. Are you serious? The hubris is off the charts. If your language doesn't have a REPL, your language is less productive. Deal with it. That said, the engineering tradeoffs are often a win. I love Rust; borrow checking is frankly incredible. But it's important to keep perspective.
- zzalpha 9y ago
  If your language doesn't have a REPL, your language is less productive. Deal with it. Oh hardly. As someone who's developed software in Perl, Python, C, Java, C#, Haskell, and a few others besides, a REPL is the one thing I use the least. I've honestly never understood the obsession with it. Is a rapid compile-run-debug cycle important? Absolutely. If I want to test something in isolation, being able to rapidly turn out a UT to prove my code does what I think it does is incredibly important. But a REPL is a nice-to-have. Nothing more. Treating its absence as some fundamental black mark on a language is completely absurd.
  - sillysaurus3 9y ago
    I tend to agree, but being able to have a REPL at all is a symptom that your language is capable of an extremely fast compile-run-debug cycle. In other words, if you can't implement a REPL, that's the definition of "less productive language." It's not about the REPL itself but the capability of implementing one. Think about it like this: On your list of languages, which of them would you say is most productive? It depends on the context, certainly: libraries, familiarity, etc. But let's assume the languages had identical ecosystems, and that you were competent in all of them. Which of them would take the smallest amount of time to write your feature? That'd probably be Python, Haskell, or even Perl. It seems very difficult to argue that Rust would top them. And the reasons why this is might be true are worth examining. Here's another aspect. Is the Rust community claiming that the entire history of computing has lead up to this point, where Rust exists, and now nobody needs to write anything in not-Rust? Are people 200 years from now going to write Rust and nothing else? How about 20? 2? It becomes very difficult to argue that your programming language is the lingua franca of the future. (And that's probably true for every language, not just Rust.)
comex 9y ago
Rust's compiler is not fast. At best it can beat C++ compilers - C++ being a language whose build times people love to bemoan - but usually it does far worse. This might change once rustc eventually gets proper incremental compilation (not the codegen-only thing that's currently in beta). Hopefully. Rust doesn't use header files, so in theory it should be possible to leapfrog C++ (at least until C++ gets modules standardized), but for now that's just theory. Right now, I don't do much serious work in Rust, almost solely because of compilation speed.
- vvanders 9y ago
  Oh please, it's plenty fast, at least on par with javac. There's also 'cargo check' which is blazing fast. If you're seeing very large compile time then it's a good sign that you probably want to break things into smaller crates anyway. I've been working on some pretty large stuff and compile speeds haven't been an issue(aside from the Emscripten linker, but that's not Rust's fault).
  - steveklabnik 9y ago
    "rustc is too slow" is possibly our most commonly-heard feedback. I am glad that you don't find it onerous, but many still do.
    - bluejekyll 9y ago
      I don't know... I really think it depends on the audience you're catering to. As someone who only ever deals with compiled languages, this has never seemed to be a problem. Now, viewing this as someone coming from Python, Ruby, Node, etc., I can see compilation as being annoying. Is it really the only reason that they are disliking the language or is that just a strawman? I wonder if too much attention is being paid to this. Now there are legitimate things we can focus on, such as making cached precompiled libraries very easy to use. This can especially be important in CI environments... This would also generally make most compilations fast.
      - 9y ago
3pt14159 9y ago
I fully agree with you, but I still start projects in Ruby. Why? Because returns from startups are exponential and the interest rate is higher than the interest rate on the technical debt. It's why compiled is a great choice for an established corporation with a well defined need and a large user base, while interpreted is better for most other business contexts, especially with tools like Numpy.
- perfmode 9y ago
  Have you seen helix? Ruby-Rust interop: https://usehelix.com/ https://usehelix.com/
  - 3pt14159 9y ago
    Yeah, but I've been doing this stuff for a while now. I used to do it in C and then in Nim (unlike Go until about a year or two ago, Nim could always compile shared objects, so using it through the ruby FFI was pretty straight forward. I've also done some stuff in Cython and just communicated through the database to my Rails app. I'm still not sure what the best way of doing things is. I tend to think that Rust is going to be the programming language of tomorrows operating system, but I'm not sure if it is going to get the wide library support of something like Cython, since the scientific community isn't as fractured as the software community. Tools like graph-tool / scipy / etc are hard to live without.

omaranto 9y ago

Compiled languages can have REPLs too. Common Lisp and Haskell come to mind.

steveklabnik 9y ago
https://github.com/murarth/rusti https://github.com/murarth/rusti was the start of one; it's not particularly maintained these days.
skariel123 9y ago
and scala
kccqzy 9y ago
For Haskell, the GHC's compiler and interpreter are very different beasts. The former is well known to be fast, but the latter is fast.
jleahy 9y ago
Or ROOT for C++ (used by CERN) https://root.cern.ch/ https://root.cern.ch/

sillysaurus3 9y ago

Yeah, I certainly understand various language trade-offs, but in my experience any of these early wins of interpreted languages come back to haunt you at significant cost. If you understood the wins of untyped languages, you'd be aware that this is often the most optimal path for a startup to take. Get features done now + fix them later is, in hundreds of cases, the way that startups win. It's also a win for people who come home from work and want to get features done on their side projects rather than write perfect code. It's beginning to get tiresome to continually hear the Rust community go on and on about how amazing Rust is and say, with a straight face, that eventually there will be no reason to write anything in not-Rust. Are you serious? The hubris is off the charts. If your language doesn't have a REPL, your language is less productive. Deal with it. That said, the engineering tradeoffs are often a win. I love Rust; borrow checking is frankly incredible. But it's important to keep perspective.

zzalpha 9y ago
If your language doesn't have a REPL, your language is less productive. Deal with it. Oh hardly. As someone who's developed software in Perl, Python, C, Java, C#, Haskell, and a few others besides, a REPL is the one thing I use the least. I've honestly never understood the obsession with it. Is a rapid compile-run-debug cycle important? Absolutely. If I want to test something in isolation, being able to rapidly turn out a UT to prove my code does what I think it does is incredibly important. But a REPL is a nice-to-have. Nothing more. Treating its absence as some fundamental black mark on a language is completely absurd.
- sillysaurus3 9y ago
  I tend to agree, but being able to have a REPL at all is a symptom that your language is capable of an extremely fast compile-run-debug cycle. In other words, if you can't implement a REPL, that's the definition of "less productive language." It's not about the REPL itself but the capability of implementing one. Think about it like this: On your list of languages, which of them would you say is most productive? It depends on the context, certainly: libraries, familiarity, etc. But let's assume the languages had identical ecosystems, and that you were competent in all of them. Which of them would take the smallest amount of time to write your feature? That'd probably be Python, Haskell, or even Perl. It seems very difficult to argue that Rust would top them. And the reasons why this is might be true are worth examining. Here's another aspect. Is the Rust community claiming that the entire history of computing has lead up to this point, where Rust exists, and now nobody needs to write anything in not-Rust? Are people 200 years from now going to write Rust and nothing else? How about 20? 2? It becomes very difficult to argue that your programming language is the lingua franca of the future. (And that's probably true for every language, not just Rust.)

comex 9y ago

Rust's compiler is not fast. At best it can beat C++ compilers - C++ being a language whose build times people love to bemoan - but usually it does far worse. This might change once rustc eventually gets proper incremental compilation (not the codegen-only thing that's currently in beta). Hopefully. Rust doesn't use header files, so in theory it should be possible to leapfrog C++ (at least until C++ gets modules standardized), but for now that's just theory. Right now, I don't do much serious work in Rust, almost solely because of compilation speed.

vvanders 9y ago
Oh please, it's plenty fast, at least on par with javac. There's also 'cargo check' which is blazing fast. If you're seeing very large compile time then it's a good sign that you probably want to break things into smaller crates anyway. I've been working on some pretty large stuff and compile speeds haven't been an issue(aside from the Emscripten linker, but that's not Rust's fault).
- steveklabnik 9y ago
  "rustc is too slow" is possibly our most commonly-heard feedback. I am glad that you don't find it onerous, but many still do.
  - bluejekyll 9y ago
    I don't know... I really think it depends on the audience you're catering to. As someone who only ever deals with compiled languages, this has never seemed to be a problem. Now, viewing this as someone coming from Python, Ruby, Node, etc., I can see compilation as being annoying. Is it really the only reason that they are disliking the language or is that just a strawman? I wonder if too much attention is being paid to this. Now there are legitimate things we can focus on, such as making cached precompiled libraries very easy to use. This can especially be important in CI environments... This would also generally make most compilations fast.
    - 9y ago

3pt14159 9y ago

I fully agree with you, but I still start projects in Ruby. Why? Because returns from startups are exponential and the interest rate is higher than the interest rate on the technical debt. It's why compiled is a great choice for an established corporation with a well defined need and a large user base, while interpreted is better for most other business contexts, especially with tools like Numpy.

perfmode 9y ago
Have you seen helix? Ruby-Rust interop: https://usehelix.com/ https://usehelix.com/
- 3pt14159 9y ago
  Yeah, but I've been doing this stuff for a while now. I used to do it in C and then in Nim (unlike Go until about a year or two ago, Nim could always compile shared objects, so using it through the ruby FFI was pretty straight forward. I've also done some stuff in Cython and just communicated through the database to my Rails app. I'm still not sure what the best way of doing things is. I tend to think that Rust is going to be the programming language of tomorrows operating system, but I'm not sure if it is going to get the wide library support of something like Cython, since the scientific community isn't as fractured as the software community. Tools like graph-tool / scipy / etc are hard to live without.