Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust 1.24

blog.rust-lang.org

Post reply on HN
Print view View original

71–80 of 215 posts

Re: Rust 1.24

#71

Post by pvg »

ZenoArrow wrote: post #68
pvg wrote: post #44

Earlier quoted context omitted.

That's a bit like asking someone to sell you on using a plasma cutter over a dremel tool. It can be done but it's not particularly useful or sensible.

Everything you can write in Python you can write in Rust, and everything you can write in Rust you can write in Python. The main differences are found in tooling, library ecosystems, development speed and runtime overhead.

Everything you can write in Python you can write in Rust, and everything you can write in Rust you can write in Python.

That really isn't true in any practically meaningful sense. 'The main difference is everything is different' is not a very strong counter-argument.

Re: Rust 1.24

#72

Post by civility »

kibwen wrote: post #12

Incremental compilation! And it's only going to incremental-er from here, as the compiler learns how to cache more and more sorts of interim artifacts to avoid redundant work. Though I think the wording in the OP is a bit off: > Historically, the compiler has compiled your entire project, no matter how little you’ve changed the code. This isn't quite correct. When you change the code in a given library, it has histor…

> Incremental compilation!

Is there some algorithm in Rust which has a necessary big-O? There were compilers in the 90s which ran a million lines per second (on much slower computers). Incremental compilation feels like working around the problem rather than solving it, and I have to imagine the complexity and maintenance is much worse.

I'm sure some of the LLVM optimization passes are expensive, but those are used in clang++ too, and it's not terribly slow.

Re: Rust 1.24

#73

Post by jrhurst »

fafhrd91 wrote: post #43
fafhrd91 wrote: post #42

tokio-minihttp is 1 in plaintext benchmark in TechEmpower Web frameworks benchmark https://www.techempower.com/benchmarks/#section=data-r15&hw=...

hyper is 6 and actix is 7 https://github.com/actix/actix-web Rust is represented well!

I tried Actix a while back and it was very intimidating compared to some other frameworks. I'd like to jump back into it at some point, but right now for my prototype I got lazy and went with Rocket.rs.

Any suggestions of Opensource projects that use Actix?

Re: Rust 1.24

#74

Post by pas »

aidenn0 wrote: post #20
talson wrote: post #15

Can someone sell me on using rust over python? I am just gernerally curious as to the advantage beyond rust being compiled.

While there is overlap between problems that might be sanely solved using python and problems that might be sanely solved using rust, the languages target very different problems. You could write parts of a network server or parts of an OS kernel in python. You could write nearly the entirety of it in rust. I would say that you need not use rust if python works well for you, but rust is probably better than C for imp…

Python is great, and getting better.

Just religiously use mypy. (Gradual typing!)

And profiling, and when something is reallly slow, bring out the Cython.

And when something is still not fast enough, well ...

Release the Rustacean!

Re: Rust 1.24

#75

Post by pcwalton »

civility wrote: post #72
kibwen wrote: post #12

Incremental compilation! And it's only going to incremental-er from here, as the compiler learns how to cache more and more sorts of interim artifacts to avoid redundant work. Though I think the wording in the OP is a bit off: > Historically, the compiler has compiled your entire project, no matter how little you’ve changed the code. This isn't quite correct. When you change the code in a given library, it has histor…

> Incremental compilation! Is there some algorithm in Rust which has a necessary big-O? There were compilers in the 90s which ran a million lines per second (on much slower computers). Incremental compilation feels like working around the problem rather than solving it, and I have to imagine the complexity and maintenance is much worse. I'm sure some of the LLVM optimization passes are expensive, but those are used i…

> There were compilers in the 90s which ran a million lines per second (on much slower computers).

Those compilers performed nowhere near the level of optimization that modern compilers do.

> I'm sure some of the LLVM optimization passes are expensive, but those are used in clang++ too, and it's not terribly slow.

clang++ is sure slow if it has to rebuild an entire codebase from scratch.

The main reason that C++ compilers get away with not having partial compilation is that it forces programmers to do the division into code units manually through separate .h and .cpp files. Rust doesn't have this, except at the crate level, so it needs partial compilation instead. It turns out that partial compilation is better in the first place, because compilation units tend to be fairly coarse-grained: .cpp files frequently grow very large.

Re: Rust 1.24

#76

Post by steveklabnik »

civility wrote: post #72
kibwen wrote: post #12

Incremental compilation! And it's only going to incremental-er from here, as the compiler learns how to cache more and more sorts of interim artifacts to avoid redundant work. Though I think the wording in the OP is a bit off: > Historically, the compiler has compiled your entire project, no matter how little you’ve changed the code. This isn't quite correct. When you change the code in a given library, it has histor…

> Incremental compilation! Is there some algorithm in Rust which has a necessary big-O? There were compilers in the 90s which ran a million lines per second (on much slower computers). Incremental compilation feels like working around the problem rather than solving it, and I have to imagine the complexity and maintenance is much worse. I'm sure some of the LLVM optimization passes are expensive, but those are used i…

It's not a big-O thing. The optimization passes aren't necessarily huge either; right now, 50% of the time is in LLVM compiling IR -> machine code. The static checks, optimization passes, and everything else are minuscule overall. You can see this with -Z time-passes.

We have some hunches, but nothing super conclusive yet; basically, right now it's all about how much IR we generate.

Don't forget the differences in compilation model; C/C++'s compilation units are much smaller, so incremental isn't as big of a deal.

Re: Rust 1.24

#77

Post by steveklabnik »

dsymonds wrote: post #70

Good to see rustfmt arrive. Sad that it is configurable, though. The biggest benefit of its predecessors such as gofmt is that they are not configurable, leading to a much more uniform formatting style and avoiding endless discussions about whitespace layout.

Yeah, I'm not psyched about it either, but that ship has sailed.

The defaults are what's considered the "official" style; we expect the vast majority of people to use it. Defaults are powerful.

Re: Rust 1.24

#78

Post by pcwalton »

dsymonds wrote: post #70

Good to see rustfmt arrive. Sad that it is configurable, though. The biggest benefit of its predecessors such as gofmt is that they are not configurable, leading to a much more uniform formatting style and avoiding endless discussions about whitespace layout.

If rustfmt were not configurable, it would get a lot less use. Rust has been around for quite some time now, and there's a lot of code out there. We can't force anybody to run rustfmt, and if they don't like the results, they won't use it. It's not a choice between different code styles and a single code style; it's a choice between different code styles with a tool to keep things tidy and different code styles with a tool nobody uses. Things were different for Go for a variety of historical reasons, one important reason being that gofmt existed early on.

To take a concrete example, adopting gofmt's choice to not have a line length limit would have been a nonstarter, because lots of code out there uses long expressions manually wrapped to be readable. A lot of the work in rustfmt has gone into playing nicely with community conventions like these.

Re: Rust 1.24

#79

Post by Thaxll »

fafhrd91 wrote: post #42

tokio-minihttp is 1 in plaintext benchmark in TechEmpower Web frameworks benchmark https://www.techempower.com/benchmarks/#section=data-r15&hw=...

I wouldn't post Rust benchmarks in here it's behind Java in every scenarios.

Re: Rust 1.24

#80

Post by kibwen »

dsymonds wrote: post #70

Good to see rustfmt arrive. Sad that it is configurable, though. The biggest benefit of its predecessors such as gofmt is that they are not configurable, leading to a much more uniform formatting style and avoiding endless discussions about whitespace layout.

I don't agree. There is a default configuration, and that configuration is very good (I've been following the process of nailing it down, and IMO it's been done very tastefully), and is the formatting used by official Rust codebases, lending it the weight of authority. I have no reason to configure it to do anything differently. But I also have no reason to forbid anyone else from formatting code as they please. What's the possible harm? If you're on a team, and you want code uniformity, you require the default configuration. If you're worried about pulling some random code and having it use {tabs|spaces} instead of {spaces|tabs} (which, btw, is, without hyperbole, the dumbest argument in the entire human history of programming) then you set your editor to run rustfmt on files before opening them.

The gofmt argument isn't the final word here. There's plenty of Go users who don't like gofmt's style, so they just don't use gofmt. It's easy to imagine other users who don't like gofmt's style, and don't like being pressured to use it, so they just don't use Go at all. How is that any better than just having a configurable tool with sane defaults? It's one thing for a tool to be opinionated; it's another thing entirely to be dictatorial and stubbornly inflexible.

Post reply on HN