What I learned using Julia to solve the first 50 Project Euler problems

I’m a 24-year veteran of Python programming, and during that time I’ve gotten really comfortable with the language. I first looked seriously at Julia 4 years ago; to learn Julia better, I rewrote much of the core of PyQuante in Julia. I haven’t really picked up the language since then, because I’m a manager now and don’t do much of any kind of programming anymore. But I was increasingly impressed with what I was seeing in the Julia world, and I decided to learn the language a little better over my spring break stay-cation.

I decided to re-solve the first 50 Project Euler problems. It has been a while since I’ve done any of these (2008, am I really that old?), so in a way it was like starting from scratch, although I had the answer to the problems at the bottom of each problem. It was a great experience, and I thought I would write up what I learned

Speed matters

I’ve made the argument for years that the slow speed of python doesn’t matter, because I could always use numpy or profile the code and write bottlenecks in C. But it’s liberating to have a language that’s fast through and through. When I solved the Project Euler problems in Python, I would normally write a simple version that worked for small cases, but had to figure out a smarter way to code the problem that work work for large sizes. In Julia the simple version typically worked for the small and large cases.

The intentionality shows

When I first looked at Julia 4 years ago, what I liked the most was that it learned from and built on Python’s successes and failures, so that in many ways it felt like a step forward. This was largely confirmed in this exploration, but what I see most now is that Julia doesn’t simply build on Python, it was an attempt to rebuild a language from the start with a set of deliberate choices that are often very different from those made by Python. These choices often go again my 24-years-of-Python-generated intuition, but I appreciate that there’s generally a good reason for why the different choice was made.

These are my people

Python was a small community when I started with it, and it’s been gratifying to see something I love get so popular. But the things I care about (nerdy scientific computing) are now only a small part of the Python community. In contrast, the Julia community feels like my people in a way that Python doesn’t anymore.

After my first foray into Julia, I remember thinking that if I was starting from scratch, I would learn Julia instead of Python, but it was hard to give up the intuition I had developed for the language. After this experiment, the strength, interests, and energy of the Julia community makes me want to hang with them (for the admittedly small amount of time I think about programming now).

Pluto has real advantages over Jupyter

I love Jupyter, but I really enjoyed Pluto: it’s ligher weight and starts up faster, and can take advantage of a local environment more easily. I had trouble at first breaking myself of the bad habit of using the same variable multiple times in a problem. But it got easier with time, and I came to appreciate the reactive nature of the notebooks.

The point I want to make isn’t that “Pluto is great, so one should use Julia”. The point is that Julia is a flexible, powerful language with passionate adherents that enabled something as cool as Pluto to be written in far less time than it took to write Jupyter. That’s amazing and personally exciting to me. I want to see what this community comes up with next.

To be fair, however, my brain still works more like Jupyter than Pluto. Old habits are hard to break.

I had the hang of it after ~20 problems

I’m comfortable enough with Python that I can pretty much just type out code. I got 75% of the way there with Julia after only ~20 problems. I still get tripped up with the local scope, I still find myself typing something.split(), and why, oh why, can’t I just cast a string to an int with int(“something”) (see the above point on intentionality)? But on the whole, I got comfortable with the differences of the language after only 20 problems, and I tore through problems 20-50 in very little time.

Conclusions

One of the things I’ve learned from 5 years of management is that even though I don’t need to program in my day to day job, I’m happier when I keep my hand in a few programming projects. The speed, design, and energy of Julia make it a really compelling choice for those projects, and the community is wonderful. Thank you all.

99 Likes

Congrats on solving 50 Project Euler problems!! :grin:

I just started working through them yesterday with Rust (like you, to learn the language) and I don’t think I’m going to last much longer. A few of the ones I’ve solved so far could have been done as one-liners in Julia so writing them in Rust just feels like an insane masochistic exercise.

Rust is an awesome language but it obviously doesn’t come close to Julia for numerical computing right now. I really can’t imagine being in a situation in which I have to re-write some code that’s heavy on numerical computations in a low-level language like C (or Rust) in order to achieve acceptable performance. It wouldn’t be long before I’d quit my job and go to culinary school.

18 Likes

It’s really difficult to go back to R or Python after using Julia to solve the problem of Project Euler!

There are so many cool things I can do in Julia like fast array processing without having to touch numpy and also being able to use awesome macros like @memoize (which is available in some form in Python and R; but Julia’s one the best!

Dynamic programming puzzles are just a breeze now with @memoize.

Even being able to easily define things like CircularArrays or other weird types of arrays is also amazing.

Also Primes.jl and Combinatorics.jl are so great

3 Likes