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

121–130 of 312 posts

Re: Two years of Rust

#121

Post by vvanders »

hyperpape wrote: post #110
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 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'.

Re: Two years of Rust

#122

Post by Franciscouzo »

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.

Re: Two years of Rust

#123

Post by derefr »

oblio wrote: post #109
derefr wrote: post #99

Earlier quoted context omitted.

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

Many languages have good IDE support, which is basically REPL on steroids.

True, though "good IDE support" in the sense you're talking about (i.e. being able to discover an API through the IDE) mostly relies on strong typing in the language. (Non-inferred) type declarations are their own form of documentation, with a similar effect on likelihood of a "marginal" ecosystem package getting written.

Re: Two years of Rust

#124

Post by sqeaky »

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…

What about serving uncompressed content over https?

What about serving up an error page when the user's browser odesn't have compressor you support?

What about paying attention to web standards?

What about people who are stuck with old software for one reason or another?

Re: Two years of Rust

#125

Post by kbenson »

mmstick wrote: post #98
detaro wrote: post #92

Earlier quoted context omitted.

> the standard compression algorithm for HTTPS That's utter nonsense.

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 do", but you are providing evidence that is factually incorrect, where no evidence is really required.

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.

Re: Two years of Rust

#126

Post by [deleted] »

derefr wrote: post #123
oblio wrote: post #109

Earlier quoted context omitted.

Many languages have good IDE support, which is basically REPL on steroids.

True, though "good IDE support" in the sense you're talking about (i.e. being able to discover an API through the IDE) mostly relies on strong typing in the language. (Non-inferred) type declarations are their own form of documentation, with a similar effect on likelihood of a "marginal" ecosystem package getting written.

[deleted]

Re: Two years of Rust

#127

Post by infogulch »

kbenson wrote: post #35
comex wrote: post #18

Earlier quoted context omitted.

Go, at least, is far simpler as a language than Rust, and the implementation (compiler) is less complex overall, especially if you count LLVM on Rust's side. I suppose that Go programs exhibit more complex behavior at runtime due to the GC and green threads and stuff, but it's a huge stretch to call Go more complicated overall. On the other hand, I'd argue that Rust makes up for the complexity with performance, power…

> I suppose that Go programs exhibit more complex behavior at runtime due to the GC and green threads and stuff Given the GP's note about the connection between written and compiled code and how a GC affects that, I think this is exactly what is being referred to. I.e. a GC makes everything much simpler up until it doesn't, and then it makes it much more complicated. That point may never be reached in many programs,…

> GC makes everything much simpler up until it doesn't, and then it makes it much more complicated

I would say that's true in general, but in Go there's a lot more room to ask the GC to get out of your way if you need that than most.

Re: Two years of Rust

#128

Post by lacampbell »

brandur wrote: post #114
lacampbell wrote: post #106

Earlier quoted context omitted.

Having so few constraints on implementation (e.g. duck typing) was an interesting concept, but time has proven it to be a nightmare maintainability. Citation needed. Just because static typing is has been more fashionable for the past 10 years, doesn't mean it's a closed case. Before that people were extolling the virtues of dynamic languages. Some people deciding they prefer static typing doesn't constitute some kin…

Yes, I can't prove it. There's no quantitative way of doing so. I've worked with very big duck typed codebases for quite a few years now (and largely statically typed in C# before that) and the above is my opinion. Duck typing is convenient early on, but it makes understanding code (especially where it gets complicated or you didn't write it) quite difficult, and any kind of refactoring downright scary. After a point…

I don't understand how (1) isn't a positive in your eyes. (2) is true for pretty much every large statically typed codebase I've worked on.

I'll admit, my commercial experience has all been in statically typed languages. But there are a lot of complex, well written pieces of software written using dynamic types. Maybe you don't meet their proponents, but they do exist.

FWIW, I quite like static typing, but I consider it a feature, not a religion.

Re: Two years of Rust

#129

Post by mmstick »

eridius wrote: post #112
mmstick wrote: post #107

Earlier quoted context omitted.

> You've already positioned yourself as trying to take a principled stand against software that doesn't support Brotli in the hopes of convincing the software authors to add support for Brotli. Now you're saying you don't care whether software you don't use supports Brotli. These two positions contradict each other, and if you really don't care about software you don't use, then why are you so dead set against servin…

> That I do not support web browsers that don't support Brotli should already tell you that I don't care if they support Brotli or not! If there is no support, there is no support! Doesn't effect me. You had to go out of your way to break support for these browsers. Literally every HTTP package (including Rocket) out of the box handles uncompressed responses. You had to modify it to add always-on Brotli encoding. > I…

> You had to go out of your way to break support for these browsers. Literally every HTTP package (including Rocket) out of the box handles uncompressed files. You had to modify it to add always-on Brotli encoding.

I did not have to go out of my way to 'break support for these browsers'. All I did was replace the gzip-compression code in my page cacher with brotli-compression code. In other words, I went from always-on Gzip encoding to always-on Brotli encoding! I have never supported serving uncompressed files! The web browsers I care about (Firefox, Chrome) support Brotli, and that's all I care about! There is no purposeful breaking of web browsers. That's just persecution complex talk.

> Why do you keep repeating this? That's completely irrelevant to the discussion at hand. Nothing about this discussion has anything to do with whether or not the HTTP protocol is wrapped in SSL.

You're the one that keeps bringing up that the only difference between HTTP and HTTPS is that HTTPS is HTTPS with SSL. I am merely responding to your comment that your comment about them doesn't matter! What does matter is that my website only supports the HTTPS protocol, not HTTP. The web server only listens on port 443 with TLS enabled.

> So, you want a web site that completely breaks HTTP such that only works with a handful of browsers and doesn't work with the probably tens or hundreds of thousands of pieces of other software that speaks HTTP.

This is nothing more than pure trolling. All major web browsers support Brotli over HTTPS. Apple's WebKit is the only man out, and they are, at best, a minority on the web. Firefox supports it, Chrome supports it, and Edge supports it. Even if Edge didn't support it, the fact that Firefox and Chrome support it is more than enough for me. Other browsers are just bonuses.

Furthermore, yet again, I do not have a HTTP server, so there is no HTTP here to break! HTTPS is implemented to spec, HSTS headers and all! My website is meant to be viewed by people, not machines. In addition, as the web is moving to being HTTPS-exclusive, it's about time that you start getting used to it. You're wasting your time.

Re: Two years of Rust

#130

Post by nickpsecurity »

lacampbell wrote: post #108
nickpsecurity wrote: post #41

Earlier quoted context omitted.

Oh yeah, I forgot to ask "Have you or the others considered rewriting your compiler in Modula-3? I hear you get safety, acceptable speed, and 5x iteration speed of Rust."

I look forward to your fascinating re-implementation of unix tools from the 70s - only with less functionality.

That's what would happen lol.
Post reply on HN