There's kids being noisy, which in itself isn't much of a problem, and then there's _Dutch kids_ being noisy, with the latter sounding more like a bunch of roosters at a heavy metal concert.
Readit NewsYorickPeterse commented on Let Kids Be Loud afterbabel.com/p/let-kids... · Posted by u/trevin
Location: Delft, The Netherlands
Remote: Yes (remote only)
Willing to relocate: No
Technologies: Rust, Ruby, PostgreSQL (a lot more in the past, but less relevant as to what I'm looking for)
Résumé/CV: https://yorickpeterse.com/resume/ / https://github.com/yorickpeterse/
Email: yorick at my domain name
YorickPeterse commented on Error handling in Rust felix-knorr.net/posts/202... · Posted by u/emschwartz
I disagree that the status quo is “one error per module or per library”. I create one error type per function/action. I discovered this here on HN after an article I cannot find right now was posted.
This means that each function only cares about its own error, and how to generate it. And doesn’t require macros. Just thiserror.
I suspect you're referring to this article, which is a good read indeed: https://mmapped.blog/posts/12-rust-error-handling
The downside of QBE is that it doesn't have a way to generate debug symbols. But I still love and use it.
The most recent release has the ability to generate basic debugging information (see "new experimental dbgfile and dbgloc directives. " from the release notes) as Hare needed that (and IIRC a Hare contributor added it). Unfortunately, there's no documentation on it, and last I checked to see how to use it I had to go spelunking in the Hare source code.
YorickPeterse commented on Postgres IDE in VS Code techcommunity.microsoft.c... · Posted by u/Dowwie
That "works" for about as long as you have <10 employees and <3 customers or so. After that the railsapp doesn't get to be the sole owner of the db.
It worked fine for GitLab when it had 2000+ employees and god knows how many customers. The same applies to many other large Rails shops.
YorickPeterse commented on Link Time Optimizations: New Way to Do Compiler Optimizations johnnysswlab.com/link-tim... · Posted by u/signa11
Link time optimizations were done in the 1980s if I recall correctly.
I never tried to implement them, finding it easier and more effective for the compiler to simply compile all the source files at the same time.
The D compiler is designed to be able to build one object file per source file at a time, or one object file which combines all of the source files. Most people choose the one object file.
For Inko (https://inko-lang.org/) I went a step further: it generates an object file for each type, instead of per source file or per project. The idea is that if e.g. a generic type is specialized into a new instance (or has some methods added to it), only the object file for that type needs to be re-generated. This in turn should allow for much more fine-grained incremental compilation.
The downside is that you can end up with thousands of object files, but for modern linkers that isn't a problem.
YorickPeterse commented on The inevitability of the borrow checker yorickpeterse.com/article... · Posted by u/rbanffy
I feel like if that's your take, then things like array indexing or dividing by zero should never panic. Because running into those things at runtime is very hard to prevent (unless you have tooling for enforcing that statically?)
There are cases where you might want to choose: crash and burn, or handle at runtime. Where this makes sense, Inko does actually let you do that. For example, array indexing is done using one of two methods:
- Array.get/Array.get_mut for when you want to panic on an out-of-bounds index
- Array.opt/Array.opt_mut for when you want an Option type, with it being a None for an out of bounds index
So for example:
[10, 20, 30].get(0) => 10
[10, 20, 30].get(42) => panic
[10, 20, 30].opt(0) => Option.Some(10)
[10, 20, 30].opt(42) => Option.None
There are a few places where we check for some input at runtime and panic if this is invalid, but this is limited to cases where there's simply no sensible alternative (e.g. providing a key with an invalid size to a ChaCha20 cipher).
YorickPeterse commented on The inevitability of the borrow checker yorickpeterse.com/article... · Posted by u/rbanffy
Inko is an interesting language, though the handling for panics sounds disturbing. Based on the documentation, panics abort the whole program and are not recoverable.
Things like dividing by zero or accessing an index outside of the bounds of an array will panic.
While these aren’t incredibly common, I would never want my whole production web server to go down because some random, infrequently used endpoint had a bug in some edge case.
The language seems heavily inspired by Erlang, which is very resilient to programmer errors in comparison.
In Erlang, the philosophy is to let a lightweight process crash and restart it when there is a problem. This doesn’t need to have any effect on other lightweight processes that are running.
Panics are meant to be used sparingly and as a last resort, and are meant to signal "this code is utterly broken, go fix it". Handling such errors at runtime (e.g. by restarting just a lightweight process) doesn't make much sense, as you'll keep running into the issue over and over again and possibly even end up ignoring it.
For runtime error handling you'd use algebraic types such as Result and Option, similar to most functional languages and Rust.
The reason we don't allow catching of panics (such as Rust allows) is because it can result in people more or less ignoring such errors (something I've seen happen far too often in past projects) and just retrying over and over again, achieving the same result every time. I'd much rather have the program crash and scream loudly, forcing developers to address the issue. Fortunately, the chances of you actually running into a panic at runtime should be pretty slim, so not being able to catch them shouldn't be much of an issue in practice.
YorickPeterse commented on The inevitability of the borrow checker yorickpeterse.com/article... · Posted by u/rbanffy
Author introduces inline type definition. Shouldn't allocation strategy be decided by the caller, not type definiton? Or there is a way to heap allocate value of inline type by wrapping it into some utility type, similar to Rust's Box?
> Or there is a way to heap allocate value of inline type by wrapping it into some utility type, similar to Rust's Box?
There isn't. For this to work, functions for inline types have to be compiled such that one of these approaches is used:
1. They always take inline values by pointer, and we have to guarantee those pointers are never invalidated. This again means you need some sort of borrow checking scheme.
2. We compile two versions for each function: one that takes the data by value, and one by pointer, resulting in significant code bloat and compiler complexity.
I think the split also better captures the intent: heap types are for cyclic and heavily mutated values, inline types are more for short-lived mostly immutable values.