So 50+.

Surrounding text with underscores to indicate italicization is intuitive to anyone who is familiar with that convention.

Personally, I find surrounding text with forward slashes exactly wrong for italicization, because I mentally apply a skew-transform to the text to make the slashes into vertical lines, which leaves the text itself slanted in the wrong direction. Backslashes would make more sense, and also avoid looking like regular expressions. But literally no one uses that convention and we do not need a new one.

memory safety doesn't mean just one thing, but probably it requires either a lot of rust-like features, a tracing garbage collector, or automatic reference counting.

the language being small enough that all basics can be grasped in a day

that disqualifies taking the rust-like path.

able to use all c libraries through ffi. without loss of performance or extra fu.

that disqualifies most (all?) advanced tracing gc strategies

it must not have massive pauses or stop the world GC.

that disqualifies simpler tracing gc strategies

depending on what precisely you're looking for, it's possible it might be a pipe dream. but it's also possible you'll find what you want in one of D, Nim or Swift. Swift is probably the closest to what you want on technical merit, but obviously extremely tied to Apple. D and Nim strap you with their particular flavor of tracing gc, which may or may not be suited to your needs.

I don't care to sit through sponsor reads, nothing more to it than that. When I'm viewing on a client that doesn't support sponsorblock, I'll manually seek to the end of the segment. Supporting the creator is great; I pay for YouTube Premium, though thanks to uBlock Origin I wouldn't see the add if even if I stopped paying. To a couple creators, I send a regular donation. If I could spend another $10/mo to make up for any revenue my sponsorblock usage loses other creators, I'd do that, but I'm less enthusiastic about regularly listening to sales pitches for the same products over and over again.

Also: I'm not sure how common it is for YouTube sponsorship contracts to have payment contingent on the view count for the section of the video with the sponsored segment, and I'm not sure if the way sponsorblock skips such segments is visible to YouTube's analytics. With at least some of the most prolific sponsors of creators I watch (Audible, Brilliant, etc) the payout is based on how many viewers sign up for a trial through the affiliate link. And YouTube has no incentive to make it easy for creators to share their detailed analytics with third-party sponsors, since independent sponsorships cut YouTube out of the deal. YouTube would prefer creators replace their independent sponsor reads with mid-roll ads.

What wasm is doing is something different than previous efforts. The gc facilities aren't provided for the sake of interop with other languages, or for the sake of sharing development resources across language runtime implementations. Wasm is providing gc facilities so that managed-memory runtime languages can target wasm environments without suffering on account of limitations imposed by the restrictive memory model, and secondarily to reduce bundle sizes.

Wasm can potentially support more tunable gc parameters to better suit the guest language's idiosyncrasies than can other general purpose language runtimes. And unlike the runtimes we're comparing it against, language implementers don't have to option of making something bespoke.

The parent process was an event loop based python program whose main function was to manage the creation and deletion of these child processes, and the simplest way to spawn child processes without blocking the event loop is to call fork(2) on a thread pool. My thread pool was triaging the number of worker threads based on demand, so occasionally it would decide a worker was no longer needed, and all the child processes that happened to have been created on that thread would get SIGKILL'd — something you rarely want when using a thread pool!

I didn't want the child processes to die unless the parent process's business logic decided they were no longer needed, or if the parent was itself killed (this latter reason being the motivation for setting PDEATHSIG).

Once I understood why my processes were dying, the solution was simple: make sure the worker threads never exit.

My debugging was not aided by the fact that disabling the code where I set PDEATHSIG had no effect, since someone else's code was invisibly setting it regardless.

When I'm using a tiling window manager that supports tab-style layouts (i3, sway, gnome+popOS) applications that open new windows liberally are great because the alternative is to have an ad hoc bespoke window manager inside every application, and it's much better to have a single consistent window management experience at the OS level with one set of keybondings and predictable behavior.

But if I had to have a floating window for every webpage I have open, I'd never find anything!

I don't remember where I came across this, but many years ago I saw python-style generators termed "semi-coroutines" which I'm a fan of. Python (frustratingly) doesn't implement them this way, but the beauty of generators is that by limiting the scope where execution can be suspended to the highest-level stack frame, you can statically determine how much memory is needed for the (semi-)coroutine, so it doesn't require a single allocation.

Zig takes that a step farther by considering recursive functions second-class, which lets the compiler keep track of the maximum stack depth of any function, and thereby allow you to allocate a stack frame for any non-recursive function inside of another stack frame, enabling zero-allocation full coroutines, as long as the function isn't recursive.

That would... probably be overkill for Go, since marginal allocations are very cheap, and you're already paying the runtime cost for dynamic stack size, so the initial allocation can be tiny.

I would love to see full proper coroutine support make it to Go, freeing users of the overhead of the multithreaded scheduler on the occasions where coroutine patterns work best. I remember back in 2012 or so, looking at examples of Go code that showed off goroutine's utility as control flow primitives even when parallelism wasn't desired and being disappointed that those patterns would likely be rare on account of runtime overhead, and sure enough I hardly ever see them.

Currently, you could use goroutines and channels to implement a nice way to provide general iteration support for user-defined data structures, but because of the overhead, people most often opt for clunkier solutions. This change would give us the best of both worlds.

But absolutely nothing forces you to implementing plugins as shell scripts! kak-lsp, which provides great integration with language servers, is written in rust. Peneira, a fuzzy finder tool, is implemented in python. People have written libraries for various languages that make interfacing with kakoune from your language of choice quite convenient.

The decision to make all extension functionality work over IPC instead of an embedded scripting language means everything that the editor is capable of can be controlled by any piece of software over a thoughtfully crafted and well-documented interface. Also the extensions people write for kakoune end up also serving as general purpose utilities that can be integrated into stuff other than kakoune.

I've always considered kakoune's approach to extensibility the main selling point of the editor. It has quite phenomenal plugin support for such a niche editor, and it's way easier to make your own plugin than it is with other editors because of how streamline the API is.

There's one unavoidable obstacle to people wanting to put on the headset: you're going to look really weird and isolated to other people in your environment. The tech to solve this problem doesn't exist, and maybe it's too high a barrier and this product category just isn't going to work. But Apple is betting that if they chip away at all the other reasons to not put on the headset, it'll cross the threshold where it wearing it becomes a regular routine for most people who buy one.

If they can bootstrap that into an ecosystem so that there's things you'll want to do with the device that you couldn't do with your other devices, at that point they can start selling a cheaper device that doesn't try to solve the onerousness problem through sheer luxury.

It’ll sometimes get killed by the OS without much you can do about it though.

Exception if you're going to travel with it. Built-in sounds save you on setup time.