Live data from Hacker News

First Impressions of Rust

john-millikin.com

151–160 of 191 posts

Re: First Impressions of Rust

#151

Earlier quoted context omitted.

Mind you - I have joined places that were genuinely crazy (no source control, no backups, deployment by RAID...) where some things needed fixed immediately . That was a long time ago though.

> deployment by RAID I'd like to hear that story.

The company supplied on-premise server 'appliances' for a particular market niche.

To create a new deployment, find an existing server (usually at an existing customer), take out a mirrored RAID disk and replace it with a blank one. When mirroring complete put old one back in and take your new copy and use it in a new server for the new customer....

Repeatable build process, repeatable deployment process - who needs that when you have the power of RAID-1!

Fortunately, it was a long time ago....

Re: First Impressions of Rust

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

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

Re: First Impressions of Rust

#153
post #53

Earlier quoted context omitted.

Is it just prettiness though? When I worked in the defence industry (~15 years ago now), a lot of the coding standards for C/C++ (which was starting to be used more and more over ADA at the time) were very strict on the matching alignment of things like open / closing braces, so things like hanging braces were not allowed, both opening and closing braces had to be on their own lines. The argument behind this was it m…

Maybe, maybe not. Is the potential benefit even worth fighting over? Style is just full of so many subjective details that every discussion ends in. And everybody has their favorite it's un-fucking-readable . My oppinion converged on "Fight it out and tell me what options in $formatter I need to set. Don't even tell me reasonings, just the options. leaves room ". I'd rather drink coffee than have the next horizontal…

I lean to the other side.

In a way that I tell the requester "you better have some really, really good reason for wasting my time on this".

Hell, I've even had a new hire prepare an entire presentation to convince us to change the line-length to something different than "The Language Standard".

"We follow the language standard" and if you don't like it, convince upstream (This was Rubocop/Ruby) is another one I've used in the past.

Naturally both people just gave up. There really is a better way to spend time than on tuning and tweaking a linter. Nearly all linters have some way to document and define very local exceptions for that case when some external__dependency_IsMxing_camel_case or whatever.

Re: First Impressions of Rust

#154

Earlier quoted context omitted.

> deployment by RAID I'd like to hear that story.

The company supplied on-premise server 'appliances' for a particular market niche. To create a new deployment, find an existing server (usually at an existing customer), take out a mirrored RAID disk and replace it with a blank one. When mirroring complete put old one back in and take your new copy and use it in a new server for the new customer.... Repeatable build process, repeatable deployment process - who needs…

Wow. That's both amazing that somebody thought to do that and it worked, and terrifying that it became the official solution for production deployments.

Re: First Impressions of Rust

#155
post #69

Earlier quoted context omitted.

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

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 only way to avoid those is to pay attention. Anything that steals attention generates them, in C++ as in Rust.

Old, pre-C++11 codebases (and codebases still written that way, or in C-with-classes style) suffer more. Mozilla and Google have a lot of old code.

Re: First Impressions of Rust

#156
post #141

Earlier quoted context omitted.

Imagine if every repository you pushed to GitHub had to have a globally unique name, rather than account/whatever-you-like.

So account -whatever-you-like then?

That is not the same, because ownership of _account_ isn't enforced if it's just a string. Imagine someone else uploading qayxc-resume, for example.

Re: First Impressions of Rust

#157

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

I don't like either of these. Keep it all on one line.

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.

Re: First Impressions of Rust

#158
post #69

Earlier quoted context omitted.

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

Kinda yeah, but more worryingly, 10 years later you discover it had an exploitable buffer overflow vulnerability the whole time. Now you have no idea who else has known about it, how long they've known, what systems they've compromised in what way using it, etc.

Re: First Impressions of Rust

#159
post #107
post #69

Earlier quoted context omitted.

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…

What couldn't you express satisfactorily?

Almost every feature of C++ is there to aid making powerful libraries. It has dozens that Rust lacks, more added with each Standard, and they work in synergy.

The primordial enabler in '98 was template partial specialization, that made the STL possible: same name with different types uses a different implementation.

Re: First Impressions of Rust

#160
post #65

Earlier quoted context omitted.

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.

Yes, I think this calculus changes over time. Back in the day, I think this reason was more important than it is now.
Post reply on HN