Static, Ahead of Time Compiled Julia(juliacomputing.com)
juliacomputing.com
Static, Ahead of Time Compiled Julia
http://juliacomputing.com/blog/2016/02/09/static-julia.html
8 comments
This article was pointed out to me, more than once now, as a user of Julia. However, I don't see that it has too much relevance to me as a user of the language, even if its quite outdated points were still valid today.
I am part of a team that now has over 60,000 lines of Julia code in our computer algebra package(s), and the intersection between our experience as users and the points danluu made is almost nil.
If one looks at the ranking of the language on Tiobe, it's quite obviously being used a lot for a language that hasn't even reached 1.0 yet.
I think the issues one is likely to have with Julia as an evolving language have completely moved on from those made in danluu's article. In fact, it might be useful for someone to write a "constructive criticism" blog article about the state of affairs today.
My personal opinion is that I would wait until 1.0 (which will arrive in less than 2 years time) if I were a fortune 500 company, unless you really need to be ahead of the game and are prepared to contribute to the development of the actual language itself. But for just about anything else, if you need the features Julia provides, it's probably vastly superior to the alternatives today.
Our experience is you will occasionally have to adjust some of your code to handle changes to the language prior to 1.0, and we've had to do that a few times so far (at most a few hours work each 0.x point release, even with our large, complex code base). And this mainly applies if you are really pushing Julia hard and exploring interesting corners of the language. Other than this, its more than stable enough for serious work.
I am part of a team that now has over 60,000 lines of Julia code in our computer algebra package(s), and the intersection between our experience as users and the points danluu made is almost nil.
If one looks at the ranking of the language on Tiobe, it's quite obviously being used a lot for a language that hasn't even reached 1.0 yet.
I think the issues one is likely to have with Julia as an evolving language have completely moved on from those made in danluu's article. In fact, it might be useful for someone to write a "constructive criticism" blog article about the state of affairs today.
My personal opinion is that I would wait until 1.0 (which will arrive in less than 2 years time) if I were a fortune 500 company, unless you really need to be ahead of the game and are prepared to contribute to the development of the actual language itself. But for just about anything else, if you need the features Julia provides, it's probably vastly superior to the alternatives today.
Our experience is you will occasionally have to adjust some of your code to handle changes to the language prior to 1.0, and we've had to do that a few times so far (at most a few hours work each 0.x point release, even with our large, complex code base). And this mainly applies if you are really pushing Julia hard and exploring interesting corners of the language. Other than this, its more than stable enough for serious work.
I'm an enthusiastic julia user, observer and very minor contributor. IMO a lot of the issues in this constructive rant have been addressed to some extent. For context, here's the previous HN discussion https://news.ycombinator.com/item?id=8809422
Going through the post in order:
The stable releases still have some bugs as you would expect in a young language, but 0.4 is now well below my tolerance level. For a rough idea, I now use julia daily and encounter a bug perhaps once every one or two weeks. In 0.4 I haven't encountered any bug which was a real show stopper and couldn't easily be worked around.
Testing has gotten a whole heap nicer with a decent test framework in Base (accessible in 0.4 via BaseTestNext.jl). Testing and package manager integrate in a simple but effective way which really makes the friction for writing a suite of tests for new packages very low, much lower than other languages I've used. I can't speak for actual coverage in Base, but I know it's now actually being measured and work has gone into the coverage tools.
I'm going to skip over the complaints about error handling, because others have already responded to this, for example StefanKarpinski's post to the julia-users list https://groups.google.com/d/msg/julia-users/GyH8nhExY9I/0Bzn...
Consistent benchmarking is currently being addressed, with great work going on at BenchmarkTrackers.jl, and a proper setup with dedicated benchmarking hardware for the language itself. I don't have the depth of knowledge to comment on Dan's other complaints regarding skewed benchmarking.
Regarding contributing, my experience is that contributions to Base and the runtime by unknowns (myself, say) are generally met with the fair skepticism and good taste that all good maintainers should display. Sometimes I feel the core devs could do more to encourage new contributors, and the environment can feel slightly hostile when suggesting new features. I'm not sure how to entirely avoid this, when a core job of a good maintainer is to say "no" to a lot of poorly considered requests! Much of the code in Base is still commented in a minimalistic fashion, if at all. In contrast my experience in contributing to packages has been almost entirely positive, with a lot of excitement and energy leading to some really great code and interactions.
With precompliation, slow package load times have really been improved to the extent that they're no longer a major hassle, but there's still room for improvement here.
The real sting in the tail of this blog post is the paragraph about nastiness in the community. There was a couple of unfortunately worded (though not unambiguously malicious) mails on the julia-users list following Dan's post, but the discussion was largely constructive and helpful. I've no idea about the "private and semi-private communications" and I can only hope things were patched up there.
Overall I've found the julia experience almost entirely positive. It's a joy to work with for numerical and statistical problems, and we're moving forward at work to get our first major pieces of julia code into production.
Going through the post in order:
The stable releases still have some bugs as you would expect in a young language, but 0.4 is now well below my tolerance level. For a rough idea, I now use julia daily and encounter a bug perhaps once every one or two weeks. In 0.4 I haven't encountered any bug which was a real show stopper and couldn't easily be worked around.
Testing has gotten a whole heap nicer with a decent test framework in Base (accessible in 0.4 via BaseTestNext.jl). Testing and package manager integrate in a simple but effective way which really makes the friction for writing a suite of tests for new packages very low, much lower than other languages I've used. I can't speak for actual coverage in Base, but I know it's now actually being measured and work has gone into the coverage tools.
I'm going to skip over the complaints about error handling, because others have already responded to this, for example StefanKarpinski's post to the julia-users list https://groups.google.com/d/msg/julia-users/GyH8nhExY9I/0Bzn...
Consistent benchmarking is currently being addressed, with great work going on at BenchmarkTrackers.jl, and a proper setup with dedicated benchmarking hardware for the language itself. I don't have the depth of knowledge to comment on Dan's other complaints regarding skewed benchmarking.
Regarding contributing, my experience is that contributions to Base and the runtime by unknowns (myself, say) are generally met with the fair skepticism and good taste that all good maintainers should display. Sometimes I feel the core devs could do more to encourage new contributors, and the environment can feel slightly hostile when suggesting new features. I'm not sure how to entirely avoid this, when a core job of a good maintainer is to say "no" to a lot of poorly considered requests! Much of the code in Base is still commented in a minimalistic fashion, if at all. In contrast my experience in contributing to packages has been almost entirely positive, with a lot of excitement and energy leading to some really great code and interactions.
With precompliation, slow package load times have really been improved to the extent that they're no longer a major hassle, but there's still room for improvement here.
The real sting in the tail of this blog post is the paragraph about nastiness in the community. There was a couple of unfortunately worded (though not unambiguously malicious) mails on the julia-users list following Dan's post, but the discussion was largely constructive and helpful. I've no idea about the "private and semi-private communications" and I can only hope things were patched up there.
Overall I've found the julia experience almost entirely positive. It's a joy to work with for numerical and statistical problems, and we're moving forward at work to get our first major pieces of julia code into production.
> I've no idea about the "private and semi-private communications" and I can only hope things were patched up there.
I'm the co-creator that Dan was talking about. He wrote a bunch of less-than-charitable comments on the aforementioned semi-private forum – not specifically to me, but where he surely knew I would read them – to which I responded with:
https://gist.github.com/StefanKarpinski/c72219ff8ce261172b11
You can judge for yourself whether I was nasty or dishonest. Things were, unfortunately, not patched up. Dan posted a number of responses, deleted all of them before I could read them, then left the conversation permanently.
I'm the co-creator that Dan was talking about. He wrote a bunch of less-than-charitable comments on the aforementioned semi-private forum – not specifically to me, but where he surely knew I would read them – to which I responded with:
https://gist.github.com/StefanKarpinski/c72219ff8ce261172b11
You can judge for yourself whether I was nasty or dishonest. Things were, unfortunately, not patched up. Dan posted a number of responses, deleted all of them before I could read them, then left the conversation permanently.
Luu's claims made me hold off on pushing people to contribute to Julia as I waited for corroboration (or refutation) of them. I appreciate you linking to that very fair post that replies to it. The contrast between how the two of your present your claims adds credibility to yours. I also got a great laugh out of part about one guy that barely speaks English using the project as a personal Stackoverflow. A problem I'd have not anticipated starting a language/compiler project haha.
Curious, are you all still coding the internals of the compiler in femtolisp, is most of it written in Julia indirectly relying on that, or no LISP now? A barrier to entry question basically.
Curious, are you all still coding the internals of the compiler in femtolisp, is most of it written in Julia indirectly relying on that, or no LISP now? A barrier to entry question basically.
The parser and some lowering passes are still written in femtolisp. There has been some discussion of switching to the native JuliaParser package [1]. However, JuliaParser doesn't implement the fairly tricky lowering passes that the femtolisp parser does. I personally would prefer to have the parser in Julia, but at this point the most pressing issue with parsing and lowering is speed – so it's possible that the parsing and lowering will be converted to C instead.
[1] https://github.com/JuliaLang/JuliaParser.jl
[1] https://github.com/JuliaLang/JuliaParser.jl
Thanks for the update. Decent plan. An alternative would be to code it in SPARK Ada for speed and correctness. Has side benefit that each component done that way won't be touched by halfassed developers because they lack the will to learn it. Not quick n dirty enough for them. ;)
> I personally would prefer to have the parser in Julia, but at this point the most pressing issue with parsing and lowering is speed – so it's possible that the parsing and lowering will be converted to C instead.
But isn't Julia supposed to be fast? ;)
But isn't Julia supposed to be fast? ;)
And this is just a parser. Nothing too fancy. Analysis should be able to produce some efficient code for one.
Thanks for the link. After reading the extra context Dan's comment about the community is only more baffling than before. To me your response seems about as measured and straight forwardly honest as it could be, with a double dose of constructive investigation on the purely technical matters.
Thanks for the lengthy response!
Though it would have been fair to point out that this rant was written about his experiences the last time he used Julia, in Oct. 2014, nearly 18 months ago.
The language works well for what is effectively still a beta. Sure I'd like more documentation and tests, but I'm happy to get features first. The alternative for me is trying to do some non trivial cluster computing in C or in python, either of which would suck.
What kind of cluster computing? I've had good experiences with Scala and Spark, though that might be for a different use case.
It's an MCMC algorithm for a fancy kind of matrix factorisation.
I had a look at Spark, but its linear algebra packages seemed too limited (I guess abstraction comes at a cost). I can see that Spark would be nice if it does what you need out of the box.
Heard good things about Scala, is it straightforward to get a process on a remote machine to execute code?
I had a look at Spark, but its linear algebra packages seemed too limited (I guess abstraction comes at a cost). I can see that Spark would be nice if it does what you need out of the box.
Heard good things about Scala, is it straightforward to get a process on a remote machine to execute code?
> I had a look at Spark, but its linear algebra packages seemed too limited (I guess abstraction comes at a cost). I can see that Spark would be nice if it does what you need out of the box.
Did you look at MLlib and/or just using Breeze directly? There's a bit of awkwardness in the initial set up of the cluster (mainly just having LAPACK installed on all nodes, see https://spark.apache.org/docs/1.1.0/mllib-guide.html ). Spark itself is essentially just sugar to let you write a map/reduce in natural scala style and have it distributed across a cluster - it'll only work if you can factor your algorithm in a way that fits into that paradigm. (I've heard arguments that it's possible to do that with any distributable algorithm if you're clever enough, but I'm not sure I believe them).
> Heard good things about Scala, is it straightforward to get a process on a remote machine to execute code?
Honestly, no. I love the language but Spark is very much what I think of (perhaps unfairly) as typical scientific software. Spark clusters are finicky - they're cobbled together from a few unrelated projects (especially for cases where you need LAPACK as well), and it shows, especially when it comes to updating them. There are a few organizations like Cloudera (I think there was an open-source effort under the Apache umbrella somewhere too) that try to provide a working package, and various efforts with Puppet/Chef/etc. to automate the process of putting a cluster together, and it's certainly a lot better than it was even a few years ago, but a cluster still need at least a little bit of dedicated sysadmin time (or, at a bare minimum, a programmer with a bit of *nix admin experience who's willing to get their hands dirty - that was me at times) to keep it running reliably.
If you're part of an institution that already maintains a Spark cluster - or maintains an ordinary Hadoop cluster and you're friendly enough with the sysadmins to suggest they install it - it's wonderful. If you're having to do it all from scratch I won't lie, it's going to involve a lot of fiddling and may well not be worth it for your problem.
Did you look at MLlib and/or just using Breeze directly? There's a bit of awkwardness in the initial set up of the cluster (mainly just having LAPACK installed on all nodes, see https://spark.apache.org/docs/1.1.0/mllib-guide.html ). Spark itself is essentially just sugar to let you write a map/reduce in natural scala style and have it distributed across a cluster - it'll only work if you can factor your algorithm in a way that fits into that paradigm. (I've heard arguments that it's possible to do that with any distributable algorithm if you're clever enough, but I'm not sure I believe them).
> Heard good things about Scala, is it straightforward to get a process on a remote machine to execute code?
Honestly, no. I love the language but Spark is very much what I think of (perhaps unfairly) as typical scientific software. Spark clusters are finicky - they're cobbled together from a few unrelated projects (especially for cases where you need LAPACK as well), and it shows, especially when it comes to updating them. There are a few organizations like Cloudera (I think there was an open-source effort under the Apache umbrella somewhere too) that try to provide a working package, and various efforts with Puppet/Chef/etc. to automate the process of putting a cluster together, and it's certainly a lot better than it was even a few years ago, but a cluster still need at least a little bit of dedicated sysadmin time (or, at a bare minimum, a programmer with a bit of *nix admin experience who's willing to get their hands dirty - that was me at times) to keep it running reliably.
If you're part of an institution that already maintains a Spark cluster - or maintains an ordinary Hadoop cluster and you're friendly enough with the sysadmins to suggest they install it - it's wonderful. If you're having to do it all from scratch I won't lie, it's going to involve a lot of fiddling and may well not be worth it for your problem.
Most people don't need more than a handful of linear algebra operations (or think they don't), so Breeze and most wrappers of LAPACK or similar libraries don't implement or wrap them. But most people who work seriously on numerical routines will quickly run into performance problems if all they do is call LAPACK routines for general matrices instead of taking advantage of matrix structure.
I have yet to come across any other linear algebra library for any other high level language that provides the depth of integration available in the Julia base library. Want all eigenvalues of a symmetric tridiagonal 10x10 matrix between 1.0 and 12.0? Simply call T=SymTridiagonal(randn(10), randn(9)); eigvals(T, 1.0, 12.0). Or if you want to work closer to LAPACK, simply call LAPACK.stein!. I don't see a wrapper in Breeze or SciPy for this function. Want an LU factorization on a matrix of high precision floats? lufact(big(randn(5,4))). And so on.
Julia may not have everything users want, but its base library really tries to make matrix computations easy and accessible.
I have yet to come across any other linear algebra library for any other high level language that provides the depth of integration available in the Julia base library. Want all eigenvalues of a symmetric tridiagonal 10x10 matrix between 1.0 and 12.0? Simply call T=SymTridiagonal(randn(10), randn(9)); eigvals(T, 1.0, 12.0). Or if you want to work closer to LAPACK, simply call LAPACK.stein!. I don't see a wrapper in Breeze or SciPy for this function. Want an LU factorization on a matrix of high precision floats? lufact(big(randn(5,4))). And so on.
Julia may not have everything users want, but its base library really tries to make matrix computations easy and accessible.
Something like the Scala type system seems like the best way to keep track of that kind of structure information and make use of it (perhaps even transparently). I can easily believe the current wrappers aren't there yet though. (Afraid I switched jobs six months ago and haven't been using Breeze or Spark since, so I can't justify working on it myself at the moment)
+1 this kind of issue is why I went for Julia - the support for lin alg (including with CUDA) is very good indeed.
The other issue being that Julia gives fine grained control over a cluster in a way something more abstract couldn't. (After cobbling together a scripting-style map reducer based on the default functionality - ClusterUtils.jl.)
The other issue being that Julia gives fine grained control over a cluster in a way something more abstract couldn't. (After cobbling together a scripting-style map reducer based on the default functionality - ClusterUtils.jl.)
Cheers, this was interesting. I think my 'try spark' button would get pushed if I had to do a big job using a standard method for a company e.g. some massive GLM.
My areas of focus are pretty different from that author's - e.g. I haven't tried contributing to the core language. But I've been using Julia for my research code for ~4 months now, and it's been an absolute joy.
The language allows super-readable code while remaining quite fast. The sort of research I'm doing involves interacting a bit with data then doing a bunch of simulations, and Julia excels at this. The expressiveness in how Julia handles anonymous functions, optional arguments, tuple construction/deconstruction, etc. allows for really concise configurations of how my little simulations run.
My only pain points:
- DataFrames are not as fast as the rest of the language.
- I'd like an infix function composition operator. (Possibly this exists, but I can't find it in the documentation).
9.5/10, absolutely recommend.
The language allows super-readable code while remaining quite fast. The sort of research I'm doing involves interacting a bit with data then doing a bunch of simulations, and Julia excels at this. The expressiveness in how Julia handles anonymous functions, optional arguments, tuple construction/deconstruction, etc. allows for really concise configurations of how my little simulations run.
My only pain points:
- DataFrames are not as fast as the rest of the language.
- I'd like an infix function composition operator. (Possibly this exists, but I can't find it in the documentation).
9.5/10, absolutely recommend.
> I'd like an infix function composition operator.
Do you mean like the pipe symbol?
Do you mean like the pipe symbol?
rand() |> println
No, x |> f is equivalent to f(x) while (f ∘ g)(x) is equivalent to g(f(x)). Specifically, x |> f results in a value (of the type of the return value of f) while f ∘ g results always results in a function.
Why not make one for yourself? ;)
julia> (∘)(f, g) = x -> f(g(x))
∘ (generic function with 1 method)
julia> (sum ∘ rand)(10)
3.397728240035534
Tip: type \circ<tab> to get ∘
julia> (∘)(f, g) = x -> f(g(x))
∘ (generic function with 1 method)
julia> (sum ∘ rand)(10)
3.397728240035534
Tip: type \circ<tab> to get ∘
I know, but why isn't something like this in core? * did function composition a while ago, but it was removed (beats me why) and hasn't been replaced.
Enough Perl6 has left me with <compose>(.) to get ∘ :-)
Enough Perl6 has left me with <compose>(.) to get ∘ :-)
Get involved then, Julia isn't exactly the illuminate.
That's exactly it - thanks! Somehow I missed that when searching the docs for "chain", "pipe", and "compose".
I thoroughly enjoy julia and there's no other FLOSS to replace it, but a fair bit of that rant does still seem to stand (from my own experience).
Bugs are quite easy to come across and updating software feels more like a dice roll than a normal upgrade. Parallel computing in particular has been in a pre-alpha state for ages (which may be more of a documentation issue than an implementation one). Packages were previously very slow to load, though with pre-compilation this was partially fixed (~1 order of magnitude difference). I don't write robust software in julia, so I don't know how the error handling side has been evolving. The API inconsistencies have been getting fixed, but this typically results in broken packages until the compatibility package (Compat.jl) includes some workaround. The core code is difficult to get through and architectural-level documentation was absent last I checked.
Even with these development flaws it's still by and large an enjoyable experience to use. It solves some hard problems and it makes my own work (mainly DSP/ML) move a lot faster. I would recommend it, but as their versioning scheme indicates, there's no 1.0 release yet.
Bugs are quite easy to come across and updating software feels more like a dice roll than a normal upgrade. Parallel computing in particular has been in a pre-alpha state for ages (which may be more of a documentation issue than an implementation one). Packages were previously very slow to load, though with pre-compilation this was partially fixed (~1 order of magnitude difference). I don't write robust software in julia, so I don't know how the error handling side has been evolving. The API inconsistencies have been getting fixed, but this typically results in broken packages until the compatibility package (Compat.jl) includes some workaround. The core code is difficult to get through and architectural-level documentation was absent last I checked.
Even with these development flaws it's still by and large an enjoyable experience to use. It solves some hard problems and it makes my own work (mainly DSP/ML) move a lot faster. I would recommend it, but as their versioning scheme indicates, there's no 1.0 release yet.
Given that syntax and core API changes still occur, it's quite amazing that Compat.jl can achieve a very high level of source code compatibility between versions. This and the solid deprecation system are some of the things which make me confident enough to start using julia in production.
The main valid complaints in Dan's post were:
1. Insufficient testing & coverage. Code coverage is now at 84% of base Julia, from somewhere around 50% at the time he wrote this post. While you can always have more tests (and that is happening), I certainly don't think that this is a major complaint at this point.
2. Package issues. Julia now has package precompilation so package loading is pretty fast. The package manager itself was rewritten to use libgit2, which has made it much faster, especially on Windows where shelling out is painfully slow.
3. Travis uptime. This is much better. There was a specific mystery issue going on when Dan wrote that post. That issue has been fixed. We also do Windows CI on AppVeyor these days.
4. Documentation of Julia internals. Given the quite comprehensive developer docs that now exist, it's hard to consider this unaddressed:
http://julia.readthedocs.org/en/latest/devdocs/julia/
So the legitimate issues raised in that blog post are fixed.
1. Insufficient testing & coverage. Code coverage is now at 84% of base Julia, from somewhere around 50% at the time he wrote this post. While you can always have more tests (and that is happening), I certainly don't think that this is a major complaint at this point.
2. Package issues. Julia now has package precompilation so package loading is pretty fast. The package manager itself was rewritten to use libgit2, which has made it much faster, especially on Windows where shelling out is painfully slow.
3. Travis uptime. This is much better. There was a specific mystery issue going on when Dan wrote that post. That issue has been fixed. We also do Windows CI on AppVeyor these days.
4. Documentation of Julia internals. Given the quite comprehensive developer docs that now exist, it's hard to consider this unaddressed:
http://julia.readthedocs.org/en/latest/devdocs/julia/
So the legitimate issues raised in that blog post are fixed.
> The main valid complaints [...] the legitimate issues raised [...]
This is a really passive-aggressive weaselly phrasing. I’d recommend reconsidering this type of tone in public discussion responses.
Instead of suggesting that the other complaints were invalid or illegitimate, you could just not mention them at all, or at least use nicer language in brushing them aside. E.g. “... the main actionable complaints...” or “the main technical complaints ...”
* * *
> [...] I certainly don't think that this is a major complaint at this point. [...] it's hard to consider this unaddressed [...] fixed
After reading the original post and your responses, I think the responses come across as pretty smug and dismissive.
Third-party readers would probably be more optimistic if you just left it at “we’ve made a lot of improvement since then and we’re still working on it” or similar.
This is a really passive-aggressive weaselly phrasing. I’d recommend reconsidering this type of tone in public discussion responses.
Instead of suggesting that the other complaints were invalid or illegitimate, you could just not mention them at all, or at least use nicer language in brushing them aside. E.g. “... the main actionable complaints...” or “the main technical complaints ...”
* * *
> [...] I certainly don't think that this is a major complaint at this point. [...] it's hard to consider this unaddressed [...] fixed
After reading the original post and your responses, I think the responses come across as pretty smug and dismissive.
Third-party readers would probably be more optimistic if you just left it at “we’ve made a lot of improvement since then and we’re still working on it” or similar.
Sorry if it came off as smug or dismissive, that was not the intention. I was trying to be precise – we haven't fixed everything that Dan complained about, but some of those complaints were very subjective or things that I didn't think were fair and therefore wouldn't claim to have fixed.
I read the final line completely differently to you. I read it as saying that the aforementioned issues were definitely legitimate and have therefore been addressed.
However, like you, I noted that some of the complaints had not been accepted.
However, like you, I noted that some of the complaints had not been accepted.
Giving any validity to someone with an obvious ax to grind is already going above and beyond.
[deleted]
I, for one, much prefer tons of bugs if that's what's necessary to keep the language evolving. I like the fact that powerful features are rapidly being added to the language, even if it breaks backward compatibility. Most of my programming is scientific in nature, so I write lots of one-off scripts. "Fixing" these scripts for the newest version of Julia rarely takes more than a few minutes.
Considering that Matlab, which is supposed to be a stable platform, seems about as buggy as Julia with a lot of regressions, API changes, and new bugs every release, I, too, prefer Julia, as it's not only a nicer language with better programmer and execution efficiency, but it's also open source.
I'd rather try to fix a bug in some undocumented codebase than wait 6 months for a new black box.
I'd rather try to fix a bug in some undocumented codebase than wait 6 months for a new black box.
I personally find the syntax of the language and quality of the current implementation (speed!) excellent. However, it doesn't experience the marketing languages like Rust or Golang receive.
What I personally also find worrisome is the perception (at least for me) that Julia is confined to scientific computing whereas I find it should really be a general purpose language.
What I personally also find worrisome is the perception (at least for me) that Julia is confined to scientific computing whereas I find it should really be a general purpose language.
There is no technical reason that Julia can't be used for general purpose computing. (Well personally, I'd like nested namespaces, but) it is an amazing language. Just a matter of someone putting in the time to build the required libraries and glue code. Which will happen in time.
The lack of AOT has been the main thing holding me back from adopting it for more general purpose computing. Now with AOT I can "compile" the code and get some reasonable expectation of performance and ease of deployment. I'm probably going to start using Julia and (hopefully) extending the web server packages. Basically it feels similar enough to JavaScript for web development but with more expressiveness, so I'm pretty excited by the prospect.
Now this turns up a terrible delima, do I try to use Julia or Rust for writing embedded controllers? Rust has macros and direct memory control, but the article mentions. :)
I also think the more of us that recommend Julia for general compute, the more likely it'll get used that way.
Now this turns up a terrible delima, do I try to use Julia or Rust for writing embedded controllers? Rust has macros and direct memory control, but the article mentions. :)
I also think the more of us that recommend Julia for general compute, the more likely it'll get used that way.
I am all for replacing Python with Julia.
Me too, maybe this will pressure more adoption of PyPy.
Can you elaborate on this?
For the majority of people without CS background Language == Implementation.
So if the reference implementation is a bare bones interpreter, even though there are JIT and AOT compilers tp choose from, they will say language X is interpreted.
Which in Python's case means many ignore the existence of PyPy, given that the language designers don't want to change the nature of CPython.
So if the reference implementation is a bare bones interpreter, even though there are JIT and AOT compilers tp choose from, they will say language X is interpreted.
Which in Python's case means many ignore the existence of PyPy, given that the language designers don't want to change the nature of CPython.
PyPy's adoption problem is not that it isn't the reference implementation. It's that it is incompatible with a huge body of Python modules that rely on C extensions. If you're going to lose access to libraries, may as well not make the same exact semantic decisions for a JIT-oriented language implementation that you made for an interpreted implementation.
> ... that Julia is confined to scientific computing whereas I find it should really be a general purpose language.
It is intentional. Julia could be the new Fortran like Rust could be the new C++.
It is intentional. Julia could be the new Fortran like Rust could be the new C++.
> What I personally also find worrisome is the perception (at least for me) that Julia is confined to scientific computing whereas I find it should really be a general purpose language.
With 1-based array indexing? Very unlikely.
With 1-based array indexing? Very unlikely.
> For example, the Julia community seems to have coined the term “type-stability” to describe a concept that static / compiled languages have historically enforced and dynamic / scripting languages have historically disregarded.
I was not aware that this was a Julia neologism. It seems like such an appropriate term for discussing how to make code make the most out of JIT-compilation.
I was not aware that this was a Julia neologism. It seems like such an appropriate term for discussing how to make code make the most out of JIT-compilation.
I thought that type stability was actually a crucial notion in real-world dynamic language implementations? Witness inline caches and polymorphic inline caches, for example.
The concept is certainly not new, but googling "type stability" seems to only turn up Julia-related pages or other, unrelated uses of the term, so it seems like this usage may have been coined in the Julia community. If you find prior uses with this meaning, please do let me know.
Yeah seems so. Perhaps worth having a wikipedia page for it now!
The closest concept I can think of is the concept of "strong typing," that a value does not change type based on its context, which is a fairly widely used term. It seems like Julia has some form of weak typing, at least between the different numeric primitives, and "type stability" refers to avoiding any usage of weak typing. I don't know a lot about Julia, though, so I could be way off here.
"Strong typing" and "weak typing" don't really mean anything:
http://blogs.perl.org/users/ovid/2010/08/what-to-know-before...
You probably mean "static typing" versus "dynamic typing" which I wrote a bit about in the context of Julia here:
http://stackoverflow.com/questions/28078089/is-julia-dynamic...
Basically, I think "type stability" hasn't really been a thing in the past because in dynamic languages, people have traditionally not cared about ensuring that return types are predictable based on argument types, and in static languages, a program is incorrect if that's not the case. As people care more and more about being able to statically predict the behavior of programs in dynamic languages, the concept of type-stability in dynamic languages becomes increasingly important.
http://blogs.perl.org/users/ovid/2010/08/what-to-know-before...
You probably mean "static typing" versus "dynamic typing" which I wrote a bit about in the context of Julia here:
http://stackoverflow.com/questions/28078089/is-julia-dynamic...
Basically, I think "type stability" hasn't really been a thing in the past because in dynamic languages, people have traditionally not cared about ensuring that return types are predictable based on argument types, and in static languages, a program is incorrect if that's not the case. As people care more and more about being able to statically predict the behavior of programs in dynamic languages, the concept of type-stability in dynamic languages becomes increasingly important.
I disagree: strong and weak typing are fairly well defined terms. I'm going off the definition given in "Programming Language Pragmatics," which states "a language is strongly typed if it never allows an operation to be applied to an object that does not support it; a language is said to be statically typed if it enforces strong typing at compile time."
No, the parent comment is correct: formally they're meaningless. Those definitions might be fine for casual discussions, but from an academic programming language standpoint they don't correlate to anything meaningful.
I happen to think that there are meaningful things you can express by saying "Strong Typing" or "Weak Typing" (https://news.ycombinator.com/item?id=9256695), though "well defined" might be stretching it. However, I don't like this definition at all.
Both JavaScript and Python prohibit operations on types that don't support them. They both have TypeErrors (or something similar) that are thrown at runtime for certain operations, while others produce a result.
The difference is just that JavaScript allows a bunch of operations that Python prohibits, including several that serve almost no purpose.
Is allowing 1 + "1" allowing an operation on a type that doesn't support it, or does your language just allow adding numbers and strings? There is no principled way to answer that question.
Both JavaScript and Python prohibit operations on types that don't support them. They both have TypeErrors (or something similar) that are thrown at runtime for certain operations, while others produce a result.
The difference is just that JavaScript allows a bunch of operations that Python prohibits, including several that serve almost no purpose.
Is allowing 1 + "1" allowing an operation on a type that doesn't support it, or does your language just allow adding numbers and strings? There is no principled way to answer that question.
The strong vs. weak typing axis is a more of a spectrum. Virtually every language has some form of weak typing, especially with the numeric types. I guess the litmus test for whether or not a given operation allows weak typing is if it is equivalent to implicit coercion. Languages like Java allow the operation "one" + 1, which is equivalent to "one" + (1).toString() (basically, you'd have to box the integer first to actually make this compile), so it is performing an implicit coercion, and thus an example of weak typing. In the same situation Python would throw an error, and is thus an example of strong typing.
That litmus test is probably not enough to make a true formal definition, but does allow you to make objective comparisons between languages for certain operations.
That litmus test is probably not enough to make a true formal definition, but does allow you to make objective comparisons between languages for certain operations.
By this definition, Julia is as strongly typed as possible: no automatic promotion or conversion is ever done for anything, including numbers. What appears to be "weak typing" is a clever application of multiple dispatch system with built-in fallback methods for numeric operations. See
http://docs.julialang.org/en/latest/manual/conversion-and-pr...
http://docs.julialang.org/en/latest/manual/conversion-and-pr...
Even if you are correct that they are well defined, by that definition Lisp, Ruby, Python, JavaScript and Julia are strongly typed. C, Forth and assembly language are not. So the distinction isn't useful in this discussion.
Javascript is probably one of the weakest typed languages out there. {}+{}, []+[], {}+[] are all completely valid operations in javascript that cause all kinds of implicit coercions. And assembly language is very strongly typed: it just has a very simple type system.
As for Julia, I'm not sure how strongly or weakly typed it is, but I would probably put it at around the same level as Java.
As for Julia, I'm not sure how strongly or weakly typed it is, but I would probably put it at around the same level as Java.
Well, Forth is considered untyped, which I think is apt: it's basically bytes on a stack passed between words, with semantic meaning completely in the programmer's head and hopefully well-documented.
With that in mind, shouldn't we expect it to be a good base case for describing the "weakest typed" language?
With that in mind, shouldn't we expect it to be a good base case for describing the "weakest typed" language?
Type safety is the property that no primitive operation ever applies to values of the wrong type.
"Programming Languages: Application and Interpretation" Shriram Krishnamurthi, 2003.
"Programming Languages: Application and Interpretation" Shriram Krishnamurthi, 2003.
So what is “strong typing”? This appears to be a meaningless phrase, and people often use it in a non-sensical fashion. To some it seems to mean “The language has a type checker”. To others it means “The language is sound” (that is, the type checker and run-time system are related). To most, it seems to just mean, “A language like Pascal, C or Java, related in a way I can’t quite make precise”.
"Programming Languages: Application and Interpretation" Shriram Krishnamurthi, 2003.
"Programming Languages: Application and Interpretation" Shriram Krishnamurthi, 2003.
Julia seems like an almost perfect MATLAB replacement. (for my personal preference, I would like a slightly more static/rigid language, but I understand why that's not the right choice for Julia's target users.) There is just one problem... I really, really wish they had dropped the 1-based indexing and <= upper bound on index ranges. It is so annoying.
"I really, really wish they had dropped the 1-based indexing and <= upper bound on index ranges."
really? There are quite a few things I don't like about julia, but using 1-indexing and "end" makes implementing algorithms much clearer IMHO.
The main pain points for me in julia are the module/pkg system and that the runtime is not just batteries but more like 10 generators included i.e. it could be way more minimal. But I get that the goal is to have a powerful scientific computing language and not to build a multipurpose language that emphasizes modular construction of code units and production ready package and build management utilities.
All in all, when judged by how well julia achieves its self-stated goals, I think it is excellent.
really? There are quite a few things I don't like about julia, but using 1-indexing and "end" makes implementing algorithms much clearer IMHO.
The main pain points for me in julia are the module/pkg system and that the runtime is not just batteries but more like 10 generators included i.e. it could be way more minimal. But I get that the goal is to have a powerful scientific computing language and not to build a multipurpose language that emphasizes modular construction of code units and production ready package and build management utilities.
All in all, when judged by how well julia achieves its self-stated goals, I think it is excellent.
This is kind of bike-shedding (since that's such a small part of the language), but I also think there are arguments for using 0-indexing with open upper bounds.
Guido explains his choice best:
https://plus.google.com/115212051037621986145/posts/YTUxbXYZ...
Guido explains his choice best:
https://plus.google.com/115212051037621986145/posts/YTUxbXYZ...
Well, Julia is a language designed for mathematics, where indices starting at 1 is common (vectors, matrices). You can argue that polynomials have exponents starting at zero, but then you quickly get to Laurent polynomials, and what you really should be arguing is that the lower bound should be configurable, rather than being set at one specific value (which, of course, is still possible with custom types).
Second, I don't find Guido's argument convincing. Yes, half-open ranges can be mathematically more elegant (and that's actually Dijkstra's argument), but that doesn't mean that the code necessarily becomes more readable. For example, to construct an array without the element at index i, you'd do the following with Python-style indexing:
While the notation for the specific example of i:i+k-1 might be less elegant with closed ranges, closed ranges are something that you find in every math textbook, because sums, products, unions, intersections from a to b (and other operators in that style) operate on closed ranges normally. Closed ranges are the norm in conventional mathematical notation and it makes sense to pick the option that minimizes the overhead when transcribing between mathematical texts and code.
Second, I don't find Guido's argument convincing. Yes, half-open ranges can be mathematically more elegant (and that's actually Dijkstra's argument), but that doesn't mean that the code necessarily becomes more readable. For example, to construct an array without the element at index i, you'd do the following with Python-style indexing:
a[0:i] + a[i+1:n]
a[1:i-1] + a[i+1:n]
While the notation for the specific example of i:i+k-1 might be less elegant with closed ranges, closed ranges are something that you find in every math textbook, because sums, products, unions, intersections from a to b (and other operators in that style) operate on closed ranges normally. Closed ranges are the norm in conventional mathematical notation and it makes sense to pick the option that minimizes the overhead when transcribing between mathematical texts and code.
Here are some tasks that are ugly with [1:n] indexing:
But maybe, like the static typing issue, my opinion on this topic is distorted because I spent a lot of time programming in C++ and comparatively little time reading math papers.
Or maybe it would be equally easy to make a list of tasks that are ugly with [0:n) indexing.
- the 1D index of element (i,j) in a matrix is i+(j-1)*m instead of i+j*m
- the i'th 3-element subvector of a vector is v[3*(i-1)+1:3*i]
instead of v[3*i:3*(i+1)]
- if you have vector of indices that partitions an vector into chunks,
the i'th chunk is v[ind[i]:ind[i+1]-1] instead of v[ind[i]:ind[i+1]]
But maybe, like the static typing issue, my opinion on this topic is distorted because I spent a lot of time programming in C++ and comparatively little time reading math papers.
Or maybe it would be equally easy to make a list of tasks that are ugly with [0:n) indexing.
>I really, really wish they had dropped the 1-based indexing
>, my opinion on this topic is distorted because I spent a lot of time programming in C++
Mathematics-related programming[1] in MATLAB, R Language, Mathematica, SAS, etc all use 1-based indexing. Given that the originators of Julia are MATLAB users, it makes sense that they made a deliberate choice to keep 1-based indexing.
In other words, it was more important to grab mindshare from those previous math tools rather than appeal to C/C++/Java/etc programmers.
One outlier in the landscape of numerical programming is Python+NumPy/SciPy in the sense that it uses 0-based indices. While Julia also wants to be attractive to Python programmers, it still seems like the bigger motivation was programmers of MATLAB and other math software.
[1]https://www.youtube.com/watch?v=02U9AJMEWx0&feature=youtu.be...
>, my opinion on this topic is distorted because I spent a lot of time programming in C++
Mathematics-related programming[1] in MATLAB, R Language, Mathematica, SAS, etc all use 1-based indexing. Given that the originators of Julia are MATLAB users, it makes sense that they made a deliberate choice to keep 1-based indexing.
In other words, it was more important to grab mindshare from those previous math tools rather than appeal to C/C++/Java/etc programmers.
One outlier in the landscape of numerical programming is Python+NumPy/SciPy in the sense that it uses 0-based indices. While Julia also wants to be attractive to Python programmers, it still seems like the bigger motivation was programmers of MATLAB and other math software.
[1]https://www.youtube.com/watch?v=02U9AJMEWx0&feature=youtu.be...
This, pretty much. Not to mention that, beyond languages, data is often 1-based indexed. I have never gotten a patient data set with ID=0 as the first entry. In my mind, compatibility with what users are expecting, and trying not to induce indexing errors, trumps most other concerns.
>, beyond languages, data is often 1-based indexed.
That's a good point. Probably the most widespread data example for non-programmers is spreadsheets (MS Excel, Google Sheets). The first row[1] in the spreadsheet is labeled as "1" instead of "0". The idiomatic Visual Basic programming code to loop through the rows would look something like:
That's a good point. Probably the most widespread data example for non-programmers is spreadsheets (MS Excel, Google Sheets). The first row[1] in the spreadsheet is labeled as "1" instead of "0". The idiomatic Visual Basic programming code to loop through the rows would look something like:
For Each cell In Range("a1:a25") ' not "a0:a24"
' do work
Next cell
Mathematica is actually 0-based - but with the zero index spot reserved. A list {1, 2, 3}=List[1, 2, 3] could be read as (List 1 2 3) in Lisp style; one can check if you have Mathematica that {1, 2, 3}[[0]] = List.
But I think that's neither here nor there. Whenever the index has more use than as a label, mathematics starts at zero. Modular arithmetic, polynomials, discrete fourier transformations - for that matter, any discrete approximation of continuous math - all naturally start at zero, and generate lots of -1s in one-based indexing.
But I think that's neither here nor there. Whenever the index has more use than as a label, mathematics starts at zero. Modular arithmetic, polynomials, discrete fourier transformations - for that matter, any discrete approximation of continuous math - all naturally start at zero, and generate lots of -1s in one-based indexing.
In this subthread, the phrase "0-based / 1-based" is for the word "base" accessing the first element which is semantically equivalent to x[0] in C/C++/Python/etc or x[1] in R Language. Yes in Mathematica, putting "0" between "[" "]" will get you the reserved "head" but that's not how people are talking about "0-based" here.
You will find problematic examples no matter which option you choose (which is why I personally favor being able to set the lower bound freely).
With half-open ranges, for example, you will need different code to address a segment and the last element of a segment. E.g. if you have some structure with start_of(i) and end_of(i) expressions, then you can do a[start_of(i):end_of(i)] with closed indexing and a[end_of(i)] to access the last element, while with open intervals, you have to break the abstraction and use a[end_of(i)-1].
You can also iterate over start_of(i) .. end_of(i) in a for loop naturally if ranges are closed. (See how Python's iteration is defined in terms of half-open ranges and how iterating over closed ranges – which happens often enough when the values aren't indices – is a bit of a pain in Python.)
With half-open ranges, for example, you will need different code to address a segment and the last element of a segment. E.g. if you have some structure with start_of(i) and end_of(i) expressions, then you can do a[start_of(i):end_of(i)] with closed indexing and a[end_of(i)] to access the last element, while with open intervals, you have to break the abstraction and use a[end_of(i)-1].
You can also iterate over start_of(i) .. end_of(i) in a for loop naturally if ranges are closed. (See how Python's iteration is defined in terms of half-open ranges and how iterating over closed ranges – which happens often enough when the values aren't indices – is a bit of a pain in Python.)
See https://github.com/eschnett/FlexibleArrays.jl
(somewhat in jest, there's also https://github.com/simonster/TwoBasedIndexing.jl)
(somewhat in jest, there's also https://github.com/simonster/TwoBasedIndexing.jl)
From the comments section of that G+ post I found this Dijkstra essay with really good arguments for zero-based indexing.
Not only does it have sound mathematical reasoning but also some anecdotal evidence of problems caused by one-based indexing in programming languages.
http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF
Not only does it have sound mathematical reasoning but also some anecdotal evidence of problems caused by one-based indexing in programming languages.
http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF
For statistics 1 based is much cleaner and less error prone in my opinion. R is 1 based and it drives me nuts to have to switch to Pandas.
the 10 generators are critical if it's going to supplant Matlab. one of the biggest selling points for Matlab is that you don't have to spend a bunch of time searching for libraries, installing, configuring, matching versions, etc. You just spend a bunch of money on Toolboxes instead.
[deleted]
Julia is really following Lisp and Dylan's footsteps!
Congratulations to all involved in pushing the actual state of dynamic languages.
Congratulations to all involved in pushing the actual state of dynamic languages.
> Julia Computing carried out this work under contract from the Johns Hopkins Applied Physics Laboratory (JHU APL) for the Federal Aviation Administration (FAA) to support its TCAS (Traffic Collision Avoidance System) program.
It's great! Looks like a very interesting contract.
It's great! Looks like a very interesting contract.
In case you are interested, here are slides (http://juliacon.org/2015/images/juliacon2015_moss_v3.pdf) and a presentation (https://www.youtube.com/watch?v=19zm1Fn0S9M) about TCAS (and its successor, ACAS X)
In the literature this is called Gradual Typing. Or optional typing.
Python uses it in the last couple of versions.
Python uses it in the last couple of versions.
I come from AOT languages and have lost my patience by now. Julia is overrated.
[0] http://danluu.com/julialang/