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

Making Rust as Fast as Go

christianfscott.com

Post reply on HN
Print view View original

191–200 of 211 posts

Re: Making Rust as Fast as Go

#191

Post by jfkebwjsbx »

fluffything wrote: post #181
arcticbull wrote: post #180

Earlier quoted context omitted.

> Adding unicode segmentation to the standard library and making all Rust binaries, most of which don't do unicode segmentaiton, 20 Mb larger by unnecessarily bundling the unicode tables, makes no sense. Isn't that what dead code stripping is for?

If you are shipping a binary library, like the standard library, you don't know which parts of your library users are going to use when they link it, so you need to ship binaries with all of it to all Rust users. The only one that can strip is the end user compiling a final binary, and the compiler often cannot do this for you because that requires whole program optimization and full LTO, which is super super slow. A…

You can definitely ship binary libraries and use only whatever is needed, and there is no need for LTO/WPO to achieve that.

In fact, LTO/WPO have nothing to do with the ability to link whatever is needed.

Re: Making Rust as Fast as Go

#192

Post by jfkebwjsbx »

steveklabnik wrote: post #190
arcticbull wrote: post #189

Earlier quoted context omitted.

> Proposing to make Rust come with batteries included is proposing to change one of Rust's core values. Go ahead and write an RFC for that. I'll get my popcorn. Again, my recommendation wasn't that, it was that the core team consider releasing "core" language features like Unicode support as first-party crates when they don't make sense as part of 'stdlib' not that I think they will. Feels weird to me that I have to…

(We already do do this in some cases; these crates are authored by "The Rust Project Developers". For example, the regex crate is one of these.)

Yeah, but that makes them third-party already for many orgs' policies, even if they come from the same set of developers.

As soon as you have to add a crate, you are in for extra review and pain.

Re: Making Rust as Fast as Go

#193

Post by will4274 »

otterley wrote: post #131
will4274 wrote: post #122

Earlier quoted context omitted.

Says who? When news organizations take other news organizations word for it and the story is false, that's fake news. We called it something different back then, but fake news led to the invasion of Iraq. Negligence is sufficient for fake news, malice not required.

Fake News was a term invented around 2015 during the run-up to the 2016 election. It specifically referred to the phenomenon of literally fake news stories, such as rallies and completely false stories about politicians, being published by legitimate-sounding but nonexistent news organizations, using platforms like Facebook to disseminate themselves. Usually these were done from China and Russia.

You're as silly as those people who claim that male and female refer exclusively to sex but not gender. Terms change in meaning and fake news is widely used to refer to false news stories, regardless of reason. You have to accept the way everybody else is using the word.

Re: Making Rust as Fast as Go

#194

Post by jfkebwjsbx »

fluffything wrote: post #176
arcticbull wrote: post #151

Earlier quoted context omitted.

IMO it's not as clear-cut as you make it out to be. It's a pretty arbitrary line to exclude full Unicode support from the standard library. There's a ton of stuff in libstd that could be supported as third-party crates. I don't disagree with what the Rust team has done, and I think there could be a world in which the compiler team also releases first-party crates with "enhanced" functionality beyond just libstd. I co…

> For the record, I also disagree with your assertion that "easily done in rust" should be extended to include "...by importing a third-party framework." In that sense anything is easy to do in any language where a third-party framework exists. I'm confident it's just as easy in go. Have you tried doing that in C++? Doing that in a cross-platform way (or even in a single platform) is anything but easy, because you do…

In C++ you do have cross-platform tools like cargo. For instance, vcpkg. > In Rust, you just need to write `cargo add unicode-segmentation` once in a project,

In C++ I can write `vcpkg install whatever`. Yet that does not mean my organization will allow the library.

So no, adding libraries is quite harder than installing them unless you are working in your own projects alone. And even then adding them is never a one line effort.

> If you prefer languages without a minimal standard library, then Rust isn't for you.

There is nothing minimal about Rust's std.

Re: Making Rust as Fast as Go

#195

Post by steveklabnik »

jfkebwjsbx wrote: post #192
steveklabnik wrote: post #190

Earlier quoted context omitted.

(We already do do this in some cases; these crates are authored by "The Rust Project Developers". For example, the regex crate is one of these.)

Yeah, but that makes them third-party already for many orgs' policies, even if they come from the same set of developers. As soon as you have to add a crate, you are in for extra review and pain.

I don't understand, wasn't

> it was that the core team consider releasing "core" language features like Unicode support as first-party crates

what you were asking for?

Re: Making Rust as Fast as Go

#196

Post by arcticbull »

blablabla123 wrote: post #187
entha_saava wrote: post #172

Earlier quoted context omitted.

> Except of course all the Plan 9 garbage (like Go's hand-rolled assembler) brought in to underpin Go from the 80s This is unfair criticism. If Go had used LLVM, it would affect its selling point (fast compile times) and authors knew the plan 9 toolchain well. Go the language feels like it is from 80s. But its toolchain is not at all bad. LLVM monoculture is the last thing one would want. Obligatory reminder that LLV…

Also when this LLVM stuff doesn't work, it's a major pain to troubleshoot because all this is a complexity monster. Go and its Plan 9 heritage is more like 80s retro future and things like cross-compiling are super easy

In my opinion, compile times are irrelevant. Developers can always get faster or larger machines if they need them. What matters is how the final product performs on customer machines. Performance and memory usage of the final product, plus your ability as an engineering team to avoid costly and difficult mistakes are basically the only thing that matters.

Re: Making Rust as Fast as Go

#197

Post by arcticbull »

bigbizisverywyz wrote: post #186
arcticbull wrote: post #111

Earlier quoted context omitted.

Not to mention Rune slices are insufficient for things like Flag emoji and Family emoji, which is going to be a ton of separate runes put together. The latter of which, apparently deletes one family member at a time when you hit "backspace".

Oh fab, just when I thought I had a fairly solid understanding of how to handle Unicode strings I learn something else that increases the complexity. I have nothing but respect and gratitude for people that write good unicode handling libraries, but even then the end developer has to learn a lot just to be aware of what to look out for when handling strings. Somewhere on github I think, somebody has posted a file wit…

In general, unicode requires you think differently about strings depending on context. Here's my rule of thumb.

1. If you are transporting a unicode string, reading/writing over the network or to a file, think in terms of UTF-8 bytes. Do not attempt to splice the string, treat it as an atomic unit.

2. If you are parsing a string, think in terms of code points (runes in Go, chars in Rust). A good example would be the Servo CSS parser. [1]

3. If you're comparing/searching/inspecting/sorting a string in code, segment by grapheme clusters and normalize, then do what you came to do. [2]

4. If you're displaying a string, think in terms of pixels. Do not attempt to limit a string by length in "characters" (nee grapheme clusters in the unicode world) but rather measure by what the renderer does with the string. Each character can be a thoroughly arbitrary width and height.

5. If you're building a WYSIWYG editor, there's more to it than I even know myself, but I suggest reading into what Xi did. It's going to be some combination of everything above. [3]

[1] https://github.com/servo/rust-cssparser/blob/master/src/toke...

[2] https://github.com/unicode-rs/unicode-segmentation

[3] https://github.com/xi-editor/xi-editor

Re: Making Rust as Fast as Go

#198

Post by arcticbull »

steveklabnik wrote: post #195
jfkebwjsbx wrote: post #192

Earlier quoted context omitted.

Yeah, but that makes them third-party already for many orgs' policies, even if they come from the same set of developers. As soon as you have to add a crate, you are in for extra review and pain.

I don't understand, wasn't > it was that the core team consider releasing "core" language features like Unicode support as first-party crates what you were asking for?

I think that's what I was asking for, but I'm not the person you were replying to ^_^, they were taking a more hard-line stance that it should be part of libstd.

Side-note I really appreciate all the work you folks are doing. Rust has changed the way I write software even when I'm not writing Rust, which is about the highest praise I can offer.

I'd love to pitch in.

Re: Making Rust as Fast as Go

#199

Post by steveklabnik »

arcticbull wrote: post #198
steveklabnik wrote: post #195

Earlier quoted context omitted.

I don't understand, wasn't > it was that the core team consider releasing "core" language features like Unicode support as first-party crates what you were asking for?

I think that's what I was asking for, but I'm not the person you were replying to ^_^, they were taking a more hard-line stance that it should be part of libstd. Side-note I really appreciate all the work you folks are doing. Rust has changed the way I write software even when I'm not writing Rust, which is about the highest praise I can offer. I'd love to pitch in.

Whoops, how embarrassing for me!

Thanks :)

... how would you like to pitch in? I can point you to the right people. We're always happy to have more help.

Re: Making Rust as Fast as Go

#200

Post by mratsim »

fluffything wrote: post #181
arcticbull wrote: post #180

Earlier quoted context omitted.

> Adding unicode segmentation to the standard library and making all Rust binaries, most of which don't do unicode segmentaiton, 20 Mb larger by unnecessarily bundling the unicode tables, makes no sense. Isn't that what dead code stripping is for?

If you are shipping a binary library, like the standard library, you don't know which parts of your library users are going to use when they link it, so you need to ship binaries with all of it to all Rust users. The only one that can strip is the end user compiling a final binary, and the compiler often cannot do this for you because that requires whole program optimization and full LTO, which is super super slow. A…

> The only one that can strip is the end user compiling a final binary, and the compiler often cannot do this for you because that requires whole program optimization and full LTO, which is super super slow.

Whole program dead code elimination doesn't have to be slow. Nim does that by default (it's not possible to turn it off since a couple releases actually) and it still compiles quite fast.

Post reply on HN