6 ms·

In dynamic languages like JavaScript or Python it's necessary to continually run your code in order to validate that the API (of the standard library or of depe

In dynamic languages like JavaScript or Python it's necessary to continually run your code in order to validate that the API (of the standard library or of dependencies) was used correctly, that the types match, etc. Rerunning your code continually is no longer necessary in a language like Rust, because the compiler already does that for you. People complaining about slow compile times in static languages like Rust, Haskell, Scala miss the forest from the trees, which is that the compiler eliminates entire bug categories, logic you'd otherwise need to check at runtime, either via unit tests or at least by running the code locally. Compiler times can always be better, but the compiler works as a theorem prover and the slowness is entirely justified, overall yielding a better ROI. N.B. I'm not saying that with Rust you don't need to run your code or have unit tests. There's only so much a compiler can prove. But you no longer need to do it as often. You can't switch to a language like Rust and expect Python and if you do, then the experience is going to be horrible, because Rust is a very different language.

tastyminerals2 6y ago
In theory and to some degree in practice. The compiler won't fix the code that compiles but runs incorrectly. Besides, there are statically typed functional languages where compiling time is not a problem, see D.
- bad_user 6y ago
  I haven't worked with D, but D isn't a functional programming language ;-)
  - tastyminerals2 6y ago
    You will be surprised if you do ;) Multi-paradigm to be exact. Scala is a multi-paradigm as well btw. http://beza1e1.tuxen.de/stuff/FunctionalD.pdf http://beza1e1.tuxen.de/stuff/FunctionalD.pdf
  - Recurecur 6y ago
    Julia also has plenty of functional features, but is above all a practical, fast, and fast-compiling language. The elegance is free.
raziel2p 6y ago
> In dynamic languages like JavaScript or Python it's necessary to continually run your code No it's not. It's just preferable to do your work in smaller batches so that your feedback loop is fast and you know exactly which change broke things, rather than making 10 changes and then having to figure out which of those changes 4 bugs relate to. And it's better to discover a flaw in your implementation early rather than late, which is also easier when working in small increments.
- tjoff 6y ago
  You get used to it and adapt. That might sound bad but comes with benefits as well. You will train yourself to think and be thorough to get it right the first time without it slowing you down. Getting feedback quickly can be useful (especially when trying something new), but not needing it is liberating (especially when trying something new).
avh02 6y ago
For me the problem would be learning how something does or does not work, even with a compiled language. The reason I hate Spring for example (not that I've worked with it extensively) is that the documentation gives you zero feel for what you expect the behaviour to be. It will compile, but until you run it and check what it's doing, very often you'll be developing with no idea of what you're actually building. Especially if you're trying to get specific behaviour of what you want to see (e.g: figuring out why it won't send mail, or why it doesn't ignore a certain json key or whatever), it still needs many runs to get right.
dean177 6y ago
You can have your cake and eat it too, Ocaml & Go both have type systems and compilers that are fast enough to work iteratively
- wwright 6y ago
  Ocaml is a somewhat fair comparison, but I have to say that Go is really in no way comparable to Rust. Rust is massively more complex.
  - entha_saava 6y ago
    I'd say Go is a fair comparison here. Type checking and Parsing isn't bottleneck in Rust compilation. Code generation is. LLVM is particularly heavy and while it generates optimized code, it is quite slow. Go Authors didn't pick LLVM because of compile speed reasons (as well as complexity), and that turned out to be worthwhile tradeoff.
    - monadic2 6y ago
      Well, worthwhile in terms of compile times, which makes sense knowing google’s codebase. Most people aren’t compiling massive dependency trees that can’t fit on any single computer when they push a commit. Anyway in C++ land massive compile times are just as much of a problem. Fast code is expensive. Go’s a lot of things, but being good at generating fast code ain’t one of them (looking holistically anyway).
      - entha_saava 6y ago
        > Fast code is expensive. Indeed, because all bigtech can invest on is LLVM and C++. The research on compilers and optimizations has not been getting the attention because of LLVM monoculture and the monstrosity that is C++.
        monadic2 6y ago
        Well, rust is modularizing, so there will be opportunities for alternative backend (crane lift?).
tomp 6y ago
But the compiler checks your code, and if the compiler is slow, the problem remains.
- Larrikin 6y ago
  A good IDE effectively checks your code continuously.
- staticassertion 6y ago
  The compiler is slow at building code. It's much, much faster at checking it.
neutronicus 6y ago
Rust's type system doesn't have a notion of "looks right visually," so the compiler is ipso facto unhelpful there
- estebank 6y ago
  Could you expand on this? It seems like you might have a really interesting point to make but I can't tell what it is :)
  - neutronicus 6y ago
    Short compile times are beneficial when development involves a lot of trial-and-error. The parent comment was insinuating that, when developing in Rust, one can leverage its type system to replace this trial-and-error with static verification. And, indeed, if what you're worried about is a dangling or null reference error, the Rust type system has a rich language for specifying expected behavior so you don't have to run your code to check it. If, on the other hand, your job description includes the nebulous mandate to "make it look right," there isn't any feasible way to design your types so that Rust can check that. For example, sometimes I have to do something like "make sure the dialog box is wide enough that it doesn't truncate the title string on any relevant platform." The Rust type system has no way for me to query several versions of macOS and Windows about when they start truncating dialog-box title strings and size my dialog that way, so here I am, still performing this task by trial-and-error, waiting forever to compile my code each time. Nothing about this is Rust-specific by the way. I'm similarly bearish on statically-verified cross-platform dialog boxen in Haskell. And that's one of my dumber "make it look right" tasks - I work on CAD software so most of them involve 3-D graphics and/or computational geometry. And, returning to the parent comment, waiting for C++ to compile in order to test things is a giant fucking time-sink and drain on my productivity. It can't really be automated, or, if it can, it's way beyond the reach of this organization's know-how. In summary, I call bullshit on static verification replacing snappy trial-and-error in the UI / Graphics space. In practice, you're left shifting UI / Graphics customization out of the host language and into "content" so that you can tweak it without re-compiling. But this is another massive fucking time and complexity sink that only exists because at some point you let your compile-times get so far out of control that your people couldn't do their job ("make it look right") in a reasonable amount of time.

tastyminerals2 6y ago

In theory and to some degree in practice. The compiler won't fix the code that compiles but runs incorrectly. Besides, there are statically typed functional languages where compiling time is not a problem, see D.

bad_user 6y ago
I haven't worked with D, but D isn't a functional programming language ;-)
- tastyminerals2 6y ago
  You will be surprised if you do ;) Multi-paradigm to be exact. Scala is a multi-paradigm as well btw. http://beza1e1.tuxen.de/stuff/FunctionalD.pdf http://beza1e1.tuxen.de/stuff/FunctionalD.pdf
- Recurecur 6y ago
  Julia also has plenty of functional features, but is above all a practical, fast, and fast-compiling language. The elegance is free.

raziel2p 6y ago

> In dynamic languages like JavaScript or Python it's necessary to continually run your code No it's not. It's just preferable to do your work in smaller batches so that your feedback loop is fast and you know exactly which change broke things, rather than making 10 changes and then having to figure out which of those changes 4 bugs relate to. And it's better to discover a flaw in your implementation early rather than late, which is also easier when working in small increments.

tjoff 6y ago
You get used to it and adapt. That might sound bad but comes with benefits as well. You will train yourself to think and be thorough to get it right the first time without it slowing you down. Getting feedback quickly can be useful (especially when trying something new), but not needing it is liberating (especially when trying something new).

avh02 6y ago

For me the problem would be learning how something does or does not work, even with a compiled language. The reason I hate Spring for example (not that I've worked with it extensively) is that the documentation gives you zero feel for what you expect the behaviour to be. It will compile, but until you run it and check what it's doing, very often you'll be developing with no idea of what you're actually building. Especially if you're trying to get specific behaviour of what you want to see (e.g: figuring out why it won't send mail, or why it doesn't ignore a certain json key or whatever), it still needs many runs to get right.

dean177 6y ago

You can have your cake and eat it too, Ocaml & Go both have type systems and compilers that are fast enough to work iteratively

wwright 6y ago
Ocaml is a somewhat fair comparison, but I have to say that Go is really in no way comparable to Rust. Rust is massively more complex.
- entha_saava 6y ago
  I'd say Go is a fair comparison here. Type checking and Parsing isn't bottleneck in Rust compilation. Code generation is. LLVM is particularly heavy and while it generates optimized code, it is quite slow. Go Authors didn't pick LLVM because of compile speed reasons (as well as complexity), and that turned out to be worthwhile tradeoff.
  - monadic2 6y ago
    Well, worthwhile in terms of compile times, which makes sense knowing google’s codebase. Most people aren’t compiling massive dependency trees that can’t fit on any single computer when they push a commit. Anyway in C++ land massive compile times are just as much of a problem. Fast code is expensive. Go’s a lot of things, but being good at generating fast code ain’t one of them (looking holistically anyway).
    - entha_saava 6y ago
      > Fast code is expensive. Indeed, because all bigtech can invest on is LLVM and C++. The research on compilers and optimizations has not been getting the attention because of LLVM monoculture and the monstrosity that is C++.
      - monadic2 6y ago
        Well, rust is modularizing, so there will be opportunities for alternative backend (crane lift?).

tomp 6y ago

But the compiler checks your code, and if the compiler is slow, the problem remains.

Larrikin 6y ago
A good IDE effectively checks your code continuously.
staticassertion 6y ago
The compiler is slow at building code. It's much, much faster at checking it.

neutronicus 6y ago

Rust's type system doesn't have a notion of "looks right visually," so the compiler is ipso facto unhelpful there

estebank 6y ago
Could you expand on this? It seems like you might have a really interesting point to make but I can't tell what it is :)
- neutronicus 6y ago
  Short compile times are beneficial when development involves a lot of trial-and-error. The parent comment was insinuating that, when developing in Rust, one can leverage its type system to replace this trial-and-error with static verification. And, indeed, if what you're worried about is a dangling or null reference error, the Rust type system has a rich language for specifying expected behavior so you don't have to run your code to check it. If, on the other hand, your job description includes the nebulous mandate to "make it look right," there isn't any feasible way to design your types so that Rust can check that. For example, sometimes I have to do something like "make sure the dialog box is wide enough that it doesn't truncate the title string on any relevant platform." The Rust type system has no way for me to query several versions of macOS and Windows about when they start truncating dialog-box title strings and size my dialog that way, so here I am, still performing this task by trial-and-error, waiting forever to compile my code each time. Nothing about this is Rust-specific by the way. I'm similarly bearish on statically-verified cross-platform dialog boxen in Haskell. And that's one of my dumber "make it look right" tasks - I work on CAD software so most of them involve 3-D graphics and/or computational geometry. And, returning to the parent comment, waiting for C++ to compile in order to test things is a giant fucking time-sink and drain on my productivity. It can't really be automated, or, if it can, it's way beyond the reach of this organization's know-how. In summary, I call bullshit on static verification replacing snappy trial-and-error in the UI / Graphics space. In practice, you're left shifting UI / Graphics customization out of the host language and into "content" so that you can tweak it without re-compiling. But this is another massive fucking time and complexity sink that only exists because at some point you let your compile-times get so far out of control that your people couldn't do their job ("make it look right") in a reasonable amount of time.