Neither of these are good examples of organization. You should organize stuff by feature (without having any folders called "feature", "shared", "core" or "utils"). Essentially the rule for organization is simple; the moment you have any folder that is a catch all you have lost.
I mean thats the whole philosophy of Linux distros, anyone can create a Linux distro but the job they then take on is maintaining their own distribution of packages. I'm not saying your wrong; I'm just saying that is the what a Linux distribution _is_.
Usually thats the job of the Distro maintainers, your job is to provide a .tar.gz site on your website, the distro maintainers are responsible for publishing your app on their distro's.
I'm glad that Firefox is catching up, but they still have a lot of catching up to do compared to Arc/Zen. You got people out there like xe-darc innovating on putting Docker containers in your browser, and Firefox is just getting preview support for built in profiles.
I belive it also goes into the larger Wormblossom Willow project where there will be an online component, so that you can distribute stuff either online or via USB, building a sensorship-resistant protocol that works both online and offline.
Some doors can be designed with a large push handle to unlatch from the inside while still being closed from the outside. Allowing people on the inside to escape out but not the other way around.
An artifact is the output of an automated process that take some input and outputs artifacts. Its a generic term that can mean all kinds of things depending on the process and type of output. For example if you have a program that take an Open Office document in and produce a pdf and an epub file out then "pdf" and "ebup" would be the artifacts.
You'll get pretty far if you start off with Obsidian + Markdown + a makefile with Pandoc. You can even combine Markdown and Latex files together with Pandoc. This gives you an easy workflow with all the power you need using Latex as an escape hatch. And Obsidian have enough plugins to do whatever you want (or swap it for any other Markdown or code editor of your choice).
You can't use CRDTs for version control, having conflicts is the whole point of version control. Sometimes two developers will make changes that fundamentally tries to change the code in two different ways, a merge conflict then leaves it up to the developer who is merging/rebasing to make a choice about the semantics of the program they want to keep. A CRDT would just produce garbage code, its fundamentally the wrong solution. If you want better developer UX for merge conflicts then there are both a bunch of tooling on top of Git, as well as other version control systems, that try to present it in a better way; but that has very little to do with the underlaying datastructure. The very fact that cherry-picking and reverting becomes difficult with this approach should show you that its the wrong approach! Those are really easy operations to do in Git.
> A language’s type system doesn’t need to model every possible type of guarantee
Actually this is the exact point of a type system. Why would you want to write unit tests for stuff the compiler can guarantee for you at the type system level?
I'm surprised by the backlash in the comment section here, all of these things seems like the obvious next step for Rust. It seem people are scared of big words?
React Native is able to build abstractions on top of both Android and iOS that uses native UI. Microsoft even have a package for doing a "React Native" for Windows: https://github.com/microsoft/react-native-windows
It's weird that we don't have a unified "React Native Desktop" that would build upon the react-native-windows package and add similar backends for MacOS and Linux. That way we could be building native apps while keeping the stuff developers like from React.