# I find it hard to develop in Julia

**URL:** <https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497>\
**Category:** Internals & Design\
**Created:** [February 6, 2026, 11:25am UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497 "2026-02-06T11:25:19Z")\
**Posts on this page:** 13\
**Page:** 4

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [February 10, 2026, 12:58pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/61 "2026-02-10T12:58:28Z")

</div>

> [@juliohm](#):
>
> incomplete tooling

[JETLS.jl](https://github.com/aviatesk/JETLS.jl) is already a big step forward, even though it is still a work-in-progress.

And [Flexible Julia](https://plugins.jetbrains.com/plugin/29356-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.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [February 10, 2026, 1:03pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/62 "2026-02-10T13:03:54Z")

</div>

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](https://discourse.julialang.org/t/taking-ttfx-seriously-can-we-make-common-packages-faster-to-load-and-use/74949), debugging tools, … ?).

---

<div class="post-metadata">

**Author:** ![xgdgsc](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/xgdgsc/32/608_2.png) [@xgdgsc](https://discourse.julialang.org/u/xgdgsc)\
**Post date:** [February 10, 2026, 1:06pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/63 "2026-02-10T13:06:05Z")

</div>

Why is precompilation time a problem? [LangArena - Programming Languages Benchmark Comparison](https://kostya.github.io/LangArena/) 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.

---

<div class="post-metadata">

**Author:** ![langestefan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/langestefan/32/207923_2.png) [@langestefan](https://discourse.julialang.org/u/langestefan)\
**Post date:** [February 10, 2026, 1:20pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/64 "2026-02-10T13:20:55Z")

</div>

> [@Tamas\_Papp](#):
>
> Can you, or the OP, please explain what specific tooling you are missing?

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…

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [February 10, 2026, 2:29pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/65 "2026-02-10T14:29:52Z")

</div>

> [@juliohm](#):
>
> people forget how long pre-compilation and incomplete tooling are even more serious issues from the view point of a beginner.

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.

> [@juliohm](#):
>
> However, they **feel** the slowness when they hit Enter in a script or Pluto notebook.

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.

> [@xgdgsc](#):
>
> Why is precompilation time a problem?

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.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [February 10, 2026, 8:36pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/66 "2026-02-10T20:36:51Z")

</div>

> [@Satvik](#):
>
> I guess a big question for me is where, concretely, donations might help with agenda like “document breaking changes more clearly” or “improve documentation”? I understand there’s always more work than people available to do it. We were able to make some donations last year, and hopefully will make some more in the end of 2026.

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

> **[Small Development Grants - NumFOCUS](https://numfocus.org/programs/small-development-grants)**
>
> Our open source projects are used on a daily basis by millions, yet appropriate resources to support and sustain these projects are still lacking.

SciML also has their own listing:

> **[SciML: Open Source Software for Scientific Machine Learning](https://sciml.ai/small_grants/)**
>
> Open Source Software for Scientific Machine Learning

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.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [February 10, 2026, 9:21pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/67 "2026-02-10T21:21:59Z")

</div>

> [@fonsp](#):
>
> And the end result? If you’re unlucky (like me), a slightly worse experience for my users with [higher](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429) [startup](https://discourse.julialang.org/t/startup-time-of-1000-packages-53-slower-in-julia-1-12-vs-1-10/128343) [times](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/26) and a higher memory footprint.

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?

---

<div class="post-metadata">

**Author:** ![skypuppy](https://avatars.discourse-cdn.com/v4/letter/s/54ee81/32.png) [@skypuppy](https://discourse.julialang.org/u/skypuppy)\
**Post date:** [February 11, 2026, 5:07pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/68 "2026-02-11T17:07:57Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![langestefan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/langestefan/32/207923_2.png) [@langestefan](https://discourse.julialang.org/u/langestefan)\
**Post date:** [February 11, 2026, 5:15pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/69 "2026-02-11T17:15:42Z")

</div>

> [@skypuppy](#):
>
> 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.

what does that mean?

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [February 11, 2026, 6:57pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/70 "2026-02-11T18:57:45Z")

</div>

> [@skypuppy](#):
>
> My opinion, as a simple programmer/coder/designer, is that “internals” be not only disallowed, but completely removed from the Julia world.

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

> <https://github.com/JuliaLang/julia/issues/52314>
>
> \_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.

> <https://github.com/JuliaLang/julia/issues/54903>
>
> 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.

---

<div class="post-metadata">

**Author:** ![apieum](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/apieum/32/2928_2.png) [@apieum](https://discourse.julialang.org/u/apieum)\
**Post date:** [February 13, 2026, 6:26pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/71 "2026-02-13T18:26:21Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Mason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mason/32/2423_2.png) [@Mason](https://discourse.julialang.org/u/Mason)\
**Post date:** [February 13, 2026, 6:32pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/72 "2026-02-13T18:32:34Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [February 14, 2026, 1:00pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/73 "2026-02-14T13:00:20Z")

</div>

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

[Previous page](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497.md?page=3)