I find it hard to develop in Julia

ufechner7 · February 10, 2026, 12:58pm

JETLS.jl is already a big step forward, even though it is still a work-in-progress.

And Flexible Julia might become an alternative for professional developers, because development is very fast, and bug reports and feature requests are often addressed within a few days.

stevengj · February 10, 2026, 1:03pm

Setting a topic timer — we prefer focused threads on specific topics, and this thread is just turning into a grab bag (documented vs undocumented APIs, allocation tracking, REPL tab completion, TTFX, debugging tools, … ?).

xgdgsc · February 10, 2026, 1:06pm

Why is precompilation time a problem? LangArena - Programming Languages Benchmark Comparison When you think of the overall workflow, precompilation time feels just as safe and sound as Rust and Cpp compile time. And the Revise experience is much better.

langestefan · February 10, 2026, 1:20pm

Wanted to write a long response, but I realize it’s just all the obvious things again. The main one for me is unit testing, we are a long way from the convenience of pytest and TDD in Julia is practically impossible due to precompilation (yes Revise.jl helps). Then there is the language server, which fortunately is much better now thanks to the development of JETLS. Then static type checking, fortunately there is now JET.jl which has helped me a lot. And lastly, I think we need some tooling to help make stacktraces more readable/actionable. You could make a separate topic about tooling because there is a lot to say…

Benny · February 10, 2026, 2:29pm

No we didn’t, we just had a few threads 2-3 weeks ago complaining about precompilation that didn’t have any new insights since the last complaint, so people probably just didn’t have anything to add for now. Something interesting then that seemed to have gotten glossed over is a Pluto notebook appeared to be updating dependencies relative to its stored manifest and forcing repeated precompilation, which stood out to me as unusual and problematic.

That’s only partially a precompilation issue. Scripts and notebooks themselves don’t make package images from precompilation workloads, so part of the latency is just JIT compilation. I’ve taken to making a local “package” just to cache a custom workload for a finished script, but that wouldn’t help any work in progress. I’m not sure how JIT compilation latency can be mitigated there; some code edits to a script or notebook invalidate methods, and recompiling them is the point.

If you mean that all compiled languages have to compile at some point, then there’s some truth to that. However, it’s far easier to distribute and reuse distinct AOT-compiled binaries with moderately different versions of dependencies, whereas we’re locally making very particular Julia environments where a dependency can only reasonably have 1 version because compilation is ongoing by design.

mkitti · February 10, 2026, 8:36pm

For specific tasks, there is a Small Development Grants system via NumFOCUS:

SciML also has their own listing:

While I think small development grants are nice to have, I also think that having companies that use Julia donate developer or non-developer time to address general community issues may be more sustainable over time than a gig-work approach. For example, for documentation, it may make sense to pay a professional technical writer.

In the agentic agent era, it may be especially helpful to make it clear what the outstanding tasks are, what the succcess criteria are, and how to contribute. Directly or indirectly a donation of agent tokens may be useful and able to handle some of the tasks.

mkitti · February 10, 2026, 9:21pm

It is not clear to me that every stable release needs to have less or equal startup times and a less or equal memory footprint than the previous release. I do understand why that might be desirable.

To me the issue is communication. What are the goals of the next release? Is the goal to add new features or to optimize compile times and memory footprint. If I understand these goals, I might be able to make decisions for myself better about whether I care about the new features more than I care about optimized behavior. I can then make an informed decision whether to use the LTS release or not.

Addressing the issue of compile times itself, I think we may need to consider binary distribution for some packages and architectures. Could we precompile packages for common architectures and distribute those precompile caches? Can we build tools that would allow us to do this locally?

skypuppy · February 11, 2026, 5:07pm

My opinion, as a simple programmer/coder/designer, is that “internals” be not only disallowed, but completely removed from the Julia world.
I only started programming in 1977 commercially, and this entire thread makes my brain hurt. Further, I cannot recommend a language I have huge investment in yet still have yet to write more than 3 lines of code in the REPL, to anyone searching for better tools.
To be blunt.

langestefan · February 11, 2026, 5:15pm

what does that mean?

mkitti · February 11, 2026, 6:57pm

I believe that is part of what has been proposed for strict mode:

github.com/JuliaLang/julia

Disallow access to internals (unless overridden)

opened 05:19PM - 27 Nov 23 UTC

LilithHafner

design feature

_Originally posted by @StefanKarpinski in https://github.com/JuliaLang/julia/iss…ues/49973#issuecomment-1828231790_ Not breaking existing code limits what we can do. However, there's a decent argument to be made that since what's breaking is not a public API, blocking access to package internals is not actually technically breaking according to semver. Of course, we still have to be cautious to prevent massive ecosystem breakage. It would not go well to just flip the "no private access" switch for the whole ecosystem at once. Here's a possible transition strategy: 1. Allow packages to opt into preventing access to their private internals. This should probably be a flag in the project file, but should maybe also be in the registry. There are three cases for a project that depends on a package that blocks private access: 1. Project doesn't access internals so there's no problem; 2. Project accesses internals but can easily use a public API instead—minor fix required; 3. Project accesses internals and can't easily use a public API instead—can't be easily fixed. 2. To handle the last case, we also allow projects to override one of their dependencies blocking private access. A project opting into this acts as an explicit indicator that non-breaking upgrades can break. 3. For a while make the flag for whether private access is allowed or not mandatory—you can choose yes or no but you need to have some value in the project file. 4. Later we change to preventing private access by default. Projects can drop the flag if the value is to block private access since that's the new default and only packages that need to allow private access need to keep the flag in their project files. I'm not sure about the implementation side. If we can control module internals access per depender that would be ideal. That suggests that private/public needs to be metadata associated with the binding itself, which is kind of gnarly. Maybe we can do something with auto-wrapping each package in a public-only wrapper that rebinds only the public bindings of the internal package. That's the simplest to implement, but feels kind of icky. Having public/private annotations on fields in structs would also be good, but I'm not quite ready to tackle that.

github.com/JuliaLang/julia

Add `strict` mechanism for opting into stricter subsets of the language

opened 12:48PM - 23 Jun 24 UTC

Keno

design feature

We've had a few discussions the past few weeks about a feature tentatively dubbe…d `pragma strict` after similar constructs in other languages. However, there wasn't really a cohesive writeup of the intent, so triage asked me to write one up to serve as the basis for discussion and fleshing out. I intend to edit this issue as the idea evolves. ## Basic idea The basic idea of the `pragma strict` feature is to have an opt-in mechanism of turning julia programs that are semantically valid, but undesirable for other reasons (e.g. using ambiguous syntax that should have arguably been disallowed, but we can't for backwards compatibility reasons) into errors. This would be an opt-in feature for developers who have personal, organizational or regulatory requirements for requiring stricter coding standards. An additional motivation is to provide an additional vehicle for low-frictition language evolution. For example, if a specific opt-in turns out to be popular across the majority of packages, a potential julia 2.0 that made the opt-in automatic while technically breaking, would be largely non-breaking in practice. We are not imagining a single `strict mode` opt in here, but rather a finer grained set of options, plus versioned collections of options for particular use cases. See the last section for a an initial list of such options. It is worth emphasizing again that this feature is only intended to disallow undesirable programs that are otherwise semantically valid. It is not intended to cause meaningful semantic differences in programs that are valid both in standard semantics and under the opt-in restrictions (i.e. turning on the restrictions may cause things to error, but if they don't the program should behave the same). ## How does the opt-in work? One of the primary questions in this proposal is how the user expresses the opt-in. There's a few separate semantic options, each with a number of potential syntax options. 1. Per module opt-in like our existing `Experimental.@compiler_options` 2. Per file opt-in (e.g. using a magic comment on the first line) - popular in some other languages 3. Per project opt-in in Project.toml After some discussion on triage, a Project.toml-level opt-in seems like the best option. The primary motivation here is to allow opt-ins that need to be done in the parser (e.g. whitespace requirements). We don't currently define the execution ordering of parsing and execution for packages, so a module-toplevel opt-in may be semantically too late (relatedly, it may be ambiguous what happens when the opt-in is placed in the middle of a disallowed parse). An additional concern is that ideally IDE tooling would be able to understand the active set of restrictions without having to look at the code. ## Concrete Project.toml syntax options One convenient option would be reusing Preferences.jl. One might imagine a julia-level preference like: ``` name = "MyPackage" [preferences.julia] strict = ["nomultiassign", "uniqueidentifiers"] ``` This doesn't fully mesh with the usual preferences semantics, since preferences are ordinarily uniqued per-UUID while they would be private for a particular package, but this might be ok. Alternatively, we could reserve the `strict` key in each individual package's preference table: ``` name = "MyPackage" [preferences.MyPackage] strict = ["nomultiassign", "nolocalshadow", "noglobalshadow"] ``` Alternatively, we could have a new top-level `strict` section: ``` name = "MyPackage" [strict] julia = ["nomultiassign", "nolocalshadow", "noglobalshadow"] ``` ## Initial idea list for opt-in options In this section, I'm collecting a list of potential options that might be implemented. However, I am not at this point asking people to brainstorm all the possibilities that could be implemented. I'm also not asking for detailed discussion on what should or should not be included in a particular option. Rather, I wanted to have a place to list all the ideas that have already come up and a place to link any issues that could be addressed by this feature. Full design discussions for individual flags can be had on the PRs to implement them once the overall mechanism is in place. ### Individual options - `nomultiassign` Disallows multiple assignments in the same expression without parantheses. I.e. disallows `a = b, c = d, e, = f = (1, 2)` - `nolocalshadow` Disallows shadowing of local variables, e.g. in the following ``` function foo() for i = 1:10 for i = 1:10 # Error shadowing local `i` end all(1:10) do i # Error shadowing local `i` iszero(i) end end end ``` - `noglobalshadow` Disallows shadowing of global variables, e.g. in the following: ``` function foo() missing = false # Error local `missing` shadows imported global `missing` end ``` - Some variant of unique assignment Stefan had proposed introducing a unique assignment operator, e.g. `:=` for which there would then be a corresponding opt-in to enforce all assignments use it - Enforce export versioning If we implement some variant of export versioning, there could be an opt-in forbidding unversioned exports. - Enforcing `import` for types: #25744 - Requiring explicit undef markers for undefined variables in `new`. - https://github.com/JuliaLang/julia/issues/12069 - https://github.com/JuliaLang/julia/issues/14952 ### Collections The idea of collections is that users in general don't want to individually decide which opt ins matter to them, but will likely be following a standard set by their organizations or prescribed by a style guide. To this end, there could be meta opt-ins like "basestyle", which would activate a standard collection of opt-ins. These collections should be versioned and activated based on the min-compat version of Julia. In this way, new opt-ins can be added to a collection, without automatically activating them on a julia version upgrade.

apieum · February 13, 2026, 6:26pm

Sometimes it helps to rethink the boundaries.

A refactoring approach that has worked for me is to move that instability into a single shim layer:
– specify the exact behavior you rely on (via tests),
– isolate it behind a small interface,
– vendor/duplicate only the minimal internal logic needed there,
– and confine Julia-version adaptations to that boundary.

In similar situations, this reduced patch churn and clarified ownership of the contract.

Mason · February 13, 2026, 6:32pm

This approach also has the benefit that it lets you potentially share the maintenance burden of the shim with other people who have similar problems to you.

stevengj · February 14, 2026, 1:00pm

This topic was automatically closed after 3 days. New replies are no longer allowed.

Topic		Replies	Views
What don't you like about Julia for "serious work"? Community	179	25056	April 20, 2024
Reflections on Developer Experience After Building a Large Julia Codebase General Usage	33	2704	January 11, 2026
List of most desired features for Julia v1.x Community gripes , suggestions	182	24922	November 17, 2017
Forward compatibility and stability of Julia vs. Packages General Usage	97	4081	August 27, 2023
Would slowing Julia's release cadence improve ecosystem quality? Community	98	5663	September 15, 2023

I find it hard to develop in Julia

Related topics