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

161–170 of 312 posts

Re: Two years of Rust

#161

Post by bluejekyll »

steveklabnik wrote: post #75
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).

"rustc is too slow" is possibly our most commonly-heard feedback. I am glad that you don't find it onerous, but many still do.

I don't know... I really think it depends on the audience you're catering to. As someone who only ever deals with compiled languages, this has never seemed to be a problem.

Now, viewing this as someone coming from Python, Ruby, Node, etc., I can see compilation as being annoying. Is it really the only reason that they are disliking the language or is that just a strawman?

I wonder if too much attention is being paid to this. Now there are legitimate things we can focus on, such as making cached precompiled libraries very easy to use. This can especially be important in CI environments... This would also generally make most compilations fast.

Re: Two years of Rust

#162

Post by nickpsecurity »

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…

Patrick Logan on Lobste.rs comes to mind. He talks a lot about using Smalltalk for robust applications. Here's one paper he shared where Smalltalk team killed the others in productivity. Unfortunately, I didn't get defect rates on all the teams where Ada or C++ were usually winning in those kinds of comparisons.

https://drive.google.com/file/d/0B0cKsRm-3yprYTR5YTRaRFBfR28...

He said they mostly just test everything at the interfaces. However, it's simplicity also allowed for powerful tools in code generation, refactoring especially, and so on.

Re: Two years of Rust

#163

Post by bluejekyll »

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

Am I the only one who sees this as pure BS? Some people like REPL's, and that's cool. But not everyone. I find it utterly annoying that in any REPL I've ever used I first have to import (or similar) the libraries I want access to in that repl environment. You end up generally writing a file to do the imports for you, or cutting and pasting.

With all that effort I almost always find it easier to just write a test-case, even in languages with a REPL. At that point I have a repeatable and testable piece of code that can be run, with almost zero error due to the REPL environment not being setup properly.

Re: Two years of Rust

#164

Post by eridius »

mmstick wrote: post #141
eridius wrote: post #113

Earlier quoted context omitted.

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…

> 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 specific behavior here. Here's what I found:

* If you point Chrome at localhost, it includes "br" in the Accept-Encoding header.

* If you point Chrome at some other domain using HTTP, it does not include "br" in the Accept-Encoding header.

* Either way, if the server actually returns a Content-Encoding of "br", Chrome will respect it.

So basically, Chrome always supports Brotli-encoded responses. However, it only requests Brotli over HTTPS and doesn't request it over HTTP, and the only reason for this distinction is to avoid middleware servers from mucking with Brotli-encoded pages that they don't understand.

Re: Two years of Rust

#165

Post by pcwalton »

comex wrote: post #52
webkike wrote: post #33

Earlier quoted context omitted.

Consider how interfaces work and how you would have to implement them. Rust may have a more complicated type system and I suppose enums are more complicated in Rust, but the things I value as simple are more simple in Rust than Go.

What about interfaces? The basic idea of fat pointers with vtables works the same as Rust's trait objects. If you mean the ability to dynamically cast from one interface type to another, which Rust doesn't support - that does require a global list of implemented interfaces per type, but without generics that's not too hard to implement. (In Rust, it would be drastically more complex, verging on impossible to pull off…

> (In Rust, it would be drastically more complex, verging on impossible to pull off with a good UX, due to various language features including wildcard impls, type-parameterized traits, and a Turing-complete type system.)

Swift can downcast, and it has generic extensions and generic protocols. I highly suspect it has a Turing-complete type system as well.

Supporting this requires heroic effort in the compiler, but it can be done.

Re: Two years of Rust

#166

Post by steveklabnik »

bluejekyll wrote: post #161
steveklabnik wrote: post #75

Earlier quoted context omitted.

"rustc is too slow" is possibly our most commonly-heard feedback. I am glad that you don't find it onerous, but many still do.

I don't know... I really think it depends on the audience you're catering to. As someone who only ever deals with compiled languages, this has never seemed to be a problem. Now, viewing this as someone coming from Python, Ruby, Node, etc., I can see compilation as being annoying. Is it really the only reason that they are disliking the language or is that just a strawman? I wonder if too much attention is being paid…

> such as making cached precompiled libraries very easy to use.

This is already true today; that is, this cost is only paid the first time you compile. It's still not fast enough for people.

On my machine, a fresh build of rustc takes an hour, and small changes take 20 minutes, and even that makes it a giant pain. It's an ergonomic thing, IMO.

Re: Two years of Rust

#167

Post by nickpsecurity »

fizixer wrote: post #153
nickpsecurity wrote: post #143

Earlier quoted context omitted.

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?

Looking at it very briefly, its feature set is probably small enough to keep the language simple yet useful. To be clear, I'm not a Rust guy, or even C++, Go, D. On top of that, I'm a 2PL advocate (two programming languages). I think a combination of a readable high-level language like Python or Scheme, and a fast systems language like C, can carry out feats that no single programming language can as far as I know. (…

I'm with you on the 2PL right tool for the job idea. It's what I did. :)

Re: Two years of Rust

#168

Post by kibwen »

comex wrote: post #42
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…

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.

Re: Two years of Rust

#169

Post by cwzwarich »

derefr wrote: post #116
sillysaurus3 wrote: post #49

Earlier quoted context omitted.

I tend to agree, but being able to have a REPL at all is a symptom that your language is capable of an extremely fast compile-run-debug cycle. In other words, if you can't implement a REPL, that's the definition of "less productive language." It's not about the REPL itself but the capability of implementing one. Think about it like this: On your list of languages, which of them would you say is most productive? It de…

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 still have to deal with the horrific mess that is the cumulative total of past web-related decisions.

Re: Two years of Rust

#170

Post by kibwen »

steveklabnik wrote: post #166
bluejekyll wrote: post #161

Earlier quoted context omitted.

I don't know... I really think it depends on the audience you're catering to. As someone who only ever deals with compiled languages, this has never seemed to be a problem. Now, viewing this as someone coming from Python, Ruby, Node, etc., I can see compilation as being annoying. Is it really the only reason that they are disliking the language or is that just a strawman? I wonder if too much attention is being paid…

> such as making cached precompiled libraries very easy to use. This is already true today; that is, this cost is only paid the first time you compile. It's still not fast enough for people. On my machine, a fresh build of rustc takes an hour, and small changes take 20 minutes, and even that makes it a giant pain. It's an ergonomic thing, IMO.

> a fresh build of rustc takes an hour

A bit influenced by the fact that rustc has to compile itself three times. :P

Post reply on HN