Live data from Hacker News

Why I'm Betting On Julia

evanmiller.org

21–30 of 258 posts

Re: Why I'm Betting On Julia

#21
post #4

This sounds like premature-optimization to me. Maybe it's just me, but in the apps I write in dynamic languages, the bottleneck is rarely in the language. It's usually in some IO. EDIT: some sentence in the article gave me the impression he was using this for non-math-heavy stuff which is why I said this

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

Re: Why I'm Betting On Julia

#22
post #3

> my two concerns are 1) making it work and 2) making it fast. What about maintainability? "Code as if the next guy to maintain your code is a homicidal maniac who knows where you live." -Kathy Sierra and Bert Bates In my experience, making something work and making it (relatively) faster is easy. Making it easy to read is hard.

Some people build software as a product, for example SaaS companies, software vendors, or enterprise systems programmers. Then some build software to automate difficult tasks or to interact with data. I think the first group cares deeply (or at least should) about maintainability, the second group just wants it to work and work fast. If it's easy to update and fix later that's a bonus but not the main point. I fall into the first class of developer but I can understand the seconds point of view.

Re: Why I'm Betting On Julia

#23

I've tried Julia out a few times and been very impressed. From what I've seen it really does a great job of bridging the gap between easy-to-use and high-performance. It kind of seems like D in that way. I can definitely see lots of situations where a language like this is desirable. I'm in Chicago (and a U of C grad!). I might come to the meetup if I can.

I'm also in Chicago and probably going to the meetup. I haven't tried Julia, but I'd be interested in trying it with the help of experts.

Re: Why I'm Betting On Julia

#25
post #3

> my two concerns are 1) making it work and 2) making it fast. What about maintainability? "Code as if the next guy to maintain your code is a homicidal maniac who knows where you live." -Kathy Sierra and Bert Bates In my experience, making something work and making it (relatively) faster is easy. Making it easy to read is hard.

Some people build software as a product, for example SaaS companies, software vendors, or enterprise systems programmers. Then some build software to automate difficult tasks or to interact with data. I think the first group cares deeply (or at least should) about maintainability, the second group just wants it to work and work fast. If it's easy to update and fix later that's a bonus but not the main point. I fall i…

Also a lot of scientific computing things are very much it works or it doesn't, and once it does it is a reification of some fundamental mathematical algorithm: a black box that should never need to be opened again.

Re: Why I'm Betting On Julia

#26
post #15
post #9

Earlier quoted context omitted.

This is a confusing rebuttal, because cars have an aerodynamic design primarily for performance reasons, and Evan is very clear in this article that his primary concern is performance. I think you've misread him.

And yet he doesn't care about type systems, which are largely implemented to help with optimization, you see.

That's arguable - I hear more people talking about how types reduce bugs in code than how it improves performance. Besides, that's one of the three examples he mentioned, and the the other two are not features involved with said optimisation.

Re: Why I'm Betting On Julia

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

Re: Why I'm Betting On Julia

#28
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…

But Node.js does glue together things written in C (by backend engineers maybe) and then used in node with javascript (by frontend engineers like you said).

Re: Why I'm Betting On Julia

#29
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…

not to mention the node package manager, ability to host web servers in couple lines of code, and nice implementation of single threaded pump pattern making it a very scalable platform. seems quite ingenious to me.

Re: Why I'm Betting On Julia

#30
post #18
post #8

> but it's poised to do for technical computing what Node.js is doing for web development I stopped right there. 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.

> 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.
Post reply on HN