adrusi

Go has a heavy runtime, including both a garbage collector and a userland scheduler. Those features both make it inappropriate for some applications where you would use c, and also make calling (and especially being called from) foreign code problematic. You effectively cant implement a library in go and then call it from another language, not without considerable ffi overhead at the very least.

42 videos on his car review channel plus 13 videos on his main channel (a few might be crossposted) plus a couple tesla reviews from several years earlier than the others.

So 50+.

it's maybe negligible compared to the code-size bloat of web applications, but delivering large libraries over the network with only limited caching is less than ideal

At least in English, typographic conventions have historically equated underlining with italics, and the reason the underscore key is present on your keyboard is because it was used on typewriters to format text that would have been italicized in printed text.

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.

while at the same time being memory safe.

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.

The cost of the land to the grower is lower on account of the presence of the turbines.

I do not understand why one should use this

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.

That idea of a universal/generic VM supporting many languages has been tried many times, with limited success

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 surprising behavior was that the child process received the configured signal not when the process that created it exited, but rather when the specific thread that called fork(2) exited.

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.

I had a hell of a time a few months ago debugging why my child processes were dying, before learning that PDEATHSIG=9 (don't ask) kills child processes when the thread that created them in the parent process exits.

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.

I'm quite nearby to Scott in social space, and no, I don't think it's just "never come up." It's a very highly selected scene.

I really appreciate apps that open new windows where it makes sense, but I'm pretty sure the reason it died out is because people started using too many windows for conventional floating window managers to handle. I'm not sure if many people really felt the burden it would have caused, because the growth in number of windows arguably began with having many webpages open at once, and firefox, and then later internet explorer with version 7 (or maybe 6?), introduced tabs as a core part of using a web browser.

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!

A goroutine really is implemented as a coroutine though. It's just that without this runtime optimization, there hasn't been a way to interact with them without letting a multithreaded scheduler manage their execution.

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.

This is an interface that can be implemented in terms of goroutines and channels, but can also be implemented with a lower-overhead scheduler tweak. The article shows how it could be implemented using goroutines and channels, and then reports the result of that implementation versus an optimized version that avoids synchronization overhead and scheduler latency which is unnecessary with this pattern.

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.

Kakoune is scripted over IPC, not bash scripts. The configuration language has some built in functionality for embedding bash scripts, and for smaller plugins or one-off personal customization, yeah you can do everything in a bash script.

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.

I see a lot of the pricey functionality they packed into this thing as about making it less onerous to put on. People need to actually decide to put it on to do stuff that they could do with their existing devices.

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.

You can sideload UTM if you sign it with your own developer key, and run VMs with JIT-based acceleration.

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

I don’t know the details around this, but it seems like it would be near impossible to get 100% ethical sourcing, because no matter how good your process of vetting suppliers is, at Starbucks scale, you’re going to get fraud. A shady supplier just needs to bribe or blackmail one of your procurement staff to look the other way.

It's somewhat youthful internet slang. You'd hear it at the American public highschool I was at 12 years ago.

For anyone price-sensitive, I highly recommend getting the cheapest 88-key hammer-action keyboard you can find and hooking it up to Pianoteq Stage rather than buying a dedicated digital piano.

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

Well about one time in three that someone mentions "legal weed" in the circles I run in, someone will drop a remark about how there's federalism-themed ambiguity over how legal it actually is, so I'm not sure how "silent" it really is.

Wait, wasn't "es4x" the name of the scrapped edition of ecmascript which was decided to be too ambitious and replaced by the much more conservative ES5?

Answer: no. That one was branded "e4x"

Many people map j/k to gj/gk and forget that's not the default behavior.

Singal isn't a bigot. It's not the service to trans people that many people seem to think it is to call anyone who documents unflattering dimensions of trans politics a bigot. Colin Wright, mentioned in the article, could more reasonably be called a bigot, though having his Paypal account terminated on that basis wouldn't be just.

But this really shouldn't be about Singal or Wright. I, a trans woman, had a fine evening out with the actual author of the piece, Yassine Meskhout, back in April along with a few other folks, and I'm quite sure he isn't bigoted against trans people.

With iPhone video hardware, ProRes support, and a thunderbolt interface that makes 4k ProRes actually practical to get off the device, the iPad Pro is now likely to be the best video recording device for certain creative niches. You can even edit the video on the same device that captured it in a pinch.

Oh huh. Hadn't even heard of Google surveys then. Thanks for the clarification.

In principle I agree that there's issues with ligature fonts, but I tried using one for a few months a while back and found that in practice I didn't find myself having to think more about what the underlying text actually was, and it was occasionally delightful to look at the pretty symbols.

On the whole I think they're nice.

The choice not to create these directories basically doesn't exist, because all sorts of software will automatically create them if they don't exist, their creation isn't centrally orchestrated. A while back I was using a minimal i3-based desktop and when I launched transmission-gtk it thought I might want a "Downloads" folder, and would create it whenever it launched, even though it had been configures to download files elsewhere.

    ~2 msec (mouse)
    8 msec (average time we wait for the input to be processed by the game)
    16.6 (game simulation)
    16.6 (rendering code)
    16.6 (GPU is rendering the previous frame, current frame is cached)
    16.6 (GPU rendering)
    8 (average for missing the vsync)
    16.6 (frame caching inside of the display)
    16.6 (redrawing the frame)
    5 (pixel switching)

By my count that's a whole 50 ms that shouldn't be there.

From the linked article:

One thread is calculating the physics and logic for frame N while another thread is generating rendering commands based on the simulation results of frame N-1.

Maybe modern games do use CoW memory?

[The GPU] might collect all drawing commands for the whole frame and not start to render anything until all commands are present.

It might, but is this typical behavior? This implies that the GPU would just sit idle if it finished rendering a frame before the CPU finished sending commands to draw the next one — why would it do that?

Most monitors wait until a new frame was completely transferred before they start to display it adding another frame of latency.

Maybe this is what is meant by the "16.6 (frame caching inside of the display)" item? That might be real then.

It's become harder to develop stupid simple bookmarklets because modern web pages are trickier to reverse-engineer, the market has expanded by a lot, and now people can make working on handy WebExtensions their full time job, and those are nothing more than bundled userscripts and bookmarklets that have access to some bonus APIs.

It used to be browser extensions were only used by a select few power users, if you don't count those installed by malware/shitware. Now it's common to see folks who only use their computers for Instagram and Youtube having all sorts of browser extensions installed intentionally, and use regularly. And they're essentially just bookmarklet/userscript bundles with access to some special extra APIs.

What's more, with the proliferation of Electron in desktop applications, now even more of the UIs we use are programmable.