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

Two years of Rust

blog.rust-lang.org

Post reply on HN
Print view View original

241–250 of 312 posts

Re: Two years of Rust

#241

Post by pjmlp »

brandur wrote: post #201
nickpsecurity wrote: post #146

Earlier quoted context omitted.

It's one of those things that's happened to so many people with so many C++ compilers on projects of any significant size that almost everyone says it. Happened to me with several where I moved from a Pascal-like language to find the compile time terribly slow even when I barely used the language. A lot of it is do to how the language's syntax, semantics, and esp templating are designed. Plenty of languages with even…

Oh totally agreed that C++'s compilation times are (quite infamously) a mess. I think that my parent was asserting that Rust's compile times are "usually ... far worse" (the "it" in the quote above is a reference to Rust). For all I know, that might be true, but it's one of those "citation needed" type things.

Personal experience.

It takes me about half an hour to update rustfmt, racer and rustsym, every time a new Rust release comes out. On a dual core with 8 GB and HDD.

On the same computer, any of my VC++ 2015/2017 builds, configured to take advantage of incremental compilation and linking, using forward classes and PIMPL idioms, with all third party dependencies already available as binary dependencies, takes around 5 minutes.

Lack of incremental compilation and cargo not being able to deal with binaries dependencies has putted me off, after all if I want slow builds I can have them already in C++ when I go template meta-programming craziness, which are not that slow when using the experimental work Microsoft is doing with C++ modules.

Also since our use of C++ is constrained to libraries used from Java/.NET/Android/iOS, the build times are usually relatively fast.

Hard to sell Rust to anyone on the team, if that means their workflow would become slower, in spite of the safety improvements over C++.

Re: Two years of Rust

#242

Post by carllerche »

jadbox wrote: post #216
brandur wrote: post #3

I'm consistently blown away by just how good the project management for this language is. It's not just the forward progress that the language is making (which is considerable), but also just how well they package the information up into a form that the rest of us who are not involved day to day can digest, like has been done here. Another example is the "This Week in Rust" newsletter which takes progress that would'…

Tokio feels like something that needs its own funding and dedicated team... it feels like its development has been slower than what you would expect of a critical (to me) tool for elegantly handling async connections, which is particularly important for web servers.

I'm curious what gives you that impression. What do you think is missing or should be tackled sooner than later? There has been a lot of evolution, however it has all been done in backwards compatible ways so there has not yet been a need to bump the version. It's also spread out across a number of crates.

Re: Two years of Rust

#243

Post by pjmlp »

nickpsecurity wrote: post #234
brandur wrote: post #201

Earlier quoted context omitted.

Oh totally agreed that C++'s compilation times are (quite infamously) a mess. I think that my parent was asserting that Rust's compile times are "usually ... far worse" (the "it" in the quote above is a reference to Rust). For all I know, that might be true, but it's one of those "citation needed" type things.

Maybe I misread as I quickly moved through the thread. It does look ambiguous now. All I'll claim is horrible compile times on C++. I'm not sure where Rust is at now.

On personal projects sadly slower than C++ equivalents.

But I do take advantage of all VC++ improvements for fast C++ compilation, even playing around with the ongoing research work for C++ modules.

Re: Two years of Rust

#244

Post by flukus »

jfoutz wrote: post #240
flukus wrote: post #233

Earlier quoted context omitted.

That assumes you're using cargo and it's "fuck the package manager" approach.

But that's how languages do it. CPAN was my first experience with it. At development time, I need weird libraries.i hope they're ready by release time. Package managers are awesome, but sometimes, fuck them.

Higher level languages get away with it because they are platforms in their own right, rust is meant to be a systems level language. I expect a systems level language to work with the system, not against it.

Re: Two years of Rust

#245

Post by carllerche »

brandur wrote: post #38
ben_jones wrote: post #27

Earlier quoted context omitted.

In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but is interested in learning something lower: C++, Rust, etc.

> In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but is interested in learning something lower: C++, Rust, etc. I think the most classically cited problem is the learning curve. Understanding ownership and lifetimes, and understanding how to satisfy the borrow checker can be quite daunting. Here are a few that I…

The futures underpinning of Tokio actually doesn't have much to do with futures. The task system is really what is special about it (though, currently futures are the main way it is exposed) however, there is a lot of potential other routes that can be explorered. If you want green threads, you could build them on top of the task system and it would interopt with futures.

Re: Two years of Rust

#246

Post by bluejekyll »

flukus wrote: post #233
bluejekyll wrote: post #139

Earlier quoted context omitted.

`cargo check` is pretty darn fast, and that's pretty much all you need while developing. I'd say it's generally 50% faster than a standard compile (not benchmarking, just a gut feeling). On top of that `cargo watch 'test'`, runs fine on a 100kloc project, way better than my personal experience with Java. Now, when Rust compiles all dependencies from the ground up it is really slow, but that's only generally one time…

That assumes you're using cargo and it's "fuck the package manager" approach.

Cargo is a development and build tool, and it's quite possibly the best I've ever used. I don't know of any specific reason it's "fuck the package manager".

Cargo does it's own dependency management, so I assume you mean to say that because of this, it makes it difficult to integrate into standard methods package managers use. After reading some of the email threads with OpenBSD, I do get the sense that it's complex in that situation, but isn't that because of Ports? And Ports' expectations? Most things in Ports are C, right? I haven't worked with Ports in a long time, so I don't know it very well.

If you're pre-building something and pushing a package for say dpkg or rpm, I don't see a problem. If you're packaging source, then you'll need have the rust tools installed on the host to do that, which seems obvious.

After that, I can see some debate about blessing versions of crates in the Rust ecosystem for use in the OS' package manager, but this starts to blur the lines between what the OS is guaranteeing and what is the responsibility of the build tool. Should an OS want to bless crates, cargo does have an override for crates.io: http://doc.crates.io/config.html see the 'registry' section. I believe the other options in that configuration would also be things that the package manager on the OS would want to specify as well.

I haven't done any of this myself, but would be interested in trying to help figure it out if you have specific concerns.

Re: Two years of Rust

#247

Post by pjmlp »

vvanders wrote: post #71
comex wrote: post #42

Earlier quoted context omitted.

Rust's compiler is not fast. At best it can beat C++ compilers - C++ being a language whose build times people love to bemoan - but usually it does far worse. This might change once rustc eventually gets proper incremental compilation (not the codegen-only thing that's currently in beta). Hopefully. Rust doesn't use header files, so in theory it should be possible to leapfrog C++ (at least until C++ gets modules stan…

Oh please, it's plenty fast, at least on par with javac. There's also 'cargo check' which is blazing fast. If you're seeing very large compile time then it's a good sign that you probably want to break things into smaller crates anyway. I've been working on some pretty large stuff and compile speeds haven't been an issue(aside from the Emscripten linker, but that's not Rust's fault).

I wish it would be on par with javac, but my experience compiling rustfmt, rustsym and racer tells me otherwise.

Also a bit disappointed when compared with other languages that support modules, specially the ones whose toolchains support binary dependencies.

Not everyone has a high end development workstation.

I am however confident the experience will eventually improve.

Re: Two years of Rust

#248

Post by pjmlp »

bluejekyll wrote: post #246
flukus wrote: post #233

Earlier quoted context omitted.

That assumes you're using cargo and it's "fuck the package manager" approach.

Cargo is a development and build tool, and it's quite possibly the best I've ever used. I don't know of any specific reason it's "fuck the package manager". Cargo does it's own dependency management, so I assume you mean to say that because of this, it makes it difficult to integrate into standard methods package managers use. After reading some of the email threads with OpenBSD, I do get the sense that it's complex…

My main pet peeve with cargo is lack of support for binary crates.

Compiling the whole world, including dependencies is big waste of time.

I already tried to play around with workspaces to see if at least crates only get compiled once.

With other AOT compiled languages I use, zero third party dependencies are compiled from scratch.

Re: Two years of Rust

#249

Post by pjmlp »

flukus wrote: post #244
jfoutz wrote: post #240

Earlier quoted context omitted.

But that's how languages do it. CPAN was my first experience with it. At development time, I need weird libraries.i hope they're ready by release time. Package managers are awesome, but sometimes, fuck them.

Higher level languages get away with it because they are platforms in their own right, rust is meant to be a systems level language. I expect a systems level language to work with the system, not against it.

So do you enjoy packaging code for every single OS, in its own specific way?

Re: Two years of Rust

#250

Post by executesorder66 »

mmstick wrote: post #45

You might like to know that I've had great success with full stack web development using Rust. My website ( https://mmstick.tk ) is hosted with the Rocket ( https://rocket.rs/overview/ ) web framework and operates as a fully static binary with 100% Rust code. I've even got HTTPS and Brotli compression.

I get a message that says, "Your web browser does not support Brotli, and therefore is not supported. Report this as a bug to your web browser vendor."

I am using Firefox 53.02 on Linux, and my browser is sending this request header:

Accept-Encoding: gzip, deflate, br

As far as I know Firefox fully supports brotli compression. Any idea what is wrong?

Post reply on HN