Specifically, do you worry that Microsoft is going to eventually do the Microsoft thing and horribly fuck it up for everyone?
I'm not sure you are aware, but Microsoft created TypeScript.
https://devblogs.microsoft.com/typescript/announcing-typescript-1-0/
Without Microsoft, TypeScript would not exist.
FYI, there's a TypeScript community in Lemmy.
I'm sure that any non-trolling/flamebait discussion over TypeScript is welcomed in there.
Could also be that the standard is lacking in some areas.
I don't think that explains it.
If we're talking about extensions that cover custom features then obviously those aren't supposed to be standardized because they haven't been widely adopted.
If an implementation is missing a feature then that's a shortcoming of that particular implementation, not SQL's.
If an implementation screws up and has non-compliance qwirks, that's a bug in the implementation, not a problem with SQL.
Take SQLite for example. It explicitly does not support static, rigid typing, and claims it's a feature. However, SQL supports static typing and other implementations leverage that for performance and cost gains. Additionally, SQLite also keeps a list with a summary of all the SQL features it purposely does not implement.
SQLite is pretty popular. Does this mean SQL is lacking in any way? Is the SQL standard "lacking" because it supports ALTER TABLE foo ADD CONSTRAINT even though SQLite does not? Or is this a problem caused by an implementation failing to comply with a standard?
I’m absolutely biased as a data engineer who loves SQL, but there are some good reasons why SQL has been the de facto standard for interacting with databases since the 80s.
I find it funny how the people who actually have to wrangle data swear by SQL as awesome, but there are always random hacks coming out of the woodwork, who don't even look at SQL at all, with sweeping statements claiming SQL sucks because reasons.
It's like the most opinionated people against SQL are the ones who don't use SQL.
sql was built so people other than devs can use it, but we got stuck with it.
Not really. Being designed with UX in mind, so that it sacrifices conciseness for readability, does not make it something for "people other than devs".
Likewise, BASIC was also developed with UX in mind, and no one in their right mind would ever claim that it's not a programming language.
excellent tui for selecting chunks like incommit -i. Arrow keys quickly fold and unfold files/chunks/individual lines
git add -p might not have a fancy TUI interface but it supports picking files/chunks without an issue. I'm not sure how this could be described as a UI problem.
commits come in 3 categories:
I'm not sure how that would be useful in Git's perspective. In Git, public commits are commits pushed to a shared remote repository, and draft/secret commits are just local commits that you don't push. I'm not sure what value those specialized types of commits add.
Git's approach sounds simpler, consistent, and coherent, and thus simple to learn. I'm not sure what was gained by pushing that level of complexity onto Mercurial.
when you rebase, your previous commits are marked obsolete and hidden from most UI.
I'm also not sure if that makes sense. If you rebased a branch, you don't expect the original branch to stay there. As the name implies, what you want to do is to replay a sequence of commits onto another branch. In the rare cases you wish to keep the original branch in place, you just create a new branch alongside the old branch and rebase the new one instead.
Keeping the old branch in place after rebasing it feels inconsistent and illogical.
No matter how low overhead you get, it’s still node, which means it’s still an actual order of magnitude behind Go & Asp.Net Core
I'm not so sure about that, at least in general terms. Some benchmarks show Node.js outperforming Go. See Web server 'hello world' benchmark : Go vs Node.js vs Nim vs Bun (previous discussion here)
each system has it’s own dialect and quirks
That does not mean that SQL, as specified by one of it's standard versions, is not portable. It just means that some implementations fail to comply with the standard and/or provide their own extensions.
If an implementation fails to comply with the standard, that's a failure on the side of the implementation, not a failure of SQL.
Honestly, a similar tool should rethink the design to be more intuitive, orthogonal and have fewer concepts that cover all use-cases.
With regards to Git I'm a victim of Stockholm syndrome, thus it's hard for me to see where are all those alleged unintuitive design choices.
This analysis is rendered even more difficult as these criticisms of Git are depicted in vague terms without mentioning a single concrete example.
To make matters worse, these accusations become even less credible given the fact that all other Git competitors seem to copy Git's user interface almost verbatim. This means Git must be doing something right.
So given this issue, is there any concrete example of where Git is lacking in the UI department?
It’s long running, so you want a database so you can store your state. If you’re storing state, locking it into a state machine makes sense.
That's besides the point. Of course that the most fitting way to represent a state machine is with a state machine. The point is that implementing the transition table in a database table creates many problems while apparently solving none.
This submission isn't exactly on-topic, but I presume it will spark some interest among some of the readers.
I don't think there is any merit to that concern. Not only is TypeScript FLOSS, Microsoft also has an excellent track record developing high-quality programming languages and tech stacks. Take for example C#. It's been around for over two decades and if anything it's getting better by the release.
I understand the rationale behind the concern, but there is also a factor of mindlessly parroting cliches.