Live data from Hacker News

Why I'm Betting On Julia

evanmiller.org

91–100 of 258 posts

Re: Why I'm Betting On Julia

#91

How does Julia interface with C? Is it easy to interface Julia with C because all it does is compile the C with Clang/LLVM?

Julia does not compile the C code; it links against shared libraries. It helps that Julia types can model C structs easily.

Manual entry on calling C: http://docs.julialang.org/en/latest/manual/calling-c-and-for...

Blog post on passing Juila callback functions to C code: http://julialang.org/blog/2013/05/callback/

Re: Why I'm Betting On Julia

#92
Does Julia have AOT compiler which produces a binary which can be linked to a C program? I am asking this because I have to consider availability on iOS - which is a platform prohibits JIT.

Re: Why I'm Betting On Julia

#93
post #27

"Julia was not designed by language geeks — it came from math, science, and engineering MIT students" This statement is built on a false dichotomy. And it is not really true for Julia, take the type system for example, sophisticated AND unintrusive.

> "Julia was not designed by language geeks — it came from math, science, and engineering MIT students"

This makes me a bit cautious about the language. Scientific computing people are often very smart but they are not programmers or computer scientists and may do funny things that a computer scientist would not. Like one based indexing of arrays in Julia. This is not a big deal but I'm a bit wary that there may be some nasty surprises for a language geek computer scientist like me :)

Another example is the byte addressing of UTF-8 strings, which may give an error if you try to index strings in the middle of a UTF-8 sequence [1]. s = "\u2200 x \u2203 y"; s[2] is an error, instead of returning the second character of the string. I find this a little awkward.

There's a flip side to this too, if you're dealing with scientific computing there seems to be a wide variety of scientific computing libraries available in Julia [2].

Overall I find this language very interesting and it is on my shortlist of new languages to take a look at when time permits.

[1] http://docs.julialang.org/en/latest/manual/strings/#unicode-... [2] http://docs.julialang.org/en/release-0.2/packages/packagelis...

Re: Why I'm Betting On Julia

#94
post #90

I really don't like the anti-intellectual tone of the beginning. "The problem with most programming languages is they're designed by language geeks, who tend to worry about things that I don't much care for. Safety, type systems, homoiconicity, and so forth." can be rewritten as: "The problem with most software is that they are designed by computer geeks, who tend to worry about things that I don't much care for. Inf…

How is this anti-intellectual? Most languages are designed by language geeks by definition. And language geeks tend to worry about the things mentioned. And he doesn't care about these things because they've been largely irrelevant for the work he's had to do.

But then the rest of his article is precisely about how they're relevant. For example he says he doesn't care about type systems, and then his only code example is showing off Julia's type-specialization feature. Maybe he just means he doesn't care about the theory behind why it works, e.g. he likes to fly on planes but doesn't care to learn aerospace engineering himself (which is fine).

Re: Why I'm Betting On Julia

#95
post #20

I'm excited by Julia, but I don't think this article makes a very good sell. It's neat that you can dump the generated assembly, but I'd rather see a demonstration of a robust profiler so that I know which functions I need to dump in the first place. I also disagree that the popularity of Node stems from "getting disparate groups of programmers to code in the same language". From what I've observed, it's not that bac…

I tend to agree with you about tools. I have yet to meet a language feature that's more important than library availability, profiling, autocompletion, documentation, debugging, etc. Then again, I don't face the script/C/CUDA choice everyday (most of his detractors on this thread don't either, I'd be willing to bet) so his circumstances are probably different enough to justify a different priority list. His argument…

> I've never met a FFI I didn't come to loathe

I've felt that pain. With so many new programming languages popping up, I've been wondering if the next killer programming improvement isn't strictly a programming language at all, but rather something that rethinks the linker, manages execution, and facilitates interfaces between larger blocks of code (maybe in multiple languages).

Re: Why I'm Betting On Julia

#96
mini ASK HN: would there be any interest in supporting Julia in Visual Studio? (as a free/oss plugin).

i lead the Python Tools for Visual Studio project at msft and would be curious if there is interest.

as a side note, if you do you use Python & require Python/C++ debugging, PTVS now supports it: http://www.youtube.com/watch?v=wvJaKQ94lBY#t=10

Re: Why I'm Betting On Julia

#97
I don't really see the need for the author to make himself into a "cowboy" coder and point out how they ignore all those valuable insights and enlightenments of programmers.

Julia is a kind-of-fine language that is designed to appeal Matlab users first of all by its syntactical looks. Just like Javascript was designed to appeal to C and Java users by imitating their look.

Under the hood, Julia is quite a smart development, not only in terms of code generation, but also in terms of datatypes and object models.

Multiple dispatch is something that more or less only Lisps typically offer natively (and Dylan). When working with types (especially in dynamically strongly typed languages) this is often something what I am missing in other languages. Consider Python:

    if isinstance(x, Y):
        ...
    elif isinstance(x, Z):
        ...
This feature alone shows that the authors of Julia are rather the thoughtful language-loving authors.

So I would like to leave the small scope of the article but look at the greater picture: Julia and its competitors. There are actually quite a few on the market. A few domain-specific numerical libraries exist for C/C++/Fortran for scientific purposes (ROOT at Cern, etc.). They are more or less falling out of fashion. For a long time, Matlab has been dominant in some faculties for evaluation and working with data, process signals and images. It is not by accident that Matlab was created as a convenient Wrapper to Fortran libraries at the time. From a software developer's perspective, Matlab is for Cowboys.

Next to its high price (and the vendor lock in forced upon college and university students who are trained for matlab when there exist suitable open source alternatives), the most appalling thing about Matlab is its poor performance as a programming language. While its easy to write small scripts, solve linear algebra problems and plot a few things, I have hardly seen well organized Matlab code and I just think that it is impossible. While Matlab licenses cost heaps of money, support is not good and upon a version change you have to spend considerable amounts of work getting around API changes.

The Matlab clones available (Octave) are generally unimpressive. I think this has to do with the big effort of copying Matlab and the need to develop the whole tool stack (parser, interpreter, libraries). Contributors are hard to find because octave hardly offers any benefit over the original, like ReactOS with Windows, Octave can only react. I still value the effort of the octave folks, they have done some great work!

Scientific Python has chosen a slightly different path. Taking the fairly uncontroversial programming language Python, the authors created an infrastructure of thematically separated modules. While eliminating the need to design and implement an own programming language, a lot of work could be spent on building useful libraries. Also, existing libraries were reusable (databases, XML, etc.) and Python is a really convenient programming languages for both Newbies and professional software developers. So with this pragmatic approach, the contributers have created one of the best environments for scientific software development and would be my suggestion for anyone at the moment who just wants to use one system.

What still amazes me: While working in an ipython notebook (http://ipython.org/notebook.html) on some numerical calculations, I can just pull up Sympy (http://sympy.org) and perform some symbolic computations (Fourier transforming some function analytically or taking the derivative of some other, etc.).

Oh, and have I told you about how Scipy can replace R for really cool statistical analyses?

The part where Julia kicks in now is the point that Matlab has a lot of market ground, especially with engineers who are not extraordinarily passionate about programing. For some people the burden of learning another syntax is just too big, they are not full time programmers but spend their time more with acquiring data and using the results. I really hope that some of them who are not willing to switch to scientific python can agree on switching to Julia.

Full Disclosure: I have occasionally been forced to work with Matlab (so I do have some experience with it without being an expert) and it was not fun. This is one of the reasons I would like all Scientists to have the chance of choosing a good environment that is suitable for them. If its Matlab for some, so be it ;-) I have never looked back.

Re: Why I'm Betting On Julia

#98
post #58

Just yesterday I decided to start seriously developing in Julia. High-level languages are a bottleneck for computational biology. We need to be able to write things fast, and have them run fast. So far no language really does this. But Julia looks like the one. I'm going to put together a BioJulia team is anyone is interested in playing.

You might also look at biogo for inspiration https://code.google.com/p/biogo/

Re: Why I'm Betting On Julia

#99
post #6

> The problem with most programming languages is they're designed by language geeks, who tend to worry about things that I don't much care for. Safety, type systems, homoiconicity, and so forth. I'm sure these things are great, but when I'm messing around with a new project for fun, my two concerns are 1) making it work and 2) making it fast. For me, code is like a car. It's a means to an end. The "expressiveness" of…

This is about the ability to complete a project fast, which is typically about both convenience of fast prototyping, and performance (ie. you don't want to wait days for the results to be computed before changing something in the code, and you want that change to be easy).

And probably few buyers who want fast cars care about aerodynamic design per se -- they care about speed; sure, if better aerodynamics is what's necessary then so be it, but they would also prefer a fast car with poor aerodynamics and a huge engine to the very aerodynamic and fuel efficient, but slow one.

Re: Why I'm Betting On Julia

#100
post #30
post #18

Earlier quoted context omitted.

> Node.js has only a few great use cases where it shines and in the real world, the vast majority of shops have not switched to using it. Of course not. 'Switching' is usually more pain than it's worth, especially if your previous solution works. New start-ups are likely the ones who will be using it, just as Rails took off in the start-up world. Likewise, R and Python are going to continue to be in use in existing p…

In my experience, most people are turned off by using Javascript on the backend of web-development. Your experience may be different, but I just don't think the analogy made in the original article is a very good one.

I was about to say, they ought to be turned off by JavaScript on the back end when there are so many other options. Then I remebered that people use PHP more often than not for back end work.
Post reply on HN