10 ms·

Julia is everything python could have been, and much more. I'm stuck with python right now as a lot of people in the data science/ML community are, but it's bec

by mruts 7y ago

Julia is everything python could have been, and much more. I'm stuck with python right now as a lot of people in the data science/ML community are, but it's becoming increasingly viable to use Julia for "real" work. The Python-Julia interop story is pretty strong as well, which allows you to (somewhat) easily convert pandas/pytorch/sklearn code into Julia using Python wrappers. Julia has some unconventional things in it but they are all growing on me: 1. Indices by default start with 1. This honestly makes a ton of sense and off by one errors are less likely to happen. You have nice symmetry between the length of a collection and the last element, and in general just have to do less "+ 1" or "- 1" things in your code. 2. Native syntax for creation of matrices. Nicer and easier to use than ndarray in Python. 3. Easy one-line mathematical function definitions: f(x) = 2*x. Also being able to omit the multiplication sign (f(x) = 2x) is super nice and makes things more readable. 4. Real and powerful macros ala lisp. 5. Optional static typing. Sometimes when doing data science work static typing can get in your way (more so than for other kinds of programs), but it's useful to use most of the time. 6. A simple and easy to understand polymorphism system. Might not be structured enough for big programs, but more than suitable for Julia's niche. Really the only thing I don't like about the language is the begin/end block syntax, but I've mentioned that before on HN and don't need to get into it again.

kgwgk 7y ago
> Julia is everything python could have been The goals of Python were quite different from the goals of Julia.
- mruts 7y ago
  I’m not sure what Python’s goals are to be honest. It seems to me that the language is outclassed in every way by better, more consistent, more powerful, and more performant languages. Python programmers seem content implementing the same things over and over again. Like, for example, flattening a list/monad. List of things python doesn’t have but should: pattern matching, multi-line lambdas, more data structures (look at Scala for an example of what kind of data structures a standard library should provide), real threading, options, monads, futures, better performance, and more.
  - kgwgk 7y ago
    "In a 1999 report, Van Rossum highlighted the following as his goals for Python: It should be an easy and intuitive language, just as powerful as major competitors. It should be open source, so anyone can contribute to its development. Its code should be understandable as plain English. It should be suitable for everyday tasks, allowing for short development times." https://www.computerhistory.org/fellowawards/hall/guido-van-rossum/ https://www.computerhistory.org/fellowawards/hall/guido-van-... “The first sound bite I had for Python was, "Bridge the gap between the shell and C." So I never intended Python to be the primary language for programmers, although it has become the primary language for many Python users. It was intended to be a second language for people who were already experienced programmers, as some of the early design choices reflect.‘ https://www.artima.com/intv/pyscaleP.html https://www.artima.com/intv/pyscaleP.html
    - deleted 7y ago
      [deleted]
  - j88439h84 7y ago
    Interesting list, thanks. FWIW, my view on these.. - I agree about pattern matching, that'd be nice. - Multi-line lambdas haven't been important, but maybe I'm missing something. - The list of data structures in the stdlib doesn't matter to me, since the 200k libraries on PyPI make up for it, and since packaging is easy nowadays with Poetry, they are as good as built-in but they get more frequent fixes and improvements than would be possible for the stdlib. Maybe there are some good side-effects of having extra types built in, based on a community of people using these types? - Threading, I suppose, though Python isn't really the right language overall for that stuff anyway. - Options, and monads, yeah that'd be nice. - Futures are an idea whose time has come and gone IMO, but they're in asyncio anyway :\. - For performance, PyPy is quite fast for many use cases. Is there a language that has all these things built in and has a repl?
- superdimwit 7y ago
  In my opinion, it's an unfortunate accident that Python became popular for numerical / data-ey workloads. It's good for some things, but fast low-overhead loopy code is definitely not one of them!
  - j88439h84 7y ago
    CPython, yeah :\ I wish the pypy team had finished numpypy. Then fast numerical programs could be written in python instead of relying on all kinds of C extensions and stuff. Python would be great for numerics then.
j88439h84 7y ago
Does it have a type checker like mypy? Python's protocols (https://www.python.org/dev/peps/pep-0544/ https://www.python.org/dev/peps/pep-0544/) are "structured enough for large programs".
- mruts 7y ago
  Julia has static typing. I wouldn’t go that far and say Python is suitable for large programs. It’s clearly not. Working on a large python code base is hell.
  - j88439h84 7y ago
    Old Python, before mypy, attrs/dataclasses, etc., is a pain. Nowadays with modern tooling, it's terrific.
    - hsaliak 7y ago
      this. I find it hilarious that people keep comparing a python release from 2010 with something that was released in O(months). Modern python - mypy, attr/dataclasses has come a long way. Numba has also come a long way since it's initial release.
    - Jach 7y ago
      How much do you leverage the REPL when you're developing? In my experience with "old Python" (I've yet to update my resume with new Python) I developed in an incremental manner making heavy use of the REPL, I never had the pains I do in static languages without a REPL story. Your comment to me reads like "Nowadays with modern tooling [that lets me develop Python like Java developers develop Java], it's terrific." My day job is Java with a powerful IDE that is crucial for my productivity, but this is because I'm trapped in the "write a comet mass of code interacting with a solar mass of other code and lean on the compiler and IDE tools in addition to my reason to tell me it has a chance of working" way of developing rather than sending small chunks of code to a REPL, testing immediately, and building things up. If I had to (or only knew how to) develop old Python in the Java way I'd probably go mad too. TDD can almost sometimes substitute for a REPL in JavaLand, but it has its own flaws... (And yes modern Java now has something like a REPL, my work environment unfortunately hasn't updated to support it. Soon.)
kbd 7y ago
I can't believe I'm jumping into the inevitable 1-based indexing discussion, but I'm surprised to see you say that one-based indexing results in "less "+ 1" or "- 1" things in your code". Most arguments I've seen come out to "it's fine" (certainly) or "it's more comfortable for mathematicians" (which I can't speak to). Besides Dijkstra's classic paper[1] showing why 0-based indexing is superior, in practice I find myself grateful for 0-based indexing in Python because of how slices and things just work out without needing +1/-1. I'd like to understand. Could you give an example of when 1-based indexing works out better than 0-based? [1] http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF
- mruts 7y ago
  The classic example is getting the last element of an array. With 1-based indexing the length of the array is the index of the last element. It has a nice symmetry to it. Also I find it elegant that for 1-indexing that the start and end value for slices are both inclusive, instead of the first one being inclusive and the last being exclusive. Also, isn’t it just weird that the index of an element is one less than it’s “standard” index? Like if I take the first nth elements of a list, it would stand to reason that the nth element should be the last element, right? The reason for zero indexing is historical, related to pointer offsets. I don’t think anyone chose them to be easier for people. They just made them that way because it maps closer to how contiguous values in arrays are accessed. Also, with 1-indexing I can multiply numbers by arrays and get reasonable offsets. 3 x 1 is three, so I would get the third element of the list. But with 0-indexing, I have 0 x 3 which gives me the same element, clearly inconsistent. There are some good reasons for 0-indexing and I have been using it in every language for my entire career. The amount of code I’ve written in Julia is marginal compared to my 0-indexing experience, so I might be missing something. One nice this about 0-indexing is that I can slice a list in half with the same midpoint. For example a Python array with 10 elements: fst, snd = arr[0:5], arr[5:10] A little nicer than: fst, snd = arr[1:5], arr[6:10] Though you could have inclusive slices with 0-indexing, but it would be inconvenient and suffer from the same problem as 1-indexing.
  - kbd 7y ago
cshenton 7y ago
One reason I really like the 1 based indexing is that I can have a UInt index and 0 can act as a sentinel value. Really nice for writing things like vector embedded linked lists.

by mruts 7y ago

kgwgk 7y ago

> Julia is everything python could have been The goals of Python were quite different from the goals of Julia.

mruts 7y ago
I’m not sure what Python’s goals are to be honest. It seems to me that the language is outclassed in every way by better, more consistent, more powerful, and more performant languages. Python programmers seem content implementing the same things over and over again. Like, for example, flattening a list/monad. List of things python doesn’t have but should: pattern matching, multi-line lambdas, more data structures (look at Scala for an example of what kind of data structures a standard library should provide), real threading, options, monads, futures, better performance, and more.
- kgwgk 7y ago
  "In a 1999 report, Van Rossum highlighted the following as his goals for Python: It should be an easy and intuitive language, just as powerful as major competitors. It should be open source, so anyone can contribute to its development. Its code should be understandable as plain English. It should be suitable for everyday tasks, allowing for short development times." https://www.computerhistory.org/fellowawards/hall/guido-van-rossum/ https://www.computerhistory.org/fellowawards/hall/guido-van-... “The first sound bite I had for Python was, "Bridge the gap between the shell and C." So I never intended Python to be the primary language for programmers, although it has become the primary language for many Python users. It was intended to be a second language for people who were already experienced programmers, as some of the early design choices reflect.‘ https://www.artima.com/intv/pyscaleP.html https://www.artima.com/intv/pyscaleP.html
  - deleted 7y ago
    [deleted]
- j88439h84 7y ago
  Interesting list, thanks. FWIW, my view on these.. - I agree about pattern matching, that'd be nice. - Multi-line lambdas haven't been important, but maybe I'm missing something. - The list of data structures in the stdlib doesn't matter to me, since the 200k libraries on PyPI make up for it, and since packaging is easy nowadays with Poetry, they are as good as built-in but they get more frequent fixes and improvements than would be possible for the stdlib. Maybe there are some good side-effects of having extra types built in, based on a community of people using these types? - Threading, I suppose, though Python isn't really the right language overall for that stuff anyway. - Options, and monads, yeah that'd be nice. - Futures are an idea whose time has come and gone IMO, but they're in asyncio anyway :\. - For performance, PyPy is quite fast for many use cases. Is there a language that has all these things built in and has a repl?
superdimwit 7y ago
In my opinion, it's an unfortunate accident that Python became popular for numerical / data-ey workloads. It's good for some things, but fast low-overhead loopy code is definitely not one of them!
- j88439h84 7y ago
  CPython, yeah :\ I wish the pypy team had finished numpypy. Then fast numerical programs could be written in python instead of relying on all kinds of C extensions and stuff. Python would be great for numerics then.

j88439h84 7y ago

Does it have a type checker like mypy? Python's protocols (https://www.python.org/dev/peps/pep-0544/ https://www.python.org/dev/peps/pep-0544/) are "structured enough for large programs".

mruts 7y ago
Julia has static typing. I wouldn’t go that far and say Python is suitable for large programs. It’s clearly not. Working on a large python code base is hell.
- j88439h84 7y ago
  Old Python, before mypy, attrs/dataclasses, etc., is a pain. Nowadays with modern tooling, it's terrific.
  - hsaliak 7y ago
    this. I find it hilarious that people keep comparing a python release from 2010 with something that was released in O(months). Modern python - mypy, attr/dataclasses has come a long way. Numba has also come a long way since it's initial release.
  - Jach 7y ago
    How much do you leverage the REPL when you're developing? In my experience with "old Python" (I've yet to update my resume with new Python) I developed in an incremental manner making heavy use of the REPL, I never had the pains I do in static languages without a REPL story. Your comment to me reads like "Nowadays with modern tooling [that lets me develop Python like Java developers develop Java], it's terrific." My day job is Java with a powerful IDE that is crucial for my productivity, but this is because I'm trapped in the "write a comet mass of code interacting with a solar mass of other code and lean on the compiler and IDE tools in addition to my reason to tell me it has a chance of working" way of developing rather than sending small chunks of code to a REPL, testing immediately, and building things up. If I had to (or only knew how to) develop old Python in the Java way I'd probably go mad too. TDD can almost sometimes substitute for a REPL in JavaLand, but it has its own flaws... (And yes modern Java now has something like a REPL, my work environment unfortunately hasn't updated to support it. Soon.)

kbd 7y ago

I can't believe I'm jumping into the inevitable 1-based indexing discussion, but I'm surprised to see you say that one-based indexing results in "less "+ 1" or "- 1" things in your code". Most arguments I've seen come out to "it's fine" (certainly) or "it's more comfortable for mathematicians" (which I can't speak to). Besides Dijkstra's classic paper[1] showing why 0-based indexing is superior, in practice I find myself grateful for 0-based indexing in Python because of how slices and things just work out without needing +1/-1. I'd like to understand. Could you give an example of when 1-based indexing works out better than 0-based? [1] http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF

mruts 7y ago
The classic example is getting the last element of an array. With 1-based indexing the length of the array is the index of the last element. It has a nice symmetry to it. Also I find it elegant that for 1-indexing that the start and end value for slices are both inclusive, instead of the first one being inclusive and the last being exclusive. Also, isn’t it just weird that the index of an element is one less than it’s “standard” index? Like if I take the first nth elements of a list, it would stand to reason that the nth element should be the last element, right? The reason for zero indexing is historical, related to pointer offsets. I don’t think anyone chose them to be easier for people. They just made them that way because it maps closer to how contiguous values in arrays are accessed. Also, with 1-indexing I can multiply numbers by arrays and get reasonable offsets. 3 x 1 is three, so I would get the third element of the list. But with 0-indexing, I have 0 x 3 which gives me the same element, clearly inconsistent. There are some good reasons for 0-indexing and I have been using it in every language for my entire career. The amount of code I’ve written in Julia is marginal compared to my 0-indexing experience, so I might be missing something. One nice this about 0-indexing is that I can slice a list in half with the same midpoint. For example a Python array with 10 elements: fst, snd = arr[0:5], arr[5:10] A little nicer than: fst, snd = arr[1:5], arr[6:10] Though you could have inclusive slices with 0-indexing, but it would be inconvenient and suffer from the same problem as 1-indexing.
- kbd 7y ago

cshenton 7y ago

One reason I really like the 1 based indexing is that I can have a UInt index and 0 can act as a sentinel value. Really nice for writing things like vector embedded linked lists.