verdagon

24 ms·

211.
by verdagon 4y ago
Yep, or generational references [0] which also protect against that kind of thing ;) The array-centric approach is indeed more applicable at the high levels of the program. Sometimes I wonder if a language could use an array-centric approac
212.
by verdagon 4y ago
That's just a logic error, and not memory unsafety which might risk UB or vulnerabilities. The type system enforces that if we use-after-"free" (remember, we're not free'ing or malloc'ing), we just get a differ
213.
by verdagon 4y ago
The approach can reuse old elements for new instances of the same type, so to speak. Since the types are the same, any use-after-free becomes a plain ol' logic error. We use this approach in Rust a lot, with Vecs.
214.
by verdagon 4y ago
A lot of embedded devices and safety critical software sometimes don't even use a heap, and instead use pre-allocated chunks of memory whose size is calculated beforehand. It's memory safe, and has much more deterministic executio
215.
by verdagon 4y ago
Reasonable answers, thank you! I wonder how D might address that.
216.
by verdagon 4y ago
What about bounds checking on array access, like most memory safe languages?
217.
by verdagon 4y ago
Mind explaining why it's a bad thing to rely on the OS's built-in protections around nulls? I'm familiar with a few arguments w.r.t. large structs and arrays running past the protected pages, but they seem pretty trivially so
218.
by verdagon 4y ago
Rust has a great approach to memory safety for plenty of use cases, but I personally believe that the future lies with languages that have a more seamless blend between shared mutability and static analysis. Going all-in on borrow-checked s
219.
by verdagon 4y ago
For sure. Most of those are pretty young and experimental, so I'm glad D is adding something solid!
220.
by verdagon 4y ago
It's amazing what strides languages are making in the realms of memory safety. I think D's got the right idea, to have pockets of zero-cost memory safety, on top of an overall architecture that embraces shared mutability's be
221.
by verdagon 4y ago
I'm also curious if they have any plans on memory safety. If it's based on Swift and Rust, perhaps they'll do RC?
222.
by verdagon 4y ago
Vale lead here, there's something lovely about the V and L sounds, it's worth the crowding ;) Very cool language!
223.
by verdagon 4y ago
A valid question! Semicolons and other forms of syntactic redundancy often enable much better error messages. We're leaning towards keeping them in Vale. However, we can always change our minds later and make them optional, so it seems
224.
by verdagon 4y ago
Yep, thats what we mean with dereferencing, aliasing, and dealiasing. That statement is referring to our sample program, a roguelike game that we use for benchmarking. As for why this is the case, I'm not sure! I suspect its because a
225.
by verdagon 4y ago
I share this perspective, it's why Vale chose generational references over a borrow checker. In practice, the borrow checker has to reject a lot of perfectly fine patterns, such as observers, dependency injection (the pattern, not the
226.
by verdagon 4y ago
Good question! If one defines safety as a lack of UB or vulnerabilities, then I'd say Vale's a bit safer than other languages like Rust. I say this because: 1. There are no unsafe blocks in Vale. 2. Vale memory is decoupled from n
227.
by verdagon 4y ago
I see RC and GR as two methods of ensuring memory safety: one that extends the life of an object, and one that asserts the object is still alive. They both protect us from vulnerabilities and UB, but with different approaches. Yep, it was c
228.
by verdagon 4y ago
Thanks! The increased memory overhead would seem to be a problem, but in the programs I work on at least (games, web servers, compilers), the vast majority of references in a program are owning references which aren't fat pointers. Non
229.
by verdagon 4y ago
I'm glad MTE is catching on, I think it's the future for C and C++'s memory safety story. Hopefully intel comes out with something for it soon too! Vale is taking a similar approach at the language level, by putting a generat
230.
by verdagon 4y ago
Vale lead here, thanks for posting! For those interested in the PL space, here are some of the shenanigans we've been up to in Vale: * We added "Higher RAII", a form of linear typing that allows destructors to have return typ
231.
by verdagon 4y ago
It does, currently in the form of IFunction1<R, P>, IFunction2<R, P1, P2>, etc. We also just introduced variadic generics in version 0.2, which is the first step towards a unified IFunction<R, ...> interface. Long term, we
232.
by verdagon 4y ago
Good summary! Generational references were less than half the overhead of RC as of last benchmark. [0] Re inline data: A piece of inline data will (most often) share the generation of its containing object. A generational reference can incl
233.
by verdagon 4y ago
Entertaining slides! I've long thought that we should do OO at architectural levels and FP at the detail levels.
234.
by verdagon 4y ago
Does anyone else get the feeling that we (as a field) are missing something basic about concurrency? Like there's a really elegant solution just around the corner, that has the low overhead of async/await without the complexity. O
235.
by verdagon 4y ago
IIRC, the branch predictor can work with function pointers as well. It can sometimes mitigate problems like this, though not as completely as just monomorphizing away the run-time branching/calling like they did.
236.
by verdagon 4y ago
I think that's right. C++ binaries tend to be pretty large because they use templates/monomorphization a lot, even when there aren't really meaningful performance gains. For example, it often doesn't make sense to have 2
237.
by verdagon 4y ago
I've found it depends on what paradigm one is using. The borrow checker is great in some architectures that agree with it, but pretty incompatible with a lot of basic abstractions and can therefore impose more artificial complexity and
238.
by verdagon 4y ago
That's probably acceptable for most use cases. On Google Earth, even sub-millisecond pauses would have been too much, we had to fight pretty hard for every sliver of performance we could get.
239.
by verdagon 4y ago
Sure, I don't contest that memory unsafety has some large drawbacks of its own. I'm glad that languages are innovating in memory safety. My comment was about the tradeoffs we make for our memory safety guarantees, and whether they
240.
by verdagon 4y ago
A lot of apps don't need internet access, or only communicate with a single (trusted) website, with no data exchanged with other users. I might even say most apps.

More ›