Two years of Rust • Hacker News Board

Re: Two years of Rust

#211

Post by eridius » Tue, May 16, 2017, 2:16 AM UTC

mmstick wrote: post #206

eridius wrote: post #191

Earlier quoted context omitted.

I already explained this in another comment almost an hour ago ( https://news.ycombinator.com/item?id=14346188 ). Brotli works perfectly fine over HTTP. The only difference between HTTP and HTTPS here is Chrome does not include "br" in the Accept-Encoding header for HTTP. But it will still handle a Content-Encoding of "br" just fine over HTTP. > One of the major reasons for me moving my website to HTTPS is so that I…

Brotli does not work over HTTP. Period. It doesn't work, and you have yet to prove that it works. I am not the only person who can provide proof that it will not work. It clearly states it on the Google URLs that I sent you that it does not work without HTTPS, along with some reasons as to why that decision was made. You are, instead, trying to argue in face of reality. That is foolish. > You clearly did not test thi…

> Brotli does not work over HTTP. Period. It doesn't work, and you have yet to prove that it works.

I really do not appreciate you continually calling me a liar (since I've told you in no uncertain terms that I personally have tested this behavior), especially since all you're doing is an appeal to authority ("Google engineers!") based on a misunderstanding of the issue at hand. You keep claiming you have "evidence", but all your "evidence" proves is that you need to work on your reading comprehension skills, because those pages do not say what you think they say.

> You are basically calling Google and each of these authors that I've linked as liars

Let me try this again:

YOU DO NOT UNDERSTAND THIS ISSUE. YOU DO NOT UNDERSTAND HOW CONTENT ENCODINGS WORK OR WHAT EFFECT HTTPS HAS ON BROTLI. I AM NOT CALLING THEM LIARS, I AM CALLING YOU INCREDIBLY IGNORANT.

I am done with this conversation. I am not going to respond to any more of your comments. You don't understand basically any part of what's going on here, but you think you do and you won't even acknowledge the possibility that you are wrong. You're also misinterpreting nearly everything I say, because you're not actually reading my damn comments, you're just skimming them looking for things you can argue against. Case in point, your sentence that starts with "First you said it was 40%"; I was talking about tools that speak HTTP, which was extremely clearly from context, and you're completely misinterpreting that as browsers, and what's more you're even putting words in my mouth (literally nowhere did I say 40%).

Re: Two years of Rust

#212

Post by swsieber » Tue, May 16, 2017, 2:19 AM UTC

WatchDog wrote: post #91

vvanders wrote: post #71

Earlier quoted context omitted.

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

Is it as fast as javac? Maybe on a line of code basis, but I imagine java is much simpler to to implement incremental compilation with. Since sources map pretty much 1 to 1 with classes, you mostly only need to recompile the class that changed.

Unfortunately, it's not quite that easy since java inlines constants, plus you have to account for package protected, inherited methods, etc. that you don't have to implicitly import. But really, it's the constants that make incremental compilation slower...

Re: Two years of Rust

#213

Post by amorphid » Tue, May 16, 2017, 2:21 AM UTC

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

When you compile Java from the command line, is the compiler smart enough to not recompile files that haven't changed? Or is that an IDE feature?

Re: Two years of Rust

#214

Post by dang » Tue, May 16, 2017, 2:21 AM UTC

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.

We detached this ludicrous flamewar from https://news.ycombinator.com/item?id=14344760 and marked it off-topic.

You repeatedly posted uncivilly in these comments. That's a bannable offense on HN, so please don't do it again, regardless of how wrong you think others are.

Re: Two years of Rust

#215

Post by dang » Tue, May 16, 2017, 2:30 AM UTC

eridius wrote: post #211

mmstick wrote: post #206

Earlier quoted context omitted.

Brotli does not work over HTTP. Period. It doesn't work, and you have yet to prove that it works. I am not the only person who can provide proof that it will not work. It clearly states it on the Google URLs that I sent you that it does not work without HTTPS, along with some reasons as to why that decision was made. You are, instead, trying to argue in face of reality. That is foolish. > You clearly did not test thi…

> Brotli does not work over HTTP. Period. It doesn't work, and you have yet to prove that it works. I really do not appreciate you continually calling me a liar (since I've told you in no uncertain terms that I personally have tested this behavior), especially since all you're doing is an appeal to authority ("Google engineers!") based on a misunderstanding of the issue at hand. You keep claiming you have "evidence",…

> You are an ignorant fool.

That is a serious breach of HN's civility rule and the sort of thing we ban people for. When someone is provocatively repeating wrong statements (or appears to be) and is getting increasingly rude, the way to deal with that is not to lose your own cool, it's to realize that there's no win in this and just leave it.

A.k.a. don't feed the trolls, it takes two to tango, two wrongs don't make a right, and sundry other things our mothers told us.

Re: Two years of Rust

#216

Post by jadbox » Tue, May 16, 2017, 2:31 AM UTC

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.

Re: Two years of Rust

#217

Post by dang » Tue, May 16, 2017, 2:33 AM UTC

mmstick wrote: post #206

eridius wrote: post #191

Earlier quoted context omitted.

I already explained this in another comment almost an hour ago ( https://news.ycombinator.com/item?id=14346188 ). Brotli works perfectly fine over HTTP. The only difference between HTTP and HTTPS here is Chrome does not include "br" in the Accept-Encoding header for HTTP. But it will still handle a Content-Encoding of "br" just fine over HTTP. > One of the major reasons for me moving my website to HTTPS is so that I…

Brotli does not work over HTTP. Period. It doesn't work, and you have yet to prove that it works. I am not the only person who can provide proof that it will not work. It clearly states it on the Google URLs that I sent you that it does not work without HTTPS, along with some reasons as to why that decision was made. You are, instead, trying to argue in face of reality. That is foolish. > You clearly did not test thi…

The bulk of the responsibility for this ludicrous flamewar is yours. You became increasingly uncivil and spatty in this thread, and proliferated reams of tit-for-tat filler.

This is the sort of argument that gets a few combatants hot and bothered and clogs up the site with tedium for everyone else. We ban accounts that do this, so please make sure it doesn't happen again. HN threads are for good conversation, and there's no worse conversation than this kind of bickering.

Re: Two years of Rust

#218

Post by dang » Tue, May 16, 2017, 2:41 AM UTC

zzalpha wrote: post #64

dwaltrip wrote: post #61

Earlier quoted context omitted.

I didn't say it was a deal breaker? Your post came off as implying REPLs don't have serious benefits for anyone, which felt a bit presumptuous to me.

Yup, that's fair. BTW, I actually stand by your interpretation. I challenge anyone to demonstrate significant productivity gains (as measured by number of lines of tested, production code written) that can be attributed to the availability of a REPL (which was the claim of the poster I was replying to). I honestly don't buy it. I believe it's a very nice tool for learning a new language, and maybe for exploring an ex…

You're demanding the impossible here and elsewhere in the thread. Asking for the impossible is maybe ok, demanding it not so much.

No one can demonstrate productivity gains because productivity can't be measured. Lines of code can, and those are often a bad thing. Some of our most productive efforts make programs smaller.

Re: Two years of Rust

#219

Post by eridius » Tue, May 16, 2017, 2:42 AM UTC

dang wrote: post #215

eridius wrote: post #211

Earlier quoted context omitted.

> Brotli does not work over HTTP. Period. It doesn't work, and you have yet to prove that it works. I really do not appreciate you continually calling me a liar (since I've told you in no uncertain terms that I personally have tested this behavior), especially since all you're doing is an appeal to authority ("Google engineers!") based on a misunderstanding of the issue at hand. You keep claiming you have "evidence",…

> You are an ignorant fool. That is a serious breach of HN's civility rule and the sort of thing we ban people for. When someone is provocatively repeating wrong statements (or appears to be) and is getting increasingly rude, the way to deal with that is not to lose your own cool, it's to realize that there's no win in this and just leave it. A.k.a. don't feed the trolls, it takes two to tango, two wrongs don't make…

I've deleted the offending line. But I admit to being a little surprised that "ignorant fool" is considered a serious breach. That honestly seems fairly tame to me. I was looking for a phrase that meant that not only are they ignorant, but they're either unwilling or unable to recognize this. But I suppose I can believe that other people may read more into the phrase that I intended.

Re: Two years of Rust

#220

Post by dang » Tue, May 16, 2017, 2:48 AM UTC

eridius wrote: post #219

dang wrote: post #215

Earlier quoted context omitted.

> You are an ignorant fool. That is a serious breach of HN's civility rule and the sort of thing we ban people for. When someone is provocatively repeating wrong statements (or appears to be) and is getting increasingly rude, the way to deal with that is not to lose your own cool, it's to realize that there's no win in this and just leave it. A.k.a. don't feed the trolls, it takes two to tango, two wrongs don't make…

I've deleted the offending line. But I admit to being a little surprised that "ignorant fool" is considered a serious breach. That honestly seems fairly tame to me. I was looking for a phrase that meant that not only are they ignorant, but they're either unwilling or unable to recognize this. But I suppose I can believe that other people may read more into the phrase that I intended.

Dr. Dang recommends full recalibration of your internet provocation meter. "Ignorant fool" is well into the red!