That’s entirely fair for the usecase of a small script or plugin, or even a small website. I’d quickly get annoyed with Python if I had to use it for a larger project though.
TypeScript breaks down when you need it for a codebase that’s longer than a few thousand lines of code. I use pure JavaScript in my personal website and it’s not that bad. At work where the frontend I work on has 20,000 lines of TypeScript not including the HTML files, it’s a massive headache.
This is the case for literally all interpreted languages, and is an inherent part of them being interpreted.
It’s actually the opposite. The idea of “types” is almost entirely made up by compilers and runtime environments (including interpreters). The only thing assembly instructions actually care about is how many bits a binary value has and whether or not it should be stored as a floating point, integer, or pointer (I’m oversimplifying here but the point still stands). Assembly instructions only care about the data in the registers (or an address in memory) that they operate on.
There is no part of an interpreted language that requires it to not have any type-checking. In fact, many languages use runtime environments for better runtime type diagnostics (e.g. Java and C#) that couldn’t be enforced at runtime in a purely compiled language like C or C++. Purely compiled binaries are pretty much the only environments where automatic runtime type checking can’t be added without basically recreating a runtime environment in the binary (like what languages like go do). The only interpreter that can’t have type-checking is your physical CPU.
If you meant that it is inherent to the language in that it was intended, you could make the case that for smaller-scale languages like bash, Lua, and some cases Python, that the dynamic typing makes it better. Working with large, complex frontends is not one of those cases. Even if this was an intentional feature of JavaScript, the existence of TypeScript at all proves it was a bad one.
However, while I recognize that can happen, I’ve literally never come across it in my time working on Typescript. I’m not sure what third party libraries you’re relying on but the most popular OAuth libraries, ORMs, frontend component libraries, state management libraries, graphing libraries, etc. are all written in pure Typescript these days.
This next example doesn’t directly return any, but is more ubiquitous than the admittedly niche libraries the code I work on depends on: Many HTTP request services in TypeScript will fill fields in as undefined if they’re missing, even if the typing shouldn’t allow for that because that type requirement doesn’t actually exist at runtime. Languages like Kotlin, C#, and Rust would all error because the deserialization failed when something that shouldn’t be considered nullable had an empty value. Java might also have options for this depending on the serialization library used.
As a TypeScript dev, TypeScript is not pleasant to work with at all. I don’t love Java or C# but I’d take them any day of the week over anything JS-based. TypeScript provides the illusion of type safety without actually providing full type safety because of one random library whose functionality you depend on that returns and takes in any instead of using generic types. Unlike pretty much any other statically typed language, compiled TypeScript will do nothing to ensure typing at runtime, and won’t error at all if something else gets passed in until you try to use a method or field that it doesn’t have. It will just fail silently unless you add type checking to your functions/methods that are already annotated as taking in your desired types. Languages like Java and C# would throw an exception immediately when you try to cast the value, and languages like Rust and Go wouldn’t even compile unless you either handle the case or panic at that exact location. Pretty much the only language that handles this worse is Python (and maybe Lua? I don’t really know much about Lua though).
TLDR; TypeScript in theory is very different from TypeScript in practice and that difference makes it very annoying to use.
Bonus meme:
Honestly chapter 3 was way worse to me at first. I hate those red dustbunny things and I swear they made the timing specifically so that I would constantly run into them and I hate it.
I believe in 2a and 5b Celeste supremacy. Aside from having the best soundtracks I also like those levels the most as well
Zangoose is a Pokemon, there’s probably hundreds of sites with it
You have found neither my site nor a site talking about me
Hey did you know that any JSON file is also a valid YAML file? I bet you’ll love YAML a lot more now that you have this information
I don’t have any GitHub.io sites but I appreciate the joke :)
How did you find one of my GitHub repos?
One step at a time 😭
There are a few libraries we’re using that stopped being developed after Angular ~9-10 and one we use extensively with breaking changes between 10-12. Updating to 8 wasn’t too bad but for some reason Angular’s update tool didn’t actually do anything so I had to update the package.json manually and fix stuff by hand (luckily the only change was fixed with a bulk find/replace)
To me at least angular makes a bit more sense than React’s way of doing things does. React tries to be functional with its components and yet it seems like they end up basically trying to mimic classes with useState and useEffect. To me Angular’s class-based approach makes a bit more sense (though I am primarily interested in backend development more than frontend so that could be why)
It does kind of fall into a lot of the traps of Object-Oriented programming though so I can see why a lot of people don’t like it
Don’t come at me like that 😭
You know neovim can use the exact same LSPs (Language Server Protocol) for intellisense as VS Code right? There’s intellisense, git integration, code-aware navigation, etc. Neovim can be everything VS code is (they’re both just text editors with plugins), except Neovim can be configured down to each navigation key so it’s possible to be way more efficient in Neovim. It’s also faster and more memory edficient efficient because it isn’t a text editor built on top of a whole browser engine like VS Code is.
I use a Neovim setup at home (I haven’t figured out how to use debugger plugins with Neovim and the backend I work on is big enough that print debugging endpoints would drive me insane) and I can assure you I have never given variable names one letter unless I’m dealing with coordinates (x, y, z) or loops (i, j) and usually in the latter scenario I’ll rename the variable to something that makes more sense. Also, we don’t do it to seem hardcore, it’s because there are actual developer efficiency benefits to it like the ones I listed above.
By your own logic you “can’t be bothered” to learn how to edit a single config file on a text editor that has existed in some form for almost 50 years (vi). Stop making strawman arguments.
My bad, that’s on me, it looks like the C++ libraries I found use either templates or boost’s reflection. There might be a way to do it with macros/metaprogramming but I’m not good enough at C/C++ to know.
I’m learning rust and C at the same time and was mixing up rust’s features with C’s. Rust’s answer to reflection is largely compile-time macros/attributes and I mistakenly assumed C’s attributes worked similarly since they have the same name.
See my other comment for more detials but it kind of destroys the type safety of the language. In Java for example, it lets you modify private/protected fields and call private/protected methods.
It’s also slower than accessing a field normally since you need to do a string lookup (but slightly faster than a hashmap/dictionary) so if you use it over a large enough list it’ll cause slowdowns.
Most use cases for it in Java/C# revolve around testing, serialization, and dynamic filtering/sorting. And most of those cases can be handled more safely using macros/attributes (EDIT: and templates as well, though those are also pretty painful to deal with) because that gets handled at compile-time in C/C++.
It’s pretty cool when you use it right but it’s also really easy to shoot yourself in the foot with, even by C++ standards. For example, in other languages (I’m coming from Java/C# which both have it) it lets you access private/protected fields and methods when you normally wouldn’t be able to.
There’s also a noticeable performance penalty over large lists because you’re searching for the field with a string instead of directly accessing it.
For the times it is necessary (usually serialization-adjacent or dynamic filtering/sorting in a table) to use reflection, it’s faster at runtime than converting an object to a dictionary/hashmap. However, 99% of time it’s a bad call.
There’s a pretty big difference though. To my understanding enable_if happens at compile time, while reflection typically happens at runtime. Using the latter would cause a pretty big performance impact over a (large) list of data.
The dev who owned the branding for forge (LexManos) is infamously abrasive and rude to others to the point where the forge community was slowly falling apart because new people didn’t want to be involved with him. The rest of the team decided to rebrand to NeoForge and continue without him.
Probably performance - the Java server takes up a lot of memory and CPU for what it does. The base implementation first started in 2011, so it wasn’t exactly designed to be multithreaded or parallelized because most games were still largely single-threaded at the time. Rewriting it from scratch in a different language probably helps with that