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

171–180 of 191 posts

Re: First Impressions of Rust

#171

Post by boris »

majewsky wrote: post #140
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?

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

Not bad, we might steal some of these ideas for build2 if you don't mind.

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

This part is iffy: if you release a patch, it implies that it has backwards-compatible interface. So this will realistically only work for taking over the maintenance of the old package, not for replacing it with something entirely new. I think a version epoch might work for the latter.

Re: First Impressions of Rust

#172

Post by atombender »

Macha wrote: post #167
atombender wrote: post #164

Earlier quoted context omitted.

Names can be powerful. Owning a name like "fuse" implies that this is the thing called "fuse". A flat "top level" namespace encourages treating names, especially short names, as something with intrinsic value. You end up with the same problems that the .com namespace has, such as name squatting and first mover advantage. Qualifying all names removes this property from names and levels the playing field. There's no va…

But then everyone just wants @fuse/fuse rather than fuse. If one project is @fuse/fuse and the other is @atombender/fuse, the first is going to have more legitimacy, just as if they were called fuse and atombender-fuse.

In reality, that does not seem to have happened, because the top-level is your name, and people have a different relationship to their own "branding", for the most part. People/companies also usually have more than one package.

Re: First Impressions of Rust

#173

Post by nybble41 »

ssokolow wrote: post #87
rat9988 wrote: post #32

Earlier quoted context omitted.

Scrolling works with keyboard. There is nothing weird about shadow dom, it's part of the standard.

That's like saying "There's nothing wrong with using setjmp/longjmp. It's part of the standard." I firmly believe that you shouldn't need client-side JavaScript for anything fancier than things like progressively enhancing a form field into a clickable star-rating widget unless you're writing an actual "web app"... definitely not for a blog. I'm just glad the text of his articles remains readable under the influence…

This is one of the last sites that I would criticise for use of client-side JavaScript. It uses one small script to implement a few simple web components. The power required to run that script is negligible compared to what the browser itself requires merely to render static HTML. You probably produced more CO2 just breathing while writing that comment than can be cumulatively attributed to this script across all visitors to this site to date.

The shadow-DOM thing svnpenn commented on is a red herring. It doesn't interfere with keyboard scrolling, which works perfectly well. The shadow DOM is merely used to isolate CSS styling rules so that they apply to an instance of a component rather than sharing a single global namespace. The elements are still rendered as part of the parent document.

Re: First Impressions of Rust

#174

Post by Drdrdrq »

YorickPeterse wrote: post #102
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?

Honestly these questions are not that hard to answer. Just look at the likes of GitHub, GitLab, or really any source code hosting platform that supports the creation of groups. > How do we decide which person/entity gets a namespace? You get a personal one, named after your user account. In addition, you can create up to N namespaces. After that, you either have to request more or pay a small fee. This prevents names…

You mean like this?

> Just because your company is named Microsoft doesn't mean you have a perpetual and exclusive right to use that name wherever you want.

Hmmm. :)

Re: First Impressions of Rust

#175

Post by ncmncm »

ncmncm wrote: post #155
supergirl wrote: post #77

Earlier quoted context omitted.

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

That is how the propaganda goes. But in modern C++ style, memory errors just don't have many opportunities to happen. I.e., with the more powerful libraries C++14 and up enables, there is little temptation to drop to a risky level. And, anywhere you choose to, you can give it your full attention. So, overwhelmingly the bugs you do get are specification bugs: the code does what was asked, but the ask was wrong. The on…

You can down-vote all you like, but it remains true all the same.

Re: First Impressions of Rust

#177

Post by majewsky »

berkes wrote: post #152
majewsky wrote: post #140

Earlier quoted context omitted.

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

> Everything not prefixed with "user/" is a shared namespace which is handled by a team of curators. The docker "hack" of using `_` is quite a smart hack here, and works well; for me at least. E.g. https://hub.docker.com/_/postgres its clear this is some "official" build.

But when you pull it, it's just `docker pull postgres:12`, not `docker pull _/postgres:12`.

Re: First Impressions of Rust

#178

Post by majewsky »

boris wrote: post #171
majewsky wrote: post #140

Earlier quoted context omitted.

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

Not bad, we might steal some of these ideas for build2 if you don't mind. > 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. This part is iffy: if you release a patch, it implies that it has backwards-compatible…

That's something the curators would have to look out for. If you're building a green-field solution, I'd also suggest to outright reject library versions that don't follow semantic versioning. A patch version bump that changes the API? Not allowed, go bump your minor version and come back. A minor version that breaks existing users? Not allowed either. It's a really easy check. I'm honestly baffled no one's doing it yet.

(Side-note: I'm only talking about libraries here, not applications.)

Re: First Impressions of Rust

#179

Post by david2ndaccount »

nybble41 wrote: post #170
quietbritishjim wrote: post #157

Earlier quoted context omitted.

You mean never wrap code and have a really long horizontal scroll? These things are subjective and you're certainly entitled to your opinion, but is say that's fairly hardcore.

You could let the editor soft-wrap the lines in place of horizontal scroll. Done well this could be the best of both worlds—adaptive to different screen/editor sizes, and the viewer decides how to indent or align the wrapped lines according to their own preferences. However, proper expression alignment would require solid language support from the editor. (Wrapping with simple indentation wouldn't be too difficult.)

I have vim set up to do this, it’s so nice.

Re: First Impressions of Rust

#180

Post by rstuart4133 »

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!

More interesting is what you do use for file paths, if you accept that both strings and bytes don't work. The answer will be I guess a dedicated FilePath type that knows paths are lists of blobs, and the blobs can further be divided up into prefixes and an extensions.

But that doesn't really solve the problem. You still have to convert file paths to strings to print them, and strings to file paths to accept them as from the terminal and databases. For that to work the round trip had better be safe on any given platform otherwise the user can't copy and paste.

Not addressing this problem has been python3's undoing when it is used as a shell scripting replacement. Actually, it's an undoing any time you want to treat "text" as interesting ascii swimming in an unknown encoding, particularly when you want to modify that ascii. HTML with an unknown encoding is a prime example.

Post reply on HN