Some Insights from a Julia Developer • Hacker News Board

Re: Some Insights from a Julia Developer

#231

Post by jernfrost » Mon, Oct 16, 2017, 6:33 AM UTC

anon_342njlkesr wrote: post #214

jernfrost wrote: post #160

Earlier quoted context omitted.

I greatly prefer Julia syntax. `end` makes the code blocks stand out more easily than }. I find it easier to see the indentation at a glance than when just dealing with a single thin character. Also I like that Julia prefers shorts words over special characters. C/C++ use far too many special characters. That might run counter to my delight at unicode support. I think it is quite nice to be able to write mathematical…

Re unicode: When writing latex, you don't want to encounter unicode greek sigma. You want \sigma, as 6 7bit-ascii chars. Same in julia; sure, define a display mode that translates certain things into unicode for people like you, but keep compatibility with code-editors/people/tools who do not understand unicode. In short: I want to it to be possible to use a dumb text-editor, not an IDE/word-processor. (ok, the text…

LuaTex which is displacing Latex is doing just that, increasingly using unicode directly. I’ve never used a plain editor on my Mac which DIDN’T handle unicode. In fact I use a plain text editor to write julia code whith unicode symbols. Anyway it is a tiny portion of the code and the Julia public API never force you to use unocode. You can always chose a non-unicode variant of the API.

Not using UTF8 in this day and age is just begging for problems.

At least on my mac you got OS wide tools for working with unicode.

Re: Some Insights from a Julia Developer

#232

Post by dnautics » Mon, Oct 16, 2017, 8:00 AM UTC

Bromskloss wrote: post #188

dnautics wrote: post #187

Earlier quoted context omitted.

Enumeration should generally begin at 1. In common language, you don't say "this person won the 0th place trophy", you say "this person won the 1st place trophy". It's address offsetting that should begin at 0. C strongly encourages you to think of arrays as simply address+offset pointers, so it absolutely should start with 0.

> you don't say "this person won the 0th place trophy" I think it would make sense to say it. The reason I don't is that people around me would misunderstand me if I did. (Around some people, it works, though!)

Why not say someone won the -1th place trophy? Where does it start?

Re: Some Insights from a Julia Developer

#233

Post by ChrisRackauckas » Mon, Oct 16, 2017, 9:01 AM UTC

omginternets wrote: post #132

SolarNet wrote: post #108

Earlier quoted context omitted.

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

Why? You don't have to write a package any differently to make it work with arbitrary indices.

Re: Some Insights from a Julia Developer

#234

Post by ChrisRackauckas » Mon, Oct 16, 2017, 9:11 AM UTC

ChrisRackauckas wrote: post #182

bluescarni wrote: post #120

Earlier quoted context omitted.

From your list of "first-choice languages", C++ is conspicuously missing. That seems rather peculiar, as the type of genericity you are praising Julia for has been one of the core concepts of generic programming in C++ since basically the late nineties with the standardization of the STL (and it's become an increasingly emphasized part of the language throughout its evolution in the last 10 years or so, see C++11 and…

I learned C because of classes in MPI and I tried to go back to it after years of Python and MATLAB but the amount of boilerplate code and the workflow slowed me down too much. C++ is definitely a fine choice if you are a great programmer but I don't find it easy at all to prototype or maintain codebases in languages like that. YMMV

I would say though that if I didn't go the Julia route I would probably be using C++. Again, in the article I wrote that for package development, I see Julia as a more productive C++ as opposed to a faster Python. I'm using it in a way that is all based around generic algorithms that can statically compile well, so it's essentially C++ template magic but with a lot less code (no headers) and I can prototype separate implementations in the REPL as I go (in Juno, highlight and do Ctrl+enter and it replaces the function in the package with the new definition). I think the other clear choice in this space is actually D. But between Julia, C++, and D, I like Julia because I found it really easy to program things and have it work the first time.

Re: Some Insights from a Julia Developer

#235

Post by StefanKarpinski » Mon, Oct 16, 2017, 1:51 PM UTC

tavert wrote: post #230

throwaway7645 wrote: post #159

Earlier quoted context omitted.

Solver licenses are extremely expensive (~100k in production), so switching solvers isn't very common. Going to C++ helps a bit with I/O before it gets to the solver if you really need it, but a lot of people do just fine with things like AIMMS which is a proprietary high level modeling language similar in performance to Python. Maybe Julia + JUMP is nice if you want to remove I/O performance barriers, but don't want…

Stefan is one of the co-creators of the Julia language, not really an operations research person. He must have misread the results in the JuMP paper where Pyomo outperforms CVX and Yalmip on several problem classes.

You're right, I was looking at the lqcp results and misread the other results. Still, the main takeaway is that of the open source options for expressing OR problems, JuMP is the only one in the same class as the commercial tools. If you've got a problem where problem construction isn't hard, cool; often that's not the case.

Re: Some Insights from a Julia Developer

#236

Post by igouy » Mon, Oct 16, 2017, 4:39 PM UTC

bjourne wrote: post #211

ihnorton wrote: post #178

Earlier quoted context omitted.

Inclusion is by selection of the admin [1,2]. There are Julia implementations available for most of the benchmarks [3] so perhaps eventually they will be included. [1] https://alioth.debian.org/forum/message.php?msg_id=182495&gr... [2] http://benchmarksgame.alioth.debian.org/play.html#languagex [3] https://github.com/JuliaLang/julia/tree/master/test/perf/sho...

Interesting! Does that mean the Benchmarks Game is not open for new languages? The faq entry is kind of ambiguous.

It means -- "If you're interested in something not shown on the benchmarks game website then please take the program source code and the measurement scripts and publish your own measurements."

Like this guy did -- https://pybenchmarks.org/

Re: Some Insights from a Julia Developer

#237

Post by CyberDildonics » Tue, Oct 17, 2017, 1:58 PM UTC

xfer wrote: post #226

CyberDildonics wrote: post #210

Earlier quoted context omitted.

I don't see too many reasonable arguments that garbage collection is slower. Taking up more memory, having pauses and requiring the same amount of thought as modern C++ are all arguments I've heard, which is my experience with Julia (sans the pauses since I haven't done something interactive yet).

Requiring same amount of thought as modern C++ is not simply true, as soon as you start dealing with cyclic data structures/shared data(reference counting takes more memory and slower than a well implemented gc), that model breaks down. Pauses is indeed a problem, which then requires you to manually tune the gc to your settings.

That's not my experience and I have dealt with all of those things to a fairly heavy degree.

> reference counting takes more memory and slower than a well implemented gc

This is a ridiculous cliche at this point. It might be true if every memory allocation was reference counted, but in C++ (and julia) almost everything winds up on the stack. What doesn't wind of up on the stack is usually being dealt with using ownership and move semantics. The number of reference counted variables in my C++ programs is usually 0 unless they are being shared across threads. Not only that, but within a thread, move semantics means that the reference count doesn't need to be touched.

While there may be 'conventional wisdom' I have implemented non-trivial software in both C++11 and Julia, and optimizing memory allocations happens in both and Julia required more thought. Julia made data structures and general functions easier to write so it wasn't as if it was a net negative, but memory allocation wise I don't feel the garbage collector made things any easier.

Then on top of that you have the myth of the 'well implemented GC'. Java, C#, D, Go and Julia are all languages where this seems to be a constant struggle. After significant R+D some are there, but if you look at D and Julia, it is a constant user complaint.

As for cyclic data structures, I'm not sure why I would do that in the first place and I'm doubly unsure why I would do it with pointers and fragmented memory allocations.

Re: Some Insights from a Julia Developer

#238

Post by StefanKarpinski » Tue, Oct 17, 2017, 3:14 PM UTC

anon_342njlkesr wrote: post #215

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 had the same problem; my problem was not the giant number of reads, but rather that a naive replacement needs a read and has a dependency on the write-back; hence, a scatter where you modify immutable structures by replacing certain fields induces a stall on cache-miss. In my case, julia/llvm was smart enough to figure out that the read and write can be eliminated. Hence, the julia code that replaces an immutable w…

Right, so the way to address this is to provide guarantees that this kind of optimization /will/ occur and providing syntax for making writing "pseudo-mutating" code more convenient. There's a PR [1] for the latter, but it's been shelved while we focus on getting 1.0 out the door instead of adding new features. Optimization guarantees + convenient syntax provides everything you need without trashing the semantics of the language by bifurcating the type system into two incompatible kinds of values.

[1] https://github.com/JuliaLang/julia/pull/21912

Re: Some Insights from a Julia Developer

#239

Post by omginternets » Wed, Oct 18, 2017, 9:01 AM UTC

ChrisRackauckas wrote: post #233

omginternets wrote: post #132

Earlier quoted context omitted.

Yeeesh, that sounds like a maintenance nightmare...

Why? You don't have to write a package any differently to make it work with arbitrary indices.

Because it's inconsistent.

Re: Some Insights from a Julia Developer

#240

Post by barche » Wed, Oct 18, 2017, 8:56 PM UTC

Great article! Coming from C++, I agree Julia feels a lot like "C++ done right", i.e. where C++ forces you to jump through hoops with the verbose template syntax, Julia does generics by default. Also, it's great not having to wonder for every function argument declaration if you should add *, &, && or any of the const variants.