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

191–200 of 312 posts

Re: Two years of Rust

#191

Post by eridius »

mmstick wrote: post #179
eridius wrote: post #134

Earlier quoted context omitted.

Always-on gzip encoding is also technically broken, it's just far more likely to be supported out of the box by other HTTP clients. > What does matter is that my website only supports the HTTPS protocol No, that has literally no bearing on this discussion about your use of Brotli encoding. You're weirdly fixated with this, but it's completely irrelevant. > This is nothing more than pure trolling. Do you normally go o…

> No, that has literally no bearing on this discussion about your use of Brotli encoding. You're weirdly fixated with this, but it's completely irrelevant. https://groups.google.com/a/chromium.org/forum/#!msg/blink-d... > > Important note: Brotli availability is restricted to HTTPS connections. You Cannot Use Brotli Without HTTPS. Chrome does not support this, and Firefox does not support this. The same goes for Edge…

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 could use Brotli compression.

Why do you care so much about this particular compression format?

> Otherwise, Firefox and Chrome will merely get a content encoding error page because br is an unknown encoding format when using HTTP!

You clearly did not test this, because Chrome interprets Brotli responses just fine over HTTP. I wager Firefox does too, but I'm not about to install Firefox just to test.

> You're wrong, and Google engineers are right. End of story.

Google engineers are right, but you are not right. You don't understand what the Google engineers are saying. The link you provided specifically has to do with the Accept-Encoding header and not Brotli support as a whole.

> My target audience consists of Linux users using either Chrome or Firefox.

I still don't understand why you're intentionally breaking the open web. It makes no sense.

> No matter how many times I explain things to you, you never seem to get it through your head.

You should try actually listening. You keep explaining things that are factually wrong or completely irrelevant. You seem to not actually understand HTTP, HTTPS, Content-Encodings, or even the idea of the open web in general. And you're going out of your way to break 99% of tools out there for no discernible reason. Why do you love Brotli so much that you're willing to break HTTP just to use it?

Re: Two years of Rust

#192

Post by mmstick »

eridius wrote: post #164
mmstick wrote: post #141

Earlier quoted context omitted.

> This is completely incorrect. Not only does Brotli have literally nothing to do with the transmission medium and whether it's encrypted, but just to be sure I just tested it and Chrome was perfectly happy to render a Brotli-encoded response over unsecured HTTP. I highly doubt that you actually tried this in practice. You are merely assuming that it works. For Google to overturn their decision would fly against all…

> I highly doubt that you actually tried this in practice. I told you explicitly that I tested it. Now you're calling me a liar. I am not "merely assuming that it works", I actually tested it to the point of controlling the exact bytes that the server sent to the client using a hand-constructed HTTP response and then pointing Chrome at that server. > For Google to overturn their decision … I just looked into the spec…

No, No, and No. Google engineers have repeatedly declared that Brotli requires HTTPS, because they do not allow it's use of HTTP. You cannot use Brotli over HTTP. You are merely assuming that you can. I am stating that you are lying because you can't have it both ways -- either Google engineers are lying about what their software does, or you are lying about what their software does. It states right there on both of the pages from Google that I linked to you. Brotli will not work without HTTPS. I should know as that's one of the main reasons why I moved to implement HTTPS. It's right there in my latest article on my website before I posted it here. Brotli does not work without HTTPS. Enable HTTPS and pages decode. Switch to HTTP and they do not decode. End of story. You're not very bright to continue arguing against this.

Re: Two years of Rust

#193

Post by mmstick »

Franciscouzo wrote: post #122
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.

Your site does not works with Firefox ESR.

That's because ESR is a very ancient version of Firefox. Many things don't work on ESR. You need at least Firefox 52.

Re: Two years of Rust

#194

Post by kibwen »

lumpypua wrote: post #174
kibwen wrote: post #168

Earlier quoted context omitted.

> but usually it does far worse Cite a source? This isn't my experience at all, Rust is still way faster at compilation than C++ on average. The advantage that C++ currently has is ccache which helps avoid needless rebuilds (which pairs well with C++'s smaller compilation units relative to Rust); building this behavior into the compiler is part of what the incremental compilation initiative is addressing.

https://michaelfairley.com/blog/i-made-a-game-in-rust/ > It consists of ~7700 lines of Rust ... > Compile times with Rust are Not Great. This is easily my single biggest gripe about Rust right now. The build for A Snake’s Tale takes 15+ seconds, which makes iterating rather tedious. The current incremental compiler work also doesn’t seem to make the build for A Snake’s Tale’s codebase any faster.

That compile time is Not Great, but 15 seconds for 7700 lines of code isn't even close to "far worse than C++". :P If incremental compilation is showing no benefits whatsoever, then I'm guessing that time is largely attributable to linking (and I tend to doubt that 7700 lines of code is counting the basic third-party libraries that are required to create a crossplatform GUI app (but I'd love to be surprised!), which will contribute to linkage time... LLD please!).

Re: Two years of Rust

#195

Post by mmstick »

jacquesm wrote: post #185
mmstick wrote: post #160

Earlier quoted context omitted.

I highly doubt that anyone depends upon a personal blog for food.

So there's your answer: you really don't care. I also don't depend on my blog for food. But I do care and if this were a customer project or something commercial you'd be dead in the water. That's a friendly way of saying that your opinion on what is 'standard' really doesn't count for much with me. You've polluted this thread with I don't know how many comments essentially shouting down each and every patient and re…

Maybe you can explain to me why I am supposed to cater to other's whims as if my personal blog was a commercial project. It's not. Nobody is trying to teach me things here. They are simply demanding that I do what I have already clearly expressed that I am not going to do. This is my personal blog, not yours. I get to set the rules, not you. Perhaps you can take a hint and not demand others to do things for you even after they've expressed that they don't want to? If anyone is polluting the thread, it's your kind. Snarky, combative, argumentative, and ignorant. If you want to be an asshole, you'll get what you ask for from me.

Re: Two years of Rust

#196

Post by Manishearth »

derefr wrote: post #158
Manishearth wrote: post #148

Earlier quoted context omitted.

Note that with strong typing this is less of an issue -- with Rust you can just go to " rel="nofollow">http://docs.rs/ and navigate the structured docs. They may lack explanatory text, but you can click around them and search and it's overall much nicer than fiddling around in a REPL. (Still, doesn't fit all use cases of a REPL for this. REPLs are especially nice for when you want to fit together highly generic APIs)

True; but also, "strong typing" on its own isn't a panacea for guidance; unless you're writing Coq or Agda, the API functions you're calling are still going to have preconditions that are not encoded in the type signature, so you're still (partially) reliant on having either good docs or a REPL [or clumsy REPL-equivalent, like exploratory unit tests] to inform you of those preconditions. And if you are writing Coq or…

Yeah, like I said, doesn't fit all use cases, but it does fit the primary one.

Re: Two years of Rust

#197

Post by kibwen »

steveklabnik wrote: post #31
cwzwarich wrote: post #30

Earlier quoted context omitted.

What are these implementations? The one I immediately found by searching ( https://github.com/thepowersgang/mrustc ) is accompanied by an explicit nongoal to correctly implement the language. It also doesn't seem particularly independent from rustc, given the similarities in implementation strategy and the fact that some parts look like rustc code converted to C++.

Mrustc is one; my understanding is that it isn't yet , because its purpose in life is to make bootstrapping/ddc stuff easier. Once that works, I thought it intended to add the stuff that's missing. There's another that's not public.

> ddc stuff

Note: this refers to "Diverse Double Compilation", which is a mitigation tactic against Reflections-on-Trusting-Trust attacks.

Re: Two years of Rust

#198

Post by kbenson »

kibwen wrote: post #175
cwzwarich wrote: post #169

Earlier quoted context omitted.

> (Which makes sense, given that Mozilla's Servo rendering engine also has the goal of being that kind of software.) Web browsers are not that kind of software. The web is evolving much faster than any of the other things you mentioned. New features get proposed every year, and you just have to deal with it and implement them, even if they complicate the implementation of the browser. Even if you cut that off, you st…

So we're in agreement that we should reimplement Chrome in Perl, then. :)

As a Perl programmer I'm not sure whether to laugh or cry. ;)

Re: Two years of Rust

#199

Post by kibwen »

Manishearth wrote: post #155
Animats wrote: post #72

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?

The dropbox stuff isn't a mix of Rust and C/C++, it's a mix of Rust and Go[1]. (Dropbox has a variety of things using Rust, and IIRC some of them are pure Rust. I don't remember the details.) [1]: https://news.ycombinator.com/item?id=11283758

The OP seems to be mostly referring to the integration with Dropbox's Windows client, which AFAIK is actually Rust+Python. Rust+Go is what Dropbox uses for their storage backend.

I personally love that Rust is getting used to complement so many other languages (e.g. Rust's first known production use was as part of a Ruby gem). Easy integration is something to be celebrated, because it means you don't need to rewrite the whole world to get benefits.

Re: Two years of Rust

#200

Post by kbenson »

nickpsecurity wrote: post #151
derefr wrote: post #116

Earlier quoted context omitted.

Why must productivity be measured in "smallest amount of time to write your feature"? Why not in "smallest Total Cost of Ownership [in man-hours] of the feature over the project lifecycle"? Some projects are written as explorational prototypes or MVPs. I don't think anyone is saying Rust is much good for those. But (numerous) other projects are written as "the first real Quality implementation of [well-known problem]…

"Why must productivity be measured in "smallest amount of time to write your feature"? Why not in "smallest Total Cost of Ownership [in man-hours] of the feature over the project lifecycle"?" In the case of startups, their goal is to sell out way before the maintenance phase of the lifecycle. So, it doesn't really matter to them so much as quickly getting out working features. In other cases, esp long-lasting endeavo…

> In the case of startups, their goal is to sell out way before the maintenance phase of the lifecycle.

Or grow so quickly that replacing most the legacy code from a year or two ago is not a significant hurdle at their new size.

In this vein, I wonder if there's actually a third path that might be better than both. Using a low-level but fairly expressive and strongly typed language but very loosely, such that it allows you to iterate fact but with less performance, and you can come back later and replace chunks as needed, but with the same language. I don't have any real experience with that, and I could see it going either way for a number of reasons, but it seems like we have more languages that might fit that criteria now (or at least they are more popular now) than we have previously.

Post reply on HN