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

181–190 of 211 posts

Re: Making Rust as Fast as Go

#181

Post by fluffything »

arcticbull wrote: post #180
fluffything wrote: post #175

Earlier quoted context omitted.

Today, if you write `cargo add unicode-segmentation` to a Rust 1.0 program, you can use the latest version of Unicode. You can also add an older version of the library and use an older version if you want. 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. As you see i…

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

Also, just because the final binary doesn't use a symbol, doesn't imply that the symbol isn't used. You can ship a library with a main function that can be run as an executable, or linked as a library. The linker doesn't know.

You would really need to go out of your way to strip your binary for your particular application. This is possible, and not that hard.

But the point remains: why should 99% of Rust users have to go through the trouble just so that those who need this don't have to write `cargo add unicode-segmentation` ?

Rust philosophy is "don't pay for what you don't use", so if your organization doesn't support third-party dependencies, they need a language with "batteries included", and not a language like Rust that comes without batteries by design.

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.

Re: Making Rust as Fast as Go

#182

Post by jfkebwjsbx »

codeflo wrote: post #173
jfkebwjsbx wrote: post #137

Earlier quoted context omitted.

Do you really need to ship them? I thought libc (CRT?) in Windows was a given, and what used to be redistributed was only the C++ ones. Is not that the case?

Thanks for the correction, Microsoft calls it the C Runtime/CRT. It‘s unfortunately complicated, and I’ll completely ignore static linking, which is possible, but not supported in many scenarios involving DLLs. It used to be the case that the CRT shipped with Windows (msvcrt.dll). That file is now considered legacy/deprecated and is no longer supported by current compilers. For several years after that, you always ha…

Thanks a lot! It indeed seems complicated...

I understand standards evolve and that they want to modularize stuff, but in the case of C the majority programs will only use the basics of the C library.

Re: Making Rust as Fast as Go

#183

Post by jfkebwjsbx »

fluffything wrote: post #174
jfkebwjsbx wrote: post #168

Earlier quoted context omitted.

> Of course it does. Many software users are stuck on multiple-year-old toolchains for various reasons, yet these systems still need to be able to handle unicode properly. So? Use the external library then. One thing does not preclude the other. > No, they cannot. Many users are stuck in older windows versions, linux versions, LTS linux versions, etc. because of their organization or their clients requirements. I wor…

> So? Use the external library then. One thing does not preclude the other. That's what everybody already does? You are proposing to, instead of doing that, move that library into the standard library where it cannot ever change. > You can provide standard Unicode handling that is good enough for 99% software out there. That's already in std? 99% of the code doesn't need to handle unicode grapheme clusters, because i…

> That's already in std? 99% of the code doesn't need to handle unicode grapheme clusters, because it doesn't deal with unicode at all.

99% of the software does not use the entirety of the std. Something is good to be in the std if for that domain it solves the majority of problems, not if everyone uses it.

> You are suggesting moving something into standard that would make unicode software harder to update

It is equally hard to update.

When people say that std libraries are harder to update they refer to changes in interfaces, not incremental updates to tables etc.

> and would make the standard library huge (>20mb larger) for all programs (the unicode tables take a lot of binary size)

Including the tables in every executable even when not used is a broken implementation.

> If a Rust user cannot write `cargo add unicode-segmentation`, they have bigger problems than not being able to handle grapheme clusters.

It is not a "problem". In most commercial software, libraries and versions are vetted. Same applies for all languages. If something is in the std, then it is already in, that is why it is useful.

> That's bad for you, but the solution isn't to make Rust bad for everybody else instead.

I don't see why that makes Rust "bad". It sounds like the opposite to me!

> Some organizations want all code in CamelCase, they can't use the standard library at all.

You are going off-topic to support your point.

Re: Making Rust as Fast as Go

#184

Post by fluffything »

jfkebwjsbx wrote: post #183
fluffything wrote: post #174

Earlier quoted context omitted.

> So? Use the external library then. One thing does not preclude the other. That's what everybody already does? You are proposing to, instead of doing that, move that library into the standard library where it cannot ever change. > You can provide standard Unicode handling that is good enough for 99% software out there. That's already in std? 99% of the code doesn't need to handle unicode grapheme clusters, because i…

> That's already in std? 99% of the code doesn't need to handle unicode grapheme clusters, because it doesn't deal with unicode at all. 99% of the software does not use the entirety of the std. Something is good to be in the std if for that domain it solves the majority of problems, not if everyone uses it. > You are suggesting moving something into standard that would make unicode software harder to update It is equ…

> I don't see why that makes Rust "bad".

And this is why people suggesting what you are suggesting never manage to achieve the change.

> 99% of the software does not use the entirety of the std

Most Rust software uses most of it.

> You are suggesting moving something into standard that would make unicode software harder to update

How do you update the unicode tables for those stuck with Rust 1.0 ? If you are going to make this claims, back them up.

> It is not a "problem". In most commercial software, libraries and versions are vetted. Same applies for all languages. If something is in the std, then it is already in, that is why it is useful.

So your organization does support third-party packages, you are just to lazy to ask for vetting ? That's not what you claimed above (you claimed that your organization does not support third-party packages at all).

The answer to this is simple, ask your organization to vet this library. If that's too complicated and takes too much effort, improve your organization's process.

Suggesting that only because you are too lazy to vet a library that library should be in standard is a laughable proposal. Think about the trade-offs, evaluate them, weight them, and if you still think doing so is worth it, write an RFC. The process for putting things into standard is open.

But if your only argument is "me,me,me,me" that's not going to go anywhere.

Re: Making Rust as Fast as Go

#185

Post by oxnrtr »

gpm wrote: post #99
arcticbull wrote: post #98

Earlier quoted context omitted.

I do believe that's quite intentional, due to the inexactness of floating-point values, it's not "right" to do that. There should be a `partial_min` function though, IMO, which has weaker guarantees.

It's absolutely intentional, and it's got being technically correct on its side, it's just frustrating.

Not really. That Rust forced total order and partial order into a sub-typing relation is a completely unnecessary, self-inflicted wound.

Re: Making Rust as Fast as Go

#186

Post by bigbizisverywyz »

arcticbull wrote: post #111
earthboundkid wrote: post #73

Earlier quoted context omitted.

If you diff föö and f though, it correctly gives an edit distance of 2. The code is weird because someone knew enough to convert the strings to slices of runes but not enough to use the rune slices consistently. :-/

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 with evil Unicode strings.

Re: Making Rust as Fast as Go

#187

Post by blablabla123 »

entha_saava wrote: post #172
arcticbull wrote: post #117

Earlier quoted context omitted.

Rust and Go are contemporaries. Rust started in 2006 at Mozilla, and the first Go public release from Google was in 2009, meaning it probably started at the same time. Except of course all the Plan 9 garbage (like Go's hand-rolled assembler) brought in to underpin Go from the 80s ;)

> 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

Re: Making Rust as Fast as Go

#188

Post by apta »

geofft wrote: post #110
apta wrote: post #81

Earlier quoted context omitted.

The original version of Docker was written in Python, and the original version of Kubernetes was written in Java, so your argument doesn't hold.

Would this be the part of my argument that doesn't mention Python (which I personally consider a systems language) at all? Or the part of my argument where I say, "you certainly could use them"?

It just means that golang isn't anything special when it comes to writing tools like these, and is in the same ballpark as python and Java (it's somewhere in between the two of them, better than python but worse than Java), and you'd have to use the same escape hatches in golang as them to implement those tools.

Re: Making Rust as Fast as Go

#189

Post by arcticbull »

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…

> 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 rely on the goodwill of third parties to provide core language functionality like complete string handling.

Re: Making Rust as Fast as Go

#190

Post by steveklabnik »

arcticbull wrote: post #189
fluffything wrote: post #181

Earlier quoted context omitted.

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…

> 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.)
Post reply on HN