verdagon

31 ms·

271.
by verdagon 4y ago
Some possibly relevant works: Pony has a separate GC for every actor. I suspect that in practice, these work a lot like arenas; since they're very short lived, I'd imagine that most actors just allocate a lot and then blast it awa
272.
by verdagon 4y ago
Take a look at Mesh [0] which brings compaction to a malloc-like system. I could see an RC-based or single-ownership-based language using it to avoid fragmentation. [0] https://tiba-jrchang.medium.com/mesh-compacting-memory-
273.
by verdagon 4y ago
RC might not fragment the heap for long! Someone built a defragmenting malloc called Mesh [0] which uses virtual page remapping to effectively merge two non-overlapping pages. Pretty brilliant stuff! [0] https://tiba-jrchang.medi
274.
by verdagon 4y ago
Ironically, even though I believe RC will make great strides, I actually agree with you. Single ownership has the most potential, especially if we decouple it from the borrow checker as we are in Vale. [0] Being able to control when somethi
275.
by verdagon 4y ago
That's great that you're interested in venturing into other fields! Switching fields every once in a while is a great way to grow and become a stellar engineer. If you have equal passion for those two choices, I would suggest lean
276.
by verdagon 4y ago
I'm not sure most people use this technique, but when I was using RC-based systems, I would often assert that an object's refcount was 1 just before I let go of that last reference. Suddenly, we have RAII-like predictable destruct
277.
by verdagon 4y ago
A valid question, happy to enlighten! To get the automatic threading speed improvements, a (region-aware) language might add a `parallel` keyword in front of loops, to temporarily freeze pre-existing memory, thus completely eliminating the
278.
by verdagon 4y ago
Definitely! Vale, Lobster, and Cone all require explicit annotations for anything that could cross thread boundaries. Vale's design bends the rules a little bit, it blends structured concurrency with region borrow checking to allow thi
279.
by verdagon 4y ago
I develop languages full time, and it's clear to me that RC will make massive strides forward in the next decade, for a few reasons: 1. First-class regions allow us to skip a surprising amount of RC overhead. [0] 2. There are entire
280.
by verdagon 5y ago
Huh! I think you're right. I never realized that the old way was clearer. I like your second example there. The compiler could probably very easily ensure that a variable was initialized before first usage. Thank you for the idea and i
281.
by verdagon 5y ago
A great point, I agree that extra syntax can help with parser errors. Vale happens to require semicolons at the end of every line, which helps with this (and a few other corner cases around custom binary operators).
282.
by verdagon 5y ago
Fortunately, the Vale compiler doesn't allow shadowing. It also says "Did you forget the set keyword?" in case they meant to modify x.
283.
by verdagon 5y ago
I'd say Vale's thesis is "Rust level performance without the pain." By making our borrow checker a lot more flexible with shared mutability, we're able to lower the learning curve and architectural restrictions sign
284.
On removing let and let mut(verdagon.dev)
33 points by verdagon 5y ago|20 comments
285.
by verdagon 5y ago
> The instances of safe code that the borrow checker can't verify as such are not "corner cases" by and large, they're genuinely non-trivial patterns, often with non-obvious drawbacks such as lack of composability&#x2
286.
by verdagon 5y ago
I'd like to hear more about the Rust rewrites you've coordinated. Why do you think Rust took longer to change than Python? I've felt this a little bit, but can only theorize why; the borrow checker makes mutability into a vir
287.
by verdagon 5y ago
We tried this style in one of Google Earth's packages for a while (using an internal C++ class similar to Rust's Result). So many operations could theoretically fail (e.g. indexing out of bounds or an expected key not existing) th
288.
by verdagon 5y ago
Correct me if I'm wrong, but IIRC pacing would still cause a latency spike, it would just be a more strategically-timed latency spike.
289.
by verdagon 5y ago
I suspect that GC'd languages could mitigate this problem by introducing regions; separate areas of memory that cannot point at each other. Pony actors [0] have them, and Cone [1] and Vale [2] are trying new things with them. If golang
290.
by verdagon 5y ago
Jon Goodwin's Cone [0] language had a nice idea of calling it "trust", as in, "Compiler, trust me, I know what I'm doing" [0] https://cone.jondgoodwin.com/coneref/reftrust.html
291.
by verdagon 5y ago
Interestingly enough, unsafe is the root reason Rust couldn't add Vale's Seamless Concurrency feature [0] which is basically a way to add a "parallel" loop that can access any existing data, without refactoring it or any
292.
by verdagon 5y ago
I made a tiny roguelike game in Zig a few months back and was really impressed. One thing I really appreciate about the language is the emphasis on keeping things simple. I heard someone put it really well yesterday: when you're progra
293.
by verdagon 5y ago
Thank you! We're pretty excited about it too. Though, I do want to be clear for readers, Seamless Concurrency [0] isn't fully implemented yet, we've only just started to play with its first building block, the region borrow c
294.
by verdagon 5y ago
Always a pleasant surprise to be scrolling through HN and seeing one of my articles on the front page! For anyone interested in how that code would get zero memory safety overhead without the classic borrow checker, a big part of it is beca
295.
by verdagon 5y ago
C++ doesn't have a concept of immutable data, or data not shared by another thread, which is part of the challenge. This "region borrow checker" aids the former; we can call a pure function that can regard previously shared-m
296.
by verdagon 5y ago
> Unless you meant that new functions could be annotated as pure in order to avoid future errors in code not yet written? Precisely. New functions can be written to treat all pre-existing memory as immutable, and we can be confident that
297.
by verdagon 5y ago
Thats fair, I suppose it depends on how one defines safety. I'd still lean toward JavaScript being safer from a language design perspective (no comment on VM/interpreter implementations!) because there's no equivalent to gola
298.
by verdagon 5y ago
Indeed it's present under the hood, we are operating on a CPU after all, which treats all of RAM as one giant shared-mutable blob of data. It will always be there, under some abstraction. The point I'm trying to communicate is tha
299.
by verdagon 5y ago
In theory yes, but when you look at the average Rust program, those mechanisms are avoided in favor of more idiomatic approaches.
300.
by verdagon 5y ago
I think it makes the most sense for Google, considering the ridiculous amount of C++ code. Even Spanner alone is larger than most company's codebases, and rewriting it in Rust would take decades, especially because of the paradigm mi

More ›