Some Insights from a Julia Developer • Hacker News Board

Re: Some Insights from a Julia Developer

#131

Post by omginternets » Sat, Oct 14, 2017, 8:27 PM UTC

vvanders wrote: post #79

ViralBShah wrote: post #71

Earlier quoted context omitted.

The point around Julia's performance is often in the context of mathematical computing. The two languages are designed for very different use cases. Julia is designed to make it extremely easy to write high performance mathematical programs with ease. Rust is designed to make it easy to do systems programming. Both are high performance for the things they are designed to do. Just like I wouldn't do systems programmin…

Sure but mathematical problems don't exist in isolation. I used to do a ton of 3D graphics work with matrices, vectors, etc. We definitely couldn't use something that didn't have the right support for data layout and good runtime semantics. C/Rust/C++ fit that very well so I wanted to understand how similar claims were made for a GC'd language. C# for instance can work with value types and was wondering is Julia has…

In the case of research, data-science and -- generally speaking -- "scientific computing", mathematical problems pretty much do exist in isolation.

This is the niche that Julia wants to occupy.

Re: Some Insights from a Julia Developer

#132

Post by omginternets » Sat, Oct 14, 2017, 8:30 PM UTC

SolarNet wrote: post #108

Bromskloss wrote: post #98

Earlier quoted context omitted.

It's not just something particular I need it for; it's everything.

If you read the OP again carefully, you'll see that you can use offset arrays for every array you make and suffer no performance penalty, because the offset is compiled away. And the development overhead is a single library import call; I replace core language data-structures all the time in any language for features I want, this is no different.

Yeeesh, that sounds like a maintenance nightmare...

Re: Some Insights from a Julia Developer

#133

Post by StefanKarpinski » Sat, Oct 14, 2017, 8:41 PM UTC

throwaway7645 wrote: post #130

StefanKarpinski wrote: post #126

Earlier quoted context omitted.

The JuMP paper [1] compares JuMP with all the major commercial and open source options in this area, including Pyomo. Pyomo is orders of magnitude slower than JuMP and doesn't scale as well so the comparison gets worse as problems get larger. (Pyomo had the worst performance of all the systems compared.) JuMP is the only open source option that has performance like commercial systems. Throw in JuMP's improved express…

Not sure how much performance matters here. You're just farming it off to CPLEX or Gurobi anyway. If performance really matters, you'll do this part in C++ anyway.

Unless you're solving toy problems, it matters quite a bit. In mathematical optimization, constructing the problem tends to be just as expensive as solving the problem is – sometimes more so. The existence of expensive commercial systems like AMPL and GAMS that only exist to express optimization problems demonstrates that this is a non-trivial issue that people are willing to pay money for. Using C++ APIs to solvers is extremely painful, inflexible, error-prone, and completely locks you into a specific solver.

Re: Some Insights from a Julia Developer

#134

Post by throwaway543219 » Sat, Oct 14, 2017, 8:50 PM UTC

StefanKarpinski wrote: post #126

throwaway7645 wrote: post #84

Earlier quoted context omitted.

Python's PULP & Pyomo are pretty similar to JUMP.

The JuMP paper [1] compares JuMP with all the major commercial and open source options in this area, including Pyomo. Pyomo is orders of magnitude slower than JuMP and doesn't scale as well so the comparison gets worse as problems get larger. (Pyomo had the worst performance of all the systems compared.) JuMP is the only open source option that has performance like commercial systems. Throw in JuMP's improved express…

Can you share an example of calling JuMP directly via pyjulia? I was under the impression that Julia macros are not currently callable from Python via pyjulia.

Re: Some Insights from a Julia Developer

#135

Post by vvanders » Sat, Oct 14, 2017, 8:54 PM UTC

StefanKarpinski wrote: post #129

vvanders wrote: post #124

Earlier quoted context omitted.

Uf, I really don't like intermixing mutability with allocation location. Those seem like two completely separate concerns. One thing that was really common for us to do was to instance a weighted graph(something like this[1]) per-actor. This means that you might have 10-300 floating point values in a block indexed by the node they interact with. It was really common to see one, maybe two values change on a per-frame…

> I really don't like intermixing mutability with allocation location. Those seem like two completely separate concerns. They're not. The semantics of value types and reference types are different in the presence of mutation. So if you want uniform object semantics in a language, then objects that can be implemented as values must be immutable. There are many languages that have kept these independent and bifurcated…

> They're not. The semantics of value types and reference types are different in the presence of mutation.

I think C#'s overloaded term for "value-types" may have caused you to misinterpret the above. Let me be more clear, if a value lives on the stack or the heap is completely separable from if it is mutable or not, that's my objection.

> ... just as well by modifying and replacing an immutable value in a mutable cell

In terms of "correctness", sure. In terms of performance see my 300+ float block example above. I shouldn't have to copy, modify, copy when I can just mutate in-place(and be explicit about that rather than relying on language semantics).

Also I can seem to find any mention in the docs about Ref's semantics aside from a passing mention in the FFI section.

Re: Some Insights from a Julia Developer

#136

Post by fasquoika » Sat, Oct 14, 2017, 8:54 PM UTC

Bromskloss wrote: post #54

fasquoika wrote: post #40

Whenever I see Julia mentioned, I like to link to this blog post by Graydon Hoare (creator of Rust). https://graydon2.dreamwidth.org/189377.html

What would you say is the takeaway point for this discussion?

This is a bit broader a point than the original post of "why you should use Julia", but bear with me. Basically, most languages (and even more generally, most tools) assume that you'll have external ways of dealing with their limitations. For example, we use slow but productive languages in conjunction with fast but tedious languages. Or we have a DSL for testing. Or we have a 3rd-party package manager. The assumption that these external tools will be there is generally true, plus it makes the language designer's job easier, so it's generally a no-brainer for them to make it. However, this pushes the complexity onto the system and the user, and creates redundancy.

There have been some attempts to forego this assumption and make a language that can do everything you need. This has led to the creation of Lisp, Forth, and Smalltalk, among others. (If you've ever wondered about the fanaticism generally associated with these languages, this is a major part of it.) Julia is attempting to be such a language, and in my opinion does a pretty good job of it.

Re: Some Insights from a Julia Developer

#137

Post by tomsthumb » Sat, Oct 14, 2017, 8:56 PM UTC

RivieraKid wrote: post #91

I really like Julia overall but I'm undecided whether it's good as a general purpose language. Right now I'm working on a few-thousands-lines-of-code project and sometimes wish Julia was more like Swift: - Writing code with Nullables is cumbersome and verbose compared to Swift. - The object.method() notation is sometimes more readable, especially in more complex expression. Plus, in an IDE it works well with completi…

My company decided to used Julia as a general purpose language for a number of projects around 2.5-1.5 years ago (I’ve been there 18 months). I firmly believe this choice had an opportunity cost somewhere in the 1-2M $ range for a sub 25 person company. The number of bugs in the language, which had no doubt since improved, and the lack of libraries, which leads to serious NIH (b/c really it’s just NI yet) was costly, and frankly dangerous in the context of security, and then generally with regards to reproducibility. At one point we had a tool which leaned heavily on macros and required a version of the language which no one no longer had on heir machine and had no download links on the internet anywhere. Luckily they are consistent in their version uploads and altering the download address to have that version happened to line up with what’s in their server, but running a company in something like that is tenuous at best.

Re: Some Insights from a Julia Developer

#138

Post by pygy_ » Sat, Oct 14, 2017, 8:57 PM UTC

conistonwater wrote: post #107

ChrisRackauckas wrote: post #46

Earlier quoted context omitted.

@attractivechaos I don't know how to reply to your last reply, so I'll do it here. 1:length(A) is bad because it's using a standard construction for intervals of numbers, but using it for indices. We don't want to get rid of it because 1:5 or 0:0.2:1 is something that is very common and necessary, but I don't see how to tell one that they should instead use eachindex(A) except through proper docs. 1:length(A) is so c…

You can click on the timestamp, and there will be a reply link there. I think reply links are hidden for a little bit of time after posting, but I'm not sure why.

This is an anti-flame war feature, designed to let people cool off before replying (fast paced discussions were often contentious before that was introduced).

Re: Some Insights from a Julia Developer

#139

Post by vvanders » Sat, Oct 14, 2017, 9:08 PM UTC

omginternets wrote: post #131

vvanders wrote: post #79

Earlier quoted context omitted.

Sure but mathematical problems don't exist in isolation. I used to do a ton of 3D graphics work with matrices, vectors, etc. We definitely couldn't use something that didn't have the right support for data layout and good runtime semantics. C/Rust/C++ fit that very well so I wanted to understand how similar claims were made for a GC'd language. C# for instance can work with value types and was wondering is Julia has…

In the case of research, data-science and -- generally speaking -- "scientific computing", mathematical problems pretty much do exist in isolation. This is the niche that Julia wants to occupy.

If that were the case I wouldn't have an adjacent subthread telling me that they are pretty much the same ;).

To be clear, I have no beef with Julia, I'm sure it's a fantastic language. I take issue with people thinking they can get the same level of performance without explicitly controlling their memory access patterns/allocations.

98% of developers will never need it in their careers but when you do there is no substitute.

Re: Some Insights from a Julia Developer

#140

Post by attractivechaos » Sat, Oct 14, 2017, 9:31 PM UTC

pygy_ wrote: post #138

conistonwater wrote: post #107

Earlier quoted context omitted.

You can click on the timestamp, and there will be a reply link there. I think reply links are hidden for a little bit of time after posting, but I'm not sure why.

This is an anti-flame war feature, designed to let people cool off before replying (fast paced discussions were often contentious before that was introduced).

I guess so. This is a well thought feature. I like it.