4 ms·
The compiler is relatively fast for recompilation but you are right, this is a problem that's actively being worked on. > support in-process hot-patching I as
by adamnemecek 5y ago
The compiler is relatively fast for recompilation but you are right, this is a problem that's actively being worked on.
> support in-process hot-patching
I assume that we are comparing this with say C++ compilers. I think that Visual Studio added this recently but idk if saying this is a valid criticism of the compiler.
> There's no Rust REPL
Are you comparing it with C++ compilers?
The Rust tooling is so much better than C++ tooling that it's not even funny. You are right, there are places where this could be improved but just cargo makes my life so so so much easier than any other package manager.
- throw10920 5y ago> The compiler is relatively fast for recompilation Relative to Rust when doing a cold-compile, maybe, but certainly not relative to other languages like C, sane C++, Go, or Common Lisp. I'm comparing Rust tooling with existing tooling in other languages in general, that is feasible to implement. Common Lisp has multiple compilers (SBCL, Allegro, Clasp) that compile code nearly instantly (within a second for my modest 2kloc codebases, and individual functions in milliseconds), have REPLs (that also do native-code compilation under the hood using the compiler proper - no hacks), and support hotpatching. Visual Studio implements in-process hot-patching, too, so between C++'s highly static nature, and the fact that SBCL is run by a tiny group of unpaid contributors, there's no reason for the Rust compiler to not have it. Meanwhile, GHC (compiling Haskell, a statically-typed language) has a REPL, so it's clear that being dynamically-typed is not a requirement. From a user's perspective, having either long compilation times or lacking a REPL is OK, but not having either is unacceptable. Having a good package manager is necessary for having good tooling, but not sufficient.