verdagon

15 ms·

121.
by verdagon 4y ago
Author here, Cone is a pretty fascinating language. It builds a borrow checker on top of any user-specified allocator, whether that be single ownership, reference counting, arenas, garbage collection, or any other user-specified strategy. A
122.
by verdagon 4y ago
Author here, I tried to make this article as balanced as possible, and even talked about Rust's advantages in concurrency and encouraging cleaner architectures and the disadvantages of MMM and GC approaches (plus other aspects, see my
123.
by verdagon 4y ago
Author here, that was indeed a typo, fixed now. Many thanks for correcting that!
124.
by verdagon 4y ago
This article was mainly about memory safety approaches (GC, RC, borrow checking, etc) and their effects on development velocity. It wasn't trying to compare all languages along all dimensions. That would be quite a long article! Anyway
125.
by verdagon 4y ago
Author here, that might actually make the comparison stronger: not all energy in a data center is wasted by the memory safety approach's drawbacks, meaning it makes less sense to optimize for memory safety overhead. But if I'm bei
126.
by verdagon 4y ago
Author here, you're correct that there are a lot of performance tradeoffs involved with various GC'd languages, and also correct that GC'd languages do have some support for deterministic destruction (especially with defer).
127.
by verdagon 4y ago
Author here, I tried to write this article to be as non-biased as possible, though it was pretty difficult. Most discussions and sources online compare Rust to easy targets, like C, C++, or Python, so we never get to really dive into the mo
128.
by verdagon 4y ago
I've used Rust quite a bit, but I would love to hear more about this. Is this comparing to lower level languages like C/C++/Zig, or higher level GC'd languages? What problems does it make us think more about up-front, an
129.
by verdagon 4y ago
A solid question, though that post you linked is about Vale, not Val ;) One day I hope to get a drink with the Val, Vala, and VALE folks and have a hearty chuckle at how this happened. Long story short, generational references like in Vale
130.
by verdagon 4y ago
AFAICT, they're both trying to achieve Rust's power with much more simplicity. Val uses mutable value semantics, which (afaict) is like using Rust's &mut and .clone() a lot. Vale uses a foundation of generational referenc
131.
by verdagon 4y ago
They do eliminate certain classes of low-level bugs, but we shouldn't always ignore the tradeoffs that can come with memory safety. GC and RC have a performance tradeoff, and borrow checking has complexity and developer velocity tradeo
132.
by verdagon 4y ago
Not freeing memory is a fairly common approach, in compilers and command line tools as well. If an AST hangs around until the end of the program anyway, why not let the OS take care of blasting it away? free() is expensive after all.
133.
by verdagon 4y ago
Even when I was there a couple years ago, 20% time was already basically dead. They had to be approved by those above one's direct managers, needed compelling justification, and getting the go-ahead was pretty rare. This was even for t
134.
by verdagon 4y ago
How's Rust at doing OOP these days? (Assuming we're in a domain or situation where OOP is a good choice, of course.) I would love to know about any projects that do OOP well in Rust.
135.
by verdagon 4y ago
Crysties!
136.
by verdagon 4y ago
I'm curious about this too. If Nim managed to design a system that gives you more flexibility without adding more complexity, that would be pretty stellar.
137.
by verdagon 4y ago
Stellar article! Was definitely worth a read. The sidenote styles are particularly ingenious, I remember trying to get float+clear to work for this and never could, but looks like it's doable!
138.
by verdagon 4y ago
The tips at the end of the article are pretty solid. I'll add some more that helped my writing immensely: * Use bold text once or twice per section to break up the monotony and draw the reader's eye to where you want it. * Shorten
139.
by verdagon 4y ago
Anyone interested in footnotes might like the way we do it on the Vale site, for example: https://verdagon.dev/blog/making-regions-part-1-human-factor Some nice things: * The footnotes are off to the side, so it's
140.
Implementing a New Memory Safety Approach, Part 1(verdagon.dev)
5 points by verdagon 4y ago|0 comments
141.
Hash Codes, Non-Determinism, and Other Eldritch Horrors(verdagon.dev)
3 points by verdagon 4y ago|0 comments
142.
by verdagon 4y ago
There's a big downside to this that I don't hear people talking about here on HN (likely because our demographic isn't representative of the average programmer at all). C-like languages are much simpler for newcomers to pick
143.
by verdagon 4y ago
I'm pretty excited by what Val is doing. I feel like this is the next step in languages: finding a way to combine the techniques of the last decade (Pony's unique references, Rust's borrow checking, etc.) in new and interesti
144.
by verdagon 4y ago
Adding generational references needs to be built into the language at a very deep level to work properly, AFAICT. One can almost do it by using "side tables" but it would come at a rather high performance cost for Rust. Since gene
145.
by verdagon 4y ago
Good news! Complexity isn't a baseline requirement: it's possible to make a language that has the basic patterns and benefits of an average Rust program. It's what we're doing in Vale [0]. It turns out, they key is to mo
146.
by verdagon 4y ago
In my experience learning Rust (and in watching others learn Rust) that first "aha!" moment is actually rather misleading. That moment comes when one learns how to technically accomplish any task in Rust. One knows the minimum s
147.
by verdagon 4y ago
I'm not sure I'd characterize Rust as an easy enough option for most people/cases, or that there's just a "few" situations, but apart from that I like your perspective, well said.
148.
by verdagon 4y ago
You didn't explicitly say this, but for anyone who might misinterpret your comment to imply that any memory-unsafe should be specifically targeted at certain small domains: A vast swath of the programming world doesn't need the le
149.
by verdagon 4y ago
I suspect a lot of the toxic discourse originally comes from folks not understanding each other's use cases and priorities. For some, memory safety is a means to an end: delivering value. In this perspective, one must weigh the benefit
150.
by verdagon 4y ago
One thing I like about Odin is that you can use any allocator with any existing function, without wiring that function to specifically do that. It just comes for free. In a way, it completely decouples the code from the allocator choice. It

More ›