phaylon

Something else I usually don't see: A system hitting a fail-safe is a lot easier to detect and handle from the outside than one that just enters an unknown invalid state.

Like, if the rule were "Always-Keep-Running" then hospital equipment power supplies wouldn't have circuit breakers that cut the power when something is wrong. But cutting power seems lot easier to detect for the backup power supply so it can fully take over.

I've felt kind of miffed in the past for not being able to join Discord communities. Discord always wanted my phone number, and I wasn't ready to share that.

I am no longer miffed :)

Not only Trump. Without the rules, Musk or Putin could run as well, the latter even work-from-home style. Also, if justice being blind is so bad before an election, why not after? Figuring out who won shouldn't involve any courts either. The public will just need to figure out who really won for themselves!

(/s just in case)

This just gives all the power to abusers.

I'd rather fix the abuse (the cause of the particular burnout), because it impacts not only the Rust developers, but all current and future contributors, and indirectly us users as well.

You know, people outside the Rust community keep bringing this up as some kind of argument against it. But to me, it's one of the biggest points for it; because the important thing about `unsafe` encapsulation isn't what's inside of it, but what's possible on the outside.

Small nitpick: Fortunately, `Rc` and `Arc` actually don't require the nightly feature.

From the Linux Plumbers Conference from a couple days ago: https://www.youtube.com/watch?v=Xw9pKeJ-4Bw&t=8040s (Warning: It's a longer stream, but the timestamp should be where the driver is shown. There's a table of contents down in the comments.)

They're usually edge cases. For example let-chains changed the parsing logic for if-let constructs across all editions.

I expect these to become even less frequent with ever rising amounts of Rust code that isn't on Github.

Just tried that command (wanted to give rebellion a bit of a go anyway) on my dual-core 4GB laptop with an SSD:

real 5m18,721s; user 6m22,607s; sys 0m20,515s

So, given that the SSD seems to make a difference, and looking at the build output, and that my CPUs looked rather bored, I'm wondering if it's the local documentation builds.

Have you tried `raco pkg install --no-docs rebellion` for comparison? That completes in around 44 seconds on my system.

Not sure about good solutions though, I only use racket for prototyping at the moment.

Been here 12.5 years and have 439 points. So I'm _almost_ there :)

Honestly, after running into the phone number requirement it's gonna be hard to get back my trust.

You required the phone number after you got all my account details. You wouldn't let me remove my account without first giving you my phone number. When I contacted your support to get you to delete my data, a simple back and forth like "you're gonna lose all your data!" and "I don't have any data" made them completely fail the Turing test. It's clear they don't really read what I was writing, they're just responding to whatever the first thought is that comes to their head.

I don't know if they're overworked, underpaid, or have quotas. Either way, none of the experience of trying to join an OSS development channel on Discord are in any way conductive towards trust. I mean, I couldn't even copy and paste the phone number requirement error message.

Yeah. I'd assume a 2018 specific one would show up below https://github.com/rust-lang/rust/tree/master/src/test/ui/ru... if needed.

It's the part of the Rust compiler test suite that makes sure odd syntactical combinations still behave as they are supposed to.

You can store it independently without it being borrowed. So your structs don't need lifetimes.

I consider it a midpoint between `String` and `&str`. Most of the convenience of `String` (barring mutation) but less costly.

A `&str` is a borrow of the string slice data, and has borrowing semantics. An `std::sync::Arc<str>` on the other hand isn't borrowed but has shared ownership and is atomically reference counted.

Does that answer the question? Could you expand on what you mean by sharing `&str`?

I usually just have a `type Text = std::sync::Arc<str>` at the root, specifically during prototyping :)

You might want to look into using `Arc<str>`. It's an immutable string slice that can have many owners and will be dropped once the last one is done with it.

> That last one is a common enough idea nowadays. Prominent people in every community advocate enforcing code style rules (Douglas Crawford's Javascript linter is famous as an early example and gofmt is practically enforced in the community).

I would argue that this is because there are differences in the severity of the tooling. gofmt for example will not override your decisions regarding line breaks last time I checked, while rustfmt will not afford you any freedoms there.

From my perspective, I'd say it's because there isn't much talk about Ada as a technology. It comes up a lot when Rust is discussed, but I never see details besides built-in ranges for numbers. I can't even remember ever hearing anything much about the library/tooling Ada ecosystem.

Also, Ada users seem to be more focused on technical content about safety/mission critical things, like this discussion. But this is a meta-area where no specific features or solutions are in focus. When there's a discussion about zero-copy parsing, compiler optimizations, platform support, scalability or any other everyday technical topic, noone knowing Ada seems to join in with their perspective and experience.

So my advice to the Ada community would be to talk more details, talk more about what you love. Tech is a big field and it's currently a lot of work to get to know Ada from the outside.

I actually tend to try and work with them. With this article as well, I tried to change my data settings instead of just leaving. But I gave up after following the 7th link without encountering a single setting, just more links to follow.

An edition is just another word for version. If the language were truly backwards compatible, you wouldn't have to tell tools like `rustc` which version/edition your code is written in.

How do you square your interpretation with the comment I linked to above?

Where do you get that understanding? All the comments and the summaries I've seen by language team members on this give me a different impression. See this comment from Niko for example: https://github.com/rust-lang/rust/issues/53668#issuecomment-...

So, can you point me to a comment that tells me that the policy still holds and is as you are presenting it?

Once again something is at odds here. You give resounding "Yes" comments, but in the backwards compatibility discussions I had with language team members, those "Yes" comments were actually "not really our problem" answers.

I also don't know how current code running in a future compiler is forward-compatibility. And the Rust guarantee only kind-of holds if you define "code" as "crate". Everything outside of or crossing that boundary is not compatible.

To clarify and bring it to an example: Are you guaranteeing that `(a<b, c>(d))` will always be parsed as a tuple with two comparisons? Because if so I believe you're the only one.

No, that wasn't for soundness fixes. This is from the discussion surrounding syntax changes like turbofish or chained if-let bindings.

Can you point me towards an authoritative post in the turbofish discussion that says that it can't happen because of backwards-compatibility changes? Because before it was locked it seemed that the language team wanted to go ahead.

I've been repeatedly told by language team members that the policy you're promising people doesn't exist. I would really appreciate it if there was further clarification.

Can I copy a module from an old project into a new crate and it will always work without adjustments?

What about code examples from StackOverflow, or Github issues? Will these work without adjustments in my local project?

Will a future syntax highlighter always be able to highlight the code in my old Rust articles?

Will future tooling always be able to read my current code?

Can I make editor macros and snippets that will keep working in every version of Rust?

If I can write code in one crate and it will compile, but then write it again in another, newer crate and it doesn't, then it isn't backwards compatible. Plus, as noted above, "code will keep compiling" isn't even a guarantee that the language team gives you.

I've had many discussions and much pain about this topic. Can you tell me what I wrote that was specifically wrong?

If backwards compatibility is guaranteed, turbofish cannot be "fixed". I can't find the link currently, but from my reddit post on this discussion the crucial quote from a language team member was:

> Our bar for doing backwards compatibility breaks has never been soundness fixes. We have in the past done changes given future-compatibility warning with lints and then made such changes without an edition.

The turbofish discussion also contains this quote:

> This RFC technically amounts to a backwards incompatible change without using the edition mechanism. However, as the RFC notes, a crater run was made and the syntax was not encountered at all.

I still feel that there is more to language compatibility than "Can rustc run it with the right setting". Rust 2018 is a new version, the fact that it's not called 2.0 is just semantics. And I still believe "version interopability" would have been a better term than misusing "backwards compatibility".

> We can’t get rid of it because we have a commitment to not breaking users’ code.

This is not really true though. The commitment is about publicly visible and crater-testable code. If you have your own code in-house, there isn't much guarantee unless all syntax/code you use is widely used in public as well. A known change in language grammar will be evaluated on its publicly visible impact, not on its general breakiness.

It's really disappointing to keep reading about guaranteed backwards-compatibility and then being told in RFC discussions that those don't exist.

I think a full, accepted specification that is adjusted in line with design decisions is still a bit out. Because as soon as you have a blessed specification, people and tools and such are going to depend on it, which limits the ability to change and break the spec down the line.

I don't think Rust is stable enough yet for a real specification.