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

161–170 of 211 posts

Re: Making Rust as Fast as Go

#161

Post by otterley »

arcticbull wrote: post #155
FpUser wrote: post #154

Earlier quoted context omitted.

"That's a fair criticism if clumsily put" - I guess the original point was a shining example of elegance. USCIS - the same organ that asks women "have you ever been a prostitute" on citizenship tests? "Though if we're being super pedantic, there's only one human species on this planet -- species of course being defined as animals who can mate and produce viable offspring." You got me here ;)

If I'm understanding you correctly you're referring to the eligibility criteria at the back of an Adjustment of Status petition, form I-485, which is part of the green card process. I'm pretty sure the prostitution questions apply to men, too. The question is "Have you EVER engaged in prostitution or are you coming to the United States to engage in prostitution?" (Part 8, Question 35). Credit where due, I suppose, an…

Don't let the troll drag you into this. It's a pointless distraction.

Re: Making Rust as Fast as Go

#162

Post by afiori »

arcticbull wrote: post #151
fluffything wrote: post #139

Earlier quoted context omitted.

> It does not make sense either to expect someone to use bleeding edge libraries from cargo yet use an old rustc compiler. 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. > They can easily update it if needed. No, they cannot. Many users are stuck in older windows versions, linux versions, LTS lin…

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…

the point would be that the standard library should be forward compatible while crates should be backward compatible.

so that current crates work with old version of compilers/toolchains.

this applies here as each new Unicode standard requires an update of the Unicode crate. ideally the best case would be to make it so that in 20 years Rust 1.0 can still use the most updated version of Unicode fragmentation. similarly to how some C libraries insist on C89 compatibility to still work on older systems.

I guess Rust would like it if this never became indispensable but also should be possible

Re: Making Rust as Fast as Go

#163

Post by arcticbull »

otterley wrote: post #161
arcticbull wrote: post #155

Earlier quoted context omitted.

If I'm understanding you correctly you're referring to the eligibility criteria at the back of an Adjustment of Status petition, form I-485, which is part of the green card process. I'm pretty sure the prostitution questions apply to men, too. The question is "Have you EVER engaged in prostitution or are you coming to the United States to engage in prostitution?" (Part 8, Question 35). Credit where due, I suppose, an…

Don't let the troll drag you into this. It's a pointless distraction.

Indeed, I shouldn't get too far off course here haha, I just happened to know exactly what they were referring to and find that whole section amusing.

Re: Making Rust as Fast as Go

#164

Post by jfkebwjsbx »

arcticbull wrote: post #149
jfkebwjsbx wrote: post #135

Earlier quoted context omitted.

Yeah, it makes no sense to be the default. Code that expects to treat NaNs is very rare.

Safety is the whole idea behind Rust, and if you draw the line here, that's neither in line with the Rust ethos, nor particularly valuable. After all, code that "expects to handle" null was pretty rare too ;)

NaNs have nothing to do with safety (same for nulls).

It is a common misconception to conflate safety with functional expectations. A program that only calls panic() is perfectly safe.

Re: Making Rust as Fast as Go

#165

Post by arcticbull »

jfkebwjsbx wrote: post #164
arcticbull wrote: post #149

Earlier quoted context omitted.

Safety is the whole idea behind Rust, and if you draw the line here, that's neither in line with the Rust ethos, nor particularly valuable. After all, code that "expects to handle" null was pretty rare too ;)

NaNs have nothing to do with safety (same for nulls). It is a common misconception to conflate safety with functional expectations. A program that only calls panic() is perfectly safe.

Ah sorry, I didn't mean safety in the UB sense, I meant in the traditional, "do what I expect, don't surprise me" sense.

Re: Making Rust as Fast as Go

#166

Post by cesarb »

codeflo wrote: post #5

I recently did some experiments with creating small static Rust binaries, custom linking, no_std et cetera. A lot of stuff around that kind of thing is unstable or unfinished, which might be somewhat expected. But I’ve also come to the conclusion that Rust relies on libc way too much. That might be fine on Linux, where GNU’s libc is well-maintained, is a bit questionable on MacOS (as seen in this article) and is a a…

> [...] relies on libc way too much. That might be fine on Linux [...]

> My understanding is that Go doesn’t use the libc at all and makes system calls directly

Actually, the only system on which it's fine to "not use the libc at all and make system calls directly" is Linux. On MacOS, Windows, and most non-Linux Unix-like systems, you must to go through the libc or its equivalent (which on Windows is kernel32.dll and/or ntdll.dll), since the system call interface is unstable (the libc or its equivalent is distributed together with the kernel, so it's updated whenever the system call interface changes).

AFAIK, Go tried for a while to use system calls directly on MacOS; after being broken several times by operating system updates, they gave up and now go through the shared libraries like everyone else. They still insist on using direct system calls on Linux, where it works mostly fine (except for things like the DNS resolver, in which AFAIK they try to guess whether they can do directly network DNS requests, or have to go through libc; and that one time in which Go's small stacks conflicted with a misoptimized kernel VDSO using too much stack).

Re: Making Rust as Fast as Go

#167

Post by FpUser »

otterley wrote: post #161
arcticbull wrote: post #155

Earlier quoted context omitted.

If I'm understanding you correctly you're referring to the eligibility criteria at the back of an Adjustment of Status petition, form I-485, which is part of the green card process. I'm pretty sure the prostitution questions apply to men, too. The question is "Have you EVER engaged in prostitution or are you coming to the United States to engage in prostitution?" (Part 8, Question 35). Credit where due, I suppose, an…

Don't let the troll drag you into this. It's a pointless distraction.

"Don't let the troll drag you into this" - Well, hello Mr. Polite. Are you that secret admirer who downvotes my posts in batches disregarding of the subject? I did notice the pattern.

Re: Making Rust as Fast as Go

#168

Post by jfkebwjsbx »

fluffything wrote: post #139
jfkebwjsbx wrote: post #136

Earlier quoted context omitted.

> Since many programs don't need to do any kind of unicode segmentation, making it part of the standard library sounds like a bad idea. In particular, given that unicode is a moving standard, it would mean that people stuck on old Rust toolchains (e.g. LTS linux distros) cannot create binaries that do proper unicode segmentation, which does not make sense. That has nothing to do with it. You could still have a librar…

> It does not make sense either to expect someone to use bleeding edge libraries from cargo yet use an old rustc compiler. 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. > They can easily update it if needed. No, they cannot. Many users are stuck in older windows versions, linux versions, LTS lin…

> 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 work in such an organization and no, we cannot use third-party packages. The same way we cannot update our toolchain. So in most cases the point is moot.

> These updates would only apply to newer Rust toolchains, that many users cannot use. Unless you are suggesting the release of patch versions for the soon to be 100 old Rust toolchains in existence every time the unicode standard is updated.

You can provide standard Unicode handling that is good enough for 99% software out there. If you need to be on the bleeding edge, then use the bleeding edge library or rustc.

It is pretty simple, actually!

Re: Making Rust as Fast as Go

#169

Post by jfkebwjsbx »

arcticbull wrote: post #165
jfkebwjsbx wrote: post #164

Earlier quoted context omitted.

NaNs have nothing to do with safety (same for nulls). It is a common misconception to conflate safety with functional expectations. A program that only calls panic() is perfectly safe.

Ah sorry, I didn't mean safety in the UB sense, I meant in the traditional, "do what I expect, don't surprise me" sense.

Safety in Rust's context is UB-free, memory errors-free, data race-free.

Safety in software engineering is more about designing systems with some degree of assurance against certain failures, but not about surprises or expectations of a programmer.

The usage you call traditional is perhaps common, but not really rooted in anything in software engineering. I'd call it an informal meaning, maybe.

PS. No need for apologies!

Re: Making Rust as Fast as Go

#170

Post by gpm »

jfkebwjsbx wrote: post #169
arcticbull wrote: post #165

Earlier quoted context omitted.

Ah sorry, I didn't mean safety in the UB sense, I meant in the traditional, "do what I expect, don't surprise me" sense.

Safety in Rust's context is UB-free, memory errors-free, data race-free. Safety in software engineering is more about designing systems with some degree of assurance against certain failures, but not about surprises or expectations of a programmer. The usage you call traditional is perhaps common, but not really rooted in anything in software engineering. I'd call it an informal meaning, maybe. PS. No need for apolog…

Safety as in unsafe blocks means what you say. But safety as in why so many people use rust is actually what arcticbull says. I think this is something that gets lost on a lot of people who don't use rust. The first form of safety is properly called memory safety.

Rust as a language isn't just designed to avoid undefined behavior, it's designed to make you write correct code, where correct means it does what you want it to. Obviously rust doesn't always succeed at that broader goal, but it actually does a pretty good job all things considered.

Arcticbull's description of rust's ethos is spot on.

Post reply on HN