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