sekao

The code example will work even if `u` is only known at runtime. That's because the inner switch is not matching on `u`, it's matching on `ab`, which is known at compile time due to the use of `inline`.

That may be confusing, but basically `inline` is generating different code for the branches .a and .b, so in those cases the value of `ab` is known at compile time. So, the inner switch is running at compile time too. In the .a branch it just turns into a call to handle_a(), and in the .b branch it turns into a call to handle_b().

Agreed. Zig's approach re-uses the existing machinery of the language far more than C++ templates do. Another example of this is that Zig has almost no restrictions on what kinds of values can be `comptime` parameters. In C++, "non-type template parameters" are restricted to a small subset of types (integers, enums, and a few others). Rust's "const generics" are even more restrictive: only integers for now.

In Zig I can pass an entire struct instance full of config values as a single comptime parameter and thread it anywhere in my program. The big difference here is that when you treat compile-time programming as a "special" thing that is supported completely differently in the language, you need to add these features in a painfully piecemeal way. Whereas if it's just re-using the machinery already in place in your language, these restrictions don't exist and your users don't need to look up what values can be comptime values...they're just another kind of thing I pass to functions, so "of course" I can pass a struct instance.

I noticed you used scare quotes...is that because you and your team don't think simplicity is valuable?

The ability to export a zig project to a single C header file would be really nice. Is that still a planned feature?

I can't imagine why they would be argumentative with a gentle diplomat like yourself.

You know, I used to think that design was a nuanced grappling of complex tradeoffs, but you convinced me: those you disagree with are just "brain-dead" "idiots". I think there is a relevant quote by Charles Bukowski about confidence, but it escapes me...

Zig and Go both let you silence the error with `_ = myvar`. It can still be annoying, but it avoids the recursive problem you mentioned. Language design is hard, and it's best to not just assume that people are "idiotic" for not thinking the way you do. Turn the volume down a bit, and maybe find a synonym for "literally" for the sake of variety.

I'm running NixOS + KDE on the AMD framework and surprisingly it worked perfectly out of the box. All I had to do was disable secure boot to get it running, and after install I had to configure the global scale in display settings to 200% so it looked right. No weird hacks needed at all -- the 23.05 installer just worked, including wifi, which apparently isn't true for Windows 11.

As I said in the last thread, the author could use support: https://www.patreon.com/join/bcachefs

This has been a solitary and largely self-financed effort by Kent over many years. He must feel pretty great to finally see this happen!

The author lost corporate funding recently and is asking for donations. I just started giving 20/mo. I don't care about kernel drama; I just want a good COW filesystem for Linux and this guy is doing a thankless service.

https://www.patreon.com/join/bcachefs

You can do a smaller pledge via the custom pledge button if you want.

Think about longevity. Whether I'm writing, drawing, making music, or anything else important to my life, will I still be able to view/edit that data in 20 years? Granted, even with offline-friendly software I may need to port it to new platforms and make sure I back up the data, but at least I have a chance. The data I still have from 20 years ago is far more precious to me than I thought it would be back then. Data that can only be accessed through an external party is ephemeral and it will inevitably disappear one day.

Richard is a great contrarian thinker. I remember him from GET LAMP, a documentary about text adventures, and his take on the power of text in games was really memorable: https://www.youtube.com/watch?v=Zctp972y_Eg

The browser target sounds neat. Do you plan on running the python in web assembly, or would it be a client/server design?

I think we will need new standards here, because terminal emulators currently don't have any semantic information about what TUI programs are rendering. Browsers have the benefit of HTML to know this is a button, and that is a paragraph. A terminal is an unstructured grid of characters. The best we can hope for is for terminal emulators to use heuristics or AI to make sense of what TUI programs are rendering.

It doesn't detract from that at all, chief. What a weird thing to say. Particularly in the case of Nim -- it doesn't "throw away" C or C++, it compiles to them!

I believe cyclic imports are coming. And Nim does supports wasm...you can target it with `--cpu:wasm32`. You most likely want to pair that with emscripten as in https://github.com/treeform/nim_emscripten_tutorial

Andrew argues that zig can produce faster programs than c or rust towards the end of the video: https://youtu.be/gn3YsZ6HUHw?t=3566

Binary files are also delta'd in git.

I didn't even know about it until today, very impressive. Generic SoA in less than 500 lines of userland code...

https://github.com/ziglang/zig/blob/master/lib/std/multi_arr...

> the big tragedy it's that is focused on freight transport

I don't see the tragedy in that. Tracks in the US are privately owned and freight makes them more money than passenger rail. Don't think we'd gain anything by artifically changing that. Even in Europe planes are usually faster and cheaper than rail when traveling between countries.

Reactive updates is the big one, in my opinion. DataScript is a triumph and arguably is the reason why so many note-taking tools (Roam, Athens, Logseq, etc) are written in Clojure. But there are so many cases where it would be nice to react when some set of entities is changed.

I think what we need is to figure out how to combine DataScript with a rules engine. I wrote a rules engine and made a writeup that compares the two together: "Using O'Doyle Rules as a poor man's DataScript" https://github.com/oakes/odoyle-rules/blob/master/bench-src/...

Subscribing to individual entities is nice but with a rules engine you have so much more fine-grained control over your reactions. And with the RETE algorithm this can be done efficiently. Most libraries in this space just ignore it and make their own ad-hoc solution -- an informally-specified, bug-ridden, slow implementation of half of a rules engine.

That is the case with JavaFX as well. It's not part of the JRE anymore. Also there really isn't any such thing as the JRE anymore, only the JDK. If you want to distribute a desktop Java app you must embed the entire runtime via javapackager. They have correctly realized that end users cannot be expected to install and update a language runtime separately...

Nim supports wasm. You can target it with `--cpu:wasm32`. You most likely want to pair that with emscripten. Here's an example: https://github.com/paranim/parakeet

See also https://github.com/hpjansson/chafa which is an image -> unicode library written in C. I built it into my BBS so users can embed images in their posts. Some turn out better than others but it gives the board a unique feel at least.

Right now not good but I have a plan for the web version. I'm going to overlay text fields, buttons and other things on top of the cells where they're being rendered. This is doable because nimwave has all the semantic information.

For terminals there is no way to do this. I think we need a new standard to represent terminal interfaces that preserves this info. I have some ideas on how to do this in a backwards compatible way but I'm on my phone at a BBQ right now so I can elaborate later :P

Good points but the suggested alternatives are ignoring the most important piece of tech we have for synchronizing content: git. My problem with ActivityPub is that when you export your content, you get a big binary file that can't be incrementally updated. I'm exploring the idea of using git to clone a completely offline version of a message board in my BBS: https://ansiwave.net/

The reason websites aren't designed to last is not due to ever-changing design trends; it's because the web is inherently ephemeral. For a website to continue to be available requires continuous effort and expense to run a web server, update SSL certs, etc. This automatically shortens the time horizon when you're developing for it.

I think the way to get more "timeless" software is to build a platform where the code and the data can be brought offline. PWAs do the first but not the second. The data needs to be in an enduring format like SQLite that can be queried offline. With that kind of system, an app or game (and the accompanying data) could remain usable 20 years from now, long after its author stopped distributing it.

I'm building my own hang out spot: https://ansiwave.net/ Strictly a BBS right now, but i'm considering adding chat as well.

Out of context, you won't necessarily be able to glean meaning from either an arbitrary SQLite database or arbitrary RDF tuples. Both are equally meaningful or meaningless depending on the observer...at the end of the day, they are just structured data with labels that (hopefully) the observer understands. One doesn't have inherently more semantic meaning than the other.

Making it available via a static file host dramatically lowers the barrier. If you have an interesting dataset, you can even throw it on github pages and pay nothing; that likely is not true for your mongo db server.

A typical request using indexes will be less than 10 separate 1KB GET requests, not 50. But yeah, more work needs to be done on performance.

Whether it makes sense to fully download the dataset depends on the project; maybe it does not. But it doesn't have to be a monolithic file. You can use SQLite's multiplex VFS to split the SQLite file into many smaller pieces (and still update the db later!).