I've built quite complex applications (e.g. a spreadsheet app) using SolidJS as a base layer, and in that sense it scales really well. It's very easy to separate data management from the UI, so architecturally it scales well, and performance-wise we rarely had issues with it at all.
The biggest issue is in finding people to work with it. If you're hiring React developers over web developers, they will probably struggle more with SolidJS's differences from React, in part because they just look so similar that there's more to "unlearn". But most web developer (i.e. anyone who can understand beyond just the confines of their favourite framework) should find it relatively easy to understand what's going on.
Haha, that was part of the reason we originally went down this route. In practice, as soon as you want to implement spills, you lose a lot of the benefits because the contents of a spill can depend on any other cell and affect almost any other cell, and you need to evaluate the spill to figure out which cells are relevant. In the end, we rewrote the spreadsheet engine to use a different mechanism that was simpler and that we could optimise better, and then hooked that into SolidJS for everything else.
I guess technically that part of the application didn't scale so well in SolidJS, but it scaled a lot better than it would have in any other framework, and we got to delay writing the engine "properly" until we'd already built everything else and got it running with real users in production.
I think the biggest issue with Deno is that it fixes real issues but in the wrong way.
Take the sandboxing stuff. In theory, you have always been able to sandbox your applications. There are so many tools that let you limit what domains an application can access or restrict access to the file system. This doesn't need to be handled at the language/runtime level. It's just that people were lazy before, and they will continue to be lazy afterwards by running Deno applications with fewer than the minimum set of restrictions because that's easier.
The more complete way of solving the problem would have been capabilities. Rather than sandboxing the whole application, you instead sandbox each individual function. By default a function can make no requests, access no files, execute nothing, etc. But while the application is running, you can pass individual functions a token that grants them limited access to the filesystem, say. This means that trusted code is free to do what is necessary, but untrusted code can be very severely limited. It also significantly reduces what dependencies can do: if you're using something like `lodash` which provides random utilities for iterating over object keys and the like, and suddenly it starts asking for access to the web, then clearly something is wrong, and the runtime can essentially make that impossible.
It's also great for things like build scripts, which are a common attack vector right now. If your runtime enforces that the build script only has access to the files in the project folder, and can't access arbitrary files or run arbitrary commands, then you're in a much safer position than if your build script can do basically anything.
This concept has been explored before, but JavaScript is basically ready-made for it. The language already has everything you need — a runtime that also acts as a sandbox, unforgeable tokens (e.g. `Symbol` or `#private` variables), etc — and you can design an API that makes it easy to use capabilities in a way that enforces the principle of least privilege. The biggest problem is that there's basically no way to make it backwards compatible with almost anything that works with Node, because you'd need to design all the APIs from scratch. But one of the great things about Deno at the start was that they did try and build all of the APIs from scratch, and think about new ways of doing things.
I mean, it's not that surprising that you'll learn better in a stack you already know well - you know enough there to know what you don't know and need to learn. But if you don't know anything about a language, it will be very difficult for you to sort fact from fiction.
It's basically doing the same thing that, say, `return true` might do to indicate a function succeeded, but with more explicit types. However, because it uses `Result`, it can be used with the `try`/question mark operator which can be convenient in some situations.
That said, a couple of the examples here feel a bit strange - they're clever things you can do, but they're not necessarily things you often have to do, particularly for a relatively simple task like this. I think the problem with the author's approach is that they can't distinguish between "weird because Rust is weird" and "weird because the LLM generated bad code", because they (understandably) don't have enough experience in what good Rust code looks like.
As I understand it, in teaching there's an idea of the "Zone of Proximal Development" (ZPD). Some things you can do without help, other things you can only do if others do it for you, and then in between there's all the stuff that you can do with some amount of assistance. Being in this zone is important for learning, at least in theory.
I suspect that's kind of happening here. If you're trying to learn something too abstract or distant from what you currently know, you'll probably use more polished or eli5-y sorts of material, because you don't yet have the skills to understand a more complex version. You're probably not in the ZPD. But if you can figure some things out by yourself, possibly with some amount of help, then you're in the learning zone and can meaningfully progress.
I have similar experiences to you with 3B1B - it's interesting, but I rarely retain anything meaningful after I've finished - and I think it's because he has to explain every part for me to understand what's going on. I'm not in the zone of proximal development because I can't do enough of the work myself. So the end result is an interesting video where someone explains a cool concept to me, but it's not learning because it's not also doing all the foundation work that gets me to the point where I can understand the video for myself.
This is true, although I have to say as someone who doesn't own a car, good public transport can avoid most of those issues. I live in a small-ish city (500K - 1M pop, depending on how you count it), and I can get pretty much anywhere I need to without worrying about schedules and certainly without worrying about strikes. The biggest issue is getting out of the city - that's when it's usually more important to worry about schedules, but it's still mostly doable - and occasionally transporting furniture or something like that.
On the other hand, the benefits I get from that public transport are incredible - it's cheap, it's always there, it requires minimal logistics in groups (no trying to figure out who goes in what car and needs to be dropped off where at what time), it works regardless of my level of inebriation (admittedly I've not pushed that one to any sort of extreme yet), it's safe enough for children to travel independently (no dropping them off and picking them up), and it's largely accessible for people with difficulties walking or moving about.
I think a big part of the issue is that people have tried out poor public transport infrastructure and recognised - often correctly - that their car is way better for them. But good public infrastructure can often be far more convenient than cars, it just requires people to be motivated enough to build and finance it. A neighbour of mine didn't notice his car had been towed for a week because he used public transport so much and so rarely touched his car. When he'd parked his car it was fine, but then they needed to block of the street to do some work somewhere, and he didn't notice they'd confiscated all the cars there. That's the sort of effect that good public transport can have - so comfortable that you can forget you even have a car.
I think the right intuition to have with jj is that `jj st` should show an empty change unless you are actively working on something. `jj commit`, as mentioned below, is a good example of this - it automatically creates a new change and checks it out. The "squash flow" also does this well - you use the branch tip as a staging area and squash work into other changes on the branch as you go along. Either way, once the work is finished, there's an empty change at the tip of the branch.
This is also supported by jj implicitly - whenever you check out a different commit, if the change you were on is empty, has no description, and is the tip of a branch, it's automatically deleted to clean things up for you.
At this point, I think React and Lit are the only major frameworks not using signals. And I'm not 100% sure about Lit.
reply