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

51–60 of 120 posts

Re: Three months of Rust

#51

Post by DasIch »

tormeh wrote: post #48
pcwalton wrote: post #35

Earlier quoted context omitted.

My point is that you pay a price for this: LLVM's optimization passes are much, much more sophisticated than those of the Plan 9 toolchain. In optimized builds of Rust, the LLVM optimization and compilation time tends to dominate, so having a simpler type system wouldn't really help. You could have a more C-like language that isn't so dependent on expensive optimization passes like multi-level inlining and SROA, gran…

If optimization is the problem, then compilation at Go speed should be possible with -O0.

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.

Re: Three months of Rust

#52

Post by jroesch »

jamii wrote: post #34
niconii wrote: post #32

Earlier quoted context omitted.

I think you may have misread that RFC. With my emphasis: > Here is a list of limitations with the current bounds syntax that are overcome with the where syntax: The list is of the limitations of normal bounds, not the limitations of where clauses. This was actually the RFC that added where clauses, and that list was the rationale for doing so.

Oh... well that's embarrassing. So, I half-remembered the actual problem I ran into and found something that half-looked like it mentioned it. Not my finest hour :S I dug up the IRC exchange for the problem I actually ran into: jamii How do I write the type of a byte iterator: fn next_path (nibbles: &mut N) -> u32 where ::Item = u8 { That gives me 'equality constraints are not yet supported' FreeFull jamii: > Equalit…

I'm the author of the above pull request (as well as other pieces of where clauses), unfortunately there are some internals that need refactoring before we can complete equality constraints, and they weren't the highest priority before 1.0 especially since you can encode a trait that acts in the same way. I'm starting at Mozilla for the summer next week and hope to fix a couple of the outstanding issues around them and associated types.

Re: Three months of Rust

#53

Post by [deleted] »

bsder wrote: post #30
arthursilva wrote: post #11

Earlier quoted context omitted.

The truth is that rust is in its infancy its all guesses at this point. Go didn't attract c++ people as people first guessed.

I saw them talking about that, but it's completely obvious. Nobody today is running C/C++ unless they need either A) complete speed or B) bare metal. Go can't do either, so there was going to be very little transfer from C/C++ to Go.

[deleted]

Re: Three months of Rust

#54

Post by rhodysurf »

prewett wrote: post #37
bsder wrote: post #30

Earlier quoted context omitted.

I saw them talking about that, but it's completely obvious. Nobody today is running C/C++ unless they need either A) complete speed or B) bare metal. Go can't do either, so there was going to be very little transfer from C/C++ to Go.

C++ is still mostly what I use, but I need neither speed nor bare metal. Maybe add C) people doing UI and applications? There aren't many other good options: Java: UI looks terrible; it's annoying living in Noun-land when CPUs are, if anything, more about verbs than nouns; and running properly on Windows is not trivial. C#: Up until recently, not cross-platform unless you're ok with Mono. (But, might be worth looking…

I am a Qt/C++ programmer by day and i have been looking at rust and there some bindings to GTK and such, but to me, nothing really comes close to the cross platform-ness of Qt. There seem to be simple QML bindings for Rust too, but thats not really the same.

Re: Three months of Rust

#55

Post by jroesch »

Manishearth wrote: post #44
jamii wrote: post #42

Earlier quoted context omitted.

> the trait can be implemented multiple times on the same type, with different A That was the intention - a function that dispatches on the type of both arguments (it probably shows that I secretly think of traits as typeclasses). I'm still trying to figure out what the implications of the above choices are. > In more complicated situations coherence may disallow one or more of those choices. I hadn't thought of that…

Traits are typeclasses :) Uh, the coherence rules are complicated and I forgot them. It's a mixture of where the impl, type, trait, and type parameters are.

The general the coherence rules stop you from defining an implementation that could be possibly defined elsewhere.

The important take away implications are: - you can not implement a trait defined in another crate for a type defined in another crate, unless the trait is parametrized by a type from the current crate - you can't define overlapping implementations

Re: Three months of Rust

#56

Post by andrewchambers »

Dewie3 wrote: post #46
andrewchambers wrote: post #7

"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…

> 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 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.

The whole Go compiler builds from source for me before the gcc configure script has completed.

Re: Three months of Rust

#57

Post by cpp098 »

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.

Re: Three months of Rust

#58

Post by crazypyro »

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.

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

Re: Three months of Rust

#59

Post by cpp098 »

crazypyro wrote: post #58
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.

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?

Re: Three months of Rust

#60

Post by insulanian »

pjmlp wrote: post #40
legutierr wrote: post #15

Earlier quoted context omitted.

If I remember properly, when Go was first developed, compilation time was one of the primary metric that Rob Pike et al were optimizing for, and drove major aspects of its design. It shouldn't be surprising that Go blows other systems out of the water in this regard. Here he is talking about it: https://www.youtube.com/watch?v=rKnDgT73v8s#t=8m53

> It shouldn't be surprising that Go blows other systems out of the water in this regard. For any developer that never used Turbo Pascal, Modula-2, Oberon compilers, just to cite a few examples among many possible ones. Those that did, can not comprehend why companies invested in languages like C and C++, which created this notion all compilers should be slow.

Oh yes, Turbo Pascal (and even Delphi / Object Pascal) had a really fast compiler. Sigh... those were the days...
Post reply on HN