5 ms·

It seems like Julia already had a pretty good solution to the two language problem as well as being designed from the ground up for numerical computation (Pytho

It seems like Julia already had a pretty good solution to the two language problem as well as being designed from the ground up for numerical computation (Python has numpy, but it seems bolted on and clunky by comparison). Yes, there are issues with large executables (large runtime), non-optimal gpu kernels, etc, but it seems like many of Julia's nagging issues could have been fairly easily solved if it had received as much investment as some of the alternatives have received - Modular appears to have a lot of funding to develop Mojo, and frameworks like PyTorch and TensorFlow have the backing of mega tech corporations. At one point Swift for TensorFlow was going to be the next big ML language and was being funded and developed by Google. I'm not sure there's a question here... more of a frustration that Julia seems to be a very good solution already (and is more mature than Mojo) and yet it seems to get passed over because companies decide to fund some new(er) shiny thing instead. BTW: I think your matrix multiplication demo could achieve very similar performance (including the SIMD, parallelization and LoopVectorization) in Julia.

Nimitz14 4y ago
julia's syntax is weird.
- pjmlp 4y ago
  As if that poses any problem to R, C++, Perl,...
  - nibles_and_bits 4y ago
    R -> dying, Perl -> dead, C++ -> also dying. Although C++'s existing size will make its death a long-drawn-out process.
    - pjmlp 4y ago
      A matter of opinion.
    - Y_Y 4y ago
      All the programmers are slowly dying too, so maybe it's a good fit.
    - serf 4y ago
      i've been reading about the upcoming death of perl and C++ for 25+ years now.
- kragen 4y ago
  python's syntax is whitespace-sensitive and doesn't have curly braces around blocks they did finally add assignments in expressions and conditional expressions, but every time i show a list comprehension to a java programmer they glaze over so i guess some weird syntax is okay
  - polotics 4y ago
    How are python list comprehension in any way more weird than Java streams?
    - kragen 4y ago
      java streams don't exist in java syntax we were talking about weird syntax, not weird semantics
      - akkad33 4y ago
        List compréhensions exist in so many languages. Are we talking those "Java" programmers who only ever coded in Java?
  - jwmoz 4y ago
    > python's syntax is whitespace-sensitive and doesn't have curly braces around blocks That's a good thing.
    - Mikhail_K 4y ago
      Not if you want to try out a copy fragment by copying it from editor into REPL.
      - kragen 4y ago
        jupyter solves this, but also you can prefix it with if 1: and remove all its internal blank lines and add a blank line after it
v3ss0n 4y ago
Julia didn't really gain momentum because syntax is offputting . When we started our first ML project in 2013 , we tried R, Julia , Python , and even at python with rugged ML libaries , we choose it because none of us liked other language syntaxes , coming from C++/Javas background. Then we fully falled in love with python.
- UncleOxidant 4y ago
  2013 was early days for Julia.
  - v3ss0n 4y ago
    still have the same syntax.
jph00 4y ago
"get passed over because companies decide to fund some new(er) shiny thing instead" is not a fair or reasonable assessment. Why would a startup that's racing against time and money decide to create a new language when something already exists that can meet their needs with just a little tweaking? My post embeds my recent keynote at JuliaCon in which I lay out some of the shortcomings of the language, as I see it. MLIR didn't even exist when Julia was created. A language that can really take advantage of MLIR, and is designed from the ground up for modern accelerators, is not something that can be readily created by tweaking Julia AFAICT.
- buggy6257 4y ago
  > Why would a startup that's racing against time and money decide to create a new language when something already exists that can meet their needs with just a little tweaking? Have you MET programmers? The idea that we/they would do this is not anywhere close to surprising.
  - UncleOxidant 4y ago
    Exactly. Lattner himself has been involved in some of this - Swift for Tensorflow comes to mind. I'm old enough to remember when Swift for Tensorflow was going to be the new ML language hotness: https://www.youtube.com/watch?v=drSpCwDFwnM https://www.youtube.com/watch?v=drSpCwDFwnM and https://www.youtube.com/watch?v=s65BigoMV_I https://www.youtube.com/watch?v=s65BigoMV_I
- UncleOxidant 4y ago
  > MLIR didn't even exist when Julia was created. A language that can really take advantage of MLIR, and is designed from the ground up for modern accelerators, is not something that can be readily created by tweaking Julia AFAICT. MLIR is another level of intermediate representation that sits at a higher level than LLVM-IR. Should the Julia folks decide that MLIR would offer advantages for optimization it wouldn't be difficult for them to add in an MLIR intermediate stage - that's kind of the whole point of an IR. But again, that would take some development effort - if the kind of investment that Mojo was getting were available for Julia it would get done. Nothing about the language itself would need to be impacted, it's the mid and backend where MLIR can offer advantages.
singularity2001 4y ago
Ergonomic wise what holds Julia back other than the deployment story is that they refuse to adopt nims universal call syntax approach f(a,b) = a.f(b)
- geysersam 4y ago
  Why is that better?
  - singularity2001 4y ago
    Familiarity and more importantly discoverability: If you type a. in the REPL or IDE you should get a list of all functions applicable to the object
    - deleted 4y ago
      [deleted]
    - Mikhail_K 4y ago
      Julia is not an OO language, and its functions dispatch on all function arguments, not just the first one.
    - geysersam 4y ago
      Familiarity changes rapidly in the world of software development. But I do agree about discoverability. However, I think the issue is rather that we need to find new discoverability systems that work for multiple dispatch rather than limit our languages to single dispatch because we can't come up with better ways to achieve discoverability. Maybe (a,b)f would be better syntax.. or we could start writing backwards ;) but now we're getting into seriously unfamiliar territory. Multiple dispatch might actually be superior for discoverability when we get this right because you can filter the method list based on all arguments rather than just the first one.
- teleforce 4y ago
  I'm pretty sure Nim copied that from D language. As they always said, imitation is the sincerest form of flattery.
echelon 4y ago
I've always felt that the choice to 1-index and favor mathematics over engineering has kept the engineers away. You can build a fantastic language for mathematicians, but people outside that domain won't feel welcome or compelled to use the language to scratch their itches. It'll just sit there. For math folks.
- currymj 4y ago
  I don’t think “mathematicians” is the right category. More like scientists/engineers who would otherwise use Fortran and Matlab (both have 1 based indexing) to do number crunching. That’s actually a lot of people though writing quite a bit of code. It’s just they just don’t work in the software industry, and usually for them the code is not the work product. I think the aspiration was to provide something that a Matlab user can immediately pick up, that is almost as fast natively as Fortran, that also provides features to do good modern software engineering if you want to. And it succeeds amazingly at this. In my own view, adoption has not been wider because 1) most people don’t need speed so the trade offs with the compiler + using a weird language aren’t worth it, and more importantly 2) outside of some incredible software gems, the package ecosystem tends to be flaky and maintained by overworked academics in their spare time.
  - echelon 4y ago
    > outside of some incredible software gems, the package ecosystem tends to be flaky and maintained by overworked academics in their spare time. That was the point I was trying to make. This language is too esoteric and leafy for most hackers / engineers / enthusiasts to spend their spare time building support packages. They'll pick up something like Nim or Rust as a new language before they'll look at Julia. By catering to mathematicians, scientists, and engineers, the broader population of software folks were excluded. Or, if "excluded" is too harsh, they at least weren't incentivized. Because of this, the best parsers, serializers, protocol implementations, scrapers, web servers, and other assortment of important technologies get written in other languages instead.
    - currymj 4y ago
ubj 4y ago
Disagree that Julia solves the two-language problem, although it was a major step in that direction. It may currently solve it for specific roles (e.g. data scientists), but it does not solve it for general-purpose programming. One specific example? Robotics and autonomous systems frequently use ahead-of-time (AOT) compiled binaries and libraries. You don't want your quadrotor / RC car / self-driving Tesla trying to perform JIT compilation while operating in time-sensitive scenarios. AOT compilation is a major Achilles heel for Julia--it's possible (with major limitations), but feels more like an afterthought than a core feature. I can't see Julia scaling to general-purpose programming until its AOT compiling capabilities improve. JAX has some of the same drawbacks. I'm very interested to see if Mojo can fill the gap of AOT compilation with a reasonably simple syntax. (And yes, I am aware of Nim--I do wish its scientific ecosystem was more developed though).
- travisoliphant 4y ago
  This is a very good point. You must support AOT compilation if you are going to have a general purpose system. This was clear when Julia came out and I interacted with core developers communicating our experience with creating SciPy and the critical reliance on the AOT features of Fortran/C/C++ as well as the bindings to Python. I believe simpler spellings can be achieved (i.e. more unification between scripting, dynamic JIT, and foundational AOT use-case), but the ecosystem is not close to a one-language to rule them all scenario.

Nimitz14 4y ago

julia's syntax is weird.

pjmlp 4y ago
As if that poses any problem to R, C++, Perl,...
- nibles_and_bits 4y ago
  R -> dying, Perl -> dead, C++ -> also dying. Although C++'s existing size will make its death a long-drawn-out process.
  - pjmlp 4y ago
    A matter of opinion.
  - Y_Y 4y ago
    All the programmers are slowly dying too, so maybe it's a good fit.
  - serf 4y ago
    i've been reading about the upcoming death of perl and C++ for 25+ years now.
kragen 4y ago
python's syntax is whitespace-sensitive and doesn't have curly braces around blocks they did finally add assignments in expressions and conditional expressions, but every time i show a list comprehension to a java programmer they glaze over so i guess some weird syntax is okay
- polotics 4y ago
  How are python list comprehension in any way more weird than Java streams?
  - kragen 4y ago
    java streams don't exist in java syntax we were talking about weird syntax, not weird semantics
    - akkad33 4y ago
      List compréhensions exist in so many languages. Are we talking those "Java" programmers who only ever coded in Java?
- jwmoz 4y ago
  > python's syntax is whitespace-sensitive and doesn't have curly braces around blocks That's a good thing.
  - Mikhail_K 4y ago
    Not if you want to try out a copy fragment by copying it from editor into REPL.
    - kragen 4y ago
      jupyter solves this, but also you can prefix it with if 1: and remove all its internal blank lines and add a blank line after it

v3ss0n 4y ago

Julia didn't really gain momentum because syntax is offputting . When we started our first ML project in 2013 , we tried R, Julia , Python , and even at python with rugged ML libaries , we choose it because none of us liked other language syntaxes , coming from C++/Javas background. Then we fully falled in love with python.

UncleOxidant 4y ago
2013 was early days for Julia.
- v3ss0n 4y ago
  still have the same syntax.

jph00 4y ago

"get passed over because companies decide to fund some new(er) shiny thing instead" is not a fair or reasonable assessment. Why would a startup that's racing against time and money decide to create a new language when something already exists that can meet their needs with just a little tweaking? My post embeds my recent keynote at JuliaCon in which I lay out some of the shortcomings of the language, as I see it. MLIR didn't even exist when Julia was created. A language that can really take advantage of MLIR, and is designed from the ground up for modern accelerators, is not something that can be readily created by tweaking Julia AFAICT.

buggy6257 4y ago
> Why would a startup that's racing against time and money decide to create a new language when something already exists that can meet their needs with just a little tweaking? Have you MET programmers? The idea that we/they would do this is not anywhere close to surprising.
- UncleOxidant 4y ago
  Exactly. Lattner himself has been involved in some of this - Swift for Tensorflow comes to mind. I'm old enough to remember when Swift for Tensorflow was going to be the new ML language hotness: https://www.youtube.com/watch?v=drSpCwDFwnM https://www.youtube.com/watch?v=drSpCwDFwnM and https://www.youtube.com/watch?v=s65BigoMV_I https://www.youtube.com/watch?v=s65BigoMV_I
UncleOxidant 4y ago
> MLIR didn't even exist when Julia was created. A language that can really take advantage of MLIR, and is designed from the ground up for modern accelerators, is not something that can be readily created by tweaking Julia AFAICT. MLIR is another level of intermediate representation that sits at a higher level than LLVM-IR. Should the Julia folks decide that MLIR would offer advantages for optimization it wouldn't be difficult for them to add in an MLIR intermediate stage - that's kind of the whole point of an IR. But again, that would take some development effort - if the kind of investment that Mojo was getting were available for Julia it would get done. Nothing about the language itself would need to be impacted, it's the mid and backend where MLIR can offer advantages.

singularity2001 4y ago

Ergonomic wise what holds Julia back other than the deployment story is that they refuse to adopt nims universal call syntax approach f(a,b) = a.f(b)

geysersam 4y ago
Why is that better?
- singularity2001 4y ago
  Familiarity and more importantly discoverability: If you type a. in the REPL or IDE you should get a list of all functions applicable to the object
  - deleted 4y ago
    [deleted]
  - Mikhail_K 4y ago
    Julia is not an OO language, and its functions dispatch on all function arguments, not just the first one.
  - geysersam 4y ago
    Familiarity changes rapidly in the world of software development. But I do agree about discoverability. However, I think the issue is rather that we need to find new discoverability systems that work for multiple dispatch rather than limit our languages to single dispatch because we can't come up with better ways to achieve discoverability. Maybe (a,b)f would be better syntax.. or we could start writing backwards ;) but now we're getting into seriously unfamiliar territory. Multiple dispatch might actually be superior for discoverability when we get this right because you can filter the method list based on all arguments rather than just the first one.
teleforce 4y ago
I'm pretty sure Nim copied that from D language. As they always said, imitation is the sincerest form of flattery.

echelon 4y ago

I've always felt that the choice to 1-index and favor mathematics over engineering has kept the engineers away. You can build a fantastic language for mathematicians, but people outside that domain won't feel welcome or compelled to use the language to scratch their itches. It'll just sit there. For math folks.

currymj 4y ago
I don’t think “mathematicians” is the right category. More like scientists/engineers who would otherwise use Fortran and Matlab (both have 1 based indexing) to do number crunching. That’s actually a lot of people though writing quite a bit of code. It’s just they just don’t work in the software industry, and usually for them the code is not the work product. I think the aspiration was to provide something that a Matlab user can immediately pick up, that is almost as fast natively as Fortran, that also provides features to do good modern software engineering if you want to. And it succeeds amazingly at this. In my own view, adoption has not been wider because 1) most people don’t need speed so the trade offs with the compiler + using a weird language aren’t worth it, and more importantly 2) outside of some incredible software gems, the package ecosystem tends to be flaky and maintained by overworked academics in their spare time.
- echelon 4y ago
  > outside of some incredible software gems, the package ecosystem tends to be flaky and maintained by overworked academics in their spare time. That was the point I was trying to make. This language is too esoteric and leafy for most hackers / engineers / enthusiasts to spend their spare time building support packages. They'll pick up something like Nim or Rust as a new language before they'll look at Julia. By catering to mathematicians, scientists, and engineers, the broader population of software folks were excluded. Or, if "excluded" is too harsh, they at least weren't incentivized. Because of this, the best parsers, serializers, protocol implementations, scrapers, web servers, and other assortment of important technologies get written in other languages instead.
  - currymj 4y ago

ubj 4y ago

Disagree that Julia solves the two-language problem, although it was a major step in that direction. It may currently solve it for specific roles (e.g. data scientists), but it does not solve it for general-purpose programming. One specific example? Robotics and autonomous systems frequently use ahead-of-time (AOT) compiled binaries and libraries. You don't want your quadrotor / RC car / self-driving Tesla trying to perform JIT compilation while operating in time-sensitive scenarios. AOT compilation is a major Achilles heel for Julia--it's possible (with major limitations), but feels more like an afterthought than a core feature. I can't see Julia scaling to general-purpose programming until its AOT compiling capabilities improve. JAX has some of the same drawbacks. I'm very interested to see if Mojo can fill the gap of AOT compilation with a reasonably simple syntax. (And yes, I am aware of Nim--I do wish its scientific ecosystem was more developed though).

travisoliphant 4y ago
This is a very good point. You must support AOT compilation if you are going to have a general purpose system. This was clear when Julia came out and I interacted with core developers communicating our experience with creating SciPy and the critical reliance on the AOT features of Fortran/C/C++ as well as the bindings to Python. I believe simpler spellings can be achieved (i.e. more unification between scripting, dynamic JIT, and foundational AOT use-case), but the ecosystem is not close to a one-language to rule them all scenario.