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

A Week with Mozilla's Rust

relistan.com

Post reply on HN
Print view View original

71–80 of 104 posts

Re: A Week with Mozilla's Rust

#71

Post by dbaupp »

copx wrote: post #58
pcwalton wrote: post #47

Earlier quoted context omitted.

Well, we have a production-quality optimizer (LLVM). So it'll always take some time to compile. Eventually once all of our LLVM patches are upstream and the versions including the patches make it into common repositories you may be able to use your system LLVM to compile the Rust compiler, at which point the compile times will drop dramatically. We continue to work on compile speed of Rust code all the time.

Will you also work on providing a better Windows package? I don't understand why you don't just bundle all the dependencies, given that they all seem to be open source and redistributable. Call me spoiled but I expect a one-click installer in this day and age. I still haven't tried to actually use Rust because of that and I am sure I am not the only one.

You're spoiled :P

But, windows is (unfortunately) a bit of a second class platform at the moment (although there have been some very big strides in the last week or so). So part of the reason for poor windows packaging is Rust isn't ready on windows yet (even more so that its normal pre-alpha-ness on Linux and Mac).

Re: A Week with Mozilla's Rust

#72

Post by pjmlp »

acqq wrote: post #45
kibwen wrote: post #42

Earlier quoted context omitted.

> What I consider missing for "properly" interfacing with > C is for Rust to be able to slurp C headers as they are, > without the need for additional "translation" files that > are presented in the article. rust-bindgen (modeled after Clay's bindgen tool) has you covered: https://github.com/crabtw/rust-bindgen/ C header files go in, the proper Rust definitions come out. There are long-term plans to adopt this as an…

I'd prefer such code to actually be the part of compiler, simply, C headers directly readable by the compiler as soon as they are referenced from the code as C headers.

The only way to do this fully automatic is to integrate a partial C compiler, able to understand the pre-processor and all types of declarations.

Re: A Week with Mozilla's Rust

#73

Post by mercurial »

acqq wrote: post #8
chimeracoder wrote: post #2

I don't want to turn this into a Go vs. Rust discussion, because the two languages are very different and have very different goals. However, I want to question the claim: > Go is also not particularly friendly to interface to external libraries written in C which doesn't seem to be explained anywhere in the article, and jars with my understanding. Go does play very well with C; cgo[0] makes this pretty straightforwa…

Rust not having the garbage collection as far as I understand can be made to produce routines that are part of C application. As far as I understand, by design Go can't be a "nice" citizen in a C application, the Go routine will bring with itself the whole city it lives in to your flat. So Go applications are something like "compiled, fast Ruby or Python." As far as I understand, Rust should theoretically be a way to…

> Rust not having the garbage collection as far as I understand can be made to produce routines that are part of C application.

Rust can operate without garbage collection if you don't use shared pointers.

> "OK it's weirder syntax but it's not so far from what would have to be written in C anyway, so where's the advantage?"

Apart from memory safety, a lot of exciting, modern features: pattern matching, typeclasses, immutability per default, built-in concurrency and parallelism, a module system, a packaging system...

> What I consider missing for "properly" interfacing with C is for Rust to be able to slurp C headers as they are, without the need for additional "translation" files that are presented in the article.

I don't know any language with this kind of FFI...

Re: A Week with Mozilla's Rust

#74

Post by pjmlp »

derengel wrote: post #4
chimeracoder wrote: post #2

I don't want to turn this into a Go vs. Rust discussion, because the two languages are very different and have very different goals. However, I want to question the claim: > Go is also not particularly friendly to interface to external libraries written in C which doesn't seem to be explained anywhere in the article, and jars with my understanding. Go does play very well with C; cgo[0] makes this pretty straightforwa…

The keyword here is "friendly", which cgo really isn't.

I never understood why they didn't went the Turbo Pascal/Delphi, Ada, Modula-3, .NET, D way and allowed for proper FFI declarations, instead of forcing a dependency into a C compiler that speaks Go calling conventions.

Re: A Week with Mozilla's Rust

#75

Post by pjmlp »

pcwalton wrote: post #47
regis wrote: post #40

Rust looks really great and I would love to switch all of my C development over to Rust but last time I tried to compile it, it took a good hour or two. Has this changed at all?

Well, we have a production-quality optimizer (LLVM). So it'll always take some time to compile. Eventually once all of our LLVM patches are upstream and the versions including the patches make it into common repositories you may be able to use your system LLVM to compile the Rust compiler, at which point the compile times will drop dramatically. We continue to work on compile speed of Rust code all the time.

I hope Rust can eventually reach compile speeds of most module based languages.

Every time I update my netbook with a new Rust release it takes a few hours, it almost feels like I am compiling KDE or something.

Re: A Week with Mozilla's Rust

#76

Post by pjmlp »

dkhenry wrote: post #11

Of all the upcoming languages out there. I think rust is best positioned. The fact that it is really the only contender that can preform the same role as C, but it folds in lots of the language design theory of the past three decades puts it in a league of its own.

> The fact that it is really the only contender that can preform the same role as C

Modula-2, Ada, Turbo/Apple Pascal were there first, but sadly lost developer hearts to C.

Re: A Week with Mozilla's Rust

#77

Post by gnur »

I don't think it's fair to compare Rust to Go, while operating on nearly the same level. They are targeting a very different crowd. Go has very clean syntax, few reserved words and writes almost as easy as python. This makes go a attractive language for programmers who have a history with languages like php & python but also want more speed. Rust on the other hand has a more complex syntax but allows you more control over memory, thus making it more attractive for those with a history in C or C++. Go is a good language to learn as your first compiled language, easy to write, easy to learn and a good ratio between performance and effort. Rust is (or will be when it's stable) a good language to learn when you have a history in C and you want memory & type safety but still the control you are used to in C/C++.

Re: A Week with Mozilla's Rust

#78

Post by dbaupp »

pjmlp wrote: post #75
pcwalton wrote: post #47

Earlier quoted context omitted.

Well, we have a production-quality optimizer (LLVM). So it'll always take some time to compile. Eventually once all of our LLVM patches are upstream and the versions including the patches make it into common repositories you may be able to use your system LLVM to compile the Rust compiler, at which point the compile times will drop dramatically. We continue to work on compile speed of Rust code all the time.

I hope Rust can eventually reach compile speeds of most module based languages. Every time I update my netbook with a new Rust release it takes a few hours, it almost feels like I am compiling KDE or something.

The compiler is pretty slow (although there's a big drive starting a few days ago to get certain aspects down (mostly compiling small files); because running the testsuite is so slow that work on the compiler is getting dragged down), but compiling the compiler itself is particularly bad:

- it has to build LLVM: Rust currently has to use a custom version; the goal is for this to be unnecessary so that the system LLVM is ok.

- it has to build itself and the standard libraries 3 times: rustc is written in Rust; so it has to bootstrap.

- it eats a lot of memory, so bootstrapping on low memory systems is bad. Much of this is historical; the bootstrapped code means that large portions of the compiler are written when the language was less developed, and so is very non-idiomatic. It's progessively being modernised

The first and last can be fixed; the second can't, at least until there are binary releases.

Re: A Week with Mozilla's Rust

#79

Post by pjmlp »

dbaupp wrote: post #78
pjmlp wrote: post #75

Earlier quoted context omitted.

I hope Rust can eventually reach compile speeds of most module based languages. Every time I update my netbook with a new Rust release it takes a few hours, it almost feels like I am compiling KDE or something.

The compiler is pretty slow (although there's a big drive starting a few days ago to get certain aspects down (mostly compiling small files); because running the testsuite is so slow that work on the compiler is getting dragged down), but compiling the compiler itself is particularly bad: - it has to build LLVM: Rust currently has to use a custom version; the goal is for this to be unnecessary so that the system LLVM…

I understand the reasons behind it.

Given my experience with compiler development, back when I was in the university, my expectations is that the second point would be pretty fast anyway, if the first and last issues are solved.

I have good experience with languages that use modules, some of them had bootstraped compilers like the Oberon family.

That is why I said I am hoping for these issues to be solved, as I think building LLVM is the main culprit.

Re: A Week with Mozilla's Rust

#80

Post by weavie »

mercurial wrote: post #73
acqq wrote: post #8

Earlier quoted context omitted.

Rust not having the garbage collection as far as I understand can be made to produce routines that are part of C application. As far as I understand, by design Go can't be a "nice" citizen in a C application, the Go routine will bring with itself the whole city it lives in to your flat. So Go applications are something like "compiled, fast Ruby or Python." As far as I understand, Rust should theoretically be a way to…

> Rust not having the garbage collection as far as I understand can be made to produce routines that are part of C application. Rust can operate without garbage collection if you don't use shared pointers. > "OK it's weirder syntax but it's not so far from what would have to be written in C anyway, so where's the advantage?" Apart from memory safety, a lot of exciting, modern features: pattern matching, typeclasses,…

> I don't know any language with this kind of FFI...

Does Objective C count?

Post reply on HN