Live data from Hacker News

Giving up on Julia

zverovich.net

131–140 of 242 posts

Re: Giving up on Julia

#131
post #128
post #117

Earlier quoted context omitted.

In Dutch, ij and ÿ are interchangeable.

My Dutch professor in college actually wrote out the "ij", but the tail of the "i" connected with the "j", making it appear to be "ÿ". It kind of blew my mind the first time I saw him write it out haha

In cursive, it is often indistinguishable too.

Re: Giving up on Julia

#132

Earlier quoted context omitted.

Lua tables are more interesting than that. You can have an table that is indexed by any supported type. That means tables indexed by positive or negative integers, floating point values, references to other objects or other tables, true, false, strings, coroutines, and external memory references can all be indexes. You can also have a single table indexed by any combination of these.

Isn't that technically a hashtable and not an array?

In Lua the same data structure is used for both. The implementation optimizes the data structure like an array when you use a range of non-negative integers as indexes.

Re: Giving up on Julia

#133

Earlier quoted context omitted.

> I think part of this problem is the community, multiple people have reported having bad interactions with core language devs. I can only think of a couple of instance where I've heard anything like this. The first and most prominent is Dan Luu. I'm very sad about losing him from the community. I've met him a couple of times in person, I still read his blog and I very much respect him. I don't think any of us have t…

I remember plenty of cases I got simply from observing the Julia repo for a few months, I could list them if you like... But I've been told by Julia contributors before that discussing this on HN is not an appropriate place. So we can discuss it, where I start linking to public examples on HN, or you can ignore my opinion on a problematic community and we can not discuss it. As to the code standards, my problem isn't…

> I remember plenty of cases I got simply from observing the Julia repo for a few months, I could list them if you like... But I've been told by Julia contributors before that discussing this on HN is not an appropriate place. So we can discuss it, where I start linking to public examples on HN, or you can ignore my opinion and we can not discuss it.

I do think HN is not the right forum to link to individual comments and call out people for their behavior. Perfectly happy to discuss the technical issues though. If you would would still like to discuss, or at least bring such instances to my attention, please do feel free to send me an email.

> People who suggest refactoring large sections of Julia's expansive base library (1600 symbols? a problem that causes parts of the slow startup time and memory usage) into other libraries (which would improve batteries included, etc. features) are summarily ignored / shouted down / (predicated on my previous paragraph) banned.

There are several recent examples where people have suggested such things, e.g. They were neither ignored nor shouted down nor banned. https://github.com/JuliaLang/julia/issues/16357 https://github.com/JuliaLang/julia/pull/16070

> Important improvements to the language go in circles on JULEP tagged issues namely any large improvement that would require multiple people and lots of dev work seems to gain little traction unless a core dev just takes the time to do it; rather than a timeline to reach consensus and then design a plan for implementing it.

I don't understand what exactly the criticism is. At first I thought it was about, too much dicussion, but then it seemed to be about too little dev time, please do clarify.

> There was a push to increase test coverage and then a few months later commits plummeted the code coverage numbers and no one seemed to care.

I'm not really sure which instance you're referring to, but last time there was a major drop in coverage, it was investigated, found to be a bug in the instrumentation (which was fixed). I don't really think it's fair to say that people don't care. There's somewhat of a tooling problem here, since we can't run the coverage tests on travis, so we don't get them integrated in the GitHub UI, but people do look at them and add tests as appropriate.

> Sections of important code are uncommented, undocumented, and untested on purpose.

Yes, there are undocumented and uncommented sections in the code base, but I wouldn't say that they are so on purpose. I do admit to having added such hacks in the past (and not documented them because they were gonna go away soon after), because I needed them in outside packages, but people don't let me do that anymore ;).

> Unpredictable un-typed exceptions, namespaces/modules being hard to use for non-trivial designs, interfaces without any sort of type enhancement.

These are fair points, which I'm sure you've seen the issues about. The problem is the availability of developer time, not some sort of unwillingness to fix problems. Putting together the road map of what goes into each release and prioritizing are very hard, because there's just so much that could be worked on.

> setup a transparent community policy and actually follow it;

This is being discussed (as part of larger discussions around community governance) and as I mentioned will likely be a topic at JuliaCon.

Re: Giving up on Julia

#134

Earlier quoted context omitted.

> I think part of this problem is the community, multiple people have reported having bad interactions with core language devs. I can only think of a couple of instance where I've heard anything like this. The first and most prominent is Dan Luu. I'm very sad about losing him from the community. I've met him a couple of times in person, I still read his blog and I very much respect him. I don't think any of us have t…

I remember plenty of cases I got simply from observing the Julia repo for a few months, I could list them if you like... But I've been told by Julia contributors before that discussing this on HN is not an appropriate place. So we can discuss it, where I start linking to public examples on HN, or you can ignore my opinion on a problematic community and we can not discuss it. As to the code standards, my problem isn't…

[deleted]

Re: Giving up on Julia

#135
post #35
post #15

If you want to replace Matlab you should use Octave, julia is for making your next climate model, not for "hello world" ricing

I've found the Armadillo C++ library ( http://arma.sourceforge.net/ ) to be a better replacement, when concerned about speed.

IME eigen3 is even better (although the template-induced hellish compilation times are a huge pain).

Re: Giving up on Julia

#136

- One-based indexing setting aside whether zero- or one-based indexing is 'better'; R and MATLAB have one-based indexing, so the convention is likely familiar to many in the Julia target audience. still, as the OP says, (relatively) painless interoperability with C and C++ is an advertised Julia feature, both of which use zero-based index (although Fortran is one-based), and that mis-match is a definite obstacle to i…

It does look like support for arbitrarily based arrays (like Fortran 90) will be available in Julia v0.5 (thanks to Tim Holy's great work). Julia is very flexible, and the next thing is to allow row-major instead of just column-major arrays (something that I've heard is also being worked on, although I don't know if it will be ready for v0.5)

Re: Giving up on Julia

#137

Earlier quoted context omitted.

> I think part of this problem is the community, multiple people have reported having bad interactions with core language devs. I can only think of a couple of instance where I've heard anything like this. The first and most prominent is Dan Luu. I'm very sad about losing him from the community. I've met him a couple of times in person, I still read his blog and I very much respect him. I don't think any of us have t…

I remember plenty of cases I got simply from observing the Julia repo for a few months, I could list them if you like... But I've been told by Julia contributors before that discussing this on HN is not an appropriate place. So we can discuss it, where I start linking to public examples on HN, or you can ignore my opinion on a problematic community and we can not discuss it. As to the code standards, my problem isn't…

[deleted]

Re: Giving up on Julia

#138

Earlier quoted context omitted.

> I think part of this problem is the community, multiple people have reported having bad interactions with core language devs. I can only think of a couple of instance where I've heard anything like this. The first and most prominent is Dan Luu. I'm very sad about losing him from the community. I've met him a couple of times in person, I still read his blog and I very much respect him. I don't think any of us have t…

I remember plenty of cases I got simply from observing the Julia repo for a few months, I could list them if you like... But I've been told by Julia contributors before that discussing this on HN is not an appropriate place. So we can discuss it, where I start linking to public examples on HN, or you can ignore my opinion on a problematic community and we can not discuss it. As to the code standards, my problem isn't…

Also, I do thank you for taking the time to give feedback.

Re: Giving up on Julia

#139

Happy to address these points: - Startup performance/memory usage Yes, we are definitely very acutely aware of these. Julia is not currently optimized for frequently run short scripts. That's the price on pays for having to bring up the entire runtime system (initializing the compiler, RNG, external libraries etc). The good news is that there will be a solution to this soon, which is to statically compile your julia…

Keno - take a look at what I did in https://github.com/ScottPJones/StringUtils.jl (building on the backs of giants, such as Tom Breloff, Dahua Lin, and others, incorporating some code from Formatting.jl). It solves problems I've had both with string literals, formatting, and outputting funny Unicode characters (without having to use UTF-8 in my source code).

I really like your Cxx.jl, that does seem to answer the issue raised here (are there any good features in pybind11 though that aren't already in Cxx.jl? that might be a good source for ideas on how to improve Cxx.jl if not)

Re: Giving up on Julia

#140

Happy to address these points: - Startup performance/memory usage Yes, we are definitely very acutely aware of these. Julia is not currently optimized for frequently run short scripts. That's the price on pays for having to bring up the entire runtime system (initializing the compiler, RNG, external libraries etc). The good news is that there will be a solution to this soon, which is to statically compile your julia…

The thing about 1 based indexing is that it's a kind of in your face "this is different" decision from the point of view of a programmers of most popular languages. To be honest I wouldn't want to start investing my time into a language where people who proposed 1 based indexing are making design decisions. It's not that I think they are incompetent but it's clear they care way more about some different world than ab…

To be honest I wouldn't want to start investing my time into a language where people who proposed 1 based indexing are making design decisions.

Possibly because you're used to working with languages like C, C++, Java, Pascal, Javascript, Python, etc. But in the world of languages tied closely to scientific / mathematical programming (Matlab/Octave, R, etc.) 1-based indexing is the norm. If you'd "grown up" so to speak, in that world, you'd probably find 0-based indexing distasteful.

Post reply on HN