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

201–210 of 312 posts

Re: Two years of Rust

#201

Post by brandur »

nickpsecurity wrote: post #146
brandur wrote: post #76

Earlier quoted context omitted.

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…

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.

Re: Two years of Rust

#202

Post by Kali909 »

arwhatever wrote: post #115
maplant wrote: post #2

A few years ago I was a C evangelist. C++ was and more so now is a fine language with a lot of features I want. But Rust has that simplicity in a systems language that I crave that lets me do my own thing. That elegence. It's my favourite language by far. Keep it up!

Rust is a simple, intuitive language that just gets out of my way and lets me focus on solving the problem at hand.

I've only dabbled briefly in it and read various articles about the new features, but that hasn't been my very limited experience. The syntax and namespace constructs etc all look quite arcane to me, and then there's the borrow checker. Not sure I'd call it simple and intuitive (at least yet, for me).

Re: Two years of Rust

#203

Post by eridius »

mmstick wrote: post #192
eridius wrote: post #164

Earlier quoted context omitted.

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

mmstick, what part of "I have actually tested this" do you not understand? I am not assuming anything. Please stop skimming my comments looking for things you can try to argue against and actually read the damn things.

> It states right there on both of the pages from Google that I linked to you. Brotli will not work without HTTPS.

Again, you don't understand what you're actually reading. There are two parts to Brotli support. The first is whether the browser will declare that it supports Brotli. This is the Accept-Encoding header. The second is whether the browser will actually correctly interpret a response encoded as Brotli. HTTPS only affects the first part. Chrome only declares to the server that it can accept Brotli when sending an HTTPS request and not when sending an HTTP request. But if the server ignores the Accept-Encoding header and hands back a Brotli response anyway (like your server is doing), Chrome will handle that exactly the same way over HTTP as it does over HTTPS. Because it's just a content encoding, and there is literally no reason to make the code that handles content encodings care about HTTP vs HTTPS.

> Enable HTTPS and pages decode. Switch to HTTP and they do not decode. End of story.

Please try testing this, because I promise you this is wrong. Switch to HTTP and if the server returns a Brotli-encoded response (with the Content-Encoding header set correctly) Chrome will still decode it. The only thing HTTPS controls is the contents of the Accept-Encoding header and not the actual behavior of the response decoder. I have tested this multiple times against Chrome 58.0.3029.110, using both localhost and a remote server. You clearly have not, and in light of this your final sentence is particularly ironic.

Re: Two years of Rust

#204

Post by zzalpha »

derefr wrote: post #137
zzalpha wrote: post #120

Earlier quoted context omitted.

For (most) languages lacking a REPL, it's very similar. Instead of a REPL you write compiled unit tests and/or test programs to poke around at the API. For languages with a reasonably sophisticated IDE, use the IDE itself to jump straight to the class/function declarations to understand the surface area of the API, and jump to the decompiled code for the implementation of those functions if you're the type to want to…

> What's your experience level with other languages? ~15 years experience across C, ARM assembler, Javascript, Lua, Ruby, Python, Erlang, Go, and Rust. Mostly doing Elixir these days. Admittedly, I've never used an IDE; I write all my C in vim. > ...you write compiled unit tests and/or test programs to poke around at the API. That assumes you can get your tests to compile; or that the compilation errors are at-all he…

or rather, a language runtime that enforced some level of introspect-ability on everything

And now we get to the real meat of it.

It's not a REPL you want.

It's reflection.

It just so happens that the latter is frequently paired with the former.

And I agree, that feature, which separates C#, Java, Ruby, Perl, Python, etc, from legacy languages like C make them significantly easier to use as a developer as the compiler, debugger, and IDE can do a much better job.

But as a feature it's orthogonal to a REPL.

Re: Two years of Rust

#205

Post by derefr »

cwzwarich wrote: post #183
derefr wrote: post #173

Earlier quoted context omitted.

A rendering engine is not, itself, a web browser. (You might be thinking of a higher-level component, like Chromium's Embedded Framework? Not the same thing as a rendering engine.) There's certainly a layer of a rendering engine—the part that translates a CSSOM into rendering pragmas—that changes a lot over time. But rendering the resulting pragmas itself doesn't change much, and features requiring new pragmas come a…

I definitely know the difference between a browser and a browser engine; I worked on both WebKit and Servo. There's much more to a browser engine than rendering alone, and rendering isn't even the most complicated part of a browser engine. Outside of rendering and JS there's a steady stream of new DOM APIs, and that's the part that is similar to the "agile user-story kanban".

Yes? It sounds like you're agreeing with me, and disagreeing with your own GP comment. Or maybe I misunderstood the point of your GP comment—it sounded like you were trying to use some sort of metonymy to equate Firefox/browsers in general with Servo, as an implicit counterargument to my GGP post in the sense of "it'd be bad to write a browser in Rust for [reasons you gave]; a rendering engine is part of a browser; a rendering engine thus has the same lifecycle as the browser itself; and thus, a rendering engine is not actually a good example of a good use-case for Rust, despite Mozilla's ambitions. QED."

Clearly, though, you know what a rendering engine is, so I'm not sure what your argument in the GP post was. Was it just a tangential statement (i.e. "rendering engines are well and good, but it'd be silly to write the browser itself in Rust, for [reasons]"), rather than a rebuttal...?

Re: Two years of Rust

#206

Post by mmstick »

eridius wrote: post #191
mmstick wrote: post #179

Earlier quoted context omitted.

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

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

This is just willful ignorance on your part. I have already tested this, and it is partially why I moved towards implementing HTTPS. The web is full of resources to back this up: https://encrypted.google.com/search?hl=en&q=Brotli%20require...

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

You don't seem to understand what you think you understand. Accept-Encoding means that it will not publicly state that it supports Brotli. I wonder why that is..... because Brotli is disabled for HTTP connections. End of story again! Stop beating the dead horse! You are wrong.

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

I don't understand why you think I am. If anything, you are merely trolling and wasting your time.

> You should try actually listening

I've listened and listened, but you aren't speaking anything worth listening to. You yourself refuse to listen to my point of view and explanations, so why should I bother listening to your BS?

> You keep explaining things that are factually wrong or completely irrelevant.

I have done nothing of the sort. You, however, are stating that Brotli works over HTTP. This is factually incorrect. It is not allowed.

http://www.omgchrome.com/brotli-http-compression-coming-to-c...

> Be aware that while the compression algorithm is designed for HTTP content encoding it currently only works over HTTPS.

https://samsaffron.com/archive/2016/06/15/the-current-state-...

> Brotli is HTTPS only > > If you visit a site over HTTP your browser will not accept the br encoding. The reasoning for this is documented at the end of the chromium issue.

https://ayesh.me/apache-brotli

> 'm not sure if there is a technical reason behind this, but all the browsers I tested with require HTTPS in order to enable Brotli support. I have written a small post about more reasons to switch to HTTPS as well.

You are basically calling Google and each of these authors that I've linked as liars as we all have tested Brotli over HTTP and HTTPS and can concur precisely what Google and Mozilla engineers stated: Brotli is only supported with HTTPS!

> And you're going out of your way to break 99% of tools out there for no discernible reason.

First you said it was 40%, and now you are saying it's 99%? Both statistics are bogus given that around 80% of users are using either Chrome or Firefox, and versions that support Brotli!

And going out of my way? I already explained to you how I did not go out of my way. I am not targeting anyone. It was only a few lines of code to change my content cache from being Gzip-backed to Brotli-backed. You just have a persecution complex. I actually had to go out of my way earlier in order to implement a quick error message page for each of my routes because you cried so much about it. But that's all I'm going to give you, an error message.

Here's my advice to you: stop being childish. No matter how many times you are told that you are wrong, with evidence to back it up, you simply ignore it. That's called ignorance. I've repeatedly told you that you're wasting your time with this ignorance. And no matter how many times you demand someone to do something, you can't make them do something they aren't going to do.

Re: Two years of Rust

#207

Post by nickpsecurity »

Keyframe wrote: post #181
nickpsecurity wrote: post #34

Earlier quoted context omitted.

Lol. While we're at it, I guess that makes Adacore and pals pushing Ada the Imperial Army, Ada Division given DOD background.

And I was just about to preach Ada... ffs, man. We're not EVIL just because Death Star's OS is in Ada.

Remember that little hole in the Death Star that blew the whole thing up? It was the C FFI. ;)

Re: Two years of Rust

#208

Post by [deleted] »

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…

[deleted]

Re: Two years of Rust

#209

Post by derefr »

zzalpha wrote: post #204
derefr wrote: post #137

Earlier quoted context omitted.

> What's your experience level with other languages? ~15 years experience across C, ARM assembler, Javascript, Lua, Ruby, Python, Erlang, Go, and Rust. Mostly doing Elixir these days. Admittedly, I've never used an IDE; I write all my C in vim. > ...you write compiled unit tests and/or test programs to poke around at the API. That assumes you can get your tests to compile; or that the compilation errors are at-all he…

or rather, a language runtime that enforced some level of introspect-ability on everything And now we get to the real meat of it. It's not a REPL you want. It's reflection. It just so happens that the latter is frequently paired with the former. And I agree, that feature, which separates C#, Java, Ruby, Perl, Python, etc, from legacy languages like C make them significantly easier to use as a developer as the compile…

Reflection isn't orthogonal to a REPL; it's synergistic with a REPL. When you have a static language, yes, REPLs don't add much; reflection by itself is all you need and an IDE will suit you fine.

But when you are working in a language with runtime code generation—one where objects can build themselves new runtime-native function handles in response to messages—then a REPL will be able to do things for you that an IDE cannot†.

A REPL in a dynamic language (that takes advantage of its dynamicity) can be used to "explore" down CORBA/DBUS object trees; or fluently walk REST or SOAP endpoints without needing pre-baked WSDL descriptors to guide you to them. Heck, an Erlang REPL can hot-upgrade remote nodes. :)

† Or, at least, not a traditional IDE. You would need an IDE connected to a "live session" of your project—essentially a hybrid IDE-REPL. (Examples: Light Table; Emacs' CIDER extension for Clojure.)

Re: Two years of Rust

#210

Post by jacquesm »

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…

You really should stop with the personal attacks.
Post reply on HN