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

101–110 of 215 posts

Re: Rust 1.24

#101

Post by comex »

burntsushi wrote: post #82
comex wrote: post #53

Earlier quoted context omitted.

There’s memmem...

memmem is substring search. You could use it for char search, but does memmem know about UTF-8? If, say, memmem uses memchr internally in a skip loop and it happens to look at the first byte in the UTF-8 encoded codepoint, then it is going to perform a lot worse in most cases involving the search of text that is in a language other than English (because it will wind up searching for a very common byte). Or maybe memm…

Yeah, I suspect it wouldn't actually be a win, though of course it will depend on the implementation. Just pointing out that "there's no memchr for consecutive sequence of characters" isn't exactly true.

Re: Rust 1.24

#102

Post by civility »

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…

> Don't forget the differences in compilation model; C/C++'s compilation units are much smaller

Not everyone compiles C++ the same way. I prefer header-only libraries and a single compilation unit. Counting lines of code with "gcc -E" to get the headers, I just compiled 20,000 lines of C++ from scratch in .6 seconds with gcc and .4 seconds with clang. I don't have a comparable project in Rust.

Re: Rust 1.24

#103

Post by pcwalton »

civility wrote: post #102
steveklabnik wrote: post #76

Earlier quoted context omitted.

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…

> Don't forget the differences in compilation model; C/C++'s compilation units are much smaller Not everyone compiles C++ the same way. I prefer header-only libraries and a single compilation unit. Counting lines of code with "gcc -E" to get the headers, I just compiled 20,000 lines of C++ from scratch in .6 seconds with gcc and .4 seconds with clang. I don't have a comparable project in Rust.

How much code did the preprocessor strip out?

Re: Rust 1.24

#104

Post by pcwalton »

civility wrote: post #99
pcwalton wrote: post #75

Earlier quoted context omitted.

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

I don't know what this means.

Re: Rust 1.24

#105

Post by nine_k »

civility wrote: post #96
nerpderp83 wrote: post #93

Earlier quoted context omitted.

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.

Java without generics used to compile pretty fast.

When you add generics, lifetimes, and type inference, the amount of work the compiler does grows significantly. It allows to check much more interesting invariants, leading to the "if it compiles, it runs correctly" effect.

Re: Rust 1.24

#106

Post by kibwen »

eximius wrote: post #94
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.

I'm not sure what this is referring to. Generic types don't get monomorphized when exported in libraries, they get compiled to intermediate-language metadata that is then used by downstream consumers to monomorphize as needed. Furthermore I'm pretty sure Rust doesn't allow cyclic dependencies between crates, so if foo somehow depended on bar then bar couldn't depend on foo.

Re: Rust 1.24

#107

Post by roblabla »

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 write memory bugs in Rust, by design

Unless you're talking about unsafe rust, that's wrong. And if you ARE talking about unsafe rust, well you can do the same in Python.

I do agree that python and rust are both "memory-safe" languages. I'm not sure about the other kind of safety rust provides though: thread-safety. That's really where Rust shines: you can write concurrent program and be statically guaranteed to have no data-races. I'm not sure how this transposes in python.

Re: Rust 1.24

#109

Post by todd_wanna_code »

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.

I would say types. I think types have been really a lot of help to me, coming from mostly dynamic languages. It forces you to think about your problem more than just throwing some code together. Another thing I enjoyed is easier concurrency. But apart from that, I feel like its a matter of choosing the right tool for the right task.

Re: Rust 1.24

#110

Post by civility »

pcwalton wrote: post #103
civility wrote: post #102

Earlier quoted context omitted.

> Don't forget the differences in compilation model; C/C++'s compilation units are much smaller Not everyone compiles C++ the same way. I prefer header-only libraries and a single compilation unit. Counting lines of code with "gcc -E" to get the headers, I just compiled 20,000 lines of C++ from scratch in .6 seconds with gcc and .4 seconds with clang. I don't have a comparable project in Rust.

How much code did the preprocessor strip out?

No idea, maybe a lot from the system headers. However, it was 20,000 lines of code that survived the preprocessor, 11,000 of which were inline or template from the project itself.
Post reply on HN