For anyone curious (as I was) the basic difference is that WSL1 implemented the Linux syscall table directly whereas WSL2 actually runs Linux on top of some virtual drivers (hypervisor).
WSL 2 runs a full Linux kernel under Hyper-V. There are some out-of-tree or staging drivers included in Microsoft's Linux kernel derivative and they publish their kernel sources at https://github.com/microsoft/WSL2-Linux-Kernel.
While new contributions to Forgejo will by under the GPL, old contributions coming from Gitea will still be under MIT. The original Gitea code can be sub licensed to GPL but they must still keep the MIT license around.
Presumably it quite a bit of work to track everything as either MIT + GPL or just GPL. If someone made changes to a file only containing MIT licensed code could they not still claim their contributions as MIT license to the project? Forgejo could of course decline the contribution or sub-license it as GPL but wouldn't it be possible?
AIUI, the answer to your question is "yes" (just as for upstream MIT-licensed Gitea changes being merged in after the fork and license change). The file would be sublicensed and available under GPLv3, with the MIT license maintained. So business as usual?
(Not meaning to imply I have a more complete understanding than you here!)
The default way we write applications is actually pretty scalable already.
It always hurts to build something that “won’t scale” because it was framed as a negative.
Realizing that something “scales” if it meets your current needs is pretty important.
Framing scale in terms of how many people can work on it, how fast they can work on it, and how well it meets needs is often a better way of considering the “scale” of what your building.
As you said, when request per second becomes a limiting factor you can adjust your scales but doing it from start rarely makes sense (largely because req / sec already scales pretty well)
It’s often a fear or trauma response. Nobody wants to spend 6 months out of the year trying to keep the plates spinning, and they definitely don’t want to spend 60 hours a week when things get ahead of them. Everything takes twice as long as we think it will and we don’t trust that we can keep ahead of user demand. Many of us have experienced it or been adjacent, and for a long time after we overreact to that scenario.
Because we don’t trust that we can keep the wheels on.
Over time the memory fades, and the confidence improves, and we get more comfortable with things being okay instead of unassailable. But it can be a rough road until then.
Yeah, and out of that fear, people often use stacks that require vast amounts of knowledge to actually keep things working at all, at any scale. Kubernetes is the best example where I don't trust me to keep the wheels on because it's scalable.
I somewhat agree with the author, sometimes with async rust I need to figure out how to tell the compiler that yes I want to recursively call this async function. This can be a huge pain, especially because it’s not always clear what went wrong.
Other times however rust stops me from writing buggy code and where I didn’t quite understand what I was doing. In some sense it can help you understand what your software better (when the problem isn’t an implementation detail).
I get the authors frustration, I often have the same feelings. Sometimes you just want to tell rust to get out of your way.
As an aside, I think there is room for a language similar to golang with sum types and modules and be a joy.
