11–20 of 120 posts
Earlier quoted context omitted.
Nonsense, go is fine, so is rust.
Both are really great. I think Go is better for servers and rust can be great on embedded and high performance applications.
Great to see some feedback on Rust, I've only played a bit but was quite impressed, dsepite being a mostly high level programmer. However, it sounds like Eve is a simple, dynamically typed programming language/environment. So it's super weird to me to see him rave about the safety and type system of Rust...
Earlier quoted context omitted.
Nonsense, go is fine, so is rust.
Both are really great. I think Go is better for servers and rust can be great on embedded and high performance applications.
"For our 2400 loc it takes 20s for a dev build and 70s for a release build. " I have played with rust, but not written any large amounts of code. This makes me a bit sad though, I have 7000 lines of go which takes less than a second. I think there is a bunch of bloat in software compilation which the plan9/Go people were wise to stamp out. Compare gcc/clang/rustc build times from source with building go 1.5 from sour…
The advantage, of course, is that LLVM has probably over a hundred man-years of optimizations in it, including two IRs (SSA LLVM IR, SelectionDAG), tons of target-specific optimizations (ScheduleDAG, Machine-level optimizations), great tooling (e.g. DWARF support, Address/Thread Sanitizer), and lots of community support. None of it is bloat as far as Rust is concerned. I optimize bare-metal Rust code nearly every day…
LLVM is a great innovation when it comes to making new languages from scratch, High performance will hopefully be one of rusts strong points, so its good to have so many companies working on llvm performance for free.
"For our 2400 loc it takes 20s for a dev build and 70s for a release build. " I have played with rust, but not written any large amounts of code. This makes me a bit sad though, I have 7000 lines of go which takes less than a second. I think there is a bunch of bloat in software compilation which the plan9/Go people were wise to stamp out. Compare gcc/clang/rustc build times from source with building go 1.5 from sour…
Here he is talking about it:
Earlier quoted context omitted.
The advantage, of course, is that LLVM has probably over a hundred man-years of optimizations in it, including two IRs (SSA LLVM IR, SelectionDAG), tons of target-specific optimizations (ScheduleDAG, Machine-level optimizations), great tooling (e.g. DWARF support, Address/Thread Sanitizer), and lots of community support. None of it is bloat as far as Rust is concerned. I optimize bare-metal Rust code nearly every day…
What would benchmarking say the slowest part of rustc is? Typechecking/semantic analysis, llvm, or something else. LLVM is a great innovation when it comes to making new languages from scratch, High performance will hopefully be one of rusts strong points, so its good to have so many companies working on llvm performance for free.
This isn't just an "LLVM is slow" problem, though. It's also a "rustc generates extremely verbose LLVM IR" problem. Optimizing the IR before it gets to LLVM is part of the plan for solving it.
Earlier quoted context omitted.
The advantage, of course, is that LLVM has probably over a hundred man-years of optimizations in it, including two IRs (SSA LLVM IR, SelectionDAG), tons of target-specific optimizations (ScheduleDAG, Machine-level optimizations), great tooling (e.g. DWARF support, Address/Thread Sanitizer), and lots of community support. None of it is bloat as far as Rust is concerned. I optimize bare-metal Rust code nearly every day…
What would benchmarking say the slowest part of rustc is? Typechecking/semantic analysis, llvm, or something else. LLVM is a great innovation when it comes to making new languages from scratch, High performance will hopefully be one of rusts strong points, so its good to have so many companies working on llvm performance for free.
Niko Matsakis is actively working on improving typechecking time--there should be plenty of tricks we can try once we have enough data as to the lowest-hanging fruit. Felix Klock and others are working on reducing the amount of LLVM IR we generate to speed up codegen. There have also been designs for incremental and parallel compilation that will be long-term but have potential for big improvements down the road.
I think with careful work we can get down to a good edit/compile/run experience. Compilation speed probably won't ever be as good as a direct-to-assembly compiler for language with an extremely simple type system with no real IR for optimization would be, but I don't believe there's a magic bullet that will beat LLVM's compiler performance while providing excellent optimization, and for Rust's goals we need the runtime performance.
Earlier quoted context omitted.
Both are really great. I think Go is better for servers and rust can be great on embedded and high performance applications.
I've been tempted to try getting rust going on some of the small arm micros I've got lying around. The memory safety would be tremendous boon for a lot of development there, same with the ownership/lifetime management. I think I'd probably have to strike most of the standard library but it'd still be really useful.
Earlier quoted context omitted.
What would benchmarking say the slowest part of rustc is? Typechecking/semantic analysis, llvm, or something else. LLVM is a great innovation when it comes to making new languages from scratch, High performance will hopefully be one of rusts strong points, so its good to have so many companies working on llvm performance for free.
The slowest part is LLVM. (You can pass "-Z time-passes" to rustc to get detailed timing info.) This isn't just an "LLVM is slow" problem, though. It's also a "rustc generates extremely verbose LLVM IR" problem. Optimizing the IR before it gets to LLVM is part of the plan for solving it.
(Also note that compiling a C++ file with 2000 lines can take a very long time too)
"Despite the restrictions of the type system, I am more productive in Rust than I am in either Javascript or Haskell. It manages somehow to hit a sweet spot between safety and ease of use."
When I toyed with Rust last year (so, I'll admit my knowledge is outdated, I need to refresh it), I had a pleasant experience on the productivity side. The big reward for me, coming from C/C++, is that my programs simply worked as expected once I was past fixing all the errors the compiler reported. That usually doesn't happen this way in C/C++, where you spend additional time fixing whatever null deref and whatnot that break your program in subtle ways at runtime.