When doing big long running workflows especially with plan Mode 4.7 was a clear improvement. It’s considerably worse for under specified tasks and responds to a couple sentences with 10+ paragraphs for explanatory type discussions.
Just reverse the axis on one side, typically the Julia side. This is the convention used in Lux.jl/Flux.jl. I share memory between the two with zero additional copying for my workflows on a daily basis. If you are really allergic to doing this, I’m sure it’s possible to use metaprogramming / the type system to write it the same way in both places with zero performance overhead.
Your baseline for comparison is a company that doesn't give anything away for free?
Also, contributing in open source is a choice, not a mandate. I greatly benefit from Julia and its ecosystem so I chose to contribute back some of my work, no one forced me. I chose the MIT license because I want other people to be able to make money with it, just like I make money with other peoples MIT licensed stuff.
From the sound of your post I'm guessing you view Julia as a general purpose language. I'd consider it general purpose insofar as the application leans into fast numerical computing, everyone else secondary. It can do most of the things other languages do reasonably well, but that's not why you would pick Julia for a project over say Java. You pick it because you want to write fast numerical code and express it elegantly. All of the other typical "glue" things you need to ship a product are secondary to that, but good enough to get the job done.
The key to performance with the GC in Julia is not allocating, but it has gotten substantially better since 2019.
Mojo looks neat but I'm pretty satisfied with Julia at this point for high performance numerical computing across CPU, GPU, etc. I can't help but feel this niche is already mostly solved beyond having Python like syntax. Even Python has things like Numba and Triton that are effective for less complicated / more self contained type problems.
The decision to run all of my experiments in a monorepo with a single uv.lock continues to be validated. I usually only update it a few times a year. It was pinned at 2.6.1 for lightning \o/
A more generous interpretation of your grandiose vision would obviously include some way to make the water not into a breeding ground, like what you mentioned here. But seeing as this is hacker news, I felt like playing into the respective stereotypes of an interaction between someone living in the Bay Area and Houston completely talking past eachother.
And yes, the lack of planning does cause problems. It also has obviously has some benefits, like affordable housing. I live in a suburb (Sugarland) and while it’s not particularly exciting, it has everything I need for my family… and yes, it absolutely would be better 10 degrees cooler ;)
Re: one swimming pool per child project: when can you start?
I live in Houston and would rather it be 10 degrees warmer than have to deal with 32258 additional mosquito spawning pools. The heat isn’t the worst part of Houston, most long term Houstonians are used to it. You never get used to mosquitos, especially Aedes aegypti.
Everything I just read makes me thankful that I never had to touch one of these apps before I got married. Out of all social media, dating apps have to be the most dystopian. Technology can be a force for creating deeper human connections, but this ain’t it… and I say that as someone who first connected with my wife in an online community before meeting in real life.
With that being said, I’m thankful if this hack is the start of a wonderful relationship for someone out there :)
I work in the medical device industry and most people on my team have engineering degrees and extensive experience with Matlab. Pretty much all of them would flip their table if they had to write numerical/scientific code in Rust, even though it arguably has a more robust type system.
In my experience starting with Julia in 2025, the main thing missing from the ecosystem tends to be boring glue type packages, like a production grade gRPC client/server. I heard HTTP.jl is also slow, but I havn't sufficiently dug into this myself. At least we have an excellent ProtoBuf implementation so you can roll your own performant RPC protocol.
As for the actual numerical stuff I tend to roll my own implementations of most algorithms to better control relevant tradeoffs. There are sometimes issues where a particular algorithm is implemented by a Julia package, but has performance issues / bugs in edge cases. For example, in my testing I wasn't able to get ImageContrastAdjustment CLAHE to run very fast and it had an issue where it throws an exception with an image of all zeros. You also can't easily call the OpenCV version as CLAHE is implemented in OpenCV using an object which doesn't have a binding available in Julia. After not getting anywhere within the ecosystem I just wrote my own optimized CLAHE implementation in Julia which I'm very happy with, this is truly where Julia shines. It's worth noting however that there are many excellent packages to build on such as InterprocessCommunication, ResumableFunctions, StaticArrays, ThreadPinning, Makie, and more. If you don't mind filling in some gaps here and there its completely serviceable.
As for the core language and runtime we are deploying a Julia service to production next release and haven't had any stability/GC/runtime issues after a fairly extensive testing period. All of the Python code we replaced led to a ~40% speedup while improvements to numerical precision led to measurably improved predictions. Development with Revise takes some getting used to but once you get familiar with it you will miss it in other languages. All in all it feels like the language is in a good place currently and is only getting better. I'd like to eventually contribute back to help with some of the ecosystem gaps that impacted me.
Waiting 15+ seconds to test small changes to my PyTorch training code on NFS is rather annoying. I know there are ways to work around it, but sometimes I wish we could have a training workflow similar to how Revise works. Make changes to the code, Revise patches it, then run it via a REPL on the main node. Not sure if Revise actually works in a distributed context, but that would be amazing if it did. No need to start/fork a million new Python processes every single time.
Of course I would also rather be doing all of the above in Julia instead of Python ;)
Mine did the same for image processing but coming from python/numpy/numba. We initially looked at using Rust or C++ but I'm glad we chose to stick it out with Julia despite some initial setbacks. Numerical code flows and read so nicely in Julia. It's also awesome seeing the core language continuously improve so much.
I've found that I'm most productive in Julia when minimizing the number of third party dependencies for this reason, even more so than other languages. That's not to say there are not many high quality packages available but rather the benefits of the type system align better when I have a strong understanding or control over the most pertinent interfaces. As a language Julia definitely rewards you heavily for this type of thing. Coming from Python my first instinct was to try to solve as many problems as possible with third party packages and filling in between the lines. Unsurprisingly this was the worst of both worlds.
If there was one thing I could change about Julia it most certainly wouldn't be correctness issues in my own experience. Filling in the ecosystem in terms of boring glue type stuff like a production grade gRPC client would be amazing. This was the type of problem that almost got me to give up on the language.
Technically you don't need to know what array indexing is being used if you iterate using firstindex(arr):lastindex(arr). AFAIK the issue was that this wasn't consistently done across the Julia ecosystem including parts of the standard library at the time. No clue as to whether this still holds true, but I don't worry about it because I don't use OffsetArrays.