I think it’s unfortunate that only the first paragraphs were posted (assuming because Google Translate messed up the rest too badly), because the author of the second post echos many of your points. They also talk about PPLs and why they think the Turing ecosystem is great in that area.
The first post is definitely more surface level and a little all over the place, but it seems like their general perception is positive after running a couple of “unscientific benchmarks” (it’s not mentioned directly, but they also like the idea of solving the two-language problem)
The deployment story is not very good. Most of the time, I am struggling with dependency import/caching issues under highly strict environment.
Maybe, full static compilation with assets like //go:embed or java style jar/war packaging all .jl and template files for deployment takes this so much farther.
Webassembly support will also be helpful, I guess this can only happen when there is good static compilation to binary support (otherwise, we have to load the complete julia runtime onto the browser). Ability to compile high perf code to browser for exploration/analysis is game changing. Currently in this area, rust has the best tooling and support.
In my view (background in control theory), multiple dispatch is a control-theoretic generalization, e.g., Willem’s behavioral approach to control theory. So, the conventional input/output functional approach is a subset of this general approach using shared variables.
The power from using such an approach is not immediately evident, as people could point out how some systems are well-modeled using existing input/output approaches (using existing programming languages). However, once people start to model more realistic systems, then a simplistic input/output approach will have difficulties and will necessarily become increasingly complex, inefficient and in many cases prone to inaccuracy.
The reason is that partitioning systems in terms of input/output enforces a direction, and that direction may be unphysical. The alternate approach is using shared variables, i.e. behavioral approach, wherein relations share variables instead of a priori prescribing a directional relationship.
Multiple dispatch efficiently enables this shared variables feature and as a result, the libraries users generate could share “variables,” reflecting realistic system behavior. Therefore, there’s going to be a tremendous degree of reusability, especially for scientists interested in understanding natural systems.
I expect Julia to have exponential growth. Customer-funded productivity & efficiency will eventually overrun short-term losses from lack of tools relative to more “mature” languages like Python.
I always hate to talk about OO vs multiple-dispatch to physicists or even just general scientists - it’s like category theory never makes sense to the majority of physicsts, it’s never the right way to show something abstract that is right for practioners. It’s actually not about if one is an experienced programmers or not. Practioners are usualy not both developers, they only cares about results.
I think I have a few words to explain for people who are not on Chinese forums since I was the probably the only one trying to prompt Julia on internet back in 2015 and I believe most of the Chinese users know me or saw my posts. I think this is the same as what I saw in the general English community. Since there is just people, Chinese users share the same concern as English users for a technology, there shouldn’t be a difference except localization, it’s just people don’t understand the English language.
And we (JuliaCN) are also working on localization since 2015 with many many people involved and contributed. And even there are people complained and give up, there are approximately 70,000 visitors for the Chinese documentation per month, IIRC. And there are new big companies in China start getting interested in Julia since last year and contact me and even sponsor our activities. So the fact is few people giving up doesn’t mean most people don’t like it.
So what problems do people concern?
You might find me stop doing so recent years, partly it’s because I’m getting busier, but the other part is because I find it doesn’t matter - most people are users not developers, they don’t care what this language is capable of, and why this language is better by design, what they care about is:
does Julia solve my problem in hands?
can I find a job by learning Julia?
is the package X easier to learn than Python?
I have to say, unfortunately, at the moment, 1 is a maybe, 2 and 3 is very likely no. This is why if you go to my English blog post you will find me writing blog post in the title of “building X in ONE day”, when a user see you did the same thing within 600 lines in Julia and they need 2000 lines of code in C++, they will learn Julia, you don’t need to explain what is OO and what is multiple dispatch, they will learn from these concrete examples. I’ve successfully convinced people in a few mins by just showing them the blog post - no one wants to listen to these OO vs multiple dispatch bullshit at least in physics IMHO, most people just want their work done.
In my own field of quantum computing, people love the python frameworks implemented by big companies, and keep questioning why would they use Yao.jl - I don’t like to answer it and explaining the design, I tend to show them our 10,000 layer benchmark in the paper as well as tropical algebra support, and if they want it, no matter they like multiple dispatch or not, they have to learn Julia. And I know our tutorial and documentation is bad at the moment, but since this will be only way to get their work done, people will workaround it, and maybe help improve it afterwards.
So IMHO, most people don’t care what language is better, I won’t tell them how we designed our IR and how we think circuits as algebra data types, because no one cares why and most users shouldn’t care about it.
One big advantage of Python is when you want to implement something in Python, you can find tons of different related implementation for reference for almost everything, so does C++, this is simply due to the fact that they exists much longer. When there are more Julia implementation, people will just accept multiple dispatch, you may hear complains of understanding multiple dispatch from OO, but that’s not the real complain, the real complain is when they migrate the code, there is no related readable implementation as a reference for them. And I believe this is getting better.
On the other hand, Julia still lack of teaching materials for best practice, this is not only about programming the language itself, but also about packages. For reference, you may find books just
about Pandas, Numpy, Scipy etc. for Python. Since we are just 1.0 since 2018, I don’t our ecosystem would be mature enough to have these things within just 3 years. This also really takes time.
Regarding to jobs, the jobs are growing, I won’t worry about that, but it’s true that if you only know Java or some other languages, such as C++, you may still find a software engineering job, if you only know Julia, this is probably not true.
Back to Guido’s comment
Back to Guido’s comment on web services, which I happened to worked a bit on for QuEra Computing Inc. recently as well as wrapping up IBM/AWS REST services for quantum computing (you can find my previous announcement on discourse), I have the same conclusion at the moment: you probably don’t want to do web related things in Julia at the moment. But don’t take me wrong, I do think Julia is a good language for web, and it should be. And actually in my experience of reinventing wheels that Python has in native Julia, Julia is much easier to work with because of the explicit typing and immutables and many other features as a modern language.
The problem is still about packages and popularity, Iet me talk about the issue of popularity first: how much developers can you find on linkedin that has a CV that convinces you he/she is a good Julia programmer for web? how does this ratio compare to Python? I think the answer is obvious. Genie is great, so does HTTP, but as a company, we need to think about how can we hire people for certain tech stack. And for web services which is not the core bussiness for a company, I believe people just tend to hire more popular stack but say if you know some Julia that’s a plus.
On the other hand, for packages themselves, the web ecosystem is still not large enough. To implement IBM/AWS REST wrappers, I have to partially port Python’s pydantic to Julia as Configurations and there is a work-in-progress KungIChi, because it seems no one cares schema checkers in Julia and conversion between structs and schema protocals at call. There is even no mention of OpenAPI standard (well there is only one comment) on this discourse at all. We need to admit we don’t have a huge web community here.
And when I looked at Julia web stack, there are still a lot things I belive is missing. And even just doing mocking test itself is still gonna be a painful thing until 1.7 (because we need method overlay) Or even one of the most basic problem of implementing CLIs was still a huge issue with ArgParse, so that I tried to improve this with Comonicon. If you are a system admin, I’m sure you don’t want to write julia --project=path/to/Project.toml -e "a long script" everywhere, and I think this is important for whoever works on servers.
I believe there are definitely many other bad things for web in Julia at the moment, it’s not anyone’s fault, it’s just because it’s a young community that doesn’t have enough people yet, so we do have some bad things, and we will solve them, let’s just admit it
I don’t think this is always the case, I think at the moment, Julia is a language that makes developers happy, but users may not. By developers, I mean people who loves creating wheels for others even it’s from scratch. There are too much exciting advantage that has been mentioned over and over again on slack, zulip and discourse.
As long as we show a web related application that cannot be done in Python (e.g what about interactive web UI design using Pluto-like architecture?), I believe no one would say niche.
So I stopped arguing who is better on zhihu.com (the Chinese Quora) after my last post explainning why
Python won’t be faster than Julia and why Julia is better back in 2019. And instead I choose to write more packages (https://packages.rogerluo.dev) and more blog posts. In many cases, for people who has not been to a compiler class or years of programming experience, it is hard to explain clearly from an abstract level/design level on why it is better. I tend to just show more concrete cases, I believe that’s what also most people prefers on this forum.
And we don’t need convince Guido that this is not a niche language, or whoever else. Guido doesn’t like @thautwarm 's pattern match proposal, and we are happily using it in the MLStyle package now in Julia, and many people like it, no one is always right. let’s show them code and write more packages in native Julia instead, I’m pretty sure someone would say language X is a niche language comparing to Julia 10 years later when we have much much more better packages.
no struct types interface aims to provide some extra information for the JSON parser to use via traits, where things like pydantic aims to make checks on communication schema, configurations etc easier and simple. This is two entirely different things but can be combined.
About the lack of example code, I agree. There’s also the problem that it’s way too easy to find years old code. This problem will eventually go away, of course.