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

21–30 of 191 posts

Re: First Impressions of Rust

#21

Post by Diggsey »

saagarjha wrote: post #7
thenewwazoo wrote: post #5

I went into this expecting yet another barrage of complaints about lifetimes, but was very pleasantly surprised. This is probably one of the most thoughtful experienced-programmed new-to-Rust reviews I've read in a long, long time. I frankly don't have much to add, except to say that, once you really understand the language and start building complex projects, this article really does describe the real issues you run…

I think I am familiar with Rust–I spent a week or so working with it–and I ran into many of these exact issues. I appreciate it very much when someone can give a viewpoint of of using a language beyond the superficial one ("arrays start at one in Lua"), or complains about something core to the language ("C pointers are confusing") and actually says something you will run into but is not obvious from having a basic kn…

> which we know you are using for your project because we gated all the features behind it

I don't think that's really fair, or at least hasn't been true for a long time now. Use of the stable channel far exceeds use of nightly according to all the surveys. At my company we've always stuck to the stable channel, and even in my own personal projects where I have no need for stability, I don't remember the last time I used a nightly feature, simply because I haven't found the need to...

I don't believe there are many cases left where you're forced to use nightly: most of the cases where people are using it is because there's a "nice to have" feature, not because that feature is actually essential. Even rocket, which was famed for using a ton of nightly features, now works on stable Rust.

Re: First Impressions of Rust

#22

Post by steveklabnik »

jmgao wrote: post #17
adamnemecek wrote: post #11

Unix-stuff as a part of the standard library is a terrible idea. Making your own crate is simple enough. Same with OS-dependent functionality. Re: crates namespaces, that is a crates decision, not necessarily Rust'. You can always publish your crate on github and include it with "package = { git = ... }" and you'll get the same thing as in go.

Why is that not true for the rest of the standard library? You don't really need a HashMap in your standard library, or mutexes, just a memory allocator and atomics.

Historically, the criteria for inclusion in the standard library is, does it fall under one of these three categories:

* Used in the vast majority of Rust programs.

* Reasonably common things that require a lot of unsafe to implement.

* Traits for interoperation purposes.

HashMap and mutexes fall under #2. The idea is that they'll receive significantly more scrutiny, and this is a good thing for the ecosystem.

(These are guidelines, not hard and fast rules, so not literally everything fits here, but that's the framework that was used to think about what should be included or not, generally.)

Re: First Impressions of Rust

#23

Post by anonova »

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.

Re: First Impressions of Rust

#24

Post by jmillikin »

migueloller wrote: post #12
jmillikin wrote: post #8

Earlier quoted context omitted.

> rustdoc, being a part of the Rust distribution, > has the same stability guarantees that Rust does: > once it gains a feature, it will never go away. We > (well, not me I don't really work on rustdoc, to be > clear) need the capacity to try out new features > without committing to them, same as features in the > language. I guess I expect rustdoc and rustc to be much less tightly coupled, so that I could use (for e…

Would you be willing to expand on why using strings for file paths turns out to be unworkable? Very curious what the obscure reasons are!

Short version: file paths are an OS-specific construct, and not all OSes have paths that can be round-tripped through Unicode.

The first bad option is to say "paths are bytes", which is true on traditional POSIX platforms. Then you run your code on macOS and discover it's processing your bytes as UTF-8 and applying Unicode normalization. After fixing that you try porting to Windows and get to learn about `wchar_t`.

The other bad option is to say "paths are (Unicode) strings", which works fine on Windows and macOS. It works 90% of the time on POSIX, but you'll eventually find users with non-UTF8 file paths and then you're in trouble.

My first hand experience with this going wrong is GHC, which started off with raw bytes, then moved to strings using a bad conversion function, then they tried to work around the issue by placing non-UTF8 bytes into a Unicode reserved area.

Java also has problems because it represents paths as strings and tries to use the libc locale for decoding. https://github.com/bazelbuild/bazel/pull/10111 is an example of how this breaks software in ways that are difficult to work around.

Re: First Impressions of Rust

#25

Post by jmillikin »

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

Re: First Impressions of Rust

#26

Post by jmillikin »

steveklabnik wrote: post #16
jmillikin wrote: post #8

Earlier quoted context omitted.

> rustdoc, being a part of the Rust distribution, > has the same stability guarantees that Rust does: > once it gains a feature, it will never go away. We > (well, not me I don't really work on rustdoc, to be > clear) need the capacity to try out new features > without committing to them, same as features in the > language. I guess I expect rustdoc and rustc to be much less tightly coupled, so that I could use (for e…

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

  > Yes, but that doesn't change with rustc vs cargo
  > though; it's still a single rustc invocation to
  > compile all those files.
When using Bazel instead of Cargo the developer can split the build graph into much smaller crates (down to one per module if desired), and still treat the entire assembly as one package.

I should emphasize that this is a limitation of Cargo, not rustc. rustc does just fine with big libraries, it's only Cargo that makes it difficult to write hundred-crate packages.

Re: First Impressions of Rust

#27

Post by svnpenn »

This guys website is weird.

I first noticed as scrolling doesnt work with the keyboard. Upon inspection of HTML hes using weird shadow dom stuff.

Why do people do stuff like this? Its a static site, modern HTML and CSS are huge and can handle nearly any situation.

Re: First Impressions of Rust

#28

Post by wokwokwok »

Seems a little unfair to cargo to give it a scathing review when your alternative ecosystem is C++ or Haskell.

The basic complaint boils down to "packages aren't namespaced" and "someone already took the 'fuse' package", which has been a long running controversy for exactly that name-squatting reason.

However, Cargo is great.

> Rust's default build system (Cargo) and package repository (crates.io) are the opposite. They combine the worst parts of Cabal/Hackage and NPM, resulting in a user experience that is somehow inferior to both.

No. They don't. That's your opinion, not a fact, and I completely disagree. Lots of people disagree. Your arbitrary assertion is unsubstantiated and I reject it. :) Perhaps you meant "resulting in a user experience that I found somehow inferior to both".

If you don't like it, and you prefer to use bazel, then by all means be welcome to do so... but I think a little bit of acknowledgement is in order that ... frankly, that behavior should be discouraged.

We want a unified good build system for rust, not a ridiculous mess of difference package managers and build systems like in some other language ecosystems. Sometimes, conformity is a better approach, and I would be deeply saddened to see rust go that way.

I'm very impressed with the efforts to bring wasm support to cargo, and the other initiatives.

Be nice. Lots of people work really hard on cargo. They're doing a great job.

Re: First Impressions of Rust

#29

Post by Ericson2314 »

Yes thank you for not fauning over Cargo like many other reviews.

The simple fact is Cargo did not learn from prior art to the extent Rust did.

Things have gotten better, but Rust is still better designed. Hopefully Cargo can someday catch up.

Re: First Impressions of Rust

#30

Post by lmm »

jmgao wrote: post #17
adamnemecek wrote: post #11

Unix-stuff as a part of the standard library is a terrible idea. Making your own crate is simple enough. Same with OS-dependent functionality. Re: crates namespaces, that is a crates decision, not necessarily Rust'. You can always publish your crate on github and include it with "package = { git = ... }" and you'll get the same thing as in go.

Why is that not true for the rest of the standard library? You don't really need a HashMap in your standard library, or mutexes, just a memory allocator and atomics.

If the "platform" concept works out then those things probably should move out of the standard library. Look at how many people had to upgrade language versions to deal with DoS attacks on their HashMap implementations, when it should've been just a case of upgrading their HashMap library.
Post reply on HN