> Tech is supposed to just be tech, but when the community behaves this badly about adopting improvements how can that not influence your decision to invest in that tech?
What you say was bad about it? And who were the bad people specifically? The people who were using python 2 or python 3?
For what it's worth, python3 >= 3.0 && python <= 3.2 were hideously broken in their unicode support. Arguably had worse/unusable uncode relative to python 2.6 or 2.7.
So there was a huge failure to launch type of problem, especially given how long python3 had been development.
It most definitely left a very sour taste in many people's mouth that didn't start dissipating till 3.5 or 3.6 when enough "killer" features had accumulated.
Even then, for a lot of usages, python 2.7 'just works'.
Like everything else, it's an opportunity cost. Personally, I think LC is a great return on time invested. It takes far less time and money than say, any of the traditional gatekeepers, even for example a CS degree, or even perhaps a good data structures and algorithms class that is semester long.
It seems like depending on how you configure typescript (e.g, in tsconfig), typescript is already something like an ensemble of mini-languages with different dialects and semantics. Much more so than other languages. But I agree, restricted typescript that has to do less work (data or control flow analysis) would probably be on the orders of magnitude faster.
> It's not at all a readable language imo. It is very much write-optimized. It has tons of code golfing and one liners.
Agreed. This might have been applied to the "Zen of Python" days back in 1999, when the competition was Perl, but python has slowly morphed into a more and more perl-like language.
JSON like it or not, is the world's most dominant data exchange format, so much so that processing JSON is a not so insignificant part of all data center CPU cycles.
Julia has one good library for this (JSON3.jl), but it really should be embedded in the language.
Furthermore, Julia has very nice support for multi-dimensional arrays, but it's built in support for dictionaries/hash maps isn't very good, and they might be more prevalent in many types of data processing (certainly in many "big data" types of workloads). There is another third party library for this (Dictionaries.jl) but once again, in practice, JavaScript and TypeScript not only much faster and more optimized for this, but also have better tooling available out of the box.
Again, not a knock on Julia at all, it's great for certain things, but it's important to understand where the ecosystem has gaps are and where things can be learned from other ecosystems.
I'll give you my two cents since I've tinkered with both languages extensively (tho I mostly write Python or C++ professionally, and Scala in the past).
I'd say TypeScript has a lot of things that are missing from Julia that are very useful for "data" oriented usages. And vice versa, Julia has a lot of numerical and metaprogramming stuff that is missing or nacient from the JS ecosystem.
I would say that TypeScript makes it a cake to create robust data processing pipelines around the most use data format in the world (which is JSON). I find structural subtyping surprisingly good for anything 'dataset' oriented, especially building up streaming datasets from various APIs and storage mechanisms (e.g, the usual "data engineering") in very robust ways. Julia also lacks interfaces or traits which are important for larger codebases.
Also, the tooling and developer experience is much better in TypeScript. Julia sometimes is like going back in time in that regard.
I have high hopes for Julia but I suspect that anyone who doesn't say that it could use some of TypeScript's features probably has not used TypeScript or JavaScript recently. There is a reason why TypeScript has influenced pretty much every other dynamic language in the last 5 years.
These are all important things when you have a large codebase, or need something robust in production. These are things that Julia has not yet been able to break into. Almost every feature in TypeScript was created to solve problems with JavaScript historically in this regard.