afdbcreid

4 ms·

61.
by afdbcreid 2mo ago
> Typescript, Rust or C++ type system complexity is routinely a compile time problem that people have to work around or tackle from both sides True, but this has very little to do with these being NP-hard. As an example I know well: In R
62.
by afdbcreid 2mo ago
You can create an `struct Algebraic<T>(pub T)` newtype that overloads operators using algebraic methods. In fact such wrapper might be added to std (it was discussed but decided that not yet. Such wrappers exist for wrapping and satur
63.
by afdbcreid 2mo ago
It must be interesting to program in it! But yes, you can absolutely represent irrational numbers (only a finite amount of them of course). You can even do it symbolically.
64.
by afdbcreid 2mo ago
They're not real, they're rationals (well rationals are real but you get it). If you want "simple" rationals, you can use the numerator/denominator scheme. This has its own problems but if you avoid overflows, they
65.
by afdbcreid 2mo ago
C++ has introduced the concept of erroneous behavior for this, which is much better.
66.
by afdbcreid 2mo ago
First, I'm not sure. Rust has MIR optimizations and also other transformations. But even if yes, MLIR is part of the LLVM project, so it's technically still "just an LLVM wrapper".
67.
by afdbcreid 2mo ago
The problem with ownership tracking is that it's global. Humans are bad with global things, linters too, but LLMs are exceptionally bad at them due to the context window and (currently, at least) not knowing enough where to search. So
68.
by afdbcreid 2mo ago
I wouldn't call Go's type system "good". It's basic or less. It's sound, at least (in the presence of data races), but that is the case (or mostly the case) for most programming languages.
69.
by afdbcreid 2mo ago
> Performance wise it's the first language in long time that isn't just an LLVM wrapper Why? Because it uses MLIR? Rust has its own MIR, it's even more not-LLVM-wrapper.
70.
by afdbcreid 2mo ago
I'm not sure what you tried to prove by those docs, but they don't say that they deviate from IEEE-754.
71.
by afdbcreid 2mo ago
True, however: if some human would improve the lower bound that would still end as some few posts on mathematics magazines, even if it would be no less impressive. The general public is not interested in the mathematical details, it is in
72.
by afdbcreid 2mo ago
> Regardless, those optimisations are available on the respective JITs. I'm pretty sure this is wrong. No JS engine, RyuJIT or or HotSpot break IEE-754. Java does have intrinsics for algebraic floating point operations (but does not
73.
by afdbcreid 2mo ago
I believe the MVP was chosen specifically to have the same features as JavaScript, so that browser engines can implement it without major changes. So not really an odd target.
74.
by afdbcreid 2mo ago
This is far from trivial. Consider the WasmGC proposal, which had a somewhat similar goal. Then C# came and said "we can't use it, we have different needs". So did Go.
75.
by afdbcreid 2mo ago
Maybe we should automatically exclude indexing, but it's telling that current crates like no-panic do not to that (instead they check if the compiler optimizes out the panic, which accepts more cases but is not reliable and understanda
76.
Rust-lang/rust is adopting an LLM policy(blog.rust-lang.org)
121 points by afdbcreid 2mo ago|71 comments
77.
by afdbcreid 2mo ago
The question (one question, at least) is what to do with unwinding. If we consider every function to be able to unwind, that means you basically need to have a lot of boilerplate, and it's also not clear how to express that syntactic
78.
by afdbcreid 2mo ago
In my open source work I believe this is the same. I don't have numbers, but I'm sure the vast majority of my time isn't spent writing code. Of course, it depends on how you define "writing code".
79.
by afdbcreid 2mo ago
The problem with the trivial implementation is that it's barely useful. You cannot use indexing, for example. Not to mention it's still not easy: to have any usefulness, there will need to be a way to be generic over it (similar
80.
by afdbcreid 2mo ago
Then this is, unfortunately, entirely wrong. Here's an example causing a segfault when there is a bound checks that the compiler omits: https://godbolt.org/z/8f6rv4dja The example is adapted from a Rust example sh
81.
by afdbcreid 2mo ago
One of the main reasons Rust needs this capability is because C++ has it, and Rust wants to interop with it. It's not that better model (enabling it additionally can bring benefits, but also complications; enabling it by default, l
82.
by afdbcreid 2mo ago
The more accurate definition of `!Forget`, similar to `Pin<&mut !Unpin>`, is not "can be leaked" but "if the underlying storage is reused, the destructor is guaranteed to run". This enables all important (decid
83.
by afdbcreid 2mo ago
But also come with a plausible implementation strategy, that from what I know is not currently known for no-panic.
84.
by afdbcreid 2mo ago
Like others said, Pin is incompatible with these semantics. Some people argue, though, that we need both (basically because pinned types can be moved before being pinned).
85.
by afdbcreid 2mo ago
If anything, pin ergonomics is at greater risk. People still discuss if we need both, but if we don't, then we go for this goal and not pin ergonomics, as it's more general. It (the immobile types proposal) is at a greater risk be
86.
by afdbcreid 2mo ago
Then perhaps people need to pay to get their paper reviewed?
87.
by afdbcreid 2mo ago
The government can just arrest you and lock you out of all sites. It's not like they cannot do it today.
88.
by afdbcreid 3mo ago
I'm well aware. I don't know a moving GC crate for Rust, but I do know that building a safe moving GC crate for Rust is possible, using the same principles as existing GC crates. It will not be exactly as performant as Java, bec
89.
by afdbcreid 3mo ago
No, you really can. You can use GC crates and the performance will be like Java, or you can use Rc and the performance will be like Swift. The only reason Rust people use unsafe for data structures (and they do not always do) is that for th
90.
by afdbcreid 3mo ago
That is of course true, but if anything that just proves more what I said. Also that too is part of the "common wisdom" (that as I said, is not always true).

More ›