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

91–100 of 215 posts

Re: Rust 1.24

#91

Post by vvanders »

andrewflnr wrote: post #83
michaelchisari wrote: post #18

Earlier quoted context omitted.

Performance is quite a bit higher for rust. And it's a much safer language by design (and forces the programmer to be as such). That said, development time in Python is much faster. Honestly, it depends on what you're building.

Rust is not safer than Python in Rust's own terminology. It takes more work than in C, but you can write memory bugs in Rust, by design. Python will catch those damn near every time, and if it doesn't you file a bug. Sure, there's less serious classes of bugs that Rust is likely to catch, but that's not really safety except in a definition loosened to near uselessness.

You can describe "safe" along different axes and python is not completely immune to memory issues. I guarantee that if you start using ctypes you'll manage it at some point.

Re: Rust 1.24

#92

Post by Shoop »

steveklabnik wrote: post #76
civility wrote: post #72

Earlier quoted context omitted.

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

Is there a way to generate IR which is easier on LLVM? The Jai compiler compiles 60kloc with an llvm backend in seconds. Could performance like this be seen in rustc?

Re: Rust 1.24

#93

Post by nerpderp83 »

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…

Those languages were Wirthian, and were designed for fast compilation.

Re: Rust 1.24

#94

Post by eximius »

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…

It would recompile foo if you changed something in bar that caused a generic function in foo to monomorphize differently, AFAIK.

Re: Rust 1.24

#95

Post by nerpderp83 »

Thaxll wrote: post #79
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.

Performance is one dimension of many.

Re: Rust 1.24

#96

Post by civility »

nerpderp83 wrote: post #93
civility wrote: post #72

Earlier quoted context omitted.

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

Those languages were Wirthian, and were designed for fast compilation.

Oberon certainly compiles quickly, and I believe Delphi (Pascal-ish) was fast too, but I was thinking of Microsoft's Java compiler before they got spanked.

Re: Rust 1.24

#97

Post by saghm »

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've never once seen or experienced any discussion about whitespace layout in Rust. OTOH, I've had several discussions about whitespace layout in Go in less than a year of programming in it due to gofmt not enforcing a maximum line length. Previous to writing Go, I worked on a C++ project that used clang-format (with a custom configuration), and we never had to have any formatting discussions because it also handled maximum line lengths.

Re: Rust 1.24

#98

Post by oconnor663 »

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.

Just my favorite single reason: I love ownership. I love knowing what a function is going to do with the HashMap/dictionary I pass into it. I love knowing when I'm the only piece of code that can touch something. Sure, there are benefits in terms of not needing a GC too, but I just love how clear it makes everything.

Re: Rust 1.24

#99

Post by civility »

pcwalton wrote: post #75
civility wrote: post #72

Earlier quoted context omitted.

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

Not going to budge an inch, eh? It must be as good as it will ever get.

Re: Rust 1.24

#100

Post by thsowers »

Thaxll wrote: post #79
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.

Maybe in web, but overall I don't think this is true [0]

[0]: https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...

Post reply on HN