> [T]he Bun project lead can do whatever the hell he wants with his own project. There is no objectively "right" path here, in a moral sense.
I think this is the exact point that the article was getting at in the last section. It is okay to not be very good at software engineering or people management! It is useful to know these things if you want to understand why the Bun project made specific technical decisions, but they don't make the people involved "bad people" in a more nebulous moral sense.
The lead developer of Zig is discussing these factors because the main technical decision was moving away from Zig.
Bun's bundler claimed the bottom place in my recent analysis of how JavaScript tools handle generating inline script tags[1], because despite making lofty promises about being able to bundle applications into standalone HTML files, it produced a baffling combination of spurious syntax errors and miscompilations when presented with tricky code.
I'm pretty sure the version I tested was the Zig one (have they made a stable release of the Rust rewrite yet?). So I can definitely see how Bun's move-fast-and-break-things philosophy would have been a poor fit for the Zig community, even prior to the Rust rewrite.
Scissors are the other big one; most of them are designed so that when to try to use them with your left hand, you end up pushing the blades apart slightly so they don't cut as well (or at all).
With that being said, self-deprecating jokes about how left-handedness is an affront to God are definitely a prominent feature of lefty culture.
(Edit: I guess formal place-setting is another area of society that assumes right-handedness, as well as restaurants that pack people close enough together that everyone needs to use the same hands to avoid elbowing each other.)
It's really easy to serve fallback images to browsers that don't support AVIF, either client-side using the <picture> tag or server-side via the Accept header. Which mostly eliminates the concern from the article, since you don't have to drop support for any customers.
It kind of makes me wonder if anyone has made a build system / framework that serves nested CSS to modern browsers, and falls back to a preprocessed CSS file that removes all the nesting for older browsers.
The gist of it is that standards organizations like the IETF depend on a specific carve-out in US antitrust law (in order for it to be legal for American companies like Cisco and Google to participate in them), and that carve-out includes a specific definition of what "standards organizations" and "consensus" are. So even if the IETF uses different words to describe its processes, those processes still have to comply with the legal definition that separates a "standards organization" from, like, an illegal cartel.
This is really common because of two design features that most UI frameworks share:
- The code that changes the color of the button is an internal part of the "button" component, so that people don't have to individually implement it on every button. But this means that it's kind of disconnected from the code that actually performs the action. If the "on click" handler has some last-ditch check that aborts the action, like the "don't rotate the image if it's in the middle of the rotate animation" check from the article, often there's no way for it to tell the button to cancel the color change. (And conversely sometimes the "on click" handler can fire even if the color change animation doesn't play correctly.)
- Buttons usually change color when you press down the mouse button, but only perform the action when you release the mouse button. Sometimes this is used to intentionally give you a chance to cancel the action at the very last minute by dragging your mouse off the button while it's still held down (or, on mobile, to e.g. reinterpret your interaction as scrolling instead of clicking), other times it just creates more opportunities for something to happen that prevents the action from working after the color change has already happened.
iOS has an accessibility option called "Ignore Repeats", which seems like a better approach because it's system-wide. So people who need that kind of accommodation can have it in places like the on-screen keyboard too, without needing everyone else to slow down their typing.
As I understand it, Zig is trying to bring in almost all the stuff that would usually be done by external tools. Zig has its own solution for finding system libraries (instead of pkg-config), it integrates its own C/C++ compiler, and you can do code generation with comptime (or, worst-case, a Zig program that can also be compiled to WebAssembly) instead of an external script. So I think there's a good chance that you'll be able to build most Zig projects entirely inside the sandbox someday.
There's still the obvious problem that if the build system emits malicious code, you'll probably run that code anyway. Personally I think this kind of sandboxing is more useful for enforcing build reproducibility rather than, like, protecting you from viruses in the build.zig file.
Not really? This change is about the code for downloading and extracting third-party packages. The @cImport change was part of an effort to (eventually) make Zig's dependency on LLVM/libclang optional, so that it could (eventually) be put into a third-party package, but it doesn't seem directly related.
Given that the most recent time Anthropic attempted regulatory capture, the US government responded by saying "alright, we agree that Mythos is too dangerous to release, so we've banned you from releasing Mythos," I can't wait to see what the outcome of this next push is.
The first page of the published paper ( https://orb.binghamton.edu/nejcs/vol8/iss1/6/ ) also claims that the game was developed by "Josh Wordle", so maybe it just isn't the highest-quality scholarship in the world.
I definitely remember only learning about two groups, personally. Is the third group, like, "irregular verbs", or do some books teach "the -suru verbs" as the third group (instead of "suru" being a single irregular verb that you can attach nouns to)?
Technically, it's possible to write the "si" sound as スィ, similarly to much more common constructions like ファ and ティ.
Wiktionary lists eight whole words that use it! (The entry for スィ itself, a couple obscure loanwords and proper names, and a couple alternate spellings of words that Japanese people normally pronounce using the "shi" sound.) https://en.wiktionary.org/wiki/Category:Japanese_terms_spell...
I used to get these terms mixed up all the time because some textbooks use "Group 1" and "Group 2" to refer to these verbs, but Group 1 doesn't mean ichidan.
For all that I'm not totally sold on this article's idea of "stems" and "suffixes", I think it does a good job of avoiding this pitfall and correctly explaining the groups.
"Disappearing consonant" doesn't work for the potential form, unless you expand the representation to allow writing -[rar]eru. (Edit: And I think imperative would require like "-[ro](e)".)
Which, like, is clean in the sense that Redux is technically Turing-complete (you can encompass _any_ difference between two strings by saying that one string uses the stuff in brackets and the other string uses the stuff in parentheses), but that doesn't make it a good idea.
I'm not totally sure this "stems and suffixes" mental model really works well for everything else. Forms like the imperative (食べろ), volitional (食べよう), provisional (食べれば), potential (食べられる), and causative (食べさせる) aren't cleanly handled either -- they work similarly for godan verbs, but you have to add a different suffix for ichidan verbs.
It's definitely useful to understand how "chi" and "tsu" fit into the hiragana chart, and if your asterisk notation helps you remember which verbs are ichidan vs godan then that's great, but I'm not sure it's worth trying to unify -masu and -nai into one model.