Startups are building with the Julia Programming Language
juliazoid.com
juliazoid.com
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".
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.
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.
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?
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?
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.
[0]:https://discourse.julialang.org/t/taking-ttfx-seriously-can-...
https://github.com/JuliaLang/julia/pull/47184#issuecomment-1...
For others who feel they've been gaslit by the julia community, this blog post [1] resonated with me, especially the 2022 update.
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
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
Related: I think Julia is an excellent starting language (compared to Python). Is anyone teaching Julia to new programmers with success?
I haven't kept up with the ecosystem - I'm curious how things have improved in the last 5 year!
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.
Either that, or most languages used today are stuck in the past!
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.
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.
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.
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.