Didn’t know Roc was still being worked on. I think it’s an interesting concept for a language that I personally haven’t seen elsewhere
What concepts do you find interesting, compared to other FP languages?
How Our Rust-to-Zig Rewrite Is Going
151–160 of 336 posts
Re: How Our Rust-to-Zig Rewrite Is Going
#152Earlier quoted context omitted.
Claude Code uses bun.
Yeah I get they use it but I don't understand why you would buy it. it's just the runtime for code that makes up the agent.
Bun was a startup. Startups can go out of business, and then you are now scrambling to move your code to something else. They could also be bought by someone who has different priorities regarding future development than you, and that's also a risk.
The simplest solution to these problems, if you have the capital, is to buy them.
Re: How Our Rust-to-Zig Rewrite Is Going
#153Earlier quoted context omitted.
> In extremely high performance code you use different data structures and algorithms and change your approach to memory allocation. It's worth noting that the reason Rust doesn't include support for custom memory allocation patterns like Zig does has nothing to do with memory safety. It's more of a historical accident that it just wasn't something that was prioritised early in the projects history and is now hard to…
No disagreement in principle; in practice taking that approach in Zig is safer than in Rust, because in Rust it’s “all or nothing.”
The interfaces to custom allocators are more idiomatic, standardized, and normalized in Zig, but there's nothing systematically unsafer about the Rust equivalent. You can use custom allocators all you want in Rust, as long as you're okay using third-party crates like Bumpalo.
On that topic, worth mentioning that Rust's long-awaited `Allocator` trait is perilously close to stabilizing; watch for https://github.com/rust-lang/rust/pull/157428 to be merged, then the stabilization PR to progress here: https://github.com/rust-lang/rust/pull/156882
Re: How Our Rust-to-Zig Rewrite Is Going
#154Does this mean every time you find yourself using lots of “unsafe” Rust blocks, it’s not the right tool for the job? I suspect it’s not that simple, but what are people’s experience?
Re: How Our Rust-to-Zig Rewrite Is Going
#155Earlier quoted context omitted.
> Compilers are not security sensitive, usually. The compiler is one of the most significant trust boundaries we have. Its decisions can intentionally or unintentionally create vulnerabilities in programs compiled by the compiler, which means that if you can compromise a compiler you can compromise everything downstream. Unsafe memory access in a compiler can be exploited in order to hijack the compiler itself (this…
For this to be useful you would need to modify the compiler binary to make the exploit persistent. Otherwise why put an exploit for the compiler in the source to so that the compiler can put some malware in a binary, when you can put the malware in the source directly?
Because:
1. There are lots of things that compilers load into their memory that aren't actually source code. A memory exploit turns non-source data into executing-in-the-compiler code.
2. Depending on the language semantics, a memory exploit can allow substantially higher privilege than just being loaded as library code. Latent malicious code that never gets called into never becomes active, but if you can exploit a weakness in the compiler you can make your code execute at any time you'd like instead of relying on the main application calling in to your malicious library.
Re: How Our Rust-to-Zig Rewrite Is Going
#156Earlier quoted context omitted.
No, it would fundamentally change how Zig works.
no, it would not. If you do not believe me, you should try out the repo.
the architecture doesn't make sense. MIRI doesn't perform static analysis on MIR. It is, as the name says, an interpreter. The borrow checker is entirely different from miri.
Rust's borrow checker requires lifetime annotations. Zig code doesn't contain any such annotations. How does your design handle this?
Re: How Our Rust-to-Zig Rewrite Is Going
#157Earlier quoted context omitted.
Then that's equivocation. Why do we want a very specific form of safety instead of wanting safety in general?
Memory safety is: 1. Foundational for other forms of safety 2. Has an objective definition, when some other forms of safety are either subjective or inter-subjective. That said, I don't understand why your parent brought this up to you, you are talking about memory safety in your original comment here, so that's what Rust's safety is about.
I feel that the buzz phrase "memory safety" has been defined by Rust to mean "the safety Rust gives you". Obviously memory usage can be more safe or less safe, and Rust is decidedly on the safe end of the spectrum, but it also has the gaping type system holes demonstrated in cve-rs which completely shatter any claim that safe code is safe, and there are other bugs which occur in Rust while the programmer is distracted by trying to prove their code is memory-safe.
Re: How Our Rust-to-Zig Rewrite Is Going
#158Earlier quoted context omitted.
Memory safety is: 1. Foundational for other forms of safety 2. Has an objective definition, when some other forms of safety are either subjective or inter-subjective. That said, I don't understand why your parent brought this up to you, you are talking about memory safety in your original comment here, so that's what Rust's safety is about.
I feel that the buzz phrase "memory safety" has been defined by Rust to mean "the safety Rust gives you". Obviously memory usage can be more safe or less safe, and Rust is decidedly on the safe end of the spectrum, but it also has the gaping type system holes demonstrated in cve-rs which completely shatter any claim that safe code is safe, and there are other bugs which occur in Rust while the programmer is distracte…
> the buzz phrase "memory safety" has been defined by Rust to mean "the safety Rust gives you".
It's more that Rust's safety guarantee is memory safety. No more, no less. It's not about buzz, this term was used long before Rust existed.
> it also has the gaping type system holes demonstrated in cve-rs
This is not a "gaping hole". It is a compiler bug, which has never been found in the wild.
> there are other bugs which occur in Rust
This is true! Every language can have bugs in it, and Rust does not claim to solve all bugs.
Re: How Our Rust-to-Zig Rewrite Is Going
#159Earlier quoted context omitted.
For this to be useful you would need to modify the compiler binary to make the exploit persistent. Otherwise why put an exploit for the compiler in the source to so that the compiler can put some malware in a binary, when you can put the malware in the source directly?
Because: 1. There are lots of things that compilers load into their memory that aren't actually source code. A memory exploit turns non-source data into executing-in-the-compiler code. 2. Depending on the language semantics, a memory exploit can allow substantially higher privilege than just being loaded as library code. Latent malicious code that never gets called into never becomes active, but if you can exploit a…
1. What would this be?
2. Good point, but for most purposes I think exploiting some aspect of the build system or the language that moves the exploit code or causes it to be executed before main would be easier than exploiting a memory issue in the compiler (I agree though in principle).
Re: How Our Rust-to-Zig Rewrite Is Going
#160[dead]