5 ms·

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 computi

by ablekh 6y ago

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.

ddragon 6y ago
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.
- ablekh 6y ago
  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).

by ablekh 6y ago

ddragon 6y ago

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.

ablekh 6y ago
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).