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

First Impressions of Rust

john-millikin.com

Post reply on HN
Print view View original

41–50 of 191 posts

Re: First Impressions of Rust

#41

Post by oconnor663 »

jmillikin wrote: post #25
erickt wrote: post #13

> Closed-world ("sealed") traits. Rust's rules against private types in the public API are good civilization but they make it difficult to define pseudo-private traits like Mount that I want users to name but not implement or call into. Rust actually supports sealed traits by using public traits in private modules. See this for how to use it, and how it works: https://rust-lang.github.io/api-guidelines/future-proofin…

I'm aware of that workaround and do use it in `rust-fuse`[0], but I'm not satisfied for two reasons: * It's not understood by rustdoc, so I have to manually document that the trait is sealed. * It technically violates Rust's rules against private symbols in the public API, so a future version of rustc might deprecate or remove that functionality. [0] https://github.com/jmillikin/rust-fuse/blob/a6ad16d1127d36f8...

> a future version of rustc might deprecate or remove that functionality

Are you sure about this? My understanding is that stable Rust limits itself to compatibility breaks that are both rare and trivially worked around. (Like adding a new inherent method to a standard type that happens to have the same name as your trait method.) Even in a new edition, I think there's a very heavy leaning towards changes that can be automated by `cargo fix`. Removing this idiom seems like it would be much too big of a change. (The obvious automatic fix -- just inserting `pub` as needed -- would presumably make a bunch of currently safe APIs unsound.)

Re: First Impressions of Rust

#42

Post by breatheoften »

da39a3ee wrote: post #39
breatheoften wrote: post #37

An insufficient auto-formatter is very frustrating ... I think there are very smart older programmers who don't appreciate this fact properly. They sort of have a belief that there does not exist a "sufficiently good" good code formatter for all users -- and so therefore code formatter should have tons of configuration options to satisfy a range of style choices. I think that opinion belongs in the past (with the dis…

Whether reformat is called on save is up to your text editor and has nothing to do with the language.

Yes but there is no reason a language ecosystem can't assumes that this functionality is present, implemented in canonical form, and that it is a language use error not to enable.

If the language designers assume the capability exists and will be used -- they can specifically evolve the language based on this assumption. All thats needed is a super high quality, compiler-provided implementation of the functionality -- and to set the expectation -- "sorry you have to wire this functionality up -- otherwise your code is going to be more likely to break if you edit the source files over time while also upgrading your compiler over time."

I'm benoaning the fact that no languages I'm aware of have advertised such a position as part of their evolution plan ...

Re: First Impressions of Rust

#43

Post by ChrisSD »

throwaway894345 wrote: post #40
jmgao wrote: post #15

Earlier quoted context omitted.

If your String type must be valid Unicode (which is true for pretty much every language that isn't C++), it cannot represent all paths. On most unixy filesystems, filenames are arbitrary byte sequences which aren't valid UTF-8, and on windows, NTFS stores filenames as UTF-16, but it allows unpaired surrogates.

What languages require string types to be valid Unicode? Go for example let’s you put anything in a string; it’s only Unicode if you put Unicode into the string including via creating string literals.

Rust, Java, Swift...

Re: First Impressions of Rust

#44

Post by zamalek »

> I eventually gave up on trying to make the formatted rust-fuse code look pretty, and settled for "consistent".

Even though it's a bit ugly, this is a big win.

As for why it does this, from my experience, rust-fmt will try to keep lines under a column limit but not greedily. e.g. if a params list would extend past the limit, then all params get a newline. It seems to try to balance horizontal estate and vertical estate and I've become used to that (even though it is inconsistent at times).

Any formatting rule is going to fall over eventually. Rust-fmt seems to make sane choices the majority of the time.

Re: First Impressions of Rust

#45

Post by cptroot »

throwaway894345 wrote: post #40
jmgao wrote: post #15

Earlier quoted context omitted.

If your String type must be valid Unicode (which is true for pretty much every language that isn't C++), it cannot represent all paths. On most unixy filesystems, filenames are arbitrary byte sequences which aren't valid UTF-8, and on windows, NTFS stores filenames as UTF-16, but it allows unpaired surrogates.

What languages require string types to be valid Unicode? Go for example let’s you put anything in a string; it’s only Unicode if you put Unicode into the string including via creating string literals.

I think python also takes the approach where strings must be valid unicode. Both Rust and Python use their String types to represent valid unicode, and something else ([] and byte strings, respectively) to represent other encodings and invalid unicode.

Re: First Impressions of Rust

#46

Post by TheCycoONE »

anonova wrote: post #23

I find it absolutely frustrating that Rust packaging/crates.io doesn't support namespaces. The arguments I've read are always theoretical/what ifs, but I've yet to be convinced the current situation is better than the practical benefits of namespaces.

Conversely the arguments I've heard for namespaces is that multiple people want to reimplement or make bindings for the same C library.

In maven central, in my anecdotal experience, namespaces usually either distinguish forks of the same library, or to group related libraries. There has never been, in my experience, a case where I wanted two packages with the same name in different namespaces.

I think a better system of handling unmaintained crates; with the possibility of reclaiming a name would go a long way with the author's use case. I don't have any great ideas here: package with no update in some time (a year?) is eligible. Someone requests to take over name - the author is notified and has a period of time to click an "I'm still here" button. If they don't - new author gets the name. Some 'super version' number is incremented so crate authors opt into the new or old foo. That last part is where I'm the most hesitant.

Re: First Impressions of Rust

#47

Post by cgrealy »

zamalek wrote: post #44

> I eventually gave up on trying to make the formatted rust-fuse code look pretty, and settled for "consistent". Even though it's a bit ugly, this is a big win. As for why it does this, from my experience, rust-fmt will try to keep lines under a column limit but not greedily. e.g. if a params list would extend past the limit, then all params get a newline. It seems to try to balance horizontal estate and vertical est…

Consistency > prettiness

Re: First Impressions of Rust

#48

Post by steveklabnik »

jmillikin wrote: post #33
steveklabnik wrote: post #31

Earlier quoted context omitted.

Ah, so you're not saying that you take the same project and port it from Cargo to Bazel and it somehow does less work, you're saying that it's easier to make projects with a larger number of smaller crates with Bazel than Cargo? That would be the bit I'm missing, Bazel and Cargo should invoke rustc the same amount of times per crate: once. Cargo doesn't change the compilation model of the language. (Sorry, I feel a b…

Yep, exactly. If I were building rust-fuse with Bazel I would probably split it into about 4 crates (fuse_kernel, fuse_io, protocol, server). This is what I tried to do in Cargo and gave up because of the crates.io packaging requirement.

Gotcha. You can use path as a dependency if you also use the version as a dependency, and it’ll use the path locally but the version when you publish. Maybe that needs to be better documented and would have just fixed your issue. (This is described at https://doc.rust-lang.org/stable/cargo/reference/specifying-... )

Re: First Impressions of Rust

#49

Post by steveklabnik »

escardin wrote: post #34
steveklabnik wrote: post #16

Earlier quoted context omitted.

> I guess I expect rustdoc and rustc to be much less tightly coupled Yeah, and that could work in theory. The thing is, rustdoc uses the compiler as a library, so they actually are pretty tightly coupled. This causes a lot of pain but also has a bunch of upsides. I really want to see a rustdoc that is not, but it's gonna take a long time. > That's correct. Cool, I thought so, I just wasn't 100% sure! I think it's int…

> Cool, I thought so, I just wasn't 100% sure! I think it's interesting how different people take away different things here, to me, this demonstrates that you don't have to have namespaces; many of the largest ecosystems do not and have not had them. We did learn a lesson there, just didn't come to the same conclusion that you did. This one is more controversial within the community though, many people do agree with…

Sure, but that’s not really what I was talking about. Citing maven would have made the point stronger for exactly that reason!

(And the lesson isn’t that either, the claim was never “this feature is terrible and ruins the language”, there very much are successful examples. The claim is that the lack of the feature does not mean failure.)

Re: First Impressions of Rust

#50

Post by jmillikin »

steveklabnik wrote: post #48
jmillikin wrote: post #33

Earlier quoted context omitted.

Yep, exactly. If I were building rust-fuse with Bazel I would probably split it into about 4 crates (fuse_kernel, fuse_io, protocol, server). This is what I tried to do in Cargo and gave up because of the crates.io packaging requirement.

Gotcha. You can use path as a dependency if you also use the version as a dependency, and it’ll use the path locally but the version when you publish. Maybe that needs to be better documented and would have just fixed your issue. (This is described at https://doc.rust-lang.org/stable/cargo/reference/specifying-... )

That requires publishing the internal crates as separate entries in crates.io, if I understand correctly, which I don't want to do (see the final section on crates.io's packaging model).

Ideally I could have a single crates.io package, with a single tarball, containing multiple crates. The internal crates would not be exposed to users, wouldn't have versions, wouldn't be on docs.rs, and so on.

Post reply on HN