verdagon

14 ms·

1.
by verdagon 29d ago
This isn't quite accurate; Mojo uses the same memory safety approach as Rust. It has some mutable aliasing, but only intra-function, so in practice programs will be pretty much Rust-shaped.
2.
by verdagon 3mo ago
Hi, article's author here (Verdagon, Vale's creator), and no, I'm just writing about someone else's language (Ante) that I thought was interesting. Ante is making some very intriguing steps forward in memory safety desig
3.
by verdagon 5mo ago
I'm often skeptical of the desire to create a lot of passes. In the early Vale compiler, and in the Mojo compiler, we were paying a lot of interest on tech debt because features were put in the wrong pass. We often incurred more comple
4.
The Impossible Optimization, and the Metaprogramming to Achieve It(verdagon.dev)
9 points by verdagon 11mo ago|1 comments
5.
by verdagon 1y ago
This approach solves one borrow checking pain point (by allowing temporary mutable aliasing, even across function boundaries), but the post might actually be a bit conservative in saying it will influence our programs' data to look lik
6.
by verdagon 1y ago
Big fan of Verona, I love their memory safety approach as well. I wrote a bit about it in the Grimoire [0] too. IIRC they plan for the user to specify whether a region is backed by an arena allocator or GC, which sounds pretty nice. It&#x27
7.
by verdagon 1y ago
Yep, adding or removing an element would invalidate existing pointers to any other element in the hash table. This is generally regarded as a good thing if your elements are stored contiguously in the hash table, because a resize would caus
8.
by verdagon 1y ago
Great question! That's a big enough topic that I'd love to write a followup post about it. There's also a good thread on r/Compilers at https://www.reddit.com/r/Compilers/comments/1n2ay7g&#
9.
by verdagon 1y ago
Hey all, this is a post explaining a new memory safety model by my friend Nick Smith (original proposal at https://gist.github.com/nmsmith/cdaa94aa74e8e0611221e65db8e4... ) It was interesting enough that I knew I had to
10.
by verdagon 1y ago
Great point =) That's true for a lot of languages (including Mojo too), so I should have said "non-owning reference" there. I'll update the post to clarify. Thanks for catching that!
11.
Group Borrowing: Zero-cost memory safety with fewer restrictions(verdagon.dev)
85 points by verdagon 1y ago|86 comments
12.
Understanding SIMD: Infinite complexity of trivial problems(modular.com)
257 points by verdagon 2y ago|116 comments
13.
by verdagon 2y ago
I can imagine a Rust-like language where we have move-constructors (in TFA), and every generated Future subtype is opaque and also heap allocated for us. I think the need for Pin could then disappear, because the user would have no way to
14.
by verdagon 2y ago
Good to see some more uses of linear types! Very few languages can use linear types, and their potential is huge IMO. OP shows the benefits of a linear RC that tracks references dynamically, and one can even imagine a version where the co
15.
by verdagon 2y ago
I've been looking into this, and I suspect that one actually needs surprisingly little to interoperate safely with Rust. TL;DR: The lowest common denominator between Rust and any other memory-safe language is a borrow-less affine typ
16.
by verdagon 2y ago
Just did, thanks for the suggestion!
17.
Layer-wise inferencing and batching: Small VRAM doesn't limit LLM throughput(verdagon.dev)
2 points by verdagon 2y ago|0 comments
18.
by verdagon 2y ago
Thanks! And yeah I get that a lot >_> You're always welcome to swing by the discord where I can give a less arcane explanation! ( https://discord.gg/SNB8yGH )
19.
by verdagon 2y ago
Hah I like this one! PS. Congrats! https://verdagon.dev/blog/easter-egg-notes
20.
by verdagon 2y ago
It could, but then that List would have to be linear itself, and then the program would make sure that you eventually drain the list and destroy each element. (One caveat is for linears in globals, which aren't implemented in Vale yet.
21.
by verdagon 2y ago
A really good question. In short, a linear List (or array, or hash map, etc) will only have two available destroyer functions: 1. drop_into(list, func): It consumes the list, calling the given `func` for each element. 2. expect_empty(list):
22.
by verdagon 2y ago
I've got some weird plans for variants. Basically, we'd represent an enum as a non-heap-allocated sealed interface with a struct for each "case". Basically, think of a Scala case class. Then, depending on where we put it
23.
by verdagon 2y ago
Almost, but see the replies to IcyWindows' comment for why this unfortunately doesn't work in C++. Also, I would love it if C++ had a way to actually move. That would unlock all sorts of interesting possibilities.
24.
by verdagon 2y ago
You're exactly right, and that's kind of what Vale's `destruct` is, if you squint.
25.
by verdagon 2y ago
They almost work like this. std::move doesn't actually move an object; it leaves an intact instance... which we still don't know how to destroy (because its destructor is private). This also means that if we have an e.g. Outer s
26.
by verdagon 2y ago
There are a couple technical reasons: 1. In RC and tracing GC languages, a linear object would need exactly one special "linear" reference to it, which would be responsible for eventually "consuming" (though not deleting
27.
by verdagon 2y ago
I'm glad you brought inheritance up! This rule has solved it nicely in my experience: if a struct is linear, then it can only inherit linear interfaces. And implementation inheritance works because it's really just a combination o
28.
by verdagon 2y ago
Thank you, my friend =) So glad to hear you enjoy the articles!
29.
The Type of Sprintf(ryanbrewer.dev)
13 points by verdagon 2y ago|21 comments
30.
by verdagon 2y ago
Cool to see this on HN! This is my favorite part of language design: you get to play with weird ideas and see how the implications cascade through the rest of the program. It kind of blew my mind when a linear type solved a caching prob

More ›