YorickPeterse

Did you miss the following parts?

    Given my past experiences with X1 Carbon laptops breaking outside of warranty and the frustration that comes with replacing their components, I decided it was time to look for a replacement.
    [...]
    There are also some other issues with the X1 line in general, such as poor CPU cooling and the absolute nightmare that is opening them up to replace parts or clean them properly.

Maintaining an X1 is certainly possible, but it's incredibly frustrating and based on my past experiences with this series I strongly suspect other components will also fail in the near future.

> The author doesnt know what he wants and doesn't know what framework provides.

Indeed, I just pressed a "Buy now" button without a moment's thought. Clearly the fault is all mine.

The photos are just meant to illustrate the difference to the reader, not to be anything scientific. Of course manual calibration is ideal, but having a somewhat sensible default calibration isn't much to ask for and is in fact something many other laptops do just fine.

I may be wrong here but IIRC at least with the 7th generation you have to disassemble the whole thing to get to the keyboard. I'll have to take a look though, because if it's really that simple then I may be able to make my life a bit easier. Thanks for the suggestion :)

I literally mention the reason in the article in the "Configuration" section (https://yorickpeterse.com/articles/im-returning-my-framework...)...

I did briefly look into the XPS series but it seems this series isn't really a thing anymore? I also found a lot of comments describing recurring issues with the trackpad (or was it the keyboard? I can't remember). Basically it seemed like too much of a gamble.

I probably should've done a better job at clarifying this, but my issue with OLEDs isn't just that (at least historically) they tend to be too bright even at lower brightness, but also the other issues they come with such as burn-in and text potentially looking less pleasant compared to IPSs displays. Burn-in is probably my biggest concern here, especially since it really seems to be a case of winning the lottery or not (i.e. for some it's fine for years, others get burn-in after just a few months).

Basically I just trust IPS more than any other technology :)

For a good laptop it wouldn't be too bad, i.e. my X1 Carbon cost me about the same back in 2019 if I remember correctly. But it's ultimately about the price/quality trade-off, and this is where I feel Framework has some work to do, at least with the 16 inch model.

If you leave KL city and go to the surrounding areas, such as Petaling Jaya or Subang Jaya, it becomes more manageable (entering KL from there feels like a 5-10C temperature increase). It gets better the further you go of course, but for tourists that may be a bit tricky as it won't be as easy to get around (at least not without a car).

Yes there is: HTTP/2's and HTTP/3's framing of messages is such that you can't reliably dump a file as-is onto an HTTP/2 connection, as it may exceed the maximum size allowed by a frame.

At least one reason could be that `sendfile` is useless when using HTTP/2 or HTTP/3, as you can no longer just dump the contents directly onto a socket. Whether that actually makes a practical difference on modern hardware remains to be seen of course.

If only Israel wasn't committing a genocide itself, and hadn't treated the Palestinian people like lesser beings for decades, maybe things would be different.

> They are not directly comparable since ZFS is also the volume manager for your ZFS filesystems, enabling features like `zfs send` of snapshots or entire filesystems for easy backups.

Btrfs supports both snapshots and sending/receiving them between different hosts. You can also create additional Btrfs subvolumes.

This is mostly what I meant with the differences between zfs and btrfs not being that significant for most: they largely seem to give you the same end result, instead taking a different path to get there. I do know that zfs is better in terms of reliability (or at least people love to bring that up), but it's something I don't have any experience with myself and thus can't comment on.

I'm using UTM (https://mac.getutm.app/), mostly because it seemed like the easiest thing to set up.

Meanwhile it works perfectly fine without any fuzz on my two Fedora Silverblue setups. This sounds less like a case of "Podman is suffering by definition" and more a case of a bunch of different variables coming together in a less than ideal way.

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.

  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

15 years of backend experience, with a focus on distributed systems, compilers, and language runtimes. Currently looking for a Rust focused job that involves doing something meaningful for the world (e.g. no crypto, high-frequency trading, etc).

I suspect you're referring to this article, which is a good read indeed: https://mmapped.blog/posts/12-rust-error-handling

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.

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.

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.

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

This pattern is applied across the standard library where this makes sense, such that the developer can pick which option works best for their needs.

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).

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.

> 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.

Inko used to have a tracing GC (see https://yorickpeterse.com/articles/friendship-ended-with-the... for more details), but this was removed due to the various problems the presence of a tracing GC introduces.

I don't think the choice of linear vs affine makes much of a difference, but I could be mistaken.

Not quite. A borrow doesn't do cleanup because it's, well, a borrow, i.e. a temporary reference to some owned value. It's the owned value that's tasked with disposing of any resources/memory when it goes out of scope, just as in Rust.

The cost of borrowing (at least with heap types) is an increment upon creating the borrow, and a decrement upon disposing of the borrow. Over time I'd like to optimize those away, but that's not implemented at this time.

In Inko a borrow is sort of a hybrid in that it does increment a counter, but there's no shared ownership like there is in traditional reference counting (e.g. a borrow is never tasked with cleaning up data).

Terminology is a bit annoying here, as e.g. "reference" can also be interpreted as "a pointer", though it depends on who you ask. I stuck with "borrow" because that just made the most sense to me :)

On the diagnostics side of things, the compiler produces these in two places:

1. If you try to define a `mut` field (= one you can normally assign a new value), it will produce an error at the definition site

2. If you try to do something like `some_inline_value.field = value` it also produces an error at the call/assignment site

The actual messages could use some improvements, but that's not a super high priority for the time being as I'm more focusing on the language overall.

Although linear typing is certainly interesting, I think linear typing on its own is not enough. That is, you basically end up with something like Austral where you use linear types _plus_ some form of compile-time borrow checking, at which point we're back at borrow checking (did I mention it seems inevitable?) :)