7 ms·

Julia is a language I really wanted to like, and to a certain extent I do. However after spending some time working with it and hanging out on the Discourse ch

Julia is a language I really wanted to like, and to a certain extent I do. However after spending some time working with it and hanging out on the Discourse channels (they certainly have a very friendly and open community, which I think is a big plus), I've come to the tentative conclusion that its application domains are going to be more limited than I would have hoped. This article hits on some of the issues that the community tends to see as advantages but that I think will prove limiting in the long run. > Missing features like: > Weak conventions about namespace pollution > Never got around to making it easy to use local modules, outside of packages > A type system that can’t be used to check correctness These are some of my biggest gripes about Julia, especially the last two. To these I would add: * Lack of support for formally defined interfaces. * Lack of support for implementation inheritance. Together with Julia's many strengths I think these design choices and community philosophy lead to a language that is very good for small scale and experimental work but will have major issues scaling to very complex systems development projects and will be ill-suited to mission critical applications. In short I think Julia may be a great language for prototyping an object detection algorithm, but I wouldn't want to use it to develop the control system for a self-driving car. Unfortunately this means that Julia probably isn't really going to solve the "2 language problem" because in most cases you're still going to need to rewrite your prototypes in a different language just like you would previously in going from, for example, a Matlab prototype to a C++ system in production.

oxinabox 7y ago
Author of post here: there were a major gripe for me starting out too. It took me a fair while to conclude that they allowed to useful things in the bigger picture. and it certainly is not a pure win. I do miss static typing. I would question the claim it doesn't scale to production. I know people who have build hugely complex production systems in perl that are still running today 20 years later. Further, I myself work on what we believe to be the largest closed source julia code base, in terms of number of contributors, number of packages and total size. (Its also pretty large in general, though i have yet to work out how it stacks up against DiffEq-verse). And I have seen thing go from research prototype into running in production. It works. I am not going to deny though there are advantages to other languages. There are many trade-offs in the world
- tgflynn 7y ago
  > I know people who have build hugely complex production systems in perl that are still running today 20 years later. Sure, but there aren't many programmers who would want to maintain such a system.
  - klyrs 7y ago
    Perl's just another language I've known. Maintaining a 20yo codebase in a language that people find distasteful sounds like comfortable job security, to me.
  - fludlight 7y ago
    Most programmers want to build new things, not work on maintenance projects, regardless of tech stack. That said, many people do enjoy that sort of work and finding them is not unusually difficult unless the project is so big that you need dozens of bodies.
cultus 7y ago
People write large-scale systems in dynamically-typed languages all the time. Multiple dispatch and macros make clean scaling easier than it would be in most other dynamic languages. Its competitors in numerical performance are C/C++ and Fortran, which are both minefields (C much more so). Julia is definitely safer in practice than these kind of languages with weak, unsafe type systems. I'm not saying static types don't have benefits as well, but it would also be very against the design goals as a Matlab/R competitor. Inheritance would also directly clash and overlap with multiple dispatch, which is strictly more powerful.
- tgflynn 7y ago
  > multiple dispatch, which is strictly more powerful. In a language that supports classes I can have class B inherit from class A and automatically provide all of class A's functionality without adding a single extra line of code. I can extend class B's functionality by adding only code that is specific to it. I don't see how to do that with multiple dispatch, at least the way it's implemented in Julia.
  - logicchains 7y ago
    >In a language that supports classes I can have class B inherit from class A and automatically provide all of class A's functionality without adding a single extra line of code. And people will abuse this to create horrible brittle inheritance hierachies. There's a reason modern languages like Go and Rust deliberately don't support implementation inheritance; to many people it's an antifeature.
    - tgflynn 7y ago
      The thing about software is that the "one true way" changes every 2 or 3 years. A few decades ago inheritance was considered a key software design principle, then it was abused by many (especially Java programmers, I think), just like any other powerful feature, now it's considered evil. If multiple dispatch becomes as popular as classes/inheritance was, I suspect it will go through the same love/hate cycle. All I know is that I have used implementation inheritance to good effect on multiple occasions and found it to be a very valuable feature.
short_sells_poo 7y ago
You touch upon some interesting pain points. I really like Julia and working with it is a pleasure. Except the Module system, which feels unnecessarily arcane. I'm happy to be educated on why, but it seems to successfully combine the awkwardness of C-style #include with the mess of a free-form module system. The end result is a Frankenstein monster where technically everything is possible, everything could be included anywhere, there are no boundaries or even conventions. It makes for a frustrating experience for a newbie. Say you have a package, and inside is a file called `xyz.jl`. You open the file and it defines a module called Xyz. But this tells you absolutely nothing about where in the package Xyz will appear. It could be included somewhere deep in the hierarchy, or it could be a submodule. It could be included multiple times in multiple places! That's bad design for sure, but the language places no boundaries on you. You open another file `abc.jl`, and see no modules at all, just a bunch of functions, which in turn call other functions that are defined God knows where. A julia file does not have to contain any information about where the symbols it's using come from, since it will be just pasted in verbatim to some location somewhere. The whole module system feels like one big spaghetti of spooky action at a distance. It's a shame too, because the rest of the language is very neat. Once one gets over the hurdle of the modules, it is possible to establish conventions to bring some sanity in there, but it's a hurdle that many people will probably not want to deal with.
- deleted 7y ago
  [deleted]
- improbable22 7y ago
  How would you like modules to work? It seems great to me that paths & source files are mostly irrelevant, you're free to re-organise without changing anything. And that `using Xyz` is always talking to the package manager. You can make sub-modules and say `using .Xyz`, but there's very little need to do so, and few packages do. You can shoot yourself in the foot by including source twice, as you can by generating it with a macro, or simply copy-pasting wrong.
  - Seanny123 7y ago
    I mean, I'd like them to work like Python, Ruby and TypeScript, but you're right to say I can't describe why I want this. Is there some guide I could read about structuring a large Julia project? It was pretty easy to intuit with Python, wherein I would put related files in a folder. But with Julia, everything is everywhere and I'm baffled.
Seanny123 7y ago
I don't understand type systems very well. When you say "check correctness" do you mean something beyond static linting with type-hints, like in Python? Or do you mean something deeper, like in functional languages like Elm and F#? Also, is there always a trade-off between types and flexible meta-programming? Like, OCaml has meta-programming capabilities, but they make type-checking way harder, according to my PhD friend who's written extensively in Scheme and OCaml.
yahyaheee 7y ago
Yep this has been my conclusion as well, I really wanted to like Julia and there are parts of it I do, but I think it misses the mark in some big ways.

oxinabox 7y ago

Author of post here: there were a major gripe for me starting out too. It took me a fair while to conclude that they allowed to useful things in the bigger picture. and it certainly is not a pure win. I do miss static typing. I would question the claim it doesn't scale to production. I know people who have build hugely complex production systems in perl that are still running today 20 years later. Further, I myself work on what we believe to be the largest closed source julia code base, in terms of number of contributors, number of packages and total size. (Its also pretty large in general, though i have yet to work out how it stacks up against DiffEq-verse). And I have seen thing go from research prototype into running in production. It works. I am not going to deny though there are advantages to other languages. There are many trade-offs in the world

tgflynn 7y ago
> I know people who have build hugely complex production systems in perl that are still running today 20 years later. Sure, but there aren't many programmers who would want to maintain such a system.
- klyrs 7y ago
  Perl's just another language I've known. Maintaining a 20yo codebase in a language that people find distasteful sounds like comfortable job security, to me.
- fludlight 7y ago
  Most programmers want to build new things, not work on maintenance projects, regardless of tech stack. That said, many people do enjoy that sort of work and finding them is not unusually difficult unless the project is so big that you need dozens of bodies.

cultus 7y ago

People write large-scale systems in dynamically-typed languages all the time. Multiple dispatch and macros make clean scaling easier than it would be in most other dynamic languages. Its competitors in numerical performance are C/C++ and Fortran, which are both minefields (C much more so). Julia is definitely safer in practice than these kind of languages with weak, unsafe type systems. I'm not saying static types don't have benefits as well, but it would also be very against the design goals as a Matlab/R competitor. Inheritance would also directly clash and overlap with multiple dispatch, which is strictly more powerful.

tgflynn 7y ago
> multiple dispatch, which is strictly more powerful. In a language that supports classes I can have class B inherit from class A and automatically provide all of class A's functionality without adding a single extra line of code. I can extend class B's functionality by adding only code that is specific to it. I don't see how to do that with multiple dispatch, at least the way it's implemented in Julia.
- logicchains 7y ago
  >In a language that supports classes I can have class B inherit from class A and automatically provide all of class A's functionality without adding a single extra line of code. And people will abuse this to create horrible brittle inheritance hierachies. There's a reason modern languages like Go and Rust deliberately don't support implementation inheritance; to many people it's an antifeature.
  - tgflynn 7y ago
    The thing about software is that the "one true way" changes every 2 or 3 years. A few decades ago inheritance was considered a key software design principle, then it was abused by many (especially Java programmers, I think), just like any other powerful feature, now it's considered evil. If multiple dispatch becomes as popular as classes/inheritance was, I suspect it will go through the same love/hate cycle. All I know is that I have used implementation inheritance to good effect on multiple occasions and found it to be a very valuable feature.

short_sells_poo 7y ago

You touch upon some interesting pain points. I really like Julia and working with it is a pleasure. Except the Module system, which feels unnecessarily arcane. I'm happy to be educated on why, but it seems to successfully combine the awkwardness of C-style #include with the mess of a free-form module system. The end result is a Frankenstein monster where technically everything is possible, everything could be included anywhere, there are no boundaries or even conventions. It makes for a frustrating experience for a newbie. Say you have a package, and inside is a file called `xyz.jl`. You open the file and it defines a module called Xyz. But this tells you absolutely nothing about where in the package Xyz will appear. It could be included somewhere deep in the hierarchy, or it could be a submodule. It could be included multiple times in multiple places! That's bad design for sure, but the language places no boundaries on you. You open another file `abc.jl`, and see no modules at all, just a bunch of functions, which in turn call other functions that are defined God knows where. A julia file does not have to contain any information about where the symbols it's using come from, since it will be just pasted in verbatim to some location somewhere. The whole module system feels like one big spaghetti of spooky action at a distance. It's a shame too, because the rest of the language is very neat. Once one gets over the hurdle of the modules, it is possible to establish conventions to bring some sanity in there, but it's a hurdle that many people will probably not want to deal with.

deleted 7y ago
[deleted]
improbable22 7y ago
How would you like modules to work? It seems great to me that paths & source files are mostly irrelevant, you're free to re-organise without changing anything. And that `using Xyz` is always talking to the package manager. You can make sub-modules and say `using .Xyz`, but there's very little need to do so, and few packages do. You can shoot yourself in the foot by including source twice, as you can by generating it with a macro, or simply copy-pasting wrong.
- Seanny123 7y ago
  I mean, I'd like them to work like Python, Ruby and TypeScript, but you're right to say I can't describe why I want this. Is there some guide I could read about structuring a large Julia project? It was pretty easy to intuit with Python, wherein I would put related files in a folder. But with Julia, everything is everywhere and I'm baffled.

Seanny123 7y ago

I don't understand type systems very well. When you say "check correctness" do you mean something beyond static linting with type-hints, like in Python? Or do you mean something deeper, like in functional languages like Elm and F#? Also, is there always a trade-off between types and flexible meta-programming? Like, OCaml has meta-programming capabilities, but they make type-checking way harder, according to my PhD friend who's written extensively in Scheme and OCaml.

yahyaheee 7y ago

Yep this has been my conclusion as well, I really wanted to like Julia and there are parts of it I do, but I think it misses the mark in some big ways.