mtzet

The main point is to use zswap over swap plus zram. The sd card usecase definitely doesnt want swap to disk, compressed or otherwise, so zram or no swap are the options.

A normal desktop with non-soldered components is more repairable, cheaper and can also run on stock Linux?

The only selling point is the form factor and a massive amount of GPU memory, but a dGPU offers more raw compute.

I don’t get this take. Is it so hard to understand that a computer operates on a giant array of bytes?

I think the hard thing to understand is that C’s pointer syntax is backwards (usage follows declaration is weird).

I also think understanding how arrays silently decay to pointers and how pointer arithmetic works in C is hard: ptr+1 is not address+1, but address+sizeof(*ptr)!

Pointers are not hard. C is just confusing, but happens to be the lingua franca for “high level” assembly.

So let's focus on the case where I'm setting up a bunch of bare-metal hosts as servers. What's the value proposition of using FreeBSD over Debian/Ubuntu if we're not counting familarity?

Either experience will be CLI first, so this is a tie.

ZFS integration is one point. If that's important to you, then you'd want to pick a distro like Ubuntu with first-class support. All major development happens on the Linux on ZFS branch as far as I understand, so this should be okay.

As the original post points out, FreeBSD used to have unique features as selling points: zfs, dtrace, the network stack (before SMP became ubiquitous?), kqueue, jails. I'm sure there are others. But these days it seems Linux has caught up with developments like ebpf, cgroups, namespaces and io_uring.

I'm sure the fragmented nature of Linux means that some of these low-level techs are easier to use on FreeBSD. The counterpoint is that the higher-level stack is more well-supported on Linux. You may not have to care too much about the details of namespaces and cgroups if high-level docker/kubernetes/... tooling works for you.

What am I missing?

> special case where all memory can be easily handled in arenas That seems to be an unfair bar to set. If _most_ objects are easily allocated by an arena, then that still removes most of the need for GC.

I like Jai's thesis that there's four types of memory allocations, from most common to least common:

1. Extremely short lived. Can be allocated on the function stack.

2. Short lived + well-defined lifetime (per frame/request). Can be allocated in a memory arena.

3. Long lived + well-defined owner. Can be managed by a subsystem-specific pool.

4. Long lived + unclear owner. Needs a dynamic memory management approach.

If you want to make the claim that tracing GCs surpass manual memory management in general, you should compare to a system written with this in mind, not one that calls malloc/free all over the place. I guess it might be more fair if you compare tracing GC with modern c++/rust practices.

I agree that for most systems, it's probably much more _practical_ to rely on tracing GC, but that's a very different statement.

Processors doing out-of-order execution doesn't change the semantics of the code. That's very different from the example where gcc just throws away the assignment.

The idea that he just needs to accommodate the compiler people is silly. Compilers exist to serve programmers, not the other way around. It's entirely reasonable to disagree with the compiler developers and use a flag to disable behaviour your don't want.

> I’m not a go developer. How does go document how a function can fail?

There's no magic to it. Errors are values, so it's a part of the function signature that there's an error code to check. In C++ any function can throw an exception and there's no way of knowing that it wont.

It's true that go doesn't document what _kinds_ of errors it can throw, but at least I know there's something to check.

I'm not arguying that go has modern tech, but rather that it has modern sensibilities. This means not trying to force 90s style OOP, preferring static linking for easier deployment, including a build system and package manager with the compiler and preferring static types with type inference to dynamic types.

This differentiates go, rust, zig, odin etc., from languages like C++, Java, C#, Python etc. I think it makes sense to describe that difference as one of modern sensibilities.

I agree that go and rust have different areas, but that was less clear when they were getting started. Back then go was trying to figure out what it meant by 'systems programming language' and rust had a similar threading model.

Another point is that they do share similarities, which might we might now just describe as being 'modern': They're generally procedual -- you organize your code into modules (not classes) with structs and functions, they generally like static linking, type inference for greater ergonomics, the compiler includes the build system and a packager manager, there's a good formatter.

The above are points for both rust and go compared to C/C++, Python, Java, etc.

So why do I like go? I think mostly it's that it makes some strong engineering trade-offs, trying to get 80% for 20% of the price. That manifests itself in a number of ways.

It's not the fastest language, but neither is it slow.

I really dislike exceptions because there's no documentation for how a function can fail. For this reason I prefer go style errors, which are an improvement on the C error story. Yes it has warts, but it's 80% good enough.

It's a simple language with batteries included. You can generally follow the direction set and be happy. It leads itself to simple, getting-things-done kind of code, rather than being over-abstracted. Being simple also makes for great compile times.

Thanks!

> as best as I understand it, because of the content of JeanHeyd's blog post on reflection in Rust.

I'm having trouble finding it. Can anyone link this post?

Off the charts? Compared to completely at will maybe. You generally have to pay 3 months severance + 1 month per 3 years of employment for a maximum of 6 months severance after 9 years of employment. That's it.

As someone who knows nothing at all about the success of PayPal, can you elaborate on why?

I'm also curious about his role in the success of Tesla and SpaceX. I personally find those to be two of the most interesting startups in a long while, and have been inclined to think that Musk being involved in both to be unlikely to be a coincidence.

I agree. Emacs out-of-the-box is terrible, but my Doom Emacs config is all 50 lines of code. For that I get:

- IDE-like features via LSP

- The best git porcelain out there: magit. Even when I'm not using emacs, I come back to magit for code-browsing (recursive blame) and staging hunks.

- Emacs/vim's fantastic buffer/window concept, where open files are not owned by their windows. I miss this whenever I use anything else.

- project support to quickly grep across all files or jump to files

- Very mature vi keybindings, with their infinite composability

I still sometimes find that it's either too rigid or too manual at certain things, but I could say the same for CLion and VSCode. I still come back to CLion for its refactoring tool, the 3-way merge window and the debugger integration.

It is a bit messy though. It's very well done for what it is, but it's cobbled together from many disparate components. It seems that it should be possible to create the same type of experience from a simpler, more coherent system. I rarely update the base system, but when I do, I've occasionally had to google for some exotic elisp error and add a fix here or there.