Hacker News new | past | comments | ask | show | jobs | submit login

I totally agree, leaning on Moore's Law to solve performance issue doesn't work. When you have performance issues on the language itself, you're essentially paying a performance tax on every piece of code that executes, in a compounding way. So if Julia became a widespread programming language for general applications, you have those small delays leaking into all sorts of operations, and before you know it your whole system feels slow and bogged down.

I have been testing some performance oriented software recently, and it's amazing how much more productive I feel when every keypress is immediately reflected on screen with no delay. We can adapt to poor performance, but it adds a constant cognitive load to deal with it.

In my mind Julia is suited for limited applications, like doing work in a jupyter notebook, but is not suited for general applications unless the TTFX issue can be fixed.




In my opinion, there is no such thing as a "general application". What about generating static websites? Is that a "general application"? Is TTFX a big issue there? Currently, the Julia package Franklin.jl takes around 15 seconds to create the website the first time (changes in the source code update the page in less than one second). I'd argue no.

What about Julia to produce generative art? Is TTFX an issue there? Etc. If "general applications" means _all possible applications_, then I'm not sure any language is suitable for general applications.

Julia has weaknesses which limits what it's good at. Right now I think it has more weaknesses than other languages. Some of these limits will hopefully be removed or reduced in the future. But fundamentally, I don't see Julia as some kind of domain specific or niche language. Just like any language, it just has its own set of tradeoffs.


Yeah I would agree the use cases you mentioned are probably fine for Julia as well. I could be more precise and say that Julia is not relevant for performance-relevant applications.

The problem with ignoring performance is, many applications can become a dependency of a performance relevant application even if that was not the original intent.


We recently used Julia to solve (correctly) a super complex scheduling problem for a major airline. Our budget was 5min, Python would get not even close to a solution in that time. The tool is being actively used in production.

Julia is not not only fine, but my go to language for performance problems.


Ok but comparing with Python is like a worst-case scenario, and long running tasks would amortize Julia’s performance issues.

There are a great many use-cases/language comparisons you could find where Julia would be the worse performing language.


You seem to confuse performance and latency. High performance is Julia's main selling point. Latency is its Achilles heel.

It's being very actively worked on however.


Latency is a type of performance. For instance if you have even a few milliseconds latency it's relevant in terms of UI performance.


Then you should specify. You made a blanket statement about performance, while using the least commonly considered type. If you just say 'performance', most people will assume you mean throughput.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: