I have been building a blog using Next.js (for static content) with Pluto (for interactive and richer content, inspired from MIT Intro to Computation Thinking).
I think it's a great combination of richness and expressive content which brings the user along with the interactiveness.
Great idea. I was honestly pretty disappointed by how hard it was to put a blog post I wrote in Pluto onto my static website. I still really think Pluto needs a way to generate static markdown similar to jupyter and maybe create a button to "edit or run this notebook" as an image with a link to some javascript magic with the actual notebook embedded. I ended up having to use iframes which felt far from ideal[1] since the html output is a jumbled mess[2].
That is pretty cool, and I'll definitely be taking a look (I was actually looking for what Julia was doing in the notebook space just the other day). Also the course seems interesting as well.
But I feel compelled to at least remark on the fact that they call this "revolutionary", which is a bit much and cringe worthy. While it is indeed a nice package, just don't call it revolutionary, when this type of thing has been available either in part or whole in things like Mathematica, MATLAB, LabVIEW for years (decades really) and other notebooks have very nice features as well. It's just MIT can't do anything without a little hubris.
I've been building a GUI with Makie for a personal project and its pretty powerful. It removes virtually all boilerplate code, and lets you add widgets easily. It uses Observables to allow for automatic updates to data values, which can make life much easier. You just need to draw a graph once and you can update the Observable whenever you want - the graph will redraw the data instantly.
The only drawbacks I would say are the docs needing to be expanded more and more widgets to be included (such as a menu bar).
I feel that the time to migrate to Julia is now. The ecosystem is finally coming together and there doesn't seem to be breaking changes to the language anymore.
Plots is still a problem for me. Rust and Julia have a lot in common in this respect, but I will gladly take the advantages of their package management systems if it means a longer compilation time.
I don't see how it can while their "load a module" step involved compiling it from C++ source. Although I guess that doesn't explain why it is still so slow the subsequent times.
They have little in common. Gadfly is for statistical graphs, roughly in the style of ggplot. Makie is general purpose, roughly in the style of matplotlib, but (I believe) better designed, way faster (after excruciatingly slow compile), much easier to extend with custom functionality, and awesomely interactive. There is a ggplot/Gadfly-like library built on top of Makie called AlgebraOfGraphics (homage to GGplot).
I used Genie with PackageCompiler on AWS to host build a wedding website for some friends (features included personalized invites + custom photo uploads with filters directly to the bride and groom + live mini games during the wedding). The awesome part about this was that image processing in Julia was a joy to work with. And packaging and environment issues were non existent. I've spent A LOT of time dealing with those in Python, and having things almost always just work was really nice.
I had a few issues though,
0) I could not use the free tier in heroku because Julia + Genie would take too long to start up, and Heroku's free tier will kill the VM if you don't serve a response in 30 seconds. I was able to get it to work with PackageCompiler but even that was close when the VM booted up for the first time on Heroku. At the end I decided to use AWS instead.
1) None of my friends who wanted to contribute wanted to use Julia (they said if they were learning something new they'd prefer Go, Ruby or even just using C++).
2) Library support for Genie was just okay. Implementing Auth + Database support + dealing with cookies, sessions etc took waaayyy too long, when I just wanted to implement features for the website. I wanted to parse HTML from a custom calendar page and tried to use Gumbo, and it was slow and painful to work with. In the past when I did the same thing with Python, things just worked. Beautiful Soup 4 was SOOO much more productive for me than trying to do the same thing in Gumbo.
3) Development was SLOW. Julia + Genie takes forever to reload, even with live reload. And if you change one line in the HTML that you are about to generate, and you'll have to wait 30 or more seconds to see the update in a local developent environment. This is PAINFUL. Once the size of the application grows or you add dependencies, it takes longer. The error messages aren't too good either and don't get me started on the usability of language server in vim/neovim. The one other friend who actually downloaded Julia and installed every thing in order to contribute to the project instantly gave up on making any contributions just because of the development experience.
And, when I deployed it to AWS, even after using PackageCompiler I wasn't getting instant server responses (I'm assuming I did something wrong here though). The final binaries that I was deploying to AWS were also huge (hundreds of megabytes).
On reflection, if I had implemented the same project in Python, I would have completed this maybe 10 times faster (based on past experience), and run time would be been as fast too (except for the image processing piece). Using Python + Flask and using a subprocess to call Julia would have been a better approach to solving this problem, instead of what I choose to do. I had stretch goals for this project (more mini games) that I wasn't able to even attempt making, primarily because I was dealing with all the pain points of developing in Julia (I guess it was also my fault for trying to get all this done in a couple of weeks of my spare time).
I really like Julia as a language, but using it for anything other than scientific computing (more specifically using it as a general purpose programming language) seems to me as a recipe for pain at the moment. I would not recommend deploying production applications in Julia right now unless you HAVE to use it (because of some library that's only available in Julia) or your development team is willing to put in work to write libraries from scratch + deal with slow start up.
Maybe in a few years when tree shaking is implemented and more latency issues are resolved and language server gets significantly better, it'll be a competitive choice. Until then I'll be curiously watching from a distance :)
Very interesting post, thanks for sharing. Do you have a link to your project code? Your experience seems to be in line with this post I read recently: https://viralinstruction.com/posts/badjulia/
It's written by a Julia fan, so it's a very lucid and measured take on the not so great side of Julia.
I don't have a link to the project unfortunately, it was really haphazardly put together (personal access tokens, other people's identifying information etc, have been committed to the repo), and I don't have the time to clean it up. But everything I used in the project is publicly available, and you'll just have to spend some time searching for it in various docs.
I completely agree with Jakob's take in the piece you've shared btw. Personally, I don't think Jakob goes far enough.
I've used Julia professionally too, and worked with large code bases (a 10000 line Julia monorepo project that just keeps growing), and the lack of interfaces, the lack static type checking, the lack of error types, etc would all be show stoppers for me to consider Julia at the start of our project if I knew then what I know now. I've even tried to run static type checkers like JET.jl on our code base and it just keeps spinning or failing. Unfortunately it is a sunk cost for us at this point and we'll just have to use Julia, and deal with these pain points, and hope and pray the language gets better over time.
I can see some improvements such as minor latency improvements happening over time. But (in my opinion) I don't think language features like interfaces are likely to happen until Julia 2.0. In 2018, the core team had laid out priorities in a discourse post, and marked those as done last year (i.e. 2021).
In my opinion, there's a LOT more language features required to help tooling in the ecosystem improve. The fact that they marked this as done (which I just found out while typing this comment) and that there's no follow up priorities outline post (as far as I can find) is a little troubling.
I think a lot of people that pick Julia as their first language really like it, but I believe it is mainly because they haven't experienced something better to compare it to. I'm not saying everyone is this way, and obviously everyone values different things in their programming language / development environment. I do think if you don't know what's out there you tend to just accept that something you are doing is the norm.
And I think a lot of people that come to Julia from languages like Python, R, C++ see value in Julia for solving package development issues (compared to python), better language design (compared to R), performance without verbosity (compared to C++). And I think they weight those issues more heavily than I do. I've dealt with Python packaging issues, and still do on a daily basis but I now know my way around whatever comes up. R's syntax might be kludgy but I'm damn productive if I'm using ggplot. I'd rather use Python for general purpose work and R for plotting, than having to deal with Julia. C++ though I'd never want to touch again, and would just use rust instead. If rust wasn't an option, I think I'd end up using Julia (even though I complain about it so much). This is just were my priorities / skill level lies, and I can completely see how it would be different for others.
I'm much more productive plotting in Python and R than I am in Julia, purely because of compile times, even though Julia has a much better designed plotting package than Python (R's plotting ecosystem is rather convenient even if it is counter intuitive some times).
When you've used Rust, Go, Nim etc, developing in Julia feels so ... antiquated. Just as one example, when using Rust, you can write a unit test function right next to the function you are testing. And you can run just that unit test function from a terminal (e.g. `cargo test -- test_just_this_one_function`). And because you can write a quick little test function pretty much anywhere in your code and run it in the terminal, you don't really feel the need for a REPL all that much. When I'm not writing tests, I would say I'm as productive in Rust as I am in Julia (mainly because of awesome language server features in Rust). But the moment I need to write tests in Julia ... it's a big oof y'all.
In Julia there's NO official way to run just one test. You HAVE to run all of them. And the tests can be scattered in various different tests files in the test folder. Try contributing to the core Julia language itself, and trying running their test suite. You'll have to go get coffee multiple times just to make one single patch.
For projects that I'm working on, I literally have a Julia REPL open with Revise, where I manually include a specific test file after commenting out unnecessarily global state, and then call a the function I want to test that way. It's madness, and I _think_ this is what everyone does (?). If people are saying they prefer this, I can't help but liken it to Stockholm syndrome or something to that effect.
I agree with almost all of what you said. Except personally, I'm much more productive in something like Julia (or R or Python) than a language like Rust for the type of development I usually want to do. I mostly write Python and C++ for my dayjob, but would have a hard time justifying Julia for production at the moment, though I love the language.
Even more than Rust or Go, I think Julia could take a page from Typescript in terms of tooling because JS is so dynamic and the tooling is so nice.
I do think compiler latency has gotten way better in more recent versions of Julia, but I think better ahead of time compilation, faster interpretation, and code caching are all important.
I think Julia's tooling used to be better in Atom (Juno), however, Atom is dead.
I agree with you. Julia has gotten better but it’s still way slower than Python or R. And the workflow of running tests just make it painful. I think I’m familiar enough with Julia and I can write code and it’ll likely just work, but I’m not a 100% confident. With rust (and Python or Typescript with type hinting), I’m much MUCH more confident.
This is a good, well-thought out critique. While much of it rings true, I can't say I completely agree:
Wrt. static type checking, JET.jl does the job for me. I agree it still feels too immature with slowness and important edge cases it fails to consider. More importantly, the ecosystem itself needs to fully embrace type stability for it to be optimally useful, since otherwise you will get a shitton of false positives from functioning, yet unstable dependencies. The good news is that all of these things are improving quickly for JET.jl - it's getting faster and more robust. It still feeds immature since it's actively being developed.
There is also the linter, which is available in VSCode. It's pretty good. Nowhere near the level of rust-analyzer, but still decent.
You can easily have error types in Julia - see the package ErrorTypes.jl. It's not standard to use it, but I use it in my work code, and it works quite well.
You can absolutely write tests next to code and just run one test - see InlineTests.jl and ReTest.jl
HOWEVER:
* The latency is still terrible, and it really, _really_ hinders development. I don't see that being significantly solved in the next many years, only marginally improved. This can reasonably be a showstopper for some people. You learn tribal knowledge to lessen its blow (wrap things in modules, use Revise etc), but there is no sugarcoating it: It blows.
* The lack of statically enforceable interfaces is a real problem, and I think this will NEVER be solved in Julia. There just doesn't seem to be any real motivation from the core team, and no agreement in the community on what such a solution even should look like.
* The lack of separation of tests is very annoying as well. That might literally be impossible in Julia since part of its promise is that you can dynamically change definitions that affect other modules. It's what contributes to its great composability. But it also means you need to test ALL of Base if you change one thing.
Thanks for the reply Jakob. I agree with what you are saying.
When JET.jl works it is great. But for large projects it didn't even return when I tried it. I must have waited at least half an hour once.
VSCode seems like it is offically blessed and maybe I should just cave and use it for Julia. I use vim/neovim for EVERYTHING else though. Taking me out of my extremely custom tmux + terminal + vim workflow just for Julia development annoys me unnecessarily much. Do you know if there's work on getting this to work in vim/neovim?
ErrorTypes.jl, InlineTests.jl, ReTest.jl, SetField.jl all are awesome and I've used them in personal projects. I want to see them in the core language. Maybe ErrorTypes.jl is asking for too much, but tests sorely needs improvement. A SetField like feature literally had a PR open for years and then was just closed
Without these features in the base language, adoption is going to be so slow. Convincing my team to add a dependency is a lot of work, including updating internal documents, best practices, internal training for how and when to use a certain feature, etc.
I don't know how well Julia works with other IDEs to be honest. Much of the hard work of VSCode's extension is editor-agnostic, e.g. the LSP, the type checker and the linter - but whether someone has actually implemented a Vim plugin using these, I don't know.
I think it's fine to architect a language in this way as long as there is a good 1st party effort at a comprehensive standard library. The failure mode I see most often of a small core is that there ends up being 100 libraries of varying quality and completeness to do common tasks e.g. parsing JSON.
> when using Rust, you can write a unit test function right next to the function you are testing.
I'm not sure that this is a good thing? With Julia you can also write doctests which work great, but having a separate test set as a Julia _project_ offers a lot of flexibility. For instance, we're now developing a Julia wrapper for Playwright to build end-to-end/UI tests which themselves have multiple dependencies. Having a test _project_ allows having as complex test cases as needed, with properly managed dependencies out of source. How would you handle that with an approach like Rust's?
A test project means that you can easily extend the testing capabilities of Base Julia - for Genie we use ExtendedTestSet which actually allows us to pick and run only some of the tests. Take a look at that.
I’ll first say that this is my opinion, and that I don’t have good suggestions for how Julia as a language should implement this, just that it should:
* Better language level support for testing
* Better language level support for docstrings
- currently doc strings are just normal strings stored in a global struct, and are missing crucial information about the type signature of structs or functions or methods that are being documented
* A way to type hint without using multiple dispatch / interfaces
- I want to be able to say this argument has fields x, y, z but I don’t want to use multiple dispatch to enforce this interface. Multiple dispatch is useful with the implementation details of your code depend on the data structure. But I want better static type checking for a handful of fields or methods. Typescript is absolutely awesome at this.
* Support for using @copied s.x = 1 where s is an immutable struct. Users are literally incentivized to use mutable structs instead of immutable structs because that results in shorter cleaner syntax, even though performance drops through the roof in that case. With immutable structs you’ll have to recreate the struct by calling the constructor. In most cases, the compiler will compile as this away anyway but users are going to prefer shorter cleaner syntax when writing code.
* Better macro support. Currently macros have to be valid Julia code, meaning you end up with weird dsl that only kind of sort of matches the domain being modeled. In rust and nim I can literally copy almost any syntax and paste it in a macro block and it’ll just work. This is more work for macro developers and probably will make inference harder but will improve readability.
* Language level support for extending Array or letting users define arrays that are as efficient as the built in ones.
* Similar request for String buffers.
* Rewrite parser that is currently in scheme in Julia, I suspect better tooling will fall out of this
* Support for a subset of Julia that is fast to compile and run and produces small binaries.
I think more generally I want Julia to be a slightly different language than it is ( or possibly ever can be ). Currently a user of Julia needs to be cognizant of too many things that could accidentally introduce type instability. Almost none of these problems are going to be encountered by someone that understands how compilers work / how computers work, which in my experience is not a lot of domain scientists but is a lot of the core team working on Julia. Domain scientists have PhDs or Masters in highly niche subjects after years of writing Python, R, or Matlab but are more often than not terrible software engineers. I can’t tell how many times in almost a decade of being in this field have I seen 10,000 line scripts in a single file without any comments written by extremely smart scientists. Guiding these folk from the get go to make better software engineering decisions is important imo. Currently, if I’m leading a project, I can’t trust a fresh graduate or junior engineer to write idiomatic type stable fast and extensible Julia code, even if they are the experts of their domain. They have to be experts of their domain AND awesome software engineers which is so rare to find. Given additional constraints about funding, writing proposals, documentation etc, it’s honestly kind of amazing that Julia’s libraries are as good as they are.
In my opinion, Julia really shines when one or two people have to write code to tackle a specific problem. Code is super concise and clean and it all fits in your head and everything is fine and dandy. But when you have an engineering team that needs to work with databases, authentication, logging, deployment, scaling, machine learning, data analysis and plotting, and do most if not all of that in Julia … it’s so easy to write something that gets checked in that passes tests and code review that just destroys performance benchmarks.
There are two kinds of macros, and it sounds like you want `macro foo_str(x)` which accepts anything. But the tradeoff is that you have to parse it, rather than getting an expression tree.
Thanks for all your comments, they've been really enlightening. As a data scientist who sometimes wishes for something better than Python I did have my eye on Julia, but I was unaware of what issues could arise putting Julia into production. Sadly, I think that kind of puts me at square one ... there doesn't seem to be anything, even niche, that can replace Python for our business use cases.
We're a very Spark-heavy shop so I've tried to encourage Scala, but that got no traction, and it would raise its own set of problems. I like Rust but it's simply too complex to expect scientists and data scientists to wrap their heads around; it's hard enough to get them to use Python type hints.
Very good points. Agree with most of them - especially the lack of interfaces. I'm currently working on a ~30k LOC Julia codebase which was mostly written by myself. This is split into ~80 packages within a monorepo. I've never ran into problems with tests taking too long as tests for a single module take a reasonable amount of time to run.
I'd really love a PackageCompiler that would "just work" though. Julia 1.6+ made a lot of progress in pre-compile times. However, nothing beats being able to easily release a binary...
I'm a fan of Julia and have used it and will continue to use it for a lot of my daily work which involves running numeric simulations, but I agree with your critique.
I feel like the ideal language would combine the strengths of Rust (static type checking, great LSP, better threading, better package manager, easy compilation without a large runtime, etc.) with the focus on the scientific computing domain and all the associated trade-offs that Julia has. Maybe it's not possible to have the best of both worlds, but it sure would be nice.
I feel like if you're going to go monorepo in Julia (which I'm not sure I would, personally), you'd at least want to have multiple modules in that repo. Then you can run tests separately for each module, etc.
We do but tests still take a really long time to run. Sometimes changes are so local, and running compiling and running few hundred tests to check that a 50 line patch works is debilitating.
I'm bookmarking this and showing it to everyone that claims Julia is the next big thing. Kudos for really exercising the language despite all of these painful shortcomings (you must be a very patient person).
Thanks for the input, Genie creator here. I appreciate sharing your experience and I'd like to get a bit more info about the issues you had please.
0) Yes, this is an issue I confronted early on. Precompilation can take long on small machines, causing setups like Heroku's to kill the app. The solution (which granted should be maybe better documented) is to set the `EARLYBIND` env variable to `true` - this will allow Genie to bind to the port very early so Heroku will love it. (On second thought, maybe this should be the default in production)
1) ...
2) I don't understand the issues with auth, db, cookies, sessions, etc? Genie has built in support for handling (encrypted) cookies and sessions and plugins like GenieAuthentication (or GenieAuthorisation) and SearchLight provide straightforward features. Have you used these?
3) Really weird about the 30s update, haven't heard of this from other users. What's your computer configuration if I may ask? Can't comment on vim, I/we use VSCode.
Re deployment:
* are you running the app in "prod" environment?
* are you serving the assets via a reverse proxy like Nginx/Apache?
---
I do agree that using a language and a framework you know and used many times before would have been much quicker to build, but that's the case with all new tech. Besides the learning curve of a new language and a new framework, Genie and Julia are quite young and granted there's a myriad of things that we need to build, invent and develop :-) We enjoy doing it and solving this kind of problems and I'm sorry that unlike us, you had a hard time. Thanks again for sharing your experience and maybe check us out in 1y or so, the ecosystem is maturing fast but some things just take time (Python is 30y old right?).
Thanks for writing up your experience using Julia for creating a web app.
I agree that Julia is doing well in scientific domains, but is not perceived as a general-purpose language among many developers. Other languages also have rich non-scientific libraries, frameworks, and learning resources.
The scientific domain is vast though, so Julia can certainly thrive in that space. Can it break out of that space into other fields too? It does not seem to have yet, but I guess only time will tell. (Julia recently received multi-million funding so it will be interesting to how this will be used to develop and promote Julia.)
Yea this is pretty much the norm for Julia deployments. You have to be really wise about how you architect the use of Julia for production. In a lot of common use cases, in my opinion, it's business infeasible. Unfortunately it can even be "passion project" infeasible. For serious compute projects or research - its nothing short of amazing.
I think it stands a chance but this side of things hasn't been nourished. I hope developers who have these kinds of experiences and share them are heard.
I learnt the hard way that you can architect Julia apps the wrong way. I think my biggest frustration is how easy it is to make mistakes that cause type unstable code.
From real experience and will probably get in trouble for saying this: I worked with Julia developers who are scientists. They write software like they write scripts. So everything we had was absolutely not production worthy but running in production. The whole company was built on stilts like this. I still wonder how it actually worked and never came crashing down.
Also, personal gripe and absolutely not the fault of Julia creators: I hate 1-based indexing.
There is a wealth of startups out there takings small hordes of junior devs out of non-CS grads. Learning on the go, they become proper devs or get into business a few year later. Projects get out there by pure force of will.
They are like the E. Coli of devs, cheap to make experiment with, and very adaptable to any environment.
This is true. Biotech/Physics/Math grads getting into the ad-tech/SaaS grind kind of makes me sad though. Under-utlization of talent. No doubt there are interesting challenges in literally every field, just that scientists are good at doing science - Design of Experiments, Theorizing stuff, grokking mathematics that would make me faint, etc. and the same people fucking around with webpack/JS tooling, learning how IAM works or spending their time on fixing CI/CD pipelines is depressing. We need some sort of a division of labor here.
My situation is slightly different from what you describe, but yeah, we have scientists and data scientists involved in writing Python packages, setting up CI/CD pipelines, dealing with auth and frontends for APIs. There's talk of dividing labor up a bit better so that we can focus on science and data work, but there's hardly enough engineering staff as it is and they're largely not much better from a software engineering perspective (and half of them hardly know any Python, which our non-engineers have 100% standardized on). It's kind of a mess right now.
I had a very similar experience when I deployed a microservice on k8s cluster. I wish there was vendoring, better testing frameworks, database drivers (not ODBC), proper async framework, precompilation for faster startup. Serverless workloads for pretty much impossible in Julia.
I went down the rabbit hole of cross platform dev and opted for React-native-web because I already knew React. I sure hope Flutter is a better experience because it just made me want to jump jobs to a native gig.
these days you can embed JS and WebAssembly in your HTML file and have plenty of advanced features: SIMD, GPU access, GUI (obviously), even barcode scanners gently provided by the browser, ...
it's only the tooling that is not there yet. give it a few years or so. I am doing myself some work in this area and I must say - the technology is there, it's only a matter of porting to the the web a few scientific libraries
Think about it from the other direction. Julia makes writing certain types of programs much easier than in other languages traditionally used to build app GUIs. This then makes it possible to wrap those programs in a GUI for distribution.
If you're wrapping a GUI around a CRUD app then Julia probably isn't your best choice. If you're writing a novel differential equation solver and want to provide a GUI for people to explore it then this makes it possible to do so.
Generally a lot of the end user of these programs aren't supper great at getting them to run, so an easy way to get your algorithms into the hands of users is very helpful.
R has a pretty good "share my stuff on the web" story with "R shiny" web application server that's quite popular with our data scientists.
And desktop applications for things that require files too big for easy web use is helpful too.
I also get a ton of mileage creating Pluto notebooks and sharing the results for others to run or view a static webpage of the results.
1: https://github.com/fonsp/Pluto.jl
2: https://github.com/JuliaPluto/PlutoSliderServer.jl
3: https://computationalthinking.mit.edu/Spring21/