Possible Python rival? Programming language Julia is winning over developers | Hacker News Reader

Possible Python rival? Programming language Julia is winning over developers

zdnet.com

32 pointsjoeyespo24 comments

Open articleView on HN

I'll just leave this here:

> Conventionally, Julia's arrays are indexed starting at 1

https://www.google.com/search?q=arrays%20start%20at%201&tbm=...

The default is 1, but...

> Julia supports arrays with arbitrary indices.

https://docs.julialang.org/en/latest/devdocs/offset-arrays/

I personally haven't had any problem with 1-indexing when I used to program a lot in MATLAB. Maybe that's because I first learned to program using QuickBasic, which has 1-indexing. I don't understand the passion for 0-indexing (I know the arguments).

Ouch, I didn't understand one bit of that document!

From that document:

   This code implicitly assumes that vectors are indexed
   from 1; if dest starts at a different index than src,
   there is a chance that this code would trigger a
   segfault. (If you do get segfaults, to help locate the
   cause try running julia with the option --check-bounds=yes.)

So it comes with a tradeoff, namely that if someone else chose different bounds on an array other than [1..n] and you try to access it the standard way, you'll get a segfault.

This would scare me away from using anything other than the default indexing on an array in Julia.

I hadn't seen these cartoons before. I had a good laugh :)

More seriously: there are very limited cases where indexing explicitly into an array using literals is The Right Thing to do. It's almost always better to use `map(fn, xs)`, `foreach(fn, xs)`, `for x in xs; fn(x); end`, ... .

If you really wanted to, you can even do:

    for i in firstindex(xs):lastindex(xs)
        x = xs[i]
    end

Some computer science textbooks use array indexes starting at one

Not that I particularly care to start yet another meaningless bikeshedding argument about 0 vs 1 indexing but... I think that a proper high level language should have arrays that start at 1.

It's only because of C and many programmers' weird tendency to take to heart statements from authority (Dijkstra) without any criticism that the 0-index meme is so popular now. 0-index is useful because it makes pointer arithmetic useful while pointer arithmetic is not often used in high level languages. 0-index is for offsets not counting. Vast majority of people use 1-index for counting. People who say everyone should use 0-index for counting sound really really silly to me (and frankly the vast majority of people; it's only because this meme is so popular in the programming world that they can somewhat get away with making this statement).

Dijkstra gave pretty concise justification for 0-indexing, so I wouldn't reduce it down to "authority" for why people use it. While I'm personally comfortable hopping back and forth between conventions, is there any deeper justification for using 1-indexing? "Vast majority of people" seems like the same meme you're rejecting for 0-base.

I wouldn't say there's any deeper justification for 1-based indexing but neither is there for 0-based indexing. But convention is a pretty good reason for 1-based indexing. Regarding Dijkstra, I don't buy the specific argument he originally made about sequences much less the generalized argument that has become a meme now.

His main argument is that a <= i < b (everything integers) is less "ugly" because b-a is the length of the sequence and a <= i < a is an empty sequence. And because you must use the above convention, 0 <= i < N is "nicer" than 1<= i < N+1. I don't buy his a <= i < b premise (b-a+1 is not exactly hard to write and similarly a <= i <= a-1 for an empty sequence is not impossible to write).

There is nothing wrong with a <= i <= b. It is inclusive on both sides which is much less confusing than inclusive on one side and exclusive on the other (just look at python's ranges for how it can get confusing; range(5) means 0,1,2,3,4 ...seriously? Where did my 5 go? And range(a,b) meaning a <= i < b is so much more confusing than inclusive ranges). When you use inclusive ranges, you can actually see the numbers that are on both sides of the sequence. So, if we use this convention, then 1 <= i <= N is much "nicer" than 0 <= i <= N-1.

Aside from my argument about inclusive ranges, the fact is that both inclusive ranges and 1-indexing have thousands of years of convention behind it's back. This should not be discounted since math is a language, language is for communication, and communication depends on conventions.

Unless Julia can gather the uncountable amount of libraries and frameworks (and keeping the same quality) it’s doomed to be just another “me too” language.

It’s not about the language itself, but what can you actually make with it and with its ecosystem.

This. Interested in hearing Julia acolytes describe some one thing that is way easier in Julia than Python. The scope and combined power of examples like that will determine whether and where it's worth being away from python ecosystem.

The language is built from the ground up as a fast numerical language. Take LLVM as a JIT and make the most dynamical lispy fast thing on top. It runs circles around Python in terms of fast flexible computing.

That said, not enough for me to switch.

I've heard some notes like that, but with nice wrappers for vectorised operations like numpy and TensorFlow, I don't think python world has been feeling numerical as a pain point (evidently you feel similarly enough not to switch). I wonder if Julia folks have some examples where relative extra speed really moved the needle for some application.

When writing differential equation solvers, a lot of cases are far too small for vectorization to help and lots of loops are required. Especially adaptive stochastic differential equation solvers which require using data structures (priority queues, stacks) directly in the middle of tight loops, and you have to control heap-allocations to keep it fast. I couldn't find a way how to do this in MATLAB or Python well (I mean, heap-allocated objects tend to ruin this) but Julia was a great fit.

By this logic, no new language would ever take off.

> It’s not about the language itself

I would actually argue that it’s completely about the language itself. There will be a certain number of people that recognize the value of the new language. Those people will start laying the groundwork for all the libraries that they need. For those people, the early zealots, they build out the minimal set of libraries.

Then you have the next group of people come along, less fanatical, but really like the language, and decide to make bets on it, where they fill in the gaps that they encounter.

In the next phase you now have the basics needed for the language, a growing number of users, and the libraries start flowing in. All of this would only happen because people really like the language itself.

> it’s doomed to be just another “me too” language.

I have no idea where Julia is, I’ve never used it, but I dislike this attitude, because it doesn’t allow for innovation. Julia certainly seems to be gaining users, just based on how much I keep hearing about it.

> By this logic, no new language would ever take off.

And in many cases they haven't. Javascript competitors seem like a prime example of this as there are too many javascript libraries that make your life easier, and would have to be ported to a new language.

What makes a language successful primarily is how easy it is to do productive things with it -- and that means easily using existing code (from some other language).

JavaScript has been a victim of its own success in many ways. It's so popular that other languages just transpile to js. In the end it runs js, but it doesn't matter much.

OTOH good libraries have bindings for the source language (eg react has wrappers in scalajs, clojurescript, etc)

Javascript is clearly a special case because of browser dependency on JS. You can't apply most statements about JS's popularity to other languages.

On the other hand, somebody has to write those libraries, and each "missing" library is an opportunity for a new project.

One thing I like about less popular languages is that it's often easier to get involved in the community, easier to contribute to projects, and more likely other people will use the libraries I create.

I like Python, but it often feels like I'm just plugging together pre-existing libraries for everything. Good for getting things done quickly, but less fun and less rewarding.

Julia core devs are aware that Julia does not exist in a vacuum. It is easy to wrap existing C, C++, Fortran, and Python libraries for use in Julia. Julia has such good performance and flexibility that it will not surprise me if the most important libraries get rewritten in Julia. Most people just glue libraries together most of the time (and that's perfectly fine!), but language improvements will mostly be seen by the people who write the libraries themselves.

See:

- https://docs.julialang.org/en/latest/manual/calling-c-and-fo...

- https://github.com/Keno/Cxx.jl

- https://github.com/JuliaPy/PyCall.jl

Would access to all the batteries of python, R, and C/C++ from a julia REPL suffice?

Absolutely. More and more now I am coming to the conclusion that it’s better to push into new problem domains with Python or R building on that ecosystem than it is to learn a new niche language for each thing. But Julia is so fast! They say. Well I reply, so is Numba on GPU and running my existing code on it is next to no effort! Writing C extensions to Python or R is easy too and I already know how to do it.

A language would need to be radically better for me to switch, not just incrementally.

Most of the good parts of python's scientific computing libraries are wrappers around fortran libraries.

Django + Julia = Djangulia

Reply on news.ycombinator.com