Julia, the One Programming Language to Rule Them All
wired.com
wired.com
Oh, and Julia 1.0 hasn't been released yet. We're currently working on 0.3, which should be out in about a month.
That is what it said in the fortune cookie I got the other day.
I'll show myself out. >.<
P.S. well done on the language, sounds interesting.
What is your timeline for 1.0, if that's on the near horizon?
Having one language that spans more of the space from the bare metal (C-like fine-grained numerical manipulation) to the top level (say, training a complex model on a large dataset in a REPL) would be very helpful.
Now give me some plotting and good Qt bindings, and I'm all set!
cc -o myprog myprog.c -ljulia
edit: reference to julia documentation
[0] http://docs.julialang.org/en/latest/manual/calling-c-and-for...
You can find recent binaries here: http://status.julialang.org/
You can also check the dev mailing list: https://groups.google.com/forum/?fromgroups#!forum/julia-dev
There are several aspects to this:
- Julia cannot generate linkable shared libraries, yet.
- There is a fairly small "libjulia" C API (the embedding reference in another comment), but this is a means to interact with/control the program "julia" (for dynamic interop. or IDE use, for example). "libjulia" does not export symbols for arbitrary Julia code.
- It is possible to generate a C-callable function pointer from a Julia function at runtime and to pass this into a C routine controlled by Julia (for example, to pass a comparator to a sorting routine, or an objective function to an optimizer).
I'm actually working on related prototyping then deploy tools myself for numerical computing. Albeit using ghc Haskell as the substrate so I'm making a different set of tradeoffs than julia.
This would save so many man hours... At my shop, for every MATLAB engineer (mostly older guys) you need a C++ guru (mostly younger guys) to translate his stuff into something that will run fast.
On the other hand having seen the code the MATLAB folks write... I'd be worried. It's possible to write MATLAB in a way that is clean and makes the core algorithm presentable but that's rarely a priority. The real advantage of MATLAB is the quick development cycle. With the right packages you can make C++ look comparable... sorta.
Fundamentally the problem with MATLAB engineers is that they don't understand how to optimize code b/c they don't understand what's going on under the hood and they don't understand how to organize code b/c they don't have a concept of object oriented development, writing to interfaces, design patterns etc. etc.
EDIT: Just to clarify, I don't mean to denigrate MATLAB engineers. I'm just saying that in the current system you have two groups that specialize in different things. One focuses on algorithm development, and one on programming. I'm just speculating that maybe there is a good reason for it, and it may be unreasonable to ask one person to do both.
From what I've seen - it's incredibly hard to find a good engineer that knows his stuff. They generally have PhDs and years of training in math and whatever particular field they work on. If you get one that is actually doing novel algorithm development, each one is a golden goose that will bring in revenue for the company for years to come.
By contrast if you offer a decent salary you can get a good C++ programmer with 3-4 years of experience to do all your C++ grunt work. (we hire CS students from the local University, and bring them up to speed within 6 months)
While not incredibly hard, the problem with learning "appropriate structure for long term maintainability and production use" is that it takes an awfully long amount of time. You need to go through a lot of trial and error and learning from your mistakes. You need to read programming textbooks, and keep up with the latest trends. It's actually a huge time investment.
Think of the people that for example made the traction control system for your car. You think the same person that worked out the math in some simulation in MATLAB wrote the code that went on the controller circuit? It's not impossible, but it's not likely.
Closer to home, you can think of companies like Leap Motion, the Oculus folks, the Kinect people. Often companies that deal with video processing or control systems depend on a core set of algorithms to set them apart from the competition. The engineers behind it generally have a high level of understanding of linear algebra and often statistics and 15+ years of experience in a field.
It's very hard (though in many areas not impossible) for a programmer to learn that stuff to a level where they can innovate and contribute - so you end up relying on specially trained people who don't know about inheritance and how to use git hahaha
Where I work algo development is done by about 50% PhDs, 25% MAs and 25% BA/BS.
> it's incredibly hard to find a good engineer that knows
> his stuff. They generally have PhDs and years of
> training in math and whatever particular field they work
> on. If you get one that is actually doing novel
> algorithm development, each one is a golden goose that
> will bring in revenue for the company for years to come.
I know what you're talking about.
However outside of SV there are a lot of places where that's simply not the case. What you have is basically a cross disciplinary collaboration where you just don't have the educational background nor the expertise to do the engineering yourself.
The resentment your describing is really the same resentment you can feel towards your boss -"All he does is tell us what to do. He's not in the trenches like us!" - and it's directly related to the amount of mutual respect. In essence, how hard do you feel the other person is working relative to you.
Your description of your coworkers seems to indicate that you didn't feel like they're pulling their weight, and that's definitely a big problem.
I've heard second hand that in the valley there are a lot of incompetent PhDs that use their educational background as leverage to slack off. People will often hire graduates solely based on a degree thinking that if someone has a Math PhD "they're smart, they can learn on the job, and they'll contribute in some magical way just by being there". But actually these guys have just spent 5 years in poverty getting an advanced degree and don't want to be a code monkeys with a bunch of fresh out of college 21 year-olds. And, oh yeah - reality check, no one cares about their degree in abstract algebra.
9/10 of these PhDs are crappy engineers and 9/10 times they are thrown at problems they don't really have a background in (so they can't even be crappy and regurgitate equations they're memorized).
> "That said, it isn’t for everyone. Bezanson says it’s not exactly ideal for building desktop applications or operating systems, and though you can use it for web programming, it’s better suited to technical computing.".
So what is it? Is this the supposed "One true language", or is it just another language with a narrow scientific focus?
I'm not a core developer on Julia, just a user and package creator. It is geared towards technical/scientific computing, and excels in that task - it has replaced the combination of Python and C++ I used previously. I think what Jeff Bezanson is saying is that there is nothing intrinsically unsuited about Julia for doing web programming or desktop applications. It benefits from a fresh start in this respect, and also by using best-of-breed libraries from OpenBLAS to libuv. This is in contrast to other languages for technical computing like MATLAB or R which I wouldn't consider to be practical choices for making, for example, a math-as-a-service application (although R is getting into this territory with things like shiny).
I was surprised to discover how slow it actually is to use. Here's a quick demo of booting up the Julia repl with two libraries loaded and then immediately exiting:
$ time julia -e 'using Distributions; using Gadfly; exit()'
real 0m22.778s
I'm sure they'll improve this eventually. Much like with Rust, my hopes are high. But also much like with Rust, I wish the hype came after the promises were met.
PS: this article claims that Julia 1.0 was released in 2012, but as best as I can tell the most recent code you can get calls itself 0.3. The above was with Version 0.3.0-prerelease+1174 (2014-01-23 16:58 UTC).
[1] Upon rereading, I don't think you are, but just making sure.
Its definitely a typo. Stable release is currently 0.2 (released near end of 2013) and upcoming version is 0.3 (a month or so away).
LLVM can be used as a jit, but it's really tuned for ahead of time compilation and while the llvm devs want to support jit, their focus will always favor ahead of time compilation.
Also, "one programming language to rule them all" is quite a fanciful stretch considering people having been trying to write that since the first programming language.
1) Julia's performance is great. What you're measuring is a precompilation time.
2) I hate that the top comment on HN is usually negative. Is that some stupid rule or something?
[0] http://justindomke.wordpress.com/2012/09/17/julia-matlab-and...
It could well be that you really need every bit of performance; what I want to say is that areas where "2x slower than C" are few and far in between.
So, yes, if code can be reused later on and spending a month rather than a week writing it will save you many thousand hours of CPU time, it might well make sense not to use some high-level language (although I wouldn’t classify C++11 as low-level, albeit sometimes a bit verbose).
Aggressive JIT languages are historically slow at startup. The typical tradeoff (similar to the server/client Java VM flags) is to amortize the optimizations over the length of the application if startup time is a factor.
If you start Julia (or Mathematica, Excel, or whatever) up every time you need to 'graphically explore data', you're doing it wrong. Unless you fubar your environment (not that I ever do this on a regular basis), there isn't a great reason to restart your exploratory environment.
Maybe you don't want to use the old repl, there there is something else going on there and you don't want to mess it up. Maybe I want to show someone an example, or try something out quickly.
I use and spawn ipython windows all the time. Sometimes I have 4 open at the same time.
> Aggressive JIT languages are historically slow at startup.
Explaining the reason for the slow start-up doesn't make the slow startups faster.
No, but insisting that you want startups faster, when you've been explained the technical reasons why they are slow, doesn't make them faster either. To me it sounds like:
"This ball shouldn't fall to earth".
"It fell because of gravity".
"Explaining the reason it fell, doesn't make it go upwards".
Oh please. "We've explained the technical reasons to you" excuse. As a customer the response to that is "ok, good luck with that, I am not using your product".
> "This ball shouldn't fall to earth" / "It fell because of gravity" / "Explaining the reason it fell, doesn't make it go upwards".
No the answer to that is, screw this planet, I'll go fly into space and find another planet. Which is the response people have with software they don't like.
It is more like:
"Oh your database is slow" and getting the response of "Well of course it is,the locks at level 3 in our API have not been optimized because John is on vacation still. Geez how dare you not accept that as a valid answer?"
See you've equated software features hard laws of physics. So escaping from it is "ridiculous".
To be more serious, having an interpreter JIT a module only if you use, on-demand, or save the trace of it, across execution maybe he hard but doesn't require changing the fine structure constant.
Alpha did something similar, and a number of feedback-directed/profile-based optimizing compilers will perform similar optimizations, but they are less flexible unless repeated cycles are performed in the deployed environment.
Of course Julia has a slow startup because it is JIT-compiled and therefore will run fast. This analogy does not extend to Matlab.
$ time julia -e 'println("Hello, world.")'
Hello, world.
real 0m0.209s
user 0m0.299s
sys 0m0.104s
When I had encountered the slowness I was complaining about above, I poked around online and saw that you all were certainly aware of it and had plans to improve it. I think I even downloaded a 0.2 binary and then tried out trunk to see if it had already improved. All I had meant to say was (like Rust) that I anticipate I'll need to wait for a more complete version.
Well, it does not completely ... If I run a simulation that will take 10 hours, 2 seconds is not much at all.
However, it will severely reduce its usefullness in many other cases (quick&dirty scripting, testing)... Just for the record, on an i5 system:
$ time julia --version
julia version 0.3.0-prerelease
real 0m2.156s
user 0m2.119s
sys 0m0.030s
$time julia -e 'println("Hello, world.")'
Hello, world.
real 0m2.119s
user 0m2.074s
sys 0m0.036s
2) Lack of existing infrastructure for scientists and general purpose stuff like various SQL adapters and bindings. Take any data-oriented/scientific field, there's gonna be a python library or a c++ library with python bindings for it. Data munging? pandas. Plotting? matplotlib. Machine learning? scikit-learn. MC Monte-Carlo? PyMC or PySTAN. Optimization? scipy. That's just to name a few... those are all huge libraries with many thousands commits in their repos and many thousands human hours behind them -- it will be pretty hard for anyone to catch up fast. /* it's worth mentioning here though that many libraries in scientific Python stack were developed by aggravated R / Matlab users who loved the tools but hated the language => matplotlib/pyplot was initially a direct port of Matlab's plotting tools, pandas was initially a direct port of R's data.frame, etc /
3) 1-based indexing. Seriously, wtf? / insert an arbitrary Dijkstra joke here */
Not trying to bash Julia deliberately but I'd say by publishing a fluff piece like this Wired in fact discredits the Julia community who are nice and enthusiastic folks.
Numba and especially cython are bolted on hacks to deal with the poor performance of the interpreter. They are not conducive to the kind of modularity you can get with Julia or plain Python, and they have their own set of rules for achieving high performance. Their main upside is that, as you say below, people already have a lot of Python code, but if you were starting from scratch you would probably not design them into the language. NumPyPy still doesn't implement all of NumPy, although I think it's been under development for roughly as long as Julia.
2) would be a problem for any new language, but it is partially mitigated by the PyCall package, which makes it easy to call almost any Python code from Julia. There are even Julia wrappers on top of pandas and matplotlib that allow you to use them while following standard Julia programming conventions. I've played around with calling PySTAN from Julia, and it's not substantially harder than calling PySTAN from Python.
IMO the importance of the garbage collector needs to be underscored.
My experience with Julia was that if I pre-allocated arrays and wrote in a low level like (C-like) way, then it would be fairly fast (also, need to avoid closures but that's another issue).
If, however, I generated any new values inside loops (and using proper abstractions, this is hard to avoid), then garbage collection would often massively slow down computations and make performance hard to predict.
Unfortunately, I think having a truly high performance garbage collector is a massive undertaking. I hope I'm wrong about that.
There are further possible improvements that are not strictly related to GC. We could determine that an array of the same size is being created on every iteration of the loop and allocate that memory only once. Ideally we'd automatically devectorize code to remove temporaries, but that is quite hard.
Could you explain this a little - What is so fundamentally broken about pypy/numba ? From the little I have read [1], it looks like they are inferring types to enhance performance and does a jit (just like Julia).
I am of course wondering if the magic of Julia cannot be ported on top of Numba or something.
Numba/Cython restrict what kind of code you can write so they can (jit-)compile it. Cython is less restrictive since it's more mature but it uses special syntax and is technically not python anymore.
2) Lack of libraries should never be a show stopper when it comes to adopting new languages.
3) Lua.
There are arguments in favor of 1-based indexing, especially given one of Julia's target replacement languages is R.
and later:
> "Bezanson says it’s not exactly ideal for building desktop applications or operating systems, and though you can use it for web programming, it’s better suited to technical computing."
So, Julia is not what we need? ;)
Besides this contradiction I'm not entirely convinced that we need one language to rule them all. I'm not even sure I want multi-paradigm languages (C++ anyone?).
Aren't the problems explained in the introduction of this article not caused by the tools instead of the programming languages? I don't see how using multiple languages complicates patching (unless the article is talking about monkey patching which I doubt), but I would understand how going through 4 different debuggers could drive you crazy.
Disclaimer: I'm not familiar with Julia and I will not judge it based on a Wired article.
That wasn't quoted in the article, so I'm assuming it was the author's words, not Karpinski's. The Julia devs seem to be more interested in solving the (prototype) -> (translate to low level language) -> (optimize for production) inefficiency rather than making one language to solve every conceivable problem.
EDIT: and I consider this to be all the proof I ever need: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EW...
0-based arrays are easier for computer folks who occasionally have to implement the code that translates 'a[i]' into a memory access. 1-based is easier for physicists and mathematicians who were subscripting variables before there were computer implementations to worry about and had a pile of literature already written using that idiom. It's just a clash of conventions.
I haven't made an indexing-based error in over 10 years, and the only reason I ever had it before was from having to switch back and forth between C and VB6 years ago.
http://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831....
In Julia, the natural numbers 2, 3, ..., 12 are expressed as 2:12 and the empty range starting at 2 is expressed as 2:1.
N = rows(data)
for i in 1:N
blah
You're fighting a straw man; that isn't the argument. 1-based indexing is elegant for many mathematical uses. Technical computing often implements algorithms that are best written down using mathematical notation. In such a case the largest conceptual difficulty is not the origin of the index but the successful translation of the algorithm. To minimize the possibility of error, the original indexing (especially when it involves nontrivial mathematical maps) is often preserved.
> Dijkstra makes all of the convincing arguments for why 0-based is better than 1-based.
He essentially makes only one point. Namely that, when using 0-based indexing we can easily determine the length of a sequence by only its upper index. Though it's not a profound observation since the index bias is zero, it often gets treated as such.
Either way, it's a convention. A competent programmer should be able to handle any well-specified indexing convention (including those starting at negative indices). Different circumstances will confer different benefits on different conventions, and you should use the one that's most appropriate for the task at hand rather than religiously promoting The One True Way (TM).
I don't see how you could have indexing from the tail being internally consistent if the arrays are 1-indexed.
1 and end for the first and last, 2 and end-1 for the second and second to last, and so on.
"And that’s the most coherent argument I can find; there are dozens of other arguments for zero-indexing involving 'natural numbers' or 'elegance'[2] or some other unresearched hippie voodoo nonsense that are either wrong or too dumb to rise to the level of wrong."
I still believe this is the only time EWD's work has ever been referred to as "unresearched hippie voodoo nonsense".
Is this the same Mike Hoye who hacks Zelda?[potato]
[potato] http://www.huffingtonpost.com/2012/11/16/mike-hoye-hacks-zel...
[2] http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EW...
History can inform the argument, but history does not make the argument. Observing the effects of 0-vs-1-based indexing in existing languages can give us data about the pragmatic effects of either decision. But the precise chain of cause-and-effect of decisions made in the 1960s in an environment where both the hardware and social structures around computing were radically different than they are now is really not that relevant to the question of which approach is better overall.
The article is also snide and openly insulting to nearly everybody (including Dijkstra); combined with its lack of a convincing argument, this article does not deserve to be treated as a credible position piece in support of 1-based indexing.
One problem, that I don't see mentioned, is that verification of correctness. There is a reason people use decades old packages and code: they know that the tool is reliable and correct. My supervisor's code is based off his supervisor's code, which has been around since the 80s. At least 50+ papers have been published based off this specific code so we know that it is correct. The amount of time it would take to re-write and test the code written in a new language would be a very large times-sync that no one wants to do because they could spend that time doing research. I think this is part of the reason why things change slowly in the scientific computing community as whole. There have been tens of thousands of papers published that use Fortran/C/C++/Matlab and this new kid Julia comes along and how many scientific papers have been published using Julia code? I would imagine barely even a fraction. To scientists, this is reason to be sceptical. I'm not saying I agree with this but it is how scientific computing does think.
Also, on a personal note, the marketing needs to change. Since of the creators is reading this, if you want get the scientists, drop the grandiose claims of "one language to rule them all", although that's probably not your fault. To me, I immediately smell bullshit a mile away when I hear that. Too many times in the history of scientific programming languages have people made similar types of claims only to see it crash and burn. This is why many the older folks won't bother.
Reading Julia's homepage, I would be unconvinced about why I should choose Julia over Matlab. Heck, why not use Python? Python is open source and has been around a lot longer and people have certainly of that.
Also your speed tests, well fix them. For example Matlab vs Julia. Calculating the Fibonacci numbers? Honestly who cares. Plus why are you even computing them recursively, that's a silly way to do it. I understand it demonstrates recursion, but it's a pretty useless thing in my opinion. I only ever see the Fibonacci numbers come up in programming contest problems. I can honestly say I've never seen them used in real applications that scientists do. And if they were you would never implement them this way. Also the implementation of quicksort, why did you write your own? Use the built-in one for a more fair comparison. No one writes their own sorting algorithm but uses the built-in languages ones. Do that here. It is disingenuous to Matlab to not use the built-in functions.
The real tests that I would care about would be the random matrix multiplication. That's something that is way more common than calculating Fibonacci numbers. And here Julia is a little faster than Matlab but not too much. I'd be sceptical of why I should switch. Similarly a single number tells me nothing. Just because it says Julia is faster, well that's one test. How well does Julia scale? Is it true that Julia is faster than Matlab for multiplying NxN random matrices? How well does this scale? A single test tells me nothing. I'm obviously bias towards matrix tests since my research used a lot of matrix operations, but if you read papers about various codes they almost always include scale tests. This is what my colleagues would care about more than anything since they have massive datasets so scalability is critical. Remember you are trying to sell this to scientists who are, obviously, scientists, so having good quality data to show them is critical. I discussed Julia with my colleagues and this was one of the things we immediately mentioned. The tests shown didn't convince us at all that it was even worth considering.
Plus, I'll be honest, I feel the homepage is marketed more towards computer scientists than numerical scientists. The first feature is "Multiple dispatch: providing ability to define function behavior across many combinations of argument types". The hell is that? Why do I care? Remember who your audience is! To give you an example, I will tell you about my office mate. He is a PhD student working on turbulence and uses Matlab for all his data processing afterwards. His code comes from simulations written in Fortran that run on the local supercomputing cluster. They are stored in the NetCDF format. After the simulations are done, he opens up Matlab, reads in the NetCDF file and runs a bunch of data-processing functions to compute various quantities from the raw data. He then plots these things. On the Julia homepage I don't even know if Julia can even do graphics. Can it? If it can, the homepage doesn't mention any plotting libraries. So, I repeat, what exactly does multiple dispatch mean and why is it so important? If you want him to be using Julia, then you need to explain to him why he should be using it over Matlab. Look at the numpy homepage. It is short and to the point. Plus it has a nice link to "NumPy for Matlab users" which is something I would want to know immediately. Julia, as far as I can tell, you have to go to docs, Julia manual, Noteworthy differences from other languages (which is at the bottom of the screen!!).
I could probably come up with more criticisms and suggestions but I don't want to write a book. I should say, I completely and fully support what Julia is trying to achieve. I find that Python is just too awkward to be a good Matlab replacement. To me, Python is a very general tool that also has the ability to do similar things to Matlab. However since Matlab is designed to do numerical computing, and Python isn't, I find Python to be awkward for some things. But, at least it can run on the computing clusters. Matlab is stupid with licensing and trying to get it to run on the supercomputing clusters is near impossible. Definitely in the future I am going to try Julia as a data-processing step since it is free and open-source and not subject to any of that licensing crap. Plus the parallel aspect interests me although I have no idea how good it is since I don't see any graphs showing what sorts of advantages I might get. Plus the documentation page is rather dense text-wise and not that appealing to read right now.
But, I think the tl;dr is that remember who you are marketing to. Remember that scientific computing moves slow. I know colleagues who have just discovered version control and think it's amazing.
Multiple dispatch lets the user define several functions with the same name and have the compiler pick the right one based on the arguments. For example, you could have three versions of the foo() function, one for reals, another for complex, and a third for matrices. You could define your own types and write additional versions of foo()—the compiler will pick the right one based on the underlying types. Julia's type system makes a lot of sense once you've gotten the hang of it.
I'd suggest fiddling with Julia if you have some time, as I think it rolls together some good ideas. But it still has a way to go IMHO. Redefining functions with dependencies in the interactive toplevel doesn't work quite right, and you can't delete entries from the symbol table. It concerns me that these things don't work. I figure that I'll give it another look as a tool for serious work when 1.0 gets released.
I'll stick with R in the mean time—less change of unpleasant surprises. But I could see Julia replacing R for me in a few years if it's done right.
I do use Python, but it came into it late on my project. Future projects will definitely use Python since it's good enough for data processing stuff. Hard core numerics will still be done in Fortran/C.
I definitely do see Julia being the better version of Matlab but it certainly has a ways to go.
This is my biggest problem with Julia. I'd love to tinker with Julia, port some code over, especially some slow Python code, but it's hard to do trying to shove papers out the door and knowing it'll be days/weeks before I'm up to speed, and that there's libraries I may have to reimplement (probably poorly, what with being a scientist rather than a programmer).
Well, you could scroll to the bottom of the page...
My personal experience with Julia is this: I rewrote an algorithm from MATLAB to Julia, and received a 20x speed boost without any effort. That, and a very clean language design are why I'm using it a lot more these days. I would encourage you to just try it out.
It is interesting your example about Matlab. Did you design it with vectorisation in mind? Not to dismiss your coding skills, but I've seen a lot of poorly-designed Matlab code that just doesn't exploit the Matlab language. The office mate I mentioned above was one of them. I took a look at his code once and vectorised it and something that was taking 10 minutes took 30 seconds.
I am definitely going to use it on future projects. Since right now I'm finishing up stuff it wouldn't make sense to re-write all my Matlab processing routines into Julia. I think a good specifically designed open-source version of Matlab is needed. Yes I know about Octave but I've never seen anyone really use Octave since it never seems to work for more complicated things.
Sure did. I've been using MATLAB since before it had a JIT. In fact, for the Julia code I didn't even devectorize which would play to its relative strengths. I also didn't have to pull out a profiler for all of this, it just happened with the first stab at it.
>Since right now I'm finishing up stuff it wouldn't make sense to re-write all my Matlab processing routines into Julia.
No need to, just do what I did and pick one function that's called in a tight loop and try testing that. If you don't find the performance that you'd like, post a code example on the julia-users mailing list (under the Community link on the website). Folks will either help you to 1) improve your code with Julia's design in mind, or 2) use your code as a test case to improve Julia itself. The community is very helpful.
A peek at the performance tips section in the manual is a good idea. Don't forget to wrap your code in a function for testing, and to "warm up" your code (= give the JIT a chance) before calling the @time macro on your function. Good luck!
But, from my experience trying to establish rules for using version control, I also realize that they're unlikely to ever rewrite (or even modularlize) their codebase to take advantage of any other language.
For someone who has used both Julia and lisp macros, how do they compare?
# Set up stream `sock` here
@async begin
println(sock,"Hello World")
line = readline(sock)
println(sock,"You typed ",line)
end
I had to laugh at the irony of the juxtaposition of the title and the final sentiment! I like languages so I'll definitely be checking out Julia.
If:
"Together they fashioned a general purpose programming language that was also suited to advanced mathematics and statistics and could run at speeds rivaling C, the granddaddy of the programming world."
Then:
"That said, it isn’t for everyone. Bezanson says it’s not exactly ideal for building desktop applications or operating systems, and though you can use it for web programming, it’s better suited to technical computing."
does not follow based on the definition of "general purpose."