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

91–100 of 312 posts

Re: Two years of Rust

#91

Post by WatchDog »

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

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.

Re: Two years of Rust

#92

Post by detaro »

mmstick wrote: post #50
Terribledactyl wrote: post #46

Earlier quoted context omitted.

I'm having a bit of an issue with your site in Safari. 10.12.4 sierra, extensions turned off. https://s2.postimg.org/4t8v7lqdl/Screen_Shot_2017-05-15_at_1...

You need a web browser that supports Brotli compression -- the standard compression algorithm for HTTPS. Safari does not support it, but everyone else does. Even Edge. http://caniuse.com/#feat=brotli

> the standard compression algorithm for HTTPS

That's utter nonsense.

Re: Two years of Rust

#93

Post by cyphar »

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?

I was under the impression that Mozilla Servo is entirely written in Rust (GitHub appears to not be able to run linguist on the repo at the moment, the language detection isn't showing up).

Re: Two years of Rust

#94

Post by eridius »

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…

> It's not in my interest to request for Brotli support in products that I do not use.

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 serving up uncompressed content to that software?

> Again, I do not support HTTP!

You completely missed the point. I know your site doesn't support HTTP. But HTTPS is generally understood to be part of the umbrella of "HTTP". It is in fact literally the same protocol (well, for HTTP/1.1; HTTP/2 is a brand new protocol and irrelevant for this discussion), just wrapped in SSL.

> I may do just that then.

Just so we're clear, your site currently does not work, and will continue to not work, with tools like `curl` or `wget`, or nearly all other non-browser tools people have written.

Re: Two years of Rust

#95

Post by goatlover »

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…

Lispers might be able to meet that challenge.

Re: Two years of Rust

#96

Post by marcosdumay »

arianvanp wrote: post #59
coldtea wrote: post #56

Earlier quoted context omitted.

> about how futures-based concurrency spreads into your code through huge amounts of necessary boilerplate (`.and_then(...).and_then(...).and_then(...)`) How is that more boilerplate than any other way to have concurrency?

Do notation makes this stuff a whole lot more readable (See Haskell). Or Async-await (See C#)

About do notation, can't Rust get something similar with macros? (I still didn't get to making macros in it.)

Re: Two years of Rust

#97

Post by goatlover »

brandur wrote: post #65
sillysaurus3 wrote: post #40

Earlier quoted context omitted.

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…

> It's beginning to get tiresome to continually hear the Rust community go on and on about how amazing Rust is and say, with a straight face, that eventually there will be no reason to write anything in not-Rust. Are you serious? The hubris is off the charts. So a few considerations here: (1) I really have no connection with the Rust community aside from curiosity, so it's quite dishonest to project my opinion onto a…

But do you think the Go community agrees with this, just to name one of the popular newer languages? It's nice that Rust is doing well, and more power to the community. But there is an entire world of programming language communities out there that might not agree with the assessment that Rust is the future for them.

Anyway, I was around for this kind of talk when Java was new and shiny, and there were people in the Java community claiming that Java was the future for programming, and any languages in the future would target the JVM or be phased out. That didn't happen, even though Java did well for itself.

What's really telling is that Java didn't replace C/C++, despite all the hype back then. Those two languages remain widely used.

Re: Two years of Rust

#98

Post by mmstick »

detaro wrote: post #92
mmstick wrote: post #50

Earlier quoted context omitted.

You need a web browser that supports Brotli compression -- the standard compression algorithm for HTTPS. Safari does not support it, but everyone else does. Even Edge. http://caniuse.com/#feat=brotli

> 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, except Apple's WebKit. Simple.

Re: Two years of Rust

#99

Post by derefr »

zzalpha wrote: post #43
sillysaurus3 wrote: post #40

Earlier quoted context omitted.

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. 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 ability to reflect on the API in a REPL, doing the moral equivalent of exploring a filesystem using cd(1) and cat(1), until you figure out what functions—and what arguments—combine to produce an acceptable result for your use-case.

That may sound like a bad thing, but it's not! Those packages are packages that wouldn't exist otherwise; they're marginal packages, packages which people wouldn't have had time to write if they were required to also document them properly enough to make use of them without a REPL. They're needs being satisfied, that would otherwise—given the stricter requirement of useful API documentation—be going un-met.

If you look at e.g. Ruby's gem ecosystem, there are tons of packages that have more than a million downloads, and either no docs or awful docs. How? Because Ruby is extremely amenable to exploring APIs through a REPL. You take a module or class, ask it what its children are, what its class methods are, what its instance methods are. Find a class with instance methods that sound right, attempt to instantiate it. Figure out you can't do that, look around the class methods for something that sounds like a factory method. What arguments does said factory-function take? Well, feed it some at random and see what error you get. Etc.

Re: Two years of Rust

#100

Post by mcorbin »

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…

Try Clojure.
Post reply on HN