Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Using juliac without --trim=safe took over 1 minute to compile a hello world program, and took the same for a second compilation with no source change. Without --trim you can't use dynamic types, which rules out even println without explicitly giving it a Core.stdout argument. I'll come back in a year or so to see if it's become usable.by jibal
- All I ever wanted from Julia was great a development experience, but it appears to have never quite gotten there.
As a language it has gotten there a long while ago (1.6 LTS series comes to mind).
The landscape has changed substantially since then, and now "ergonomics" has unfortunately taken lower priority due to agent-driven development.
Nevertheless I think everyone should take a page from Go's book, really, language design now should include the default development workflow.
by vitorsr - > All I ever wanted from Julia was great a development experience, but it appears to have never quite gotten there.
I feel you. After AOT support (it is improving; slowly, but still) my biggest gripe with Julia is tooling/dev experience. VSCode extension performance is abysmal. Debugging support is delegated to some external package and this debugger has to ship with its own interpreter, and download additional packages. Like, why the hell I need to download few packages just to have a debugger?
I keep track of what is going on and play with it sometimes, but to me Julia will remain a curiosity, even though the language itself is actually fun, with many good ideas (and some bad ones). Also, "two language problem" is not a problem for me.
by wolvesechoes - What makes you say that ergonomics have taken a lower priority? A lot of the things mentioned in this blogpost are ergonomic things that don't matter for agentic workflows.
Maybe it'd help me understand if you said what sort of ergonomic things you find are missing.
by eigenspace - > Faster GC by skipping image objects during marking
This one in particular I feel like we are inching towards in Python land. I had some really interesting convos from people who really want forking to "just work" and get actual memory savings, because a lot of code is really going to be in memory forever and if we can opt out of refcount work that'd be great
by rtpg - Current discussion, https://news.ycombinator.com/item?id=49651384by brudgers
- Julia would have seen more adoption with:
--> proper learning resources for beginners, but also for intermediate and advanced users. As of now resources are relatively sparse, compared to what you would find in the Python world.
--> a dedicated IDE. Python has several.
Otherwise it's a great clean language, faster and more elegant than Python. It's a shame it got stuck in Python's shadow.
by jan_m_savage - We've tried our hand at writing such a resource for Julia's tooling and workflows:by funks_
- I really like Julia, but I wind up not using it as much as I might otherwise because the startup time kills it for many use cases (though of course it's easily amortized in others).by MarkusQ
- I think there's a very bright future in this regard :)
1.13 is, to-date, the release with the fastest startup times. and AOT compilation continues to be a serious priority for upcoming releases
- I love Julia, but I feel two annoyances right now with the ecosystem.
Interactive programming seems to be having a schism between Pluto, a reactive notebook like Observable, and Bonito, a more imperative notebook like Jupyter from the creator of plotting library Makie.
The other annoyance is that the packaging ecosystem is tied very closely to Github and Gitlab as the only alternative, in an era where Microsoft is killing Github reliability, and many new projects are moving to Tangled (on the AT Protocol network) and Forgejo (with Codeberg as the flagship), which has no packaging support from JuliaHub.
- I have always used Jupyter to work in Julia. Beside .jl files, of course.
Same habit with Python.
The Ju in Jupyter does stand for Julia, you know.
Pluto was a meh experience and I didn't keep using it.
by __rito__ - The third for me is that LLM usage has exploded for the development of core Julia itself (just look at the PRs).
- I'm not sure there is anything tying Julia packaging to Github directly other than that that is where some projects are based. There is some integration with git, but any git host should do.by markkitti
- The package system typically uses a git URL and tree hash to identify a package version. It supports private registries.
Is it really tied to github or is that just the path documented in tutorials?
by andyferris - There seems to be some work on GitForge.jl related to improving the compatibility with Forgejo/Codeberg. I bet as Github continues to go downhill we will see more of an effort to improving compatibility with forges.by MrJulia
- I would add the loose definition of interfaces, because it is hard to tell if you have implemented everything or not. (The compiler does not check, you have to write extensive tests.) It's one of the reasons why I am using Julia only for small personal projects but not for larger codebases.by ziotom78
- Due to how the release cycle turned out, most new major features got pushed to v1.14, and this one is a rather iterative release focused on making various things faster, quashing bugs, and general polish.
Still though, faster GC, lower startup latency, better interrupt handling, new REPL features, and faster package mangement are all great things. I'm especially happy that the `[sources]` section of a package is now applied recursively when you `add` a non-registered package.
by eigenspace - In Java, C# and C++ land, there are equally features that take several years to finally land.
I think it is perfectly fine that Julia folks take their time as well.
by pjmlp - Over the last three years I have been doing a focussed investigation of a lot of different programming languages and styles (about 38 last count). I was reflecting over the weekend which one I really liked best. Not really for features or functionality or toolset just which one felt 'right'. Julia came out on top as the one language I wanted to play with more and I wish could give a reasoned well justified argument for it but it's really just a feeling. The right mix of intelligent design, power, absence of evangelical idiocy, and a pleasing interface. So nice to get that feeling validated from the random workings of the world and see this release message this morning. Thanks Julia team.by zuluonezero
- As you mentioned 38 languages, chances are high that these languages are not all coming from a scientific background, where 1 index based adressing of items is the norm. What is your take in respect to Julia, which is also one offset based?by jhoechtl
- To me it seems as if scripting languages have it hard right now, aside from Python.
AI seems to have changed how people find and use new languages. The influx of new people kind of ... died down for many older languages here.
by shevy-java - Same, Julia really does just feel right to me. Which makes sense since I mostly program in R.by mulderc
- I liked Julia the first time I tried it years ago. I had some Matlab experience, so it seemed a similar, yet great improvement (no cost! more modern, but lacking some key libs or toolkits). I started programming Commodore BASIC in 1977 on my PET 2001. Then 6502 Assembler/machine language, C, Turbo Pascal, and many more. I have recently gone back to assembler because of AI. I don't miss hand coding assembler or creating macros that don't exist in FASM, but AI allows me to prompt for a terse program, using tried and true asm methods, which I can then audit. Julia has great math and scientific libraries, so my asm stuff isn't in competition with my asm efforts, but I am really enjoying the asm/AI thing for now. Granted this is for my own small projects. Coding is not my main job. I use coding in my other jobs to help me with certain tasks like scheduling, simulations, engineering, and project management. I was playing with the Julia version of cadCAD that was on Python, however, Julia has a lot of other libs that are way better to do dynamic or complexity studies than cadCAD.by eggy
- > Over the last three years I have been doing a focussed investigation of a lot of different programming languages and styles
I don't know what your invesitgation covers, but a long time ago (2009) someone [0] did an interesting visual comparison of languages. sadly now it seems it's only available at archive.org [1], but I've often gone back to it, partly because it's such an elegant way of looking at some aspects of different languages.
0: http://blog.gmarceau.qc.ca 1: https://web.archive.org/web/20100412073334/http://blog.gmarc...
by niccl