> not promoted as some sort of better alternative to JavaScript, because it's really not.
This leaves me skeptical if you have extensive experience with Typescript. It's way more than "oh this is a number not a string." It's "you forgot this property on an object's return type that you built from a response value" or "your Redux reducer doesn't handle all of the possible action types so it will crash at run time"
Deno attempts to provide a standalone tool for quickly scripting complex functionality.
That's from Deno's home page. What I'm talking about isn't whether TypeScript is useful for some projects, as that has been proven beyond question. What I'm saying is that as a tool for "quickly scripting", as claimed by Deno, it is unnecessary and counter productive to JavaScript as a whole.
My point is that the Deno project is a high profile JavaScript engine which, in my opinion, is misguided in their end-user focus on TypeScript and I think it's a shame.
Devs are always searching for the "right" way to do things, and can be easily convinced to do things like misuse "const" because some pedantic fool convinced them it was sorta like type safety, and therefore not using it was "baaaaaaad". And the sheep followed and now const is used everywhere, despite the clear and unambiguous intended functionality of the feature's designers, who added it as a way of tracking, incredibly, constants and nothing else.
It would be nice if we saved a generation of devs another debacle like const, NoSQL databases and UML.
How are NoSQL databases "bad" and should in general? The term "NoSQL" in itself is very inclusive and might include databases such as redis, elasticsearch or apache cassandra.a
It's important to choose the right tool for the job and SQL/ relational DBs fit many usecases but are not always the right choice. Especially when handling massive amounts of data, that can fit into structures such as wide-column stores, databases like scylla or columnar storage with clickhouse, can help massively.
NoSQL is a good solution for the 1% of projects that need it. It sounds like you had great success with it, congrats.
Otherwise, it just ends up being a big flat in-memory table with a badly implemented version of SQL welded on top, written by developers who never bothered to learn SQL or database management in the first place. Then a bunch of fad followers jump on the bandwagon, and before you know it, we have a decade of idiots blathering on about "web scale" technologies.
That's the debacle I'm talking about. Millions of man hours wasted.
There is zero practical downside to using `const` whenever possible, and my (Fortune 100) team's backend has been using a NoSQL database for years which has saved us an absolute ton in hosting costs. Hardly a "debacle."
Our solution is the right way to do things... for ourselves. Sorry that it upsets you.
"your Redux reducer doesn't handle all of the possible action types so it will crash at run time"
And what are all these dr. Strange multiverse possibilities you speak of? Any semi seasoned JS dev has spidey sense for watching out for null and undefined, and generally you should know the type of what you are returning. Is there that much variability in what you are dealing with? If it’s an array of objects, that’s not hard to hold in your brain, just watch out for empty arrays or null/undefined items.
> Any semi seasoned JS dev has spidey sense for watching out for null and undefined
That comment reeks of the same biases that C/C++ developers make when they admit that a majority of C/C++ bugs are related to hard-to-detect pointer/memory safety issues, but claim that they're a good C/C++ developer because their own code doesn't have such bugs, despite the bugs by their very nature being hard-to-detect.
I am not a web dev at all but having something for automatic verification (even if limited) sounds more reliable than the variability of any given dev's "spidey sense".
This leaves me skeptical if you have extensive experience with Typescript. It's way more than "oh this is a number not a string." It's "you forgot this property on an object's return type that you built from a response value" or "your Redux reducer doesn't handle all of the possible action types so it will crash at run time"