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

61–70 of 191 posts

Re: First Impressions of Rust

#61

Post by eddyb »

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

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

It's public though, just not externally reachable, the private module doesn't make the trait private.

For example, if you wanted to, you could reexport the trait in the parent module (and I guess the drawback with the "sealed" pattern is accidentally doing that when it would be unsound do because of how you relied on it being "sealed", in unsafe code).

I don't think I've heard anything about plans to restrict anything based on reachability, and it would be massively backwards-incompatible so I doubt it would even be considered for an edition.

Re: First Impressions of Rust

#62

Post by peacefulhat »

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.

What do you want to do with namespaces? I don't understand.

Re: First Impressions of Rust

#63

Post by p1necone »

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…

It's a hard balance to keep. On the one hand you don't want to hold back features that you know people need, but on the other hand - once something is in stable rust the design is kind of locked in forever.

It's still a fairly young language - I think it's a good thing they're being conservative with not setting too much in stone prematurely, while still having stuff released as part of nightly to see relatively widespread use. As the language matures more and more you will see less and less important features that are missing from stable.

Re: First Impressions of Rust

#64

Post by shmerl »

cgrealy wrote: post #47
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

That depends on how ugly that consistency is.

Re: First Impressions of Rust

#65

Post by ChrisSD »

steveklabnik wrote: post #22
jmgao wrote: post #17

Earlier quoted context omitted.

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…

To be honest I think #2 was applied a bit too broadly. Sure rustc gets scrutiny but the std isn't the easiest library to contribute to. Not only is it large (by rust crate standards) but it's also tied to the compiler which adds another barrier to contributions.

Mind you, increasingly parts of the std are more like wrappers around third party crates e.g. hashbrown and parking_lot.

Re: First Impressions of Rust

#66

Post by ncmncm »

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…

When I worked for Ian Taylor (one of the creators of Go) it was a firing offense to waste time lining up columns or parentheses. Petty arranging is a waste of valuable time, time stolen from your employer if you have one. Just a one-unit indent provides all the information you need to convey to the reader.

Rust's formatter not making up artificial alignment columns is the best thing about it.

Re: First Impressions of Rust

#67

Post by qchris »

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…

Just in case anyone's not familiar with it, I figured it's worth pointing that rustfmt is also really customizable, using a `rustfmt.toml` file in the source directory. It might take a little time to get right, but it's not as if you're stuck with the default options, and a .toml file is pretty easy to play around with.

[1] https://rust-lang.github.io/rustfmt/?version=master&search=

Re: First Impressions of Rust

#68

Post by jmillikin »

pcwalton wrote: post #56

You should be able to get the size of c_ulong without any dependencies using std::mem::size_of:: (). I usually use std::os::raw instead of the libc dependency in my own crates, even though some people consider it bad style to do so. (Working in graphics it's often the case that I don't need anything from libc except a few data types.) Another note: The notion of a "compilation unit" in Rust is fuzzier than in C/C++,…

  > You should be able to get the size of c_ulong without
  > any dependencies using
  > std::mem::size_of::().
That's very useful, thank you! I hadn't noticed `std::os::raw` before, but it's exactly what I wanted.

Re: First Impressions of Rust

#69

Post by ncmncm »

kanobo wrote: post #2

Once a Rustacean always a Rustacean - a first impression will inevitably lead you down a never ending road but luckily there is a great community to support you.

I gave Rust a good solid tryout.

It turned out to be insufficiently expressive to put into libraries the semantics I want to encapsulate. I went back to C++, and have been very happy. (It's also nice that lots of people want to pay to have it done.) As with Rust, I can write 2000 lines and, once it compiles, it works.

The hardest thing about going back to C++ from Rust was getting used to putting semicolons where Rust doesn't require them. Years later it still trips me.

Re: First Impressions of Rust

#70

Post by rnestler »

vlovich123 wrote: post #58
Diggsey wrote: post #21

Earlier quoted context omitted.

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

Anyone doing OS development is still on nightly last I checked but aside from that stable has the features most people need.

I'm curios which features OS development need from nightly. Maybe inline assembly?

I've been doing some bare metal embedded projects in Rust and didn't need nightly for quite some time.

Post reply on HN