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

131–140 of 191 posts

Re: First Impressions of Rust

#131

Post by jmillikin »

ChrisSD wrote: post #117
ChrisSD wrote: post #96

Earlier quoted context omitted.

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?

Great replies so far. I'd add that if people want namespacing to actually happen they need to collaborate on an RFC ( https://github.com/rust-lang/rfcs/blob/master/0000-template.... ). Ideally someone would post a pre-RFC to internals.rust-lang.org so it can be improved before formal submission. Any such RFC needs to take in to account previous discussions (and appreciate that the crates.io team is small). E.g.: http…

I've never written a Rust RFC before, but I know how to start forum topics. Let's go!

https://internals.rust-lang.org/t/pre-rfc-user-namespaces-on...

Re: First Impressions of Rust

#132

Post by MrBuddyCasino »

dthul wrote: post #105
ChrisSD wrote: post #96

Earlier quoted context omitted.

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?

If we really wanted, Cargo could start supporting namespaces and everything currently on crates.io could go to a new default namespace (and would still be reachable under the non-namespaced name for older versions of Cargo). I don't think Rust itself needs to know about namespaces (as in: johndoe/fuse would still just expose a crate named "fuse". Crate name collisions can be handled with Cargo's already existing rena…

> DNS based verification (which has lots of drawbacks itself)

Maven is doing this to great success. The namespace issue has been solved successfully, just copy what they do. It took years until they arrived at the current system, and it works well. What drawbacks are you thinking of?

Re: First Impressions of Rust

#133

Post by twic »

aorth wrote: post #124
dthul wrote: post #108

Earlier quoted context omitted.

I don't know Maven much so please correct me if I'm wrong, but I believe there is a substantial difference: In Maven anybody could publish a package that starts with "com.google". The namespacing proposals I have seen for crates.io assume that namespaces are exclusive to a single entitity though. So once someone that is not Google reserves the "google" namespace, Google itself would not be able to publish crates unde…

I just published my first Java package on Maven Central via Sonatype OSSRH this week and when you sign up you have to verify your "groupId" (aka your namespace) using either DNS TXT records or with com.github.username where they ask you to create a repository with a given name to prove you control it. So you could easily publish a package using the com.google namespace on your blog or whatever, but not on Maven Centr…

Meanwhile, JCenter doesn't do any checking like that.

Which definitely leads to an oddity in Java land - most libraries are in Maven Central, which requires some effort to submit to, but which is reasonably carefully policed, and some are in JCenter, which is easy to submit to, but is not policed. And then some libraries are in registries run by their maintainers.

Modern build tools make it easy to add registries. In practice, JCenter doesn't seem to have problems from the lack of policing. So this is very much an oddity rather than a problem.

Re: First Impressions of Rust

#134

Post by dthul »

MrBuddyCasino wrote: post #132
dthul wrote: post #105

Earlier quoted context omitted.

If we really wanted, Cargo could start supporting namespaces and everything currently on crates.io could go to a new default namespace (and would still be reachable under the non-namespaced name for older versions of Cargo). I don't think Rust itself needs to know about namespaces (as in: johndoe/fuse would still just expose a crate named "fuse". Crate name collisions can be handled with Cargo's already existing rena…

> DNS based verification (which has lots of drawbacks itself) Maven is doing this to great success. The namespace issue has been solved successfully, just copy what they do. It took years until they arrived at the current system, and it works well. What drawbacks are you thinking of?

My initial concern was that a DNS approach would force anybody who wanted to publish to crates.io to own a domain. In a parallel thread someone mentioned that Maven allows to acquire a "com.github.username" namespace in case you don't have (or don't want to use) your own domain. That might work for crates.io as well, since it already requires you to have a Github account anyway.

Re: First Impressions of Rust

#135

Post by ragnese »

EamonnMR wrote: post #126

I'm surprised they didn't mention the elephant in the room: the borrow checking, boxes, and other ways that the code forces you to do the work of making sure your code is bug free before it will compile.

Probably because that's the entire point of Rust and has already been blogged to death. There's nothing new to say about the borrow checker or boxing heap-allocated objects.

Re: First Impressions of Rust

#136

Post by tibbe »

jmillikin wrote: post #120
rkangel wrote: post #99

Earlier quoted context omitted.

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'?

I'm fine with qualifiers, but I don't want useless qualifiers. "rust-" or "-rs" is useless because it's on crates.io. "lib" or "-lib" similarly, unless it's part of a pair with a binary of the same name. Here's a partial list of FUSE server implementations on crates.io: * fuse * cntr-fuse * drakey-fuse * fuse_mt * fuser * fuse-rs * polyfuse * fuse3 * yarf Why do we make people come up with custom prefixes or opaque c…

Why not user-fuse?

Re: First Impressions of Rust

#137

Post by dthul »

vaylian wrote: post #118
twic wrote: post #100

Earlier quoted context omitted.

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

I think it is unreasonable for people to need to own a domain (or at least pretend to own it) just to publish a package. Not everyone is part of some company or runs a website.

In a parallel thread someone mentioned that Maven allows you to obtain a "com.github.username" namespace based on your Github account, which is already a requirement to publish on crates.io anyway.

Re: First Impressions of Rust

#138

Post by majewsky »

jmillikin wrote: post #116
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…

Your formatting style works too, and rustfmt will switch to it for function calls that exceed the line width limit. rustfmt is not properly handling alignment in combination with hard tabs. It should either break after the open paren and indent both names, or break near the '+' and align them both. Good output if aligned: field: (value_1 + value_2) field: (value_1 + value_2) Good output if indented: field: ( value_1…

My personal impression from these examples you gave is that line-breaking inside an arithmetic expression is generally a horrible idea. If you have something like

  let result = (first_long_variable + second_long_variable) * (third_long_variable + fourth_long_variable);
My position is that the only way to make this look good under a line length limit is

  let factor1 = first_long_variable + second_long_variable;
  let factor2 = third_long_variable + fourth_long_variable;
  let result = factor1 * factor2;
(where of course `factor1` and `factor2` would be given names that make sense in context)

Re: First Impressions of Rust

#139

Post by theon144 »

EamonnMR wrote: post #127
p1necone wrote: post #55

Earlier quoted context omitted.

Imo lifetimes aren't that complex. They're just a wholly new programming language feature - learning lifetimes is hard because you're simultaneously learning the syntax and the concept. Compare to something like generics where it's roughly the same idea in most languages that feature them, you just need to learn the syntax and maybe some edge details that differ between languages (Contravariance and Covariance say he…

I don't think the problem with lifetimes is that they are complex, it's that other languages handle lifetimes for you, but Rust outs to onus on you to manage them. C++ also has complex object lifetimes but if you don't invoke that complexity you don't need to deal with it.

>C++ also has complex object lifetimes but if you don't invoke that complexity you don't need to deal with it.

I would tend to disagree?

In C++, I regularly ran into issues where I "invoked" the complexity with memory/object management completely incidentally, and as the saying goes, shot myself in the foot (or rather, both feet, because lifetime management issues often result in heisenbugs and other really nasty phenomena).

Rust makes that complexity explicit, which is really an analogous argument as with static/dynamic typing; it's not that the dynamic languages "handle typing for you", and "static" simply requires more work. Rather, you're forced to deal with it at the very start, instead of down the road.

Then again I'm rather new to Rust, so I might misunderstand you?

Re: First Impressions of Rust

#140

Post by majewsky »

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?

> How do we decide which person/entity gets a namespace? What about namespace squatting? What if there's a dispute?

My proposal is to give everyone a namespace corresponding to their crates.io username, so if I want to publish a JSON library, it would be "user/majewsky/json".

Everything not prefixed with "user/" is a shared namespace which is handled by a team of curators. If someone wants to publish into the shared namespace, they need to apply for a package name. So if I think my JSON library should be the standard, I could apply for having it aliased to "json" or "encoding/json" or whatever. The curators would be allowed to impose an overall structure in the shared namespace to aid those who browse it.

Crucially, the curators should have the right to revoke an existing lease. If someone publishes their JSON library into the shared namespace as "json" and then later down the line abandons the project, other community members should be allowed to apply to take over that name. Of course, existing releases would stay untouched, but if I stopped maintaining my JSON library at 1.3.7, someone else should be allowed to take that over and publish 1.3.8 or later.

I would also impose the limitation that 0.x versions are not allowed in the shared namespace. If you want a nice package name, you should be ready to commit to at least a somewhat stable interface.

> How would Rust (the language) understand namespaces?

It's not hard to imagine a Rust that works with namespaced crates. What is hard is finding a solution that's backward- and forward-compatible.

Post reply on HN