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

171–180 of 312 posts

Re: Two years of Rust

#171

Post by brandur »

lacampbell wrote: post #128
brandur wrote: post #114

Earlier quoted context omitted.

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…

> I don't understand how (1) isn't a positive in your eyes.

I like testing as much as the next person and consider it very important, but your tests should be testing business logic rather than whether your syntax is correct. The problem with dynamic languages is that while you're certainly doing the former, you're also doing way too much of the latter. Until you hit runtime, you have no idea whether you misreferenced a variable or invoked a method that doesn't exist, so you end up writing an exaggerated number of tests that are repetitive, slow things down, and end up requiring considerable maintenance.

> (2) is true for pretty much every large statically typed codebase I've worked on.

Yes, incremental deployment is always a good idea, but it's a matter of degree.

Take for example a case where I need to rename a method that's widespread throughout the codebase. In a static language, I wouldn't give this a second thought. If there's a problem my compiler will catch it, and that's the end of the story.

In a dynamic one, this is a dangerous operation: the old method name may still be getting invoked dynamically in a non-obvious way, or another branch may have been merged _after_ I branched but _before_ I deployed that still has an invocation of the old name. Hopefully you have tests on these paths that will reveal the problem, but you might not, and to hedge against that possibility, you have to roll the change out to production carefully and slowly (because even there, it might be some time before some unwitting user inadvertently triggers the bad flow).

Re: Two years of Rust

#172

Post by kibwen »

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…

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

Please point to a single place where anyone has ever said this. We have never positioned Rust as an end-all be-all language: it's a language that deliberately makes compromises in order to excel at a niche.

Re: Two years of Rust

#173

Post by derefr »

cwzwarich wrote: post #169
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]…

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

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 about remarkably slowly.

Re: Two years of Rust

#174

Post by lumpypua »

kibwen wrote: post #168
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…

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

Re: Two years of Rust

#175

Post by kibwen »

cwzwarich wrote: post #169
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]…

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

Re: Two years of Rust

#176

Post by tatterdemalion »

lacampbell wrote: post #103
tatterdemalion wrote: post #63

Earlier quoted context omitted.

> Is the Rust community claiming that the entire history of computing has lead up to this point, where Rust exists, and now nobody needs to write anything in not-Rust? Are people 200 years from now going to write Rust and nothing else? Let's be clear - the person who said there'd be no reason to write in anything else is an enthusiastic Rust user, but they don't work on Rust & don't represent "the Rust community." Th…

I'm no compiler writer, but presumably rust has some form of internal IR it compiles to before it gets turned into LLVM IR. Why not just write an interpreter for that layer and be done with it? The point of a REPL to me is to be responsive, not to run code amazingly quickly.

Yes, thats what the second point is.

Re: Two years of Rust

#177

Post by curun1r »

Manishearth wrote: post #148
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…

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)

Also, cargo doc --open for offline version of docs.rs :-)

Re: Two years of Rust

#178

Post by kibwen »

sillysaurus3 wrote: post #78
tatterdemalion wrote: post #63

Earlier quoted context omitted.

> Is the Rust community claiming that the entire history of computing has lead up to this point, where Rust exists, and now nobody needs to write anything in not-Rust? Are people 200 years from now going to write Rust and nothing else? Let's be clear - the person who said there'd be no reason to write in anything else is an enthusiastic Rust user, but they don't work on Rust & don't represent "the Rust community." Th…

Let's be clear - the person who said there'd be no reason to write in anything else is an enthusiastic Rust user, but they don't work on Rust & don't represent "the Rust community." Respectfully, the community has become increasingly vocal, and it's getting hard to separate the enthusiasm from realism. It's embedded in every HN thread. That's a good problem to have, but it can be a bit repellant to people who aren't…

The community is in every thread because the people here were HN users before they were Rust users. Look at how old my account is; I haven't quite been shilling Rust since December 2011. :P

Re: Two years of Rust

#179

Post by mmstick »

eridius wrote: post #134
mmstick wrote: post #129

Earlier quoted context omitted.

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

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. One of the major reasons for me moving my website to HTTPS is so that I could use Brotli compression. Otherwise, Firefox and Chrome will merely get a content encoding error page because br is an unknown encoding format when using HTTP! HTTPS is required, and Google engineers are telling you this themselves. You're wrong, and Google engineers are right. End of story.

> Why doesn't Safari count in your eyes as a major browser? Or perhaps more interestingly, why doesn't iOS Safari count? Are you really ok with your site not working for 100% of iOS users?

I do not care if iOS users using Safari are unable to access my website. In the same way that iOS app developers do not care that Android users cannot use their apps, I do not care if iOS users using Safari are unable to access my personal blog. My target audience is not iOS users. My target audience consists of Linux users using either Chrome or Firefox.

So basically, you have tunnel vision and are just here to bicker and argue senselessly about things you don't understand or are unwilling to accept. I'm not sure why you're so upset that I have decided to not support your access to my personal blog. No matter how many times I explain things to you, you never seem to get it through your head. This is my website, not yours. I will not support gzip, and I will not support uncompressed content, nor will I support tools that only work with HTTP.

Re: Two years of Rust

#180

Post by kibwen »

goatlover wrote: post #131
sqeaky wrote: post #111

Earlier quoted context omitted.

Depending on who you ask Java did replace everything. Consider the Tiobe Index [1]. Java Beats out everything, including C and C+++ when added together. All three are growing, but not nearly as fast as everything else is growing to the point it looks likes they are shrinking. There is an absolutely enormous amount of Java out there. https://www.tiobe.com/tiobe-index/

If you mean Java replaced C/C++ as the most widely used language, at least according to one index, then that's one thing. So if someday Rust became as popular, great for Rust. But that's not the same thing as claiming that Rust will be the One True Programming language in use that will cause all the other language communities to die out and convert to Rust. That's what is being claimed above, and what some in the Jav…

> that's not the same thing as claiming that Rust will be the One True Programming language

Again, who is claiming this? Can you link me?

Post reply on HN