nuxt, sveltekit etc don't have RSC equivalent. and won't have in future either. Vue has discussed it and explicitly rejected it. also RSC was proposed to sveltekit, they also rejected it citing public endpoint should not be hidden
they may get other vulnemerelities as they are also in JS, but RSC class vulelnebereleties won't be there
Yes, of course AI offered by a company can be sued. The reason corporations became legal people in the first place was specifically so we could sue them.
> Not everywhere in the world do companies count as people
Actually yes, everywhere in the world. That has a functioning legal system, at least.
If companies weren't treated as legal persons, they wouldn't be able to enter into contracts.
But also, just to be clear, a legal person, like a corporation, is not a natural person. Unlike a natural person, they can't vote. There isn't anywhere in the world that considers corporations to be natural persons.
Laws are different in different counties, and I can't speak to all of them, but in the US, the law said you could only sue people, and the courts realized this was a problem. Rather than saying "I guess corporations get are exempt from all liability until Congress gets around to fixing it", they came up with a weird workaround that lives with us to this day.
EDIT: Note that ianal, nor a historian. The specifics of how this came about are best learned from a more authoritative source.
>Yes, of course AI offered by a company can be sued.
In theoretical sense sure.
In a practical sense? They are invulnerable due to what can be extreme financial obstacles they can put in place. They can drag a court case out until you fold if you haven't found a lawyer willing to do it on contigency.
This is kind of unfortunate in this case as it breaks some tooling since the extra trees are not collocated with git, like editor inline history/blame or agents that know to look in git history to fix their mistakes
I think the biggest benefits of colocation are, in rough approximation of the order I encounter them:
1) Various read-only editor features, like diff gutters, work as they usually do. Our editor support still just isn't there yet, I'm afraid.
2) Various automation that tends to rely on things like running `git` -- again, often read-only -- still work. That means you don't have to go and do a bunch of bullshit or write a patch your coworker has to review in order to make your ./run-all-tests.sh scripts work locally, or whatever.
3) Sometimes you can do some kind of nice things like run `git fetch $SOME_URL` and then `git checkout FETCH_HEAD` and it works and jj handles it fine. But I find this rare; I sometimes use this to checkout GitHub PRs locally though. This could be replaced 99% for me by having a `jj github` command or something.
The last one is very marginal, admittedly. Claude I haven't had a problem with; it tends to use jj quite easily with a little instruction.
To be technical, it's more that it can read and write the on-disk Git format directly, like many other tools can.
I think the easiest way to conceptualize it is to think of Git and jj as being broken down into three broad "layers": data storage, algorithms, user interface. Jujutsu uses the same data storage format as Git -- but each of them have their own algorithms and user interface built atop that storage.
You can still use git worktrees in a colocated repository. jj workspaces are a different, but similar capability that provide some extra features, at the cost of some others.
> there is no difference as jj is only a frontend to git.
It's easy to get this impression because git is so dominant, so most people using jj use it as a frontend to git.
But jj is a fully self-contained version control system. It always stores all its commits, branches, and other repo metadata in the .jj directory. You can use it standalone like this without ever using git.
Git integration is optional, and works by importing from or exporting to Git. Internally, jj still manages its own history. Git support is just a bridge.
jj may use git as (one of) its backing stores, and its collocation offers some compatibility at the cost of important tradeoffs, but it isn’t intended to be a git frontend.
No, you are not alone.for non-tech population, it may make sense that .NET 5 is continuation of .NET 4. But the tech crowd knows .net 5 is to .net 4 is what angular 2 is to angular 1.
With .net 4 still in active use, the naming makes it harder
Might be more confusing when you consider that ".NET 5" is actually the continuation of ".NET Core 3.1", not ".NET Framework 4.x"[0].
Microsoft has historically been pretty bad at naming stuff (sometimes hilariously so, see Microsoft PlaysForSure[1] for an example - spoiler: it surely didn't play for long).
The rebranding from .NET Core 3.1 to .NET 5, and from .NET 4.x to .NET Framework, did make sense to me though - and increasingly so as development continues on ".NET > 5" with yearly releases, while ".NET Framework 4.x" is in maintenance mode.
.NET Framework was always called .NET Framework and not renamed from
NET 4 to .NET Framework. There was a time where .NET was applied as a prefix/suffix to everything Microsoft released. Microsoft Windows Server .NET. that had nothing to do with the framework/CLR/programming platform but with Internet connected features.
Fair enough - I meant that, at least in Microsoft's own communication, they started more consistently referring to .NET Framework 4.x to differentiate it from first .NET Core and later .NET.
While it was always called .NET Framework, it was very commonly referred to simply as .NET (e.g. .NET 4.5) - and the "Microsoft .NET" logo was widely used in .NET Framework branding/marketing.
the drop of .NET core branding definitely makes it worse. as the other projects(like asp.netcore, efcore) just can't drop "core" from their names on a whim.
in my opinion, they should have kept "core" branding, but shortened it to ".NET" for marketing and only for marketing.
in a better world, Microsoft would ditch the name ".NET" altogether and invent a new one. like LVM (lightweight virtual machine)
No. Was hard enough to convince people of .NET Core away from the .NET Framework. Adding a completely different name and I would have several hundred java devs now instead of beautiful .net 10 on Linux.
they may get other vulnemerelities as they are also in JS, but RSC class vulelnebereleties won't be there
reply