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

91–100 of 191 posts

Re: First Impressions of Rust

#91

Post by kibwen »

pjmlp wrote: post #71
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…

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

That's beside the point of what's being discussed here. The concern is that using unstable feature flags in your code, which only work on nightly, allows your code to be broken by compiler upgrades. But using nightly doesn't magically introduce unstable feature flags. There's no compability hazard from merely compiling a compiles-on-stable codebase with a nightly compiler for whatever reason.

Re: First Impressions of Rust

#92

Post by kibwen »

ansible wrote: post #14
k__ wrote: 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.

The asm!() to llvm_asm!() was a pain.

The silver lining is that the reason for that change was because a proposal for stable inline assembly is actually making progress now, which is IMO fantastic and long overdue.

Re: First Impressions of Rust

#93

Post by kibwen »

Ericson2314 wrote: post #29

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.

If this is referring to namespacing, that's a crates.io concern, not a Cargo concern. Cargo is fully capable of using other registries, and there's nothing stopping those registries from using namespaces to organize and disambiguate crates.

Re: First Impressions of Rust

#94

Post by vaylian »

peacefulhat wrote: post #62
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.

give everyone an equal chance to pick a good name

Re: First Impressions of Rust

#95

Post by pjmlp »

kibwen wrote: post #91
pjmlp wrote: post #71

Earlier quoted context omitted.

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

That's beside the point of what's being discussed here. The concern is that using unstable feature flags in your code, which only work on nightly, allows your code to be broken by compiler upgrades. But using nightly doesn't magically introduce unstable feature flags. There's no compability hazard from merely compiling a compiles-on-stable codebase with a nightly compiler for whatever reason.

Sorry if I thought tooling capabilities were a relevant compiler feature then.

Re: First Impressions of Rust

#96

Post by ChrisSD »

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.

How do we decide which person/entity gets a namespace? What about namespace squatting? What if there's a dispute? What do we do about all the currently un-namespaced crates? How would Rust (the language) understand namespaces? How would cargo work with them?

Re: First Impressions of Rust

#97

Post by quietbritishjim »

> it doesn't even properly align the parenthesized expression after line-breaking it:

Fair enough if that's not your preference for how parenthesized expressions should be broken across lines, but this quote makes it seem like it's objectively wrong. In fact it's very much a matter of opinion, and personally I hate the style of line breaking that he describes as "properly" aligned because you end up with a distracting pattern of indentation, and parameters get all squished into a tall narrow column:

    x = long_function_name(first_param,
                           second_param,
                           another_fn(x
                                      + y
                                      + z))
Yuck! In Clang-format, you can avoid this with the "AlignAfterOpenBracket: AlwaysBreak" option, which also wraps the first parameter / operand to the next line if it can't all fit onto one line:

    x = long_function_name(
            first_param,
            second_param,
            another_fn(x + y + z))
Just to reiterate: I appreciate that many people would still prefer the first style, and of course that's a legitimate opinion. My point is just that it's also a legitimate opinion to prefer the second style, not something you can describe as "not properly aligned".

Of course this is a nitpick on an excellent article.

Re: First Impressions of Rust

#98

Post by rkangel »

quietbritishjim wrote: post #97

> it doesn't even properly align the parenthesized expression after line-breaking it: Fair enough if that's not your preference for how parenthesized expressions should be broken across lines, but this quote makes it seem like it's objectively wrong. In fact it's very much a matter of opinion, and personally I hate the style of line breaking that he describes as "properly" aligned because you end up with a distractin…

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

It turns out that most aspects of coding style are subjective and are fine once you get used to them. The *-fmt tools that are now the fashion get everyone past that initial stage of formatting things as you personally would and get you used to a common style.

Maybe one person (the author of the style tool) is completely happy with the chosen style, but consistent is more important than personal preference on details.

Re: First Impressions of Rust

#99

Post by rkangel »

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.

Everyone complains that 'fuse' is taken so they have to use something with qualifiers (e.g. rust-fuse), and then they propose to fix this with a solution that requires that everyone uses qualifiers for everything.

It's a bit more consistent in that no-one gets good names, but is it really such a problem that a few people happened to get in early enough that they could call their library 'fuse'?

Re: First Impressions of Rust

#100

Post by twic »

ChrisSD wrote: post #96
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.

How do we decide which person/entity gets a namespace? What about namespace squatting? What if there's a dispute? What do we do about all the currently un-namespaced crates? How would Rust (the language) understand namespaces? How would cargo work with them?

As a baseline, just do it exactly like in Java/Maven, where it has been absolutely fine for almost twenty years.
Post reply on HN