verdagon

10 ms·

61.
by verdagon 3y ago
You two are correct, fixed, thanks!
62.
by verdagon 3y ago
In the basic generational references approach that was a drawback, and the reason it couldn't release memory back to the OS. We planned to use something like MESH [0] to reduce the fragmentation. We created two newer approaches since t
63.
by verdagon 3y ago
Yep, this is the correct answer. Accessing released memory is undefined in C, but well-defined in Vale. The goal is to ensure that the user predictably+safely gets either a segmentation fault or an assertion failure. We have a future improv
64.
by verdagon 3y ago
Sorry about that, it seems it doesn't print out the help file correctly any more. If you manually cat the valec-help-build.txt in the download, it should explain what you're looking for. The compiler is very rough around the edg
65.
by verdagon 3y ago
I know nothing on this topic so perhaps a naive question but: what about the employees? I imagine part of their TC was in stock, so if I was a CEO I'd feel pretty motivated to reward my employees, who quite literally bet their family&#
66.
by verdagon 3y ago
Ironically, we could say that we're losing the true ownership relationships between the objects, and we're making medium-term memory leaks more likely; drop() can free a Box pointing to a child, but can't free an index. In
67.
by verdagon 3y ago
Source about single family homes not being used as single family homes? Would love to read more!
68.
by verdagon 3y ago
This might be of interest: https://verdagon.dev/blog/first-regions-prototype It uses region-based static analysis without borrow checking: it doesn't impose aliasability-xor-mutability per object, or even per-regi
69.
by verdagon 3y ago
There are a lot of ways, but I think the most promising ones involve regions. We do this a lot manually in Rust, but a language could make this a first class concept. Some examples: * Vale combines generational references and linear types w
70.
by verdagon 3y ago
I don't think it has to be this hard to have memory safety, data race safety, and performance. After building and doing PL design in this space for a decade, I don't believe the assumption that Rust's or C++'s difficulti
71.
by verdagon 3y ago
I know! I just couldn't bring myself to remove it it. It's such a cool note. I think I'm going to do these differently in the future lol
72.
by verdagon 3y ago
You win =D
73.
by verdagon 3y ago
Fixed, thank you!
74.
by verdagon 3y ago
I'd definitely agree, and the article proposes a static analysis tool (similar to the borrow checker) for that purpose.
75.
by verdagon 3y ago
I'm not sure this has much to do with RAII. RAII does indeed require affine types, but RAII doesn't provide memory safety. The article describes a method of memory safety. (Also, I used the term "borrowless affine style"
76.
by verdagon 3y ago
I'm not sure if there's really any alternative besides using a subset, for a low-level language. Even Rust is only memory-safe within a certain subset. Edit: Actually nevermind! CHERI is a hardware technique that can make C++ memo
77.
by verdagon 3y ago
This is one of the other three secret blends that I think could bring memory safety to C++! I wrote a bit about using type-after-type as the basis for an entire language (Arrrlang, with a parrot mascot) in my last article [0] and a little b
78.
by verdagon 3y ago
> There is so much low hanging fruit in programming language design and nobody is picking it up (waves) Author here! I wrote this article about some improvements to C++, but I also made a whole programming language [0] using a lot of the
79.
by verdagon 3y ago
Later on, it adds generational references and constraint references to relax the restrictions. These are both more flexible than SlotMap because they don't require a new parameter to be passed in from the callers (and callers' cal
80.
by verdagon 3y ago
I'd say it mostly applies to manual optimization, when we're restructuring our program. If the situation calls for a B-tree, the borrow checker loves that. If the situation calls for some sort of intrusive or self-referential data
81.
by verdagon 3y ago
This is a great point, and one that doesn't get enough attention. The article talks about using a static analysis tool, but usage of that tool is indeed opt-in, like you say. I suspect a language could mitigate this with the ability to
82.
by verdagon 3y ago
I would love a language (or C++ subset!) where we could get the benefits of that secret sauce, while mitigating or avoiding some of its downsides. Like Boats said, the borrow checker works really well with data, but not so well with resourc
83.
by verdagon 3y ago
> Syntactic sugar, I think, is only there to build a moat around a tech to justify a salary premium and reduce the number of newcomers. Ascribing that kind of motive to something as innocuous as syntactic sugar is silly at best. Most syn
84.
Experimenting with Memory Management for Basil(degaz.io)
2 points by verdagon 3y ago|0 comments
85.
by verdagon 3y ago
Fixed, thanks =)
86.
by verdagon 3y ago
It depends. There are two options of generational references we've been experimenting with: * Table-based generational references where the generations are stored in a separate table, and we retire overflowed slots. This is guaranteed
87.
Single Ownership and Memory Safety Without Borrow Checking, RC, or GC(verdagon.dev)
3 points by verdagon 3y ago|1 comments
88.
by verdagon 3y ago
This isnt quite true, you can have memory-safe single ownership without borrow checking, and it feels quite different than what Rust has us do.
89.
by verdagon 3y ago
I believe electric motors _are_ actually intended and advertised to create movement which is correct, and come with warranties and liability about reliability. (Or maybe I missed a joke in here somewhere?)
90.
by verdagon 3y ago
I often hear that if a distinction exists, it should be represented in the type system; functions are either async or not, so we should track it at compile time. The thing most people don't understand about language design is that if y

More ›