Everything you just said is true for Typescript, as you can set it up as strict or as forgiving as you like, and writing one off scripts for node is just as easy as for Python. But unlike Python, it has a great type system.
First, the JS ecosystem is very web oriented, so if you want to dabble out of there, you often gonna fall short.
Secondly, the JS packaging has very poor support for compiled extensions, which mean everything that needs a perf boosts is unlikely to get good quality treatments.
Finally, the community makes it a constant moving target. After 20 years of writing both JS and Python, I can still install old django projects that use 2.7 (did it 2 months ago), but JS projects for even 5 years ago are a very hard to build.
Bottom line, I use JS for the Web because I have to, given it has monopoly on the browser, and now good GUI, but if I want to keep my options open, I would rather go rust or go than JS.
We found the package support to be far superior in JavaScript. Even a lot of non-web things like working with solar inverters and various other green energy technologies (which at least here in Europe is very, very old school) we’re significantly easier with JavaScript than they were with Python. I guess FTP is web, but it’s the example I remember the best because I had to write my own Python library for it because the most used packages couldn’t handle a range of our needs. This may be because it’s FTP is not me shortening SFTP, no no, that’s just what solar plant engineers figured would be practical. Sure they recommend you don’t put the inverters directly on the internet in their manuals, but who reads those? Not solar plant installers at least. Anyway, I fully expected Python to be king for those things considering it’s what runs a lot of IoT, but JavaScript was just plain better at it.
Which is generally the story of our migration of basically everything to typescript. Some or our C++ code ended up as Rust, and I really, really, love Rust, but most of our code base is now Typescript. It might all have been Rust if Rust was a frontend web language, but it would never be Python. The reason for this is the environment. Not just the package and module systems, but also how you can set up a very “functional programming” (in quotes because it’s not really FP but JSFP) to cut down on the usage of OOP unless absolutely advantageous, type safety, specific coding systems and how easy it is to actually enforce all of those things automatically. Is just a much better experience with Typescript compared to Python in our experience. I think you could very likely achieve some of the same with JSDoc and JS and not Typescript, but we couldn’t get that to work (as well) in our internal tooling.
Somewhat ironically, the two areas JavaScript wasn’t better than Python were in what I’d consider web-related parts of your tech stack. There aren’t any good JS SQL ORMs, Prisma is ok and so is MikroOrm but none of them compare to what’s available in Python. The other is handling XML, which is soooo easy in Python. I mean theoretically it should always be easy to handle XML, but that would require the XML you need to handle to actually adhere to any form of standards, which I guess is utopia.
But I guess you can have very different experiences.
You evaluated the needs and figured out what tools you needed for the specific job you are doing.
That's what we are supposed to do.
Everything Java 11+, modern libraries (no Spring, no Hibernate).
The Java ecosystem is so deep that you can avoid the top 2 libraries/frameworks in any major domain and #3-#5 would be highlights in other ecosystems.
Because it seems to me that once you compile something you are in the awkward world of ABI and CPU differences. And binary portability has been a paint point of programmers since before I was born (and I'm not that young).
So if there is a programming language that neatly gets around this problem, me and a lot of other folks would really like to know about it.
- a NuGet package with native deps (win, linux, osx) cross join (x86, arm) - a P/Invoke package that depends on the native one - actual software that uses the dependency
When you publish the actual software, it pulls the deps and includes the correct native build.
E.G, if you use, rust, through maturin, cross platform compilation is pretty decent: https://www.maturin.rs/distribution.html
This works far better in Rust, for example.
Of course if Python wasn’t so dog slow we wouldn’t need so many native packages.
I wish I could have TypeScript's block scope and type system but have access to Python's ecosystem. That would be a great combination.
I get the impression JS devs would rather have a new framework with bugs and cool emojis in the commits than something more stable and less buggy.
At work we are moving to nestjs and I love it.
Neither of those work well in Python. To import third party libraries you need to use Pipenv or Poetry or one of the many other half baked options.
Importing first party dependencies (e.g. code from another file) is also a nightmare because the path searching strategy `import` uses is insane. It can even import different code depending on how you run Python!