Slashdot Mirror
Julia 1.0 Released After a Six-Year Wait (insidehpc.com)
An anonymous reader quotes InsideHPC:
Today Julia Computing announced the Julia 1.0 programming language release, "the most important Julia milestone since Julia was introduced in February 2012." As the first complete, reliable, stable and forward-compatible Julia release, version 1.0 is the fastest, simplest and most productive open-source programming language for scientific, numeric and mathematical computing. "With today's Julia 1.0 release, Julia now provides the language stability that commercial customers require together with the unique combination of lightning speed and high productivity that gives Julia its competitive advantage compared with Python, R, C++ and Java."
The Register reports: Created by Jeff Bezanson, Stefan Karpinski, Viral Shah, and Alan Edelman, the language was designed to excel at data science, machine learning, and scientific computing.... Six years ago, Julia's creators framed their goals thus:
"We want a language that's open source, with a liberal license. We want the speed of C with the dynamism of Ruby. We want a language that's homoiconic, with true macros like Lisp, but with obvious, familiar mathematical notation like Matlab. We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell. Something that is dirt simple to learn, yet keeps the most serious hackers happy. We want it interactive and we want it compiled...."
In a julialang.org post announcing the milestone, the minders of the language claim to have achieved some of their goals.
The Register reports: Created by Jeff Bezanson, Stefan Karpinski, Viral Shah, and Alan Edelman, the language was designed to excel at data science, machine learning, and scientific computing.... Six years ago, Julia's creators framed their goals thus:
"We want a language that's open source, with a liberal license. We want the speed of C with the dynamism of Ruby. We want a language that's homoiconic, with true macros like Lisp, but with obvious, familiar mathematical notation like Matlab. We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell. Something that is dirt simple to learn, yet keeps the most serious hackers happy. We want it interactive and we want it compiled...."
In a julialang.org post announcing the milestone, the minders of the language claim to have achieved some of their goals.
This is really impressive from the technical standpoint, but I am wondering if they have a Code of Conduct for the language?
Didn't RTFM? Julia has several backends including LLVM. Performance is more than respectable. In particular, puts Python to shame and close to Java + JIT but without the JIT lag, load time and memory footprint annoyance.
When all you have is a hammer, every problem starts to look like a thumb.
It's natively compiled, just not statically compiled.
If compiles optimised versions of your functions as needed. So you can define a function that works on any supported numeric type, and when you call it with doubles, it will compile and cache a version of the code optimised specifically for doubles.
As a result, it is very fast for numeric code, without having to create separate function definitions for each supported type.
https://xkcd.com/927/
Otherwise claiming "Julia is the only high-level language that has run at petascale" is a bit of an exaggeration.
My first impression of Julia was favorable. I fired up the command line interpreter and typed in 2 + 2. Prints out 4, just like Python. Then typed in 2**4:
Wow, I like that. I managed to define a function, f(n) = n * n, without reading the manual but didn't get much further without reading the docs docs. But great start, I already see this as a reasonable alternative to what I usually use Python for: a desktop calculator.
Initial impression matters. Now, with a postive one, I will go deeper and see if Julia is really what I should be coding one-offs in, instead of Python or Go.
When all you have is a hammer, every problem starts to look like a thumb.
I want a tool that puts nails in like a hammer, screws screws like a screwdriver, lifts steel like a crane, cuts wood like a saw, digs dirt like a backhoe, shoots animals like a gun, stabs children like a knife...
I think that's called a "specializing compiler", like Psco/PyPy but not JIT. I don't juch like JITs, actually. A good fit for LISP but not much else.
When all you have is a hammer, every problem starts to look like a thumb.
Cheat sheet
When all you have is a hammer, every problem starts to look like a thumb.
Good or bad? Hard to say, but I would rather have these things than not. It is currently the fashion to leave out classes and provide similar functionality with interfaces or equivalent, but I find that a sticking point. Let's see how it goes.
There are situations where goto is far preferable to fiddling with local logic variables and such. Sure, goto can be tricky to implement with respect to local scope and such, but leaving it out to avoid work... doubtful. Leaving out goto for purity reasons... beyond doubtful.
When all you have is a hammer, every problem starts to look like a thumb.
For a technical computing language, One of the major overnights was plotting. It is a mess. There were about 6 different plotting libraries, each with different interface. The most popular was to install python and use Matplotlib.
There has been an attempt to wrap all of them up into plots.jl but you end up with something that never quite covers what you need.
It also uses array indexa starting from 1......
Until it has a third party module for every conceivable thing you might want to do, I'm not dropping Python. I'll pop back in 10 years and check it out :)
"We want a language that's open source with a liberal license..."
I'm not a programmer, and I can easily prove that if necessary.
Are there programming languages with restrictive licenses? What sorts of jobs would you be unable to do because of those licenses?
You mean it has a template library? C++ has that for as long as I can remember.
Templates are fine (for some definition of fine) for static type systems where types can be decided and code specialized at compile time.
Julia is however dynamic and uses different mechanism.
A leprechaun riding atop a unicorn handing out buckets of gold.
If they pull it all off in a single language, more power to them.
No, it doesn't use a template library. Or in a sense, all your code is templates.
If you haven't used or benchmarked the language, I don't get why the armchair criticism? People like yourself were once saying 'that plane will never get off the ground. We can't fly!'
It is a lot more like Perl; it runs fast, and you can write it fast too. But reading it is going to take time.
That tradeoff isn't going to go away, it is baked into the range of problems we want to solve with the same tool. The less verbose the language is, the more of the complexity is hidden. That makes it expert-friendly, but it also makes collaboration more difficult.
I prefer the Ruby solution; it can't do everything. Lots of stuff that is hard you would write in C instead. And it has an excellent C interface.
That's great for typical problems, but it doesn't really provide for distributed problems. That's what Julia is for. So it is competing with Go for non-statistical uses, not Python.
But it is mostly competing with matlab and R for those statistical uses. Also, notice they mention LISP instead of Haskell? They're not actually as ambitious as they claim to be.
The multithreading support in Julia 1.0 still says "experimental". So does it have usable threads or not? How good is the thread implementation? Comparable to Java? To C++? Are the standard data structures thread safe? How many spurious locks are there?
*Any language* puts Python to shame... except Python plus native compiled number crunching libraries. You know, the ones everybody uses.
Fascinating, how Python apologists are able to convince themselves that its horrible performance is not a reason to use a different tool. Thus the idiocy continues.
When all you have is a hammer, every problem starts to look like a thumb.
((Yes Lisp) is) (so frig)) in )))
(Awesome. (((And (So Simple) even) A
(((Child could ) use )(it probably).)
Don't worry the hardware will take care of performance issues by the time the product ships*
*Am I joking or not ?
Heretic! Splitter! Dimensional fractionator!
The Mandelbrot law is supreme!
I've fallen off your lawn, and I can't get up.
Way ahead of ya
I've fallen off your lawn, and I can't get up.
Julia and C don't prevent you from choosing a type. Neither Ada nor any other language can magically solve the problem. I'm just talking about defaults. The programmer still has to decide if it's more important for a function to scale with hardware or run the same everywhere. It's never an easy choice at any level. You could say, "every programmer should make this choice", and I sometimes see C littered with special types for this reason--this function should scale with hardware, this one shouldn't, etc. Then somebody else complains that's ugly or even unnecessary. No silver bullet, really.
I would like to hear from people who switched from the more mainstream numpy and tensorflow for linear algebra.. to Julia.
What were your experiences? Was the worflow much more productive? What were the other gains?
Better default data structures, better numerical support, more approachable for end users.
What are these "default" data structures in Lisp that you refer to?
How would you contrast the numerical support in Lisp with what's in Julia?
((Yes Lisp) is) (so frig)) in )))
(Awesome. (((And (So Simple) even) A
(((Child could ) use )(it probably).)
((Yes Lisp) is) (so frig)) in )))
(Awesome. (((And (So Simple) even) A
(((Child could ) use )(it probably).)
Lisp code doesn't look like that.
It does look respectable but that graph isn't the full story, is it? In my field we use a lot of Python and MATLAB (also some R). Python can be sped up with Cython (often dramatically). MATLAB makes it easy to integrate C or C++ via MEX files. If you were using one of those languages and really needed to speed up the sorts of things being profiled in the Julia benchmarks then you have a simple way of doing it. Usually you're just optimising an inner loop and can leave the rest of the code unchanged. In practice, however, we have access to large quantity of well-optimised code in both Python and MATLAB so we can just re-use what's already there and don't even need to bother with the above.
That graph tells me that if I had a lot of code I'd need to write in C, I might consider doing it in Julia instead. It doesn't convince me to drop Python or MATLAB in favour of Julia.
soylentnews.org
There are other trade-offs that you can have, like slow compilation times, or ability to get speed only on specific domains. Check out projects like Stalin ( https://en.wikipedia.org/wiki/... ). And btw, as someone who has an Msc in CS and published an article in an important convention, I know enough "foundations of computer science".
Avantgarde Hebrew science fiction
What have you been smoking. The champ there is C. Always will be C unless you go to assembler, which C is turned into.
FORTRAN was just one of the first languages and a really big step up from assembler. Lacks a lot of critical things, however.
Why do you think performance is the most important consideration for programming language choice?
The idiocy is in believing that everyone's needs are the same.
For the things that are usually done with Python, it would not matter if the interpreter was further 10 times slower.
If reading types is the hard part, you're only one step past Hello World anyways.
> Maybe not the MOST important, but I sure don't like waiting for the computer any longer than is strictly necessary.
No one does. But people like even less to wait for people writing code. It takes much longer to write C++ code and it takes longer to compile it as well. Fast, optimized native code is valuable only if your program is going to be used on larger amounts of data, performing intensive computations or used by a large number of people. Most code is not written for these cases.
Most code is written for very local purposes, doing fairly simple and focused things, often for one-off purposes. It is illogical to use a programing language that is slow to write code in and takes longer to compile. This is not just true today. These were successful (and rational/logical) arguments offered 2-3 decades ago when CPU time was at a much higher premium and interpreters were much less optimized.
You should measure the total performance (programmer and code) and costs, not just CPU time.
> I'm going to go out on a limb here and say that there isn't *anyone* who wouldn't benefit from faster performance.
Matlab and R are most commonly used by computer scientists and statisticians. Both are worse than Python by runtime performance. These are not unintelligent people. Their time is as valuable as anybody else's. So why do these people use them? Because their time is valuable.
Often time the runtime difference between C++ and Matlab/Python/R is 0.01 sec vs. 0.5 sec. It might matter if the difference is 1 hr and 500 hrs, same ratio, but at such small time scales, the human latency barely even takes notice.
> Mind you, there are features worth trading CPU time for, but they have to be justified and should never be the default case if they lead to performance hits. The simplest, fastest alternative should always be an option.
You have it exactly wrong. Human time is first and foremost important. That is the default case. Humans are extremely hard and expensive to train and cannot be upgraded. They are the bottleneck and need to be most managed. Performance is something you worry about after you produced something correctly. Generally speaking, identifying and optimizing small bottlenecks is much more productive than starting with performance as a key consideration even when you don't need it.
Premature optimization is the root of all evil -- Donald Knuth
The entire point of programming languages is human performance, not computer performance. CPU performance is the job for compilers (you can transliterate a fair subset of Python to C/C++. Eg. ShedSkin). That said, I am enthusiastic for productive AND fast tools - Rust & Nim, in my case, but none of these are Python/Matlab/R replacements yet.
50 hrs, not 500 hrs.
> Yes, but a poor design may make it difficult or impossible to optimize later.
Which is fine. Optimization is possible to a reasonable degree, but not completely. A 40 or 400 times slower program is only perhaps 2-4 times slower after Cython, Numba, ShedSkin etc - a very reasonable trade-off. Further that, Python is meant to be used with a splash of C for those few core data structures and algorithms, not replace it. Have a lot more custom stuff that needs native performance? Python was never meant for that use case.
> Using hashtables to implement arrays, for example.
Hence, numpy.