3 ms·

I mean scientific computing is what the language was designed for, use it if that's what you need. Just don't expect to be using those shiny numbers for anythi

I mean scientific computing is what the language was designed for, use it if that's what you need. Just don't expect to be using those shiny numbers for anything but scientific computing (and most specifically when involving large matrices). Their namespacing and modularity is terrible, writing a complex gui, non-trivial web server, 3d renderer, or any sort of real time system is right out. And they seem dead set against changing that (did I mention they ban people for making too much noise about it). But if you want to simulate something over a cluster it's a great choice. I should probably note that I have a poor opinion of their community from my observations (they are hilariously salty), I may be a bit biased.

tanlermin 10y ago
Thanks for sharing your thoughts. I want to keep my general code and scientific code in the same language. So python it is.
simondanisch 10y ago
Can you explain why you couldn't write a 3D renderer or complex gui in Julia? As someone who does exactly that it's a bit hard to follow your reasoning...
- SolarNet 10y ago
  Well, real-time 3d rendering anyway, thanks to the garbage collector and having very little control over it. How complex of a GUI are we talking here? Do you split it into many namespaces? Have long load times when not on a powerful dev machine? Ever tried to deploy said GUI? Do the right thing when exceptions in your program happen, or does it just crash the GUI or spit you out to the repl? Because I'm betting your GUI is not meant to be used by anyone but a couple of people with familiarity with the system, which is fine, but not generally what a GUI is made for.
  - tanlermin 10y ago
    Is there any dynamic language suitable for real time 3d viz?
    - SolarNet 10y ago
      Reference counted ones, by carefully controlling when the reference count for objects are released you can make sure that the rendering thread never has to do any of the expensive ones, and instead all (non-trivial) reference releases are shunted off into a different thread for deallocation. In the general case you don't care, and in the specific case you have a fine enough control you can get around the problem of unknown gc-pauses. It's slower - it is a dynamic language afterall - but it's consistent and real-time is more about being consistent.
      - tanlermin 10y ago
        gotcha
  - simondanisch 10y ago
    deployment + load times: obviously things aren't perfect, Julia is at version 0.4, after all ;) There are a lot of low hanging fruits for compile time and deployment, so I'm sure that the situation will look a lot different in a year or two. I'm not sure why Julia itself should make it difficult to "do the right thing" when exceptions occur... Real-time 3D rendering is a big area. Will we have virtual reality with ultra low latency in the next year? Definitely not! Can we have 3D CAD/scientific visualizations which hardly stutters? Definitely! Our library is already very smooth and we didn't even start optimizing yet. That's something that seems to be almost impossible in e.g Python (without just calling C for everything). So while most of these arguments are currently spot on, I do think that there is nothing fundamentally wrong with Julia. And while the maturity is not there yet, you can already be very productive with Julia and build for the future.
    - SolarNet 10y ago
      "I'm not sure why Julia itself should make it difficult to "do the right thing" when exceptions occur..." Untyped, sometimes incorrect, exceptions, https://github.com/JuliaLang/julia/issues/12485 https://github.com/JuliaLang/julia/issues/12485 and related.
      - simondanisch 10y ago
        Yeah and there is already an improvement to that: https://github.com/JuliaLang/julia/pull/12541 https://github.com/JuliaLang/julia/pull/12541. Well, anyways, I think you can easily find a lot of unsatisfactory constructs in any language, especially in young ones ;) If they outweigh the advantages is debatable. So far I've been finding satisfactory workarounds for the most daring issues, so for me the conclusion is indeed very positive.
ihnorton 10y ago
> Their namespacing and modularity is terrible, writing a complex gui, non-trivial web server, 3d renderer, or any sort of real time system is right out. And they seem dead set against changing that There are many dozens of open issues discussing namespacing, interfaces, levels of type abstraction and extensibility, garbage collector improvements, i/o latency problems, task-switching performance, and more. Prioritization of core effort in certain directions does not mean other issues are suppressed or even forgotten. Considerate proposals in other areas are welcome, and pull-requests implementing such proposals will be gratefully reviewed. They may not always be accepted -- immediately or sometimes ever. There is certainly some conservatism about adding features (such as interfaces), because features have costs and are near-impossible to remove once added. But other things just take time to get merged; for example, the generational GC took over a year, and there are other very large proposals that have been pending for longer than that because the implementation is lacking in some way or the implications are not fully worked-out to the point of consensus acceptance. That's ok, and IMHO healthy.
- SolarNet 10y ago
  Except their consensus making prevents real needed features from seeing any progress, sure they have thousands of open issues on the topic, but when did any of them last move. Oh and arguing too strongly on controversial issues (hex stringification! oh no!) gets you banned (that was a hilarious read). So how is anything supposed to move when there is a split in the community?
  - tavert 10y ago
    You have an underinformed and incorrect understanding of what happened there. Leave it at that.
    - SolarNet 10y ago
      It looks like someone got banned for submitting a PR as a hypothetical solution which a core team member disagreed with, why would I ever contribute to a project like that. Other people seem to agree on that point: http://danluu.com/julialang/ http://danluu.com/julialang/

tanlermin 10y ago

Thanks for sharing your thoughts. I want to keep my general code and scientific code in the same language. So python it is.

simondanisch 10y ago

Can you explain why you couldn't write a 3D renderer or complex gui in Julia? As someone who does exactly that it's a bit hard to follow your reasoning...

SolarNet 10y ago
Well, real-time 3d rendering anyway, thanks to the garbage collector and having very little control over it. How complex of a GUI are we talking here? Do you split it into many namespaces? Have long load times when not on a powerful dev machine? Ever tried to deploy said GUI? Do the right thing when exceptions in your program happen, or does it just crash the GUI or spit you out to the repl? Because I'm betting your GUI is not meant to be used by anyone but a couple of people with familiarity with the system, which is fine, but not generally what a GUI is made for.
- tanlermin 10y ago
  Is there any dynamic language suitable for real time 3d viz?
  - SolarNet 10y ago
    Reference counted ones, by carefully controlling when the reference count for objects are released you can make sure that the rendering thread never has to do any of the expensive ones, and instead all (non-trivial) reference releases are shunted off into a different thread for deallocation. In the general case you don't care, and in the specific case you have a fine enough control you can get around the problem of unknown gc-pauses. It's slower - it is a dynamic language afterall - but it's consistent and real-time is more about being consistent.
    - tanlermin 10y ago
      gotcha
- simondanisch 10y ago
  deployment + load times: obviously things aren't perfect, Julia is at version 0.4, after all ;) There are a lot of low hanging fruits for compile time and deployment, so I'm sure that the situation will look a lot different in a year or two. I'm not sure why Julia itself should make it difficult to "do the right thing" when exceptions occur... Real-time 3D rendering is a big area. Will we have virtual reality with ultra low latency in the next year? Definitely not! Can we have 3D CAD/scientific visualizations which hardly stutters? Definitely! Our library is already very smooth and we didn't even start optimizing yet. That's something that seems to be almost impossible in e.g Python (without just calling C for everything). So while most of these arguments are currently spot on, I do think that there is nothing fundamentally wrong with Julia. And while the maturity is not there yet, you can already be very productive with Julia and build for the future.
  - SolarNet 10y ago
    "I'm not sure why Julia itself should make it difficult to "do the right thing" when exceptions occur..." Untyped, sometimes incorrect, exceptions, https://github.com/JuliaLang/julia/issues/12485 https://github.com/JuliaLang/julia/issues/12485 and related.
    - simondanisch 10y ago
      Yeah and there is already an improvement to that: https://github.com/JuliaLang/julia/pull/12541 https://github.com/JuliaLang/julia/pull/12541. Well, anyways, I think you can easily find a lot of unsatisfactory constructs in any language, especially in young ones ;) If they outweigh the advantages is debatable. So far I've been finding satisfactory workarounds for the most daring issues, so for me the conclusion is indeed very positive.

ihnorton 10y ago

> Their namespacing and modularity is terrible, writing a complex gui, non-trivial web server, 3d renderer, or any sort of real time system is right out. And they seem dead set against changing that There are many dozens of open issues discussing namespacing, interfaces, levels of type abstraction and extensibility, garbage collector improvements, i/o latency problems, task-switching performance, and more. Prioritization of core effort in certain directions does not mean other issues are suppressed or even forgotten. Considerate proposals in other areas are welcome, and pull-requests implementing such proposals will be gratefully reviewed. They may not always be accepted -- immediately or sometimes ever. There is certainly some conservatism about adding features (such as interfaces), because features have costs and are near-impossible to remove once added. But other things just take time to get merged; for example, the generational GC took over a year, and there are other very large proposals that have been pending for longer than that because the implementation is lacking in some way or the implications are not fully worked-out to the point of consensus acceptance. That's ok, and IMHO healthy.

SolarNet 10y ago
Except their consensus making prevents real needed features from seeing any progress, sure they have thousands of open issues on the topic, but when did any of them last move. Oh and arguing too strongly on controversial issues (hex stringification! oh no!) gets you banned (that was a hilarious read). So how is anything supposed to move when there is a split in the community?
- tavert 10y ago
  You have an underinformed and incorrect understanding of what happened there. Leave it at that.
  - SolarNet 10y ago
    It looks like someone got banned for submitting a PR as a hypothetical solution which a core team member disagreed with, why would I ever contribute to a project like that. Other people seem to agree on that point: http://danluu.com/julialang/ http://danluu.com/julialang/