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

141–150 of 312 posts

Re: Two years of Rust

#141

Post by mmstick »

eridius wrote: post #113
mmstick wrote: post #104

Earlier quoted context omitted.

I'm not sure where your confusion is. It doesn't matter that HTTPS is an encrypted form of HTTP. I do not support HTTP, which means that I do not support HTTP without encryption! End of story. Attempting to access the site via HTTP will merely redirect you to the HTTPS service. Nothing is being hosted on the HTTP service. When you reach the HTTPS service, your browser will receive a HSTS header that will cause your w…

Your use of HTTPS is completely irrelevant here, but I've already addressed that in the other thread ( https://news.ycombinator.com/item?id=14345695 ). > You cannot use Brotli compression over HTTP. 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 Bro…

> 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 reasoning for the decision in the first place.

> My best guess here is you've confused HTTP/2 (which requires SSL) with Brotli encoding.

You seem to not have any experience with Brotli support and why the decision was made to only support it over HTTPS. One such comment that outlies the reasoning is from a Google employee themselves ( https://bugs.chromium.org/p/chromium/issues/detail?id=452335... ).

Hence, all vendors have followed suit and are not implementing brotli for HTTP. SSL prevents all the middle man infrastructure in place from employing such tactics that would break websites serving content with the br content encoding. There still exists much infrastructure in place that snoops HTTP traffic and, when it is detected that the content encoding is an unknown format (brotli), it will compress the stream with gzip and change the content encoding to gzip, thus breaking the website.

In addition, yet again, Google engineers clearly state that Brotli support is only available over HTTPS connections!

https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...

One of the big reasons for my decision in pursuing HTTPS support on my personal blog was so that I could, in fact, use Brotli. I already had the code in place, but enabling Brotli on my web server would merely give errors about the content encoding being unknown, and as you will notice, br is missing from the list of available accepted encodings by the browser! Yet it is there when connecting via HTTPS! That's because Brotli is completely and utterly disallowed over HTTP! Google engineers stated it themselves. You can't have it both ways.

Re: Two years of Rust

#142

Post by fnord123 »

vvanders wrote: post #121
hyperpape wrote: post #110

Earlier quoted context omitted.

Is this based on benchmarks? I don't have any, but I can do a clean compile of 8000 java classes (> 2 million lines) in 3 minutes on my underpowered Mac mini. I wouldn't expect Rust would ever be as fast to compile, even if it weren't a younger language, because Rust is doing compile time optimization that Java defers until runtime. And that's ok: there may be times what Java does is better, but there are also times…

Mostly gut feeling :). To be fair my javac comparison with with Gradle + Android Studio layered on top so it may be a bit slanted in favor of Cargo/Rust. That said I've never seen a Java build environment that I'd call 'snappy'.

Maven takes a long long time to start up, but once it's ready, javac is pretty quick.

Some Rust projects are very quick to build; but some are astonishingly slow to build. e.g. lalrpop is unusably slow (~15mins to build on 2014 Macbook Air).

I think the place here performance breaks down is liberal use of generic types in functions. e.g. AsPath and AsRef, etc.) where the compiler creates the function for all the different types and then tries to collapse them again later on. So one rules of thumb is to only use those in the public APIs and convert the type so it can be passed around without generics internally within a module. Or maybe that's just me trying to do some `cargo cult` heuristics (haha! puns!)

Re: Two years of Rust

#143

Post by nickpsecurity »

fizixer wrote: post #133
nickpsecurity wrote: post #4

Earlier quoted context omitted.

Simplicity? Modula-3 was simple, fast, and safe. PreScheme was less type-checked but powerful and simple. You can learn how to use them in a day coming from an imperative or functional language. Rust looks like it gives users extra power/safety with quite a bit of a learning curve (most say weeks to months) due to extra complexity. Definitely not simple, though. https://en.m.wikipedia.org/wiki/Modula-3 https://en.m.w…

Looking at Modula-3 wikipedia page, no thanks. (If it's case-sensitive, I don't want to switch to uppercase everytime I use the language keywords. If it's not case-sensitive, don't even get me started.) I had enough of that for a lifetime through FORTRAN, COBOL, SQL, BASIC, ASSEMBLY, etc. PreScheme sounds like an interesting idea.

Do you have anything to say about it's feature set instead of just syntactic preference? As in, it's tradeoff in balancing complexity by what set of features?

Re: Two years of Rust

#144

Post by jacquesm »

mmstick wrote: post #88
eridius wrote: post #79

Earlier quoted context omitted.

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 retur…

I don't use Apple products, nor am I user of Safari. It's not in my interest to request for Brotli support in products that I do not use. > 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. Again, I do not support HTTP! The website is HTTPS-exclusive. HTTP is basically a legacy protocol at this point. Every we…

I'll bet if your food depended on that 40% you'd fix it in a heartbeat.

Re: Two years of Rust

#145

Post by mmstick »

kbenson wrote: post #125
mmstick wrote: post #98

Earlier quoted context omitted.

All vendors do not support Brotli compression with the HTTP protocol. Brotli is only supported when accessing a site through HTTPS. Moreover, as Brotli compresses and decompresses faster than Gzip, whilst simultaneously producing smaller file sizes, there is no point in using anything other than Brotli for HTTPS website. Hence, it's the standard compression algorithm for HTTPS. All web vendors support Brotli w/ HTTPS…

> Hence, it's the standard compression algorithm for HTTPS. I think you're mistaken "de-facto standard" for "standard". They are not the same thing, and whether brotli actually is a de-facto standard is debatable, but it's not the standard. It's perfectly acceptable to do whatever you want with your own web stack and application. You wouldn't be getting much pushback if you simply justified it as "It's what I want to…

> You wouldn't be getting much pushback if you simply justified it as "It's what I want to do"

Actually, if you look at the top level comments that I've made, that's exactly what I said. What I'm getting in response to that is that I'm basically 'breaking the web' because I don't want to comply with sniffing request headers and offering gzip to Apple WebKit users. If I don't care about supporting your web browser, then I don't care about supporting your web browser. You can't make me.

> Also, it should be noted that there is a valid reason to eschew compression for HTTPS on the client side, and that's security. Compression of HTTPS channels opens up the possibility for a few more forms of attack on the encrypted data.

That kind of security isn't a concern to me. Not having compression at all would take a larger toll on my bandwidth, and increase latency of page delivery. Bandwidth isn't free.

Re: Two years of Rust

#146

Post by nickpsecurity »

brandur wrote: post #76
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…

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 h…

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 more flexibility compile faster than C++ due to better design.

Re: Two years of Rust

#147

Post by breerly »

Curious, since I haven't been following closely - is Tokio fit for both IO and CPU-bound work, or do you need to break into threads?

I use Golang daily, and have been spoiled by the opinionated approach taken to solving both CPU and IO-bound workloads.

Re: Two years of Rust

#148

Post by Manishearth »

derefr wrote: post #99
zzalpha wrote: post #43

Earlier quoted context omitted.

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…

> I've honestly never understood the obsession with it. The true key to understanding REPLs is their role in consuming third-party libraries. While languages both with and without REPLs will have well-used packages in their package ecosystems that are well-documented ; languages with REPLs will also manage to have well-used, poorly-documented packages: packages whose "documentation" consists only of the de-facto abil…

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)

Re: Two years of Rust

#149

Post by wtetzner »

fnord123 wrote: post #142
vvanders wrote: post #121

Earlier quoted context omitted.

Mostly gut feeling :). To be fair my javac comparison with with Gradle + Android Studio layered on top so it may be a bit slanted in favor of Cargo/Rust. That said I've never seen a Java build environment that I'd call 'snappy'.

Maven takes a long long time to start up, but once it's ready, javac is pretty quick. Some Rust projects are very quick to build; but some are astonishingly slow to build. e.g. lalrpop is unusably slow (~15mins to build on 2014 Macbook Air). I think the place here performance breaks down is liberal use of generic types in functions. e.g. AsPath and AsRef , etc.) where the compiler creates the function for all the dif…

> Or maybe that's just me trying to do some `cargo cult` heuristics (haha! puns!)

I always thought `cargo new` should have been called `cargo cult`.

Re: Two years of Rust

#150

Post by nickpsecurity »

sillysaurus3 wrote: post #40
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…

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

I think what you really want here is fast compiles and iterations. You can do that without a REPL if using a language that compiles ultra-fast. Industrial BASIC's I used a long time ago compiled in a split second with me seeing the results immediately. Wirth-style languages tend to be able to do that. I hear Go compiles really fast. The wait doesn't really matter at that speed. Highly-optimized, slower compiles and tests can run overnight in background on dedicated machine, too.

Post reply on HN