Live data from Hacker News

First Impressions of Rust

john-millikin.com

71–80 of 191 posts

Re: First Impressions of Rust

#71
post #21

Earlier quoted context omitted.

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…

If you want to profile your builds or compiler, nightly is still required.

Re: First Impressions of Rust

#72

Earlier quoted context omitted.

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…

> strange dance around nightly ("we never break things…except in nightly, which we know you are using for your project because we gated all the features behind it") Creating a beta channel or getting more of those features released in stable requires money or time.

There is a beta channel already. But you'll only get the features which will land in the next stable release anyway 6 weeks in advance.

Re: First Impressions of Rust

#73
post #10

Earlier quoted context omitted.

"we know you are using [nightly] for your project because we gated all the features behind it" yes, that kinda sucks.

I am curious which features you and your parent use that are still nightly only! The majority of our users are on stable, but there's always gonna be some cutting edge stuff that people use. (I'm a big user of asm! myself, but other than that, stick to stable.)

Recently I had to install nightly just to profile my build.

Re: First Impressions of Rust

#74

Earlier quoted context omitted.

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

You are correct that Maven is one of the first package registries to use a principled approach toward namespacing. I didn't mention it because -- and this may be rude to Maven -- I consider Maven's coordinates syntax to be closer to "primitive Go" than it's own distinct thing. If software hosted on `example.com/foo/bar` has the package name `com.example.foo/bar` then it's introducing ambiguity without much benefit.

It's not just the hosting, it's decoupled from where the project is hosted. Some packages do just use an arbitrary groupId. The reversed-domain-name convention makes sure you'll never get two different groups claiming the same name, and aligns with the convention for how code is namespaced in Java, but it is ultimately only a convention.

Re: First Impressions of Rust

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

There's a bigger problem that someone has reserved a ton of common names and they're all empty projects with nothing in them.

Re: First Impressions of Rust

#77
post #69
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 Rus…

isn't C++ more like "once it compiles, it works, but later you discover 10 places where it segfaults"?

Re: First Impressions of Rust

#78

Hey hey, this post is great! A few small comments: > It's not obvious to me why they do this – it's a documentation generator, why does it care what version of the Rust compiler I'm using? 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 tr…

> > PyPI launched in 2003, and CPAN has been running since 1995

> Neither of these support namespacing though, right?

But both have policies that prohibit name squatting, whereas crates.io has a policy which explicitly allows it.

Re: First Impressions of Rust

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

It's a local maxima, but it prohibits maximally readable code.

I just don't think it's a big win, but I've found it's a hard rhetorical battle to fight. Everyone's more cynically fearful of ugly code rather than having that extra leeway to write extremely readable code. I've definitely found this can throw the baby out with the bath water.

Re: First Impressions of Rust

#80

Earlier quoted context omitted.

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.

I use the following in my kernel project: asm, const_fn, const_generics, exclusive_range_pattern, global_asm, panic_info_message, start, untagged_unions.

Of those, I could get away with just global_asm, start, and const_generics if I had to, but the others certainly make my life easier in a kernel space without an allocator.

I'll be the first to admit that some of those are "I'm just going to embrace nightly if I'm stuck on it anyway".

Post reply on HN