Hacker News Reader

Comment by mruts | Hacker News Reader

Julia isn't really well suited for production environments. And by that, I mean on some server or something. In finance it's gaining marketshare as an exploratory analysis tool for traders and quants though. The code is typically productionized in C++ or whatever in the same way Python or Matlab code is.

View on HN

Is this a common thing? I'd argue it's an anti-pattern, similar to how we prefer devops over splitting purely development and purely operations nowadays.

At least the times I've seen it the first authors proclamed it as done and "just need to port it for production" only to find out pesky things like massive amounts of bugs (no testing in the originals) or unusable performance problems (turns out what you can do on a 64-core cluster overnight is not suitable for doing realtime)

Whats the alternative? Write it with prod in mind, when you don’t know if the idea is actually viable, and end up erasing a lot more time/code if it fails?

The idea for exploratory programs is just to see if the core idea is actually viable in the first place, before spending time on things like making it robust/fast.

Ofc, if you could make it robust/fast for free/cheap, then it makes sense to call it an anti-pattern — you made it fragile for no good reason — but I’m not clear on how to obtain robustness/speed without quite a bit of work

My preferable alternative would not be to use a totally different toolchain for prototyping and production, and making the people responsible for the prototype also responsible for bringing it to production.

I've heard all kinds of arguments against it, but they mostly boil down to "data scientists/analysts/whatever" can't be arsed to bring it to production (or "do not have the right skill set") and vice-versa for software developers.

I've seen much more success with a developer and less-technical person working closely in a team and bringing a project from prototype to production together.

A lot of the time, you’d just be wasting the developers time. In finance the research quants are going to have to test and explore dozens of ideas before even one is suitable enough to actually deploy in production. It doesn’t make sense for the quant and developer to work closely together in C++ or whatever when there’s a high likelihood that the trading idea doesn’t work in the first place.

Also, the quant often isn’t good enough at computer science to actually develop a production system himself. And even if he was good enough, it isn’t his comparative advantage so he probably should be focusing on research.

It's very common for larger projects requiring sophisticated algorithm development coupled with demanding runtime requirements such as high throughput, low latency, or high reliability. In such cases, the separate toolchain inefficiency can be justified by higher developer efficiency and the advantage of having two separate code bases developed two ways by two different teams. The two versions can be compared functionally to find many errors that would otherwise be missed due to bad assumptions, library issues, compiler issues, incomplete test coverage, etc.

It's certainly _very_ different to MATLAB and Python.

After all a lot of the performance sensitive libraries written in C/C++/etc... in Matlab/Python are written in Julia itself.

It really depends what you mean by production.

Why is it not suitable for production environments, its a compiled language?

It depends on the application. Sometimes you need the finer level of control over resources provided by a statically-complied language like C++. An example would be latency-sensitive applications that cannot tolerate the unpredictable delays inherent in garbage collection and just-in-time compilation. Other issues might include current availability or stability of the packages.

By this logic, Java would be unsuitable for production, too. I think perhaps you're conflating "production" and "real-time".

Personally, what I'm really looking for when I ask if something is ready for production is, first and foremost, is it buggy? Second, has it stabilized, or are breaking changes still common? Third, is package/dependency management something that ops can work with without too much hassle, preferably without just relying on Docker to keep it manageable like a parent closing the door to their teenager's pigsty of a room.

Also, you don't have to be faster than the bear. Julia's chief competitor, Python, is often used in production even though it fails the 3rd test and only semi-succeeds at the first.

Java is most certainly unsuitable for production in many domains. That doesn't mean it's unsuitable for all, nor does it mean it isn't "production ready" in general. The GP context was about Julia not being well-suited for certain production environments. I gave one of a number of possible examples where that can be true. Just as with Java, that doesn't mean it's unsuitable for all production environments.

Its probably true that Julia isn't suited to real time but then again the normal prod environments thease days are not running on a real time OS

I certainly used to write real time code for FORTRAN IV on DEC RT11 - thank goodness for the DECUS tapes for example code.

Julia should work fine in production (outside of having less mature tools to integrate with other services compared to popular languages that get direct support from the providers). That and like other said, it's not optimal for some domains (like really realtime stuff that can't have millisecond lags, though honestly latency can be kept low in general by having multiple replicas handling the requests), in embedded stuff (because of high memory profile for example) and it's sub-optimal in situations in which you can't keep the session alive (when the server will restart the application at every request, and the JIT will have a lot of effect in the response time).

The difference between an exploratory code in my opinion and production code is that production code must be correctly structured (comply to an architecture defined by the developers, properly separated in functions, readable), fully documented, unit tested, integration tested, properly tested in homolog/staging, logging, metrics, health checking and extensive error/exception handling.

So in general, during exploration phase you can use the already tested production code/libraries and extend them without much care on the above until you're satisfied with the approach/results (usually in a fast REPL/Jupyter/Revise.jl cycle). Then you start refactoring and implementing all the above to prepare for deployment (and probably during the testing you'll possibly find errors in your exploratory code, which may lead to another exploration phase). Eventually you'll end up with solid production level code.

However, the built in abilities to facilitate structuring code are somewhat lacking in Julia. I would really like a Protocol system of some kind...

It might be a question of avoiding implicit interfaces in your code (or documenting and testing it extensively in case you need them). They are great for creating really generic libraries (like Tables.jl interface), but for business logic production code it might be better to restrict the polymorphism of the language (using more strict dispatch rules, avoiding duck typing, type declaration as type asserts).

It's on Jeff's radar: https://www.youtube.com/watch?v=TPuJsgyu87U

Thanks for the great insight - is there any particular reason why this might be the case?

Julia is extremely focused on data science and scientific computing. Most of everyone using it is concerned about things like ML libraries, dataframes, matrices, etc. it’s not that Julia couldn’t be a good general purpose language, it’s just that it’s not the focus. Compare that to the JVM for example, which is mostly focused on servers serving requests.

Also, it’s pretty clear from the existing Julia libraries and homepage that serving requests isn’t what’s important to them.

Reply on news.ycombinator.com