Hacker News Reader

Comment by andi999 | Hacker News Reader

I can currently see Julia only as a replacement for Python, with the biggest advantage, that fast modules can be written in-language, and you do not default back to C. So in a sense it could solve the two language problem.

But then for my applicationsspace there are problems:

- compilation seems possible now, but one has to be careful of GPL (like in the fft)

- no way to turn off GC (so byebye real-time possibilities).

- what about GUI design? Heard some mixed messages about it

View on HN

> - no way to turn off GC (so byebye real-time possibilities).

While Julia does not offer semantic guarantees that you can avoid the GC, it;s actually quite possible and easy to write code where you're manually managing all your memory and the GC is never invoked.

> - what about GUI design? Heard some mixed messages about it

There's a lot of promising things happening with Makie.jl, Stipple.jl, Dash.jl, Pluto.jl and others. This space is still a little immature in Julia, but it's progressing fast.

JuliaRobotics is a pretty good example of this: they eliminated all GC calls from the loops in order to deploy on an Atlas robot and... that was 2018.

I know there are workarounds, but when you do not have guarantees the phrase 'production ready'is not the first that comes to my mind. (Of course in the problem spaces of matlab and python, and probably R, Julia is probably on par)

I don't think the blog post above here is about using julia for ultra-low-latency systems to be pair. 'Production ready' is a pretty vague statement and certainly doesn't apply to every usecase.

I'd say that if people have other reasons to use julia in a realtime low-latency production system -- like needing it's scientific stack -- then you can certainly make it work, you just need to do some testing to make sure you're not hitting GC.

Well, how high is the bar for calling a language 'production ready' in that case? How many production ready languages are there?

What I meant: production ready depends on the feature. So for substituting Python (and beeing able to write fast in-language extensions), the language is most likely production ready; so in a sense it is a replacement for Python + C; but not a replacement for C. And this is a bit sad, because it could have been (building linked executables should be possible, since the language is compiled).

But I like your question, lets call it 'which languages are all purpose production ready'; probably only C, C++, Java (there is a real-time version), LabView.

The FFTW package is no longer included in the stdlib. The only GPL dependency that is shipped in there is SuiteSparse.

So what non gpl fft can you use? (If your program needs one and you do not want gpl or pay for fftw)

You can use FFTW.jl with MKL: https://github.com/JuliaMath/FFTW.jl#mkl

I'm also interested in the packaging/deployment story. Can you easily make a zip with everything built-in and 0 OS dependencies? Can you ship a single, statically linked binary?

Reply on news.ycombinator.com