Startups are building with the Julia Programming Language(juliazoid.com)
juliazoid.com
Startups are building with the Julia Programming Language
https://juliazoid.com/heres-why-startups-are-building-with-the-julia-programming-language-5addadac3bdc
41 comments
My (more or less extensive) experience with Julia has been rather good.
Step 1. Prototyping. Small data, don't care about performance. Julia is as easy as python, but faster. GC doesn't matter.
Step 2. Production. Very large datasets. Performance is very important so I make sure that hot loops don't allocate, and so GC doesn't matter.
Really, I struggle to see how someone can not like this.
Regarding hiring. My experience has been that you can roughly divide people into two categories. Those who like using tools, and those who like solving problems. For the former, a different language might be an issue because they might not know and might not be in the mood for learning it. For the latter, they're happy to learn any tool that can help solve their problem. We want the latter, and for the latter learning Julia hasn't been an issue.
Step 1. Prototyping. Small data, don't care about performance. Julia is as easy as python, but faster. GC doesn't matter.
Step 2. Production. Very large datasets. Performance is very important so I make sure that hot loops don't allocate, and so GC doesn't matter.
Really, I struggle to see how someone can not like this.
Regarding hiring. My experience has been that you can roughly divide people into two categories. Those who like using tools, and those who like solving problems. For the former, a different language might be an issue because they might not know and might not be in the mood for learning it. For the latter, they're happy to learn any tool that can help solve their problem. We want the latter, and for the latter learning Julia hasn't been an issue.
I am not exactly sure what they were working on, but I am not convinced that any code can be made non-allocating easily.
For example, when you are building large trees with complex structures in the nodes and you need to both add/remove the nodes, the effort to make it non-allocating might be too much compared to just using C++ and writing things more naturally?
For example, when you are building large trees with complex structures in the nodes and you need to both add/remove the nodes, the effort to make it non-allocating might be too much compared to just using C++ and writing things more naturally?
Please put them in touch with me if possible. RelationalAI has similar GC issues which they are the core Julia developers are working hard to resolve.
I have also seen zero postings for Julia roles in cyber security companies so it is likely that they aren't tapping into the community which is why they can't find people.
I have also seen zero postings for Julia roles in cyber security companies so it is likely that they aren't tapping into the community which is why they can't find people.
It was a talk by folks from this team: https://gradient.avast.io/people-behind/
If you care about performance your code shouldn't be allocating.
If anyone from these startups is here on HN, I would love to hear your thoughts on the following:
1. How are you dealing with TTFX when deploying your code? If using PackageCompiler/StaticCompiler, is binary size an issue?
2. Are you using solely Julia, or a combination of Julia + other languages?
3. What unique value is Julia offering your startup that is difficult to find in other languages?
1. How are you dealing with TTFX when deploying your code? If using PackageCompiler/StaticCompiler, is binary size an issue?
2. Are you using solely Julia, or a combination of Julia + other languages?
3. What unique value is Julia offering your startup that is difficult to find in other languages?
We (metalenz.com) use Julia extensively in our optical design/simulation/modeling workflows:
1. Design team keeps live sessions during interactive work, otherwise launches on virtualized servers (and things take sufficiently long to compute TTFX is a rounding error)
2. Above mentioned team is exclusively Julia. Julia shows up in other things we do (low-level computer vision), but not dominant nor exclusive
3. High performance & expressive programming and flexible autodiff system for scientific computation
1. Design team keeps live sessions during interactive work, otherwise launches on virtualized servers (and things take sufficiently long to compute TTFX is a rounding error)
2. Above mentioned team is exclusively Julia. Julia shows up in other things we do (low-level computer vision), but not dominant nor exclusive
3. High performance & expressive programming and flexible autodiff system for scientific computation
Jumping the gun slightly, but TTFX likely about to get a lot better (5x+ improvement in times) in the next version (1.9). Via cachine of the native compiled code.
https://github.com/JuliaLang/julia/pull/47184#issuecomment-1...
https://github.com/JuliaLang/julia/pull/47184#issuecomment-1...
I've been hearing about improvements for the last 8 years. It has been a constant complaint and a constant broken promise.
Since 1.0 it has gotten way better. There's still work to do (obviously) but there has been continual improvement.
My concern for TTFX is the case when X is something infrequent but sensitive to latency? This a ridiculous example but when it is time for the anti-collision feature on my car to kick in, I want it to run, not compile. I think the right answer is to run a bunch of tests to get all the paths compiled and then build a new system image. But I haven't found a ton of guidance on how to do that. Seems like a perfect pipeline task.
That’s the idea. Here’s an example:
https://discourse.julialang.org/t/a-julia-dataanalysis-sysim...
I think Jevon's paradox is also hitting to some extent, coupled with the ecosystem getting bigger, so a typical project may have more transitive dependencies behind it. The functionality is going up, and the speed of compilation is going up, but the total latency is staying similar or increasing, in my experience.
that's definitely possible. I'm somewhat hopeful that some changes in 1.9 will let us cut back on transitive dependencies a lot, but it will take a few months to know for sure.
I'm not sure that there's been any "promises" to break. Folks have been saying that it's possible but it'll just take time and effort.
Indeed, every couple of years I try julia again, and every time it's still slow as molasses, all the while being told it's massively improved. One of the most annoying aspects of slow TTFX is when X is your language server. It takes like 10 minutes or something ridiculous for completions to start working after opening a moderately complex file. I had the same experience in vscode and emacs.
For others who feel they've been gaslit by the julia community, this blog post [1] resonated with me, especially the 2022 update.
[1] http://danluu.com/julialang/
For others who feel they've been gaslit by the julia community, this blog post [1] resonated with me, especially the 2022 update.
[1] http://danluu.com/julialang/
We bring up these posts every time Julia is mentioned on HN. I've become reticent to respond to these comments. It seems like any response that does not sound like it came from a customer service representative, e.g. "Thank you for expressing your concerns. We acknowledge there are issues, and we are working on it.", will get interpreted as being dismissive or arrogant. I frankly prefer to hear technical responses to the critiques and about how specific issues are being addressed even if they may not be to my satisfaction. Still though, it is important to continue a conversation about this. We should encourage a dialog rather than suppress it.
What's clear to me is that the current state of Julia is not for everyone, and that's fine. There are many other solutions in this space with extensive funding or experience that are likely a better fit for many. For some, incremental improvements on existing technology are more appropriate than a new language introducing new paradigms. Working with Julia is a participatory process, and I understand not everyone has time for that. I thank the pioneers for trying, even if they have decided its not for them at this stage. At the same time, some circumstances require more than incremental change.
On one hand, the comments here posit that nothing is changing and that Julia is slow. Perhaps more precisely the complaint is about its compilation latency: 1. "It has been a constant complaint and a constant broken promise." 2. "every couple of years I try julia again, and every time it's still slow"
On the other hand, these comments are replying to a post about a pull request [1] addressing "time to first X" (TTFX) by providing infrastructure to cache native code on a per package basis. For further background, please refer to a prior pull request merged last month which tackles the prerequisite step of supporting external linkage in system images [2]. The recent pull request also contains an evaluation from a "non-core" developer who is reviewing the pull request, sharing his real world experience with graphs, measurements, and comments about the documentation. To me this pull request is exemplary of how Julia development should work and how users can contribute to the process. Referring to the original article, I also notice that many of the companies and startups mentioned are involved with the development of the Julia language itself rather than merely the application of the language. Perhaps this ability to participate in Julia development at this stage is seen as a feature to these organizations.
I'm unclear what the critique is here with rehasing these comments in response to a pull request. Should that pull request take another approach? Is code review on that pull request progressing too slowly? Is it that the priority should shift away from the compiler to provide further infrastructure for correctness, traits, or some other feature? There's a lost opportunity here to actually expand the conversation rather than reiterating the same arguments.
Nonetheless, I thank thetwentyone for posting news about a substantive pull request addressing compilation based latency. I hope to hear more about these ongoing efforts.
[1] https://github.com/JuliaLang/julia/pull/47184 [2] https://github.com/JuliaLang/julia/pull/44527
What's clear to me is that the current state of Julia is not for everyone, and that's fine. There are many other solutions in this space with extensive funding or experience that are likely a better fit for many. For some, incremental improvements on existing technology are more appropriate than a new language introducing new paradigms. Working with Julia is a participatory process, and I understand not everyone has time for that. I thank the pioneers for trying, even if they have decided its not for them at this stage. At the same time, some circumstances require more than incremental change.
On one hand, the comments here posit that nothing is changing and that Julia is slow. Perhaps more precisely the complaint is about its compilation latency: 1. "It has been a constant complaint and a constant broken promise." 2. "every couple of years I try julia again, and every time it's still slow"
On the other hand, these comments are replying to a post about a pull request [1] addressing "time to first X" (TTFX) by providing infrastructure to cache native code on a per package basis. For further background, please refer to a prior pull request merged last month which tackles the prerequisite step of supporting external linkage in system images [2]. The recent pull request also contains an evaluation from a "non-core" developer who is reviewing the pull request, sharing his real world experience with graphs, measurements, and comments about the documentation. To me this pull request is exemplary of how Julia development should work and how users can contribute to the process. Referring to the original article, I also notice that many of the companies and startups mentioned are involved with the development of the Julia language itself rather than merely the application of the language. Perhaps this ability to participate in Julia development at this stage is seen as a feature to these organizations.
I'm unclear what the critique is here with rehasing these comments in response to a pull request. Should that pull request take another approach? Is code review on that pull request progressing too slowly? Is it that the priority should shift away from the compiler to provide further infrastructure for correctness, traits, or some other feature? There's a lost opportunity here to actually expand the conversation rather than reiterating the same arguments.
Nonetheless, I thank thetwentyone for posting news about a substantive pull request addressing compilation based latency. I hope to hear more about these ongoing efforts.
[1] https://github.com/JuliaLang/julia/pull/47184 [2] https://github.com/JuliaLang/julia/pull/44527
Would it not be better at this point to move on?
TTFX - the time-to-first whatever a package does most[0].
[0]:https://discourse.julialang.org/t/taking-ttfx-seriously-can-...
[0]:https://discourse.julialang.org/t/taking-ttfx-seriously-can-...
When I worked at Beacon biosignals briefly in 2020, they had Simon Danish (the creator of Makie there full time deploying plots/makie in the browser).
One point 2, you should check out Julius Tech which is bridging the multi language future using Julia through their graph computing tool. Other companies like RelationalAI are building on top of Julia but also have their own new language called Rel.
One point 2, you should check out Julius Tech which is bridging the multi language future using Julia through their graph computing tool. Other companies like RelationalAI are building on top of Julia but also have their own new language called Rel.
Julia scientific apps and libraries continue to grow and see momentum. Is there interest in Julia outside the scientifc sphere? I'd be interested to hear of non-scientific projects implemented in Julia (for example, business apps or web-related projects.)
Related: I think Julia is an excellent starting language (compared to Python). Is anyone teaching Julia to new programmers with success?
Related: I think Julia is an excellent starting language (compared to Python). Is anyone teaching Julia to new programmers with success?
I'm teaching an intro programming course (discipline-specific, for Earth sciences) in Julia at Dartmouth. So far so good I think -- but definitely on the sciences side of things.
Look at GenieCloud, they are essentially building the Django ecosystem in Julia, it will be huge if they are successful.
My defunct startup Staffjoy operated from 2015 to 2017 and was an early production user of Julia. We open-sourced some of the code here: https://github.com/staffjoy
I haven't kept up with the ecosystem - I'm curious how things have improved in the last 5 year!
I haven't kept up with the ecosystem - I'm curious how things have improved in the last 5 year!
Probably the most obvious improvements for most users are the big growth in the package ecosystem, with some science and math packages becoming the best available in any language (DifferentialEquations.jl, for example) and the drastic improvement in interactivity: the REPL starts instantly now, and most packages compile much faster. This will get even better in the next major release.
I’m curious (I’m planning on designing an ODE/PDE package relatively soon), what makes DifferentialEquations.jl the best available?
This lists some of its unique abilities:
https://docs.sciml.ai/DiffEqDocs/stable/
The routines are sufficiently generic, with regard to Julia’s type system, to allow the solvers to automatically compose with other packages and to seamlessly use types other than Numbers. For example, instead of handling just functions Number→Number, you can define your ODE in terms of quantities with physical dimensions, uncertainties, quaternions, etc., and it will just work (for example, propagating uncertainties correctly to the solution¹). Recent developments involve research into the automated selection of solution routines based on the properties of the ODE, something that seems really next-level to me.
[1] https://lwn.net/Articles/834571/
https://docs.sciml.ai/DiffEqDocs/stable/
The routines are sufficiently generic, with regard to Julia’s type system, to allow the solvers to automatically compose with other packages and to seamlessly use types other than Numbers. For example, instead of handling just functions Number→Number, you can define your ODE in terms of quantities with physical dimensions, uncertainties, quaternions, etc., and it will just work (for example, propagating uncertainties correctly to the solution¹). Recent developments involve research into the automated selection of solution routines based on the properties of the ODE, something that seems really next-level to me.
[1] https://lwn.net/Articles/834571/
My best answer for you is https://docs.sciml.ai/DiffEqDocs/stable/solvers/ode_solve/#F.... It's the list of the ~250 different solvers you can choose from (note that most of these have a bunch of customization options). DifferentialEquations.jl has heuristics that do a pretty good job of picking a good algorithm on it's own, but it also lets you test every algorithm you've heard of (and a bunch you haven't) to find the one that works perfectly for your problem.
The fact that Chris R and the whole SciML ecosystem are using / building on it. Lots of resources going into it and usage in real world places like Pfizer and Moderna.
How good is Julia as a general-purpose language? Can it be a viable replacement for, say, Lua in game development?
Julia is a very nice language, its core abstractions (mutli-dispatch and macros) are not tied to any particular use-case. My overriding feeling using it is that it is a language visiting from the future, it is very well put together. Having said that, I've not had the opportunity to use it in production, Python is very popular!
> My overriding feeling using it is that it is a language visiting from the future
Either that, or most languages used today are stuck in the past!
Either that, or most languages used today are stuck in the past!
It is a very well-designed language for many (although of course not all) applications. Most of the ecosystem revolves around scientific computing so you may find there is a bit of a learning curve / sparse existing libraries if you want to use it for game development.
Also, on the language side, Julia is optimized for total throughput, which means even though it is easy to write extremely fast code, it sometimes suffers latency issues during stop-the-world garbage collection or JIT compilation. Julia gives the experienced developer tools to avoid this, but especially for those less practiced with the language it could potentially be an obstacle for real-time games like FPS--of course if you are developing a turn-based game this is less of a concern.
Also, on the language side, Julia is optimized for total throughput, which means even though it is easy to write extremely fast code, it sometimes suffers latency issues during stop-the-world garbage collection or JIT compilation. Julia gives the experienced developer tools to avoid this, but especially for those less practiced with the language it could potentially be an obstacle for real-time games like FPS--of course if you are developing a turn-based game this is less of a concern.
Isn't Lua's main benefit that it has a small runtime that can be executed inside the context of a large C/C++ executable? Julia has support for C FFI, but it looks like you'd have to manually wrap all of your native code in Julia wrappers.
One library I've really liked for this use case is QuickJS. It's a super small ES2020 implementation written in C. It has a great API that lets you bind native C functions and types into JavaScript functions, objects, and classes. This lets you bind native C code that gets used naturally in JavaScript without needing to write wrappers.
One library I've really liked for this use case is QuickJS. It's a super small ES2020 implementation written in C. It has a great API that lets you bind native C functions and types into JavaScript functions, objects, and classes. This lets you bind native C code that gets used naturally in JavaScript without needing to write wrappers.
Julia is not a good choice to replace lua because its runtime is at least 60MB. It is also very slow to compile. LuaJIT would be a much better choice since it is very small and very fast.
Luajit isn't really a replacement for lua though, if you don't want to use lua.
The only thing I've seen that's really comparable to lua/luajit in terms of size and simplicity of embedding in a C program is janet. It's bigger but still a single file. I would assume also somewhat slower but if you need raw perf C is right there.... But you get a much more usable language with an actual stdlib so it's a good tradeoff for a lot of applications.
The only thing I've seen that's really comparable to lua/luajit in terms of size and simplicity of embedding in a C program is janet. It's bigger but still a single file. I would assume also somewhat slower but if you need raw perf C is right there.... But you get a much more usable language with an actual stdlib so it's a good tradeoff for a lot of applications.
> if you don't want to use lua.
But people do want to use lua. The advantage of julia is mostly speed but the disadvantages of huge runtime, long compile times and weak GC mean it isn't realistically going to be used in games much if at all. luaJIT closes the speed gap by a huge amount and is small and compiles extremely fast.
> but if you need raw perf C is right there
LuaJIT (and julia actually) have very easy FFI integration, but why not make everything in C (ignoring that actual C would be terrible idea compared to C++ for something non trivial)?
Any embedded language is embedded for a reason. I'm not sure what point you are making here.
But people do want to use lua. The advantage of julia is mostly speed but the disadvantages of huge runtime, long compile times and weak GC mean it isn't realistically going to be used in games much if at all. luaJIT closes the speed gap by a huge amount and is small and compiles extremely fast.
> but if you need raw perf C is right there
LuaJIT (and julia actually) have very easy FFI integration, but why not make everything in C (ignoring that actual C would be terrible idea compared to C++ for something non trivial)?
Any embedded language is embedded for a reason. I'm not sure what point you are making here.
I'm a huge julia fan, but man is this ever an insubstantial and unconvincing listicle.
Yeah, it doesn't really seem intended for a HN type audience. More of a high level overview of the language to show to a non-technical co-founder or senior executive.
What is the HN type audience? HN is a news feed run by Ycombinator, a "startup accelerator". While many people around here have deep technical expertise, given the name "Hacker News", I always thought the main purpose was to make news and technical discussions more accessible to non-technical co-founders and startup executives.
Seems like small teams will not run into these issues at least initially.
I really like Julia and I hope it becomes huge, but stories like this make me wonder whether the whole Julia ecosystem will ever mature to a level of Python for example. And in turn, making it viable for large organizations that might be using e.g. Python + C++ combo that might be easier to hire for/more versatile/with better known drawbacks.
Essentially, I am not sure whether the potential of Julia is that much greater than the realized potential of the incumbents to warrant the "Julia is the language of the future".