Comment by ablekh | Hacker News Reader

Comment by ablekh | Hacker News Reader

While being a big fan of Julia in general and recognizing a very significant progress in both language and ecosystem development [kudos to Julia's core team as well as numerous contributors to the language and its growing ecosystem!], I respectfully disagree with the post's author conclusion in its entirety.

For scientific computing and advanced machine learning domains, Julia is certainly a breath of fresh air and a no-brainer decision. However, as a general-purpose language as well as technology stack, I think Julia has still a long way to go. This is mostly due to relative immaturity of that part of the ecosystem, spotty - and sometimes even non-existent! - documentation (of course, except for the language itself and quite a limited number of core and popular packages) as well as some other issues, including tooling, development/compilation performance and limited pool of skilled developers.

So, from a startup founder perspective [who has to select the optimal, risk-minimizing, platform stack], despite Julia's many attractive features (including powerful meta-programming facilities - in my case, for potential DSL development), I'm now leaning toward Python and .NET ecosystems. Both offer very mature and large package ecosystems along with comprehensive tooling support and incomparably larger pool of skilled developers. Additionally, .NET offers stability of consistent development improvements, backing of a major corporation [no acquisition risk] along with support for modern enterprise-focused architectural practices and patterns, including DDD and multi-tenancy.

This.

Not trolling. I don't really know why people like to shoehorn a purpose-oriented language into all domains. Eg: Julia for scientific computing, Rust for low level programming. They would be great if they focused on those "strong zones".

I read this article not as a "Julia is ready to replace the all-purpose languages used in business", but as "Julia is ready to deploy it's scientific computing into production environments" (as opposed to just local/hobby tasks and academic environments which were the early focus). No one is recommending people to do their small e-commerce in Julia (or perhaps Rust) unless you're in for the fun of the languages (or your e-commerce happens to be a special case that will play with either language's strengths). But having a solid web deployment story is important to both regardless, be it in Julia to have live dashboards or integrating your scientific models in your microservice architecture and to serve them directly to clients or Rust for embedded web servers for IoT and other devices. For a language to be great in one domain, it has to be at least good in everything around it for when you need to connect that domain to the real world.

And Julia creators do focus on it's strong zone, with all the works on TPU, HPC and parallel computing, and so does the community with the stuff presented in juliacon like interactive reproducible notebooks (Pluto.jl) or data dashboards (Stipple.jl), both using the web domain to improve the scientific computing domain.

I'm not disagreeing with most of your comment above, except for how the post reads. To be accurate, the post's author set the context to general-purpose computing, not the scientific one. Here are two arguments for why I think so.

1. Intro section (italics emphasis mine).

"... delivering complex enterprise projects:

    Julia is fast, and has a very nice syntax, but its ecosystem is not mature enough for use in serious production projects.

For many years I would agree with it, but after JuliaCon 2020 I believe we can confidently announce that

    Julia is production ready!"

2. Section "Building microservices and applications". Even more so, practically all sections in the post, except just one ("Managing ML workflows"), describe various general-purpose and enterprise computing aspects.

Therefore, I don't see how one could view the post and author's conclusion purely from scientific computing perspective.

Fair enough, it might be my own view on what I'd use Julia in a production environment clouding my interpretation of the scope of the text, especially as the author defines this as his area at the start and says how it's what Julia shines at. Julia being an acceptable ("production-ready") language means that whenever my problem hit the areas that Julia shines, it becomes a valid candidate to evaluate considering all pros and cons.

And while right now I wouldn't recommend Julia for that web domain unless you also need it's number crunching features (which is more than just scientific computing, I work with large finance systems and there is definitely a lot of that stuff), I do think it's more of a library/community problem than a language problem. The language is well equipped to handle it (easy to use from a scripting perspective, easy parallelism, fast after warm-up, allows for clean abstractions to create sophisticated web frameworks, the mentioned easy FFI), what it lacks is the coverage and maturity of the tools and support (so I don't feel like I'm at a risk at any point that I need to do some integration, such as integrating with Kafka or any other systems, without having to write my own solution or integrating multiple languages at every step).

That's different from systems programming, embedded, game development and even GUI development (at least until smaller binaries with less warm-up) right now. Even with good library it will not be competitive with the languages that already claim those domains. Julia is a general purpose language already and more than a matlab substitute, it does not need to be good at everything (and it shouldn't try), but I don't think it should restrict the scope too much either.

I appreciate your thoughtful comment. Clearly, we are on the same page on the topic at large. As mentioned in my original comment above, I see no problems with Julia language per se (quite the opposite - I find it elegant, flexible and powerful), but rather emphasized that present issues exist around relevant ecosystem (documentation, packages, tools and support).

Apparently many have issues being polyglot and rather use an hammer for all kinds of nails, being an Tech X Developer.

This. 100%

People find the need to identify themselves as gopher or rustacean or something like that. Apparently Programmer is not hip anymore.

I doubt this has anything to do with 'feeling a need to identify' or anything like that. Many people who code aren't programmers, they have learnt a language to solve problems they have. They know just one language and do not have the time or capacity to learn another 'low-level' fast (but difficult) language for fixing bottlenecks.

Reply on news.ycombinator.com