Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Three months of Rust

scattered-thoughts.net

Post reply on HN
Print view View original

71–80 of 120 posts

Re: Three months of Rust

#71

Post by b0b_d0e »

cpp098 wrote: post #59
crazypyro wrote: post #58

Earlier quoted context omitted.

Why can't you practice Rust in a non-business environment?

Programmers always spend too much time on studying which hammer is better, but they forget what they really want to do, right?

I don't think that was the case for me at least. I felt like (using your own analogy) the more I studied Rust, the better I learned how to use every other hammer. Learning a new programming language helped me learn c++ better since I was constantly on the lookout for potential memory leaks and other common pitfalls that Rust prevents. Now when I code in c++, I always try to write the code with safety in mind.

Re: Three months of Rust

#72

Post by jamii »

phren0logy wrote: post #68

The Eve language is an offshoot of what started as LightTable, which was heavily focused on Clojure/Clojurescript. Interesting that Clojurescript was not the language of choice here, both given the roots of that project and the reputation of lisps for being languages to write other languages. I wonder if the team would be willing to comment on why they are moving away from Clojurescript?

Writing a language runtime in javascript is hard enough, clojurescript adds yet more layers of runtime overhead that we have to work around.

Clojurescript is a fine applications language, but it's not a good systems language. Most languages aren't.

Re: Three months of Rust

#73

Post by jamii »

cpp098 wrote: post #57

New languages always are trap. Programmers always waste too much time on new languages or some tricky language syntax. They should focus on the business. I will never try Rust.

Well, we first spent six months on 'cannot call function undefined of undefined'. We could have spent the last three on 'segfault' instead. Rust let us spend that time on actually experimenting instead of just fighting the computer all the time.

Re: Three months of Rust

#74

Post by [deleted] »

cpp098 wrote: post #57

New languages always are trap. Programmers always waste too much time on new languages or some tricky language syntax. They should focus on the business. I will never try Rust.

[deleted]

Re: Three months of Rust

#75

Post by the_mitsuhiko »

andrewchambers wrote: post #14
pcwalton wrote: post #10

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.

> What would benchmarking say the slowest part of rustc is? Typechecking/semantic analysis, llvm, or something else.

I feel like there are some projects out there that trigger things with bad runtime complexities in Rust. I had to stop using the piston image library because compiling it takes 15 seconds every time, which I'm not in for.

Compiling racer currently needs 2GB of RAM for no good reason.

So I'm pretty sure there is ample room for optimizations.

Re: Three months of Rust

#76

Post by the_mitsuhiko »

andrewchambers wrote: post #14
pcwalton wrote: post #10

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.

> What would benchmarking say the slowest part of rustc is? Typechecking/semantic analysis, llvm, or something else.

I feel like there are some projects out there that trigger things with bad runtime complexities in Rust. I had to stop using the piston image library because compiling it takes 15 seconds every time, which I'm not in for.

Compiling racer currently needs 2GB of RAM for no good reason.

So I'm pretty sure there is ample room for optimizations.

Re: Three months of Rust

#77

Post by pcwalton »

Jweb_Guru wrote: post #69
DasIch wrote: post #51

Earlier quoted context omitted.

Just having the ability to perform such optimizations requires an architecture that is sure to have some overhead no matter which optimizations, if any, are actually executed.

Rust could still have a toolchain like DMD devoted to fast compilation with minimal optimization. It just doesn't, yet (and likely won't for quite some time, since the present advantages of having a single toolchain are fairly significant and Rust doesn't have a formal specification yet).

There are C compilers out there that work like this (like, say, the Plan 9 C compiler) and they rarely ever get used in practice, because GCC and clang -O0 are fast enough. I think making a second compiler backend just to eliminate the IR generation step isn't going to be the solution we want in the long run.

Re: Three months of Rust

#78

Post by Sirenos »

cpp098 wrote: post #57

New languages always are trap. Programmers always waste too much time on new languages or some tricky language syntax. They should focus on the business. I will never try Rust.

Rust isn't what you seem to think it is. It targets a very specific area that's been dominated by C/C++ only because there wasn't anything better out there.

Rust still has a long way to go, but it's making progress and I would personally like to see a world where Rust is the go-to language for systems software.

Re: Three months of Rust

#79

Post by pcwalton »

andrewchambers wrote: post #56
Dewie3 wrote: post #46

Earlier quoted context omitted.

> I think there is a bunch of bloat in software compilation which the plan9/Go people were wise to stamp out. Be more specific.

linux kernel takes 20 minutes to build on my workstation, a plan9 kernel takes something tiny like 60 seconds on a raspberry pi. This is due to a few reasons. 1. Plan9 C does not allow headers to include more headers, this speeds up compilation, as there is far less useless preprocessor churn. 2. Plan9 C/Go does not do heavy optimisation, but does a decent job. 3. The system has less code overall, something like 1 mi…

> 2. Plan9 C/Go does not do heavy optimisation, but does a decent job.

That's not good enough for Rust.

> 3. The system has less code overall, something like 1 million lines of code for something like gcc seems like bloat to me, They don't remove useless features and dated features as fast as they pile it on.

Those GCC optimizations matter. You simply cannot get away with competitive performance with an AST-to-assembly plus peephole optimizations on the assembly anymore. SROA, SCCP, loop invariant code motion, algebraic identities, vectorization, aggressive alias analysis, etc. are all very important.

Post reply on HN