The rust maintainers need to learn from the mistakes of the c++ design committee and understand that not adding a feature at all is in itself a desirable feature.
For example, your section on effects:
> Functions which guarantee they do not unwind (absence of the panic effect)
> Functions which guarantee they terminate (absence of the div effect)
> Functions which are guaranteed to be deterministic (absence of the ndet effect)
> Functions which are guaranteed to not call host APIs (absence of the io effect)
The vast majority of rust programs don’t need such validation. And for those that do, the Ferrocene project is maintaining a downstream fork of the compiler where this kind of feature would be more appropriate.
I think rust is in a perfect spot right now. Covers 99.99% of use cases and adding more syntax/functionality for 0.001% of users is only going to make the language worse. The compiler itself provides a powerful api via build.rs and proc macros which let downstream maintainers build their desired customization.
> The vast majority of rust programs don’t need such validation.
The vast majority of Rust programs would benefit from such validation existing in the language, even if they never bother to explicitly leverage it themselves. For example, a non-panicking effect would be beneficial for both compilation times (don't bother pessimistically emitting unwinding glue for the enormous number of functions that don't need it, only to attempt to optimize it away later) and runtime performance (the guaranteed absence of the aforementioned glue reduces potential branch points and code size, which leads to better inlining and vectorization).
The "caveats" section in its docs hints at it, but to be explicit: no_panic is a band-aid that can break when changing optimizer options or compiler/llvm version. It's not a good option for library crates, e.g.
That being said, I'm not at all happy with all the complexity and ecosystem fragmentation that async brought. I understand what you're saying. But surprise panics is a bit of a pain point for me.
There are ways to handle these effects without bloating up normal applications. For example, using attributes implemented as intrinsics, which wouldn't really affect anything that isn't using them.
The thing is, some of these things are very useful in specific domains, and all these domains are closely related to the ideas of safety. Nondeterminism and IO are important for purity/referential transparency, which is a fairly important effect for business logic IMO. Guaranteed termination matters for formal verification. Unwind removal matters for embedded. I don't think wishing for these things is really all that unwarranted
> I actually don’t see how this is any more beneficial than the existing no_panic macro
no_panic and similar macros are doing a very hacky workaround which isn't really a great static guarantee. The simple fact that building with panic = abort makes the macro useless is an annoyance in and of itself. dtolnay did great when figuring out some path forward but it's somewhat shaky
If a piece of code does not panic in panic=unwind, then it does not panic in panic=abort either. So having coverage of panic=unwind would be sufficient to guarantee that code cannot panic. The caveat you mention with panic=abort would only apply to code that is unable to build for panic=unwind, which is uncommon.
You just know some guy will try to make cli code no-panic/deterministic use a bunch of crap and think he achieved something.
Just not allowing complex code is so much better than this.
Just even being able to look at a piece of code and trace what it is doing is 1000x more valuable than this. I regretted almost every time I allowed Traits/generics into a codebase
> I actually don’t see how this is any more beneficial than the existing no_panic macro
I think looking at the caveats listed in the no_panic docs should give you some ideas as to how a "proper" no_panic effect could improve on the macro.
Furthermore, a "proper" effect system should make working with effects nicer in general - for instance, right now writing functions that work independently of effects is not particularly ergonomic.
> The vast majority of rust programs don’t need such validation.
I think you also need to consider the niches which Rust wants to target. Rust is intended to be usable for very low-level/foundational/etc. niches where being able to track such effects is handy, if not outright required, so adding such support would be unblocking Rust for use in places the devs want it to be usable in.
> And for those that do, the Ferrocene project is maintaining a downstream fork of the compiler where this kind of feature would be more appropriate.
Given this bit from the Ferrocene website:
> Ferrocene is downstream from Rust
> It works with existing Rust infrastructure and the only changes made in the code were to cover testing requirements of ISO 26262, IEC 61508 and IEC 62304 qualification. All fixes are reported upstream for constant improvement.
I would suspect that such changes would be out of scope for the Ferrocene fork because that fork is more intended to be a qualified/certified Rust more than Rust + completely novel extensions.
> The compiler itself provides a powerful api via build.rs and proc macros which let downstream maintainers build their desired customization.
Given the complexity of the features listed this feels tantamount to asking each individual consumer to make their own fork which doesn't seem very likely to attract much interest. IIRC async even started off like that (i.e., using a macro), but that was painful enough and async thought to be useful enough to be promoted to a language feature.
I'm curious to what extent one can implement the described features using just build.rs/proc macros in the first place without effectively writing a new compiler.
You can believe in a kind of political "butterfly effect" where every little action you take has a meaningful effect on the world, but I don't think it's useful.
Downloading a browser may well put a thousandth of a smile on the face of someone you think is a bad dude, but if you give a shit about bad things happening in the world this is miles away from a good use of your time and energy.
> From what I understand these systems are legal because there is no expectation of privacy in public.
This is a common line of phrasing parroted by Flock and their supporters to no end but it's a myth. The SC, as much of a joke as they are now, established that a person has a reasonable expectation to privacy in their long term movements in Carpenter v. United States (2018). To date there is NO precedent carved out in the constitution or ANY Supreme Court case stating that people have zero expectation to privacy in public.
GPUI is a great example of the insane amount of boilerplate needed to create a component when you don't have inheritance.
My guess is that people don't create a lot of individual components in this framework to handle different business cases, and instead overload a single text input component with a million different options. I would hate to untangle a mature app written under those conditions.
Why not Go? I don’t understand starting new backend projects in a JVM language when go exits and its both faster and simpler. People love to proclaim Java’s ability to handle “big data” but I have programs parsing TB of data daily in Go without a sweat. And it was much faster to write and teach new engineers on than Java
Tailscale has made all of their client source code available for anyone to view so if you want to confirm that you’re not sending unencrypted data or keys through their servers you’re more than free to do so.
I think there is some merit to setting up wireguard (e.g. you want more devices than what Tailscale offers for free, or their servers become unreliable for some reason)
But people who push the “scarey boogeyman will look at your data” with Tailscale are either technically illiterate or overly-paranoid.
I don't think the hesitation comes from the boogeyman you speak of, but just relying on someone else other than yourself.
This has further implications than just security. Also, whoever gets into self hosting already wants to not rely on others for the most part. If you didn't go into this for the tinkering aspect, I guess Tailscale is completely ok for most, perhaps even ideal.
Nevertheless, none of this has anything to do with the achievements or not of Tailscale. People saying that your own VPN is ok have a point.
If Apple wanted to score easy points they would leave this be and add a widget/app icon animation api in the next major release of iOS. This would be way more useful than whatever crap Siri and Apple intelligence are.
reply