Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I'm Betting On Julia

evanmiller.org

Post reply on HN
Print view View original

101–110 of 258 posts

Re: Why I'm Betting On Julia

#101

Post by wirrbel »

simonster wrote: post #77
Pxtl wrote: post #50

Earlier quoted context omitted.

To be fair, there's also Python+NumPy and R in that space, not just Matlab. Besides the "tinker with LLVM" thing, what does Julia offer that Python (or Cython for speed)+NumPy does not?

Writing fast code in Julia requires less effort than it does in Python or R. You don't have to drop down to Cython or Rcpp to get good performance. If you write an algorithm in Julia the same way you'd write it in C, it will achieve equal performance. If you write it the same way you'd write it in Python or R, it may not be optimal due to the cost of memory allocation, but it's still faster than Python or R. Julia is…

To the rescue of numpy: A matrix from linear algebra and a 2D array are not exactly the same. In Python they are different convertible types and I think in practice it is hardly a drawback. That the multiplication operation is overloaded in the Mathematical World with the same symbol as the "normal" multiplication is unfortunate, numpys solution is as good as introducing two different operators (with one being an awkward .*)

I love the multiple dispatch part about julia though.

My fear however is, that unlike Python, Julia will lack enough libraries, especially on the unscientific part (GUI, databases, network, all the other stuff you need).

Re: Why I'm Betting On Julia

#102

Post by maaku »

mjn wrote: post #21
thinkpad20 wrote: post #7

Earlier quoted context omitted.

Julia's primary purpose is as a scientific language, which means lots of number-crunching on large data sets, complex computations, etc. IO is unlikely to be the bottleneck in these situations.

I'm not sure I agree with the second sentence. Any kind of crunching on large data sets has I/O bottlenecks as one of its main issues. When you're crunching on a terabyte of data, pretty much the most important thing is your precise strategy for handling that terabyte of data. I'll agree the asm can be interesting still there in some cases, though, if you think of memory-bandwidth-and-latency issues as part of I/O. T…

> There are definitely scientific simulations where compute throughput is the only real issue, but I think of them as a bit different kind of setting than big-data processing (stuff like solving complex sets of equations, which has low I/O but high computational requirements).

^^ This is the use case for Julia.

Re: Why I'm Betting On Julia

#103

Post by wirrbel »

smellelderberry wrote: post #56
Pxtl wrote: post #50

Earlier quoted context omitted.

To be fair, there's also Python+NumPy and R in that space, not just Matlab. Besides the "tinker with LLVM" thing, what does Julia offer that Python (or Cython for speed)+NumPy does not?

Julia has a community that doesn't feel threatened that their language is waning in popularity in some fields, and therefore doesn't feel the need to defend it every chance they get.

No need to make this personal. It was the original blog article that concentrated on the negative things and did not do a whole lot at explaining Julia's benefits.

I really love Scipy and friends and I also think Julia is a promising system.

Re: Why I'm Betting On Julia

#104

Post by tomrod »

astrieanna wrote: post #49

The author and I like Julia for nearly opposite reasons. (I write Julia for the language geek reasons. The power of homoiconicity is amazing for writing static analysis in the language you're analyzing.) It's really cool that Julia can appeal to people with nearly opposing priorities tho. :) I'm looking forward to giving the workshop at UChicago. It'll be my third time presenting an Intro to Julia workshop.

Will you be webcasting?

Re: Why I'm Betting On Julia

#105

Post by astrieanna »

exDM69 wrote: post #93
shele wrote: 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 s…

I think it's more like Julia is what happens when "language geeks"/experienced programmers write a language that's for technical computing, with a deep understanding of their problem domain and empathy for their users.

Strings in Julia are meant to be addressed in for loops; they index by byte not character because it's slow to index by character once you include Unicode. Julia trys, in general, to give you control over low-level things rather than hiding them with magic.

I like Julia because it's homoiconic, because of it's type system, because multiple dispatch is fun and new, and because it's just plain fun to write. I do static analysis, not math/science.

Re: Why I'm Betting On Julia

#106

Post by lightcatcher »

tieTYT wrote: post #80
untog wrote: post #11

Earlier quoted context omitted.

Seems like that's exactly what he doesn't care about. If you're prototyping or writing a lot of one off operations (for data analysis, maybe) then maintainability is less important.

IME, you only know that with hindsight. I have made one off programs I never needed to look at again. I've also made what I thought were one off programs that I needed to maintain for a while. Even in a prototype, you may need to rework a particular piece of code multiple times before it works correctly. Even with a prototype, you may need to use it as a reference for your official version. Even with a prototype, you…

> What if it isn't fast enough on your first attempt? Won't you wish your code was maintainable so you could change it to be faster?

From my experience, this isn't the case at all. A lot of the time my first attempt is in Python. The first attempt is really more of a prototype or a proof of concept. If the code works and I want to productize it, the code needs to be sped up. I have (at least) 2 choices: (1) make the Python code as fast as possible or (2) rewrite the whole thing in C/CUDA. If I take option 1, performance gains will be marginal and I still probably won't be happy with the performance of the software. Option 2 might take a bit longer, but at least I'll get something performant out. As I'm just throwing out and rewriting the first attempt, I don't actually care at all if it was maintainable code. I don't even care if the ideas in it were well explained/commented, because they're all my ideas and they're still fresh in my mind and I'm just going to rewrite the code and then document/clean up the fast version.

The appeal of Julia is that I no longer have to do this rewrite to make my code fast. Furthermore, if I don't have to do this rewrite, it is actually in my interest to make my first version of the code be maintainable and well documented.

Re: Why I'm Betting On Julia

#107

Post by jjoonathan »

digikata wrote: post #95
jjoonathan wrote: post #53

Earlier quoted context omitted.

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).

I've heard many very smart people (professors, leaders of large HPC efforts, "language geeks") express the same sentiment over the years. Unfortunately, it's a btch of a problem, as attested to by the veritable graveyard of half-baked solutions out there. Apple's "Bridge Support" is the closest thing I've seen to success (haven't worked with MS's CIL) and it leaves much to be desired.

I'm not sure there is any way around the impedance mismatches between languages. They're all slightly different for a reason. Perhaps clean C APIs are the best we can hope for.

Re: Why I'm Betting On Julia

#108

Post by dantiberian »

nbouscal wrote: post #81
candybar wrote: post #71

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…

I'm glad I'm not the only one. I couldn't make it past the first paragraph. He says he doesn't care for safety and type systems, and then says what he cares about is making it work and making it fast, both of which are significantly aided by safety and type systems.

All he's saying is he doesn't care about the features, just what they let him do with them. Type safety in and of itself isn't interesting to the author but he appreciates it's benefits.

Re: Why I'm Betting On Julia

#109

Post by jordigh »

wirrbel wrote: post #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 develo…

> 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

Nah, we have no shortage of contributors:

http://hg.savannah.gnu.org/hgweb/octave/

http://hg.savannah.gnu.org/hgweb/octave/file/052cc933aea6/do...

Re: Why I'm Betting On Julia

#110

Post by dnautics »

kevinalexbrown wrote: post #48

When out with friends recently, one of them mentioned how awesome Julia is. I was surprised to hear someone talk about it, even from another person in science. She turned and gushed about how awesome it was, how supportive the community was, even though she was "not really someone who likes programming." And she liked it so much she was telling her friends about it at a bar! If you make a programming language that pe…

I had the opposite response, I played around with julia and found myself so frustrated I went back to octave. However, it was at an early stage of development and I bet there were a ton of bugs still around. I'll have to give it another shot.
Post reply on HN