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

71–80 of 312 posts

Re: Two years of Rust

#71

Post by vvanders »

comex wrote: post #42
brandur wrote: post #10

Earlier quoted context omitted.

> Not being hindered by the compiler telling you what you can and can't do; freeing yourself from the write-compile-debug cycle, reducing it to repl-done; etc. Yeah, I certainly understand various language trade-offs, but in my experience any of these early wins of interpreted languages come back to haunt you at significant cost. I saw someone use the analogy of a credit card on here before: purchases are very easy t…

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

Re: Two years of Rust

#72

Post by Animats »

The success stories are Mozilla's Servo, Dropbox's client and back end, and parts of Gnome. That's good. It's interesting that all the success stories involve mixing Rust and C/C++ code. Are there any pure Rust successes yet?

Re: Two years of Rust

#73

Post by kccqzy »

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.

When you are presenting a site saying it's a "great success," perhaps it doesn't help that it breaks in 40% of browsers.

Re: Two years of Rust

#74

Post by eridius »

mmstick wrote: post #70
eridius wrote: post #67

Earlier quoted context omitted.

I'm not saying you should support gzip. I'm saying you're sending Brotli-encoded data even when the browser doesn't support it, which results in the browser showing what looks like effectively random bytes. You need to respect the Accept-Encoding header.

That would require that I cache both a gzip and brotli variant of each page and content that is requested. I see no reason to support gzip just because a single company has refused to implement support for Brotli. Firefox, Chrome and Edge all support Brotli. Safari is the one man out. Apple needs more complaints about the lack of Brotli in Safari. Using Safari? Don't. You have Firefox and Chrome on all of your platfo…

This is an incredibly user-hostile attitude.

Also, you don't seem to understand. I'm not telling you to support gzip. If the browser doesn't support Brotli, then just send back uncompressed content.

And it's not just Safari. All sorts of tools that support HTTP don't support Brotli. Case in point, I ran `curl` against your page and got garbage back.

Re: Two years of Rust

#75

Post by steveklabnik »

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

"rustc is too slow" is possibly our most commonly-heard feedback. I am glad that you don't find it onerous, but many still do.

Re: Two years of Rust

#76

Post by brandur »

comex wrote: post #42
brandur wrote: post #10

Earlier quoted context omitted.

> Not being hindered by the compiler telling you what you can and can't do; freeing yourself from the write-compile-debug cycle, reducing it to repl-done; etc. Yeah, I certainly understand various language trade-offs, but in my experience any of these early wins of interpreted languages come back to haunt you at significant cost. I saw someone use the analogy of a credit card on here before: purchases are very easy t…

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…

I was partly relying on the context offered by the article and my parent comment to imply that sure, Rust's compiler isn't the fastest in class, but the team has identified speed as a major outstanding problem and is working very actively to address it.

Compilers are pretty hard. Languages like C and Go are able to short circuit the problem by having a simplistic type system, but the Rust team's main option here is hard work, and so far they seem to be more than willing to engage in it.

> At best it can beat C++ compilers - C++ being a language whose build times people love to bemoan - but usually it does far worse.

Citation needed on that one. How can you even make that kind of comparison fairly?

Re: Two years of Rust

#77

Post by gue5t »

mmstick wrote: post #69
kcorbitt wrote: post #62

Earlier quoted context omitted.

If I were focused so unapologetically on purity over pragmatism at the expense of playing nice with the wider web ecosystem, I would perhaps think twice before holding my site up as a positive example of the state of web development with Rust. You may end up doing more harm than good in the PR department. :)

I see it as more of an Apple problem. Everyone else's web browser works fine, but Apple's doesn't. The main reason why companies like Apple still don't support Brotli even though the competition has supported it for more than a year now is because too many sites are focused on carrying legacy support for unsupported platforms like Safari. If more sites dropped support for legacy software, Apple would be forced to imp…

GNOME's, Xfce's, suckless', and many other web browsers are based on Webkit (WebKit2GTK+ or other ports) as well, and as far as I know none of them yet support brotli.

wget and curl both also fail to decompress your site's contents.

Same problem in netsurf, lynx, and links.

Re: Two years of Rust

#78

Post by sillysaurus3 »

tatterdemalion wrote: post #63
sillysaurus3 wrote: post #49

Earlier quoted context omitted.

I tend to agree, but being able to have a REPL at all is a symptom that your language is capable of an extremely fast compile-run-debug cycle. In other words, if you can't implement a REPL, that's the definition of "less productive language." It's not about the REPL itself but the capability of implementing one. Think about it like this: On your list of languages, which of them would you say is most productive? It de…

> Is the Rust community claiming that the entire history of computing has lead up to this point, where Rust exists, and now nobody needs to write anything in not-Rust? Are people 200 years from now going to write Rust and nothing else? Let's be clear - the person who said there'd be no reason to write in anything else is an enthusiastic Rust user, but they don't work on Rust & don't represent "the Rust community." Th…

Let's be clear - the person who said there'd be no reason to write in anything else is an enthusiastic Rust user, but they don't work on Rust & don't represent "the Rust community."

Respectfully, the community has become increasingly vocal, and it's getting hard to separate the enthusiasm from realism. It's embedded in every HN thread. That's a good problem to have, but it can be a bit repellant to people who aren't Rust converts.

Thanks for the breakdown and future roadmap. I hope the compile times can be kept to a minimum in order to avoid C++'s fate.

Re: Two years of Rust

#79

Post by eridius »

mmstick wrote: post #69
kcorbitt wrote: post #62

Earlier quoted context omitted.

If I were focused so unapologetically on purity over pragmatism at the expense of playing nice with the wider web ecosystem, I would perhaps think twice before holding my site up as a positive example of the state of web development with Rust. You may end up doing more harm than good in the PR department. :)

I see it as more of an Apple problem. Everyone else's web browser works fine, but Apple's doesn't. The main reason why companies like Apple still don't support Brotli even though the competition has supported it for more than a year now is because too many sites are focused on carrying legacy support for unsupported platforms like Safari. If more sites dropped support for legacy software, Apple would be forced to imp…

Have you filed a bug report asking Apple to support Brotli (https://bugreport.apple.com)?

And it's not just Safari. I think it's safe to say the overwhelming majority of software that issues HTTP requests does not support Brotli. And you're also not following the HTTP spec. Safari sends the Accept-Encoding header with a value of "gzip, deflate". If you're unwilling to support either of those, and unwilling to return an uncompressed response, then you SHOULD return a 406 (Not Acceptable) instead of just blindly returning Brotli-encoded data to a client that doesn't understand it.

Re: Two years of Rust

#80

Post by zambal »

zzalpha wrote: post #43
sillysaurus3 wrote: post #40

Earlier quoted context omitted.

Yeah, I certainly understand various language trade-offs, but in my experience any of these early wins of interpreted languages come back to haunt you at significant cost. If you understood the wins of untyped languages, you'd be aware that this is often the most optimal path for a startup to take. Get features done now + fix them later is, in hundreds of cases, the way that startups win. It's also a win for people w…

If your language doesn't have a REPL, your language is less productive. Deal with it. Oh hardly. As someone who's developed software in Perl, Python, C, Java, C#, Haskell, and a few others besides, a REPL is the one thing I use the least . I've honestly never understood the obsession with it. Is a rapid compile-run-debug cycle important? Absolutely. If I want to test something in isolation, being able to rapidly turn…

The usefulness of a REPL depends a lot on the language/interpreter/vm. In Erlang and Elixir the REPL is more than nice to have. Being able to connect to a production node and peeking around what is happening can be very valuable.

I guess it's one of those things that's imho hard to appreciate if you never experienced it.

Post reply on HN