# 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:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![franckgaga](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/franckgaga/32/218241_2.png) [@franckgaga](https://discourse.julialang.org/u/franckgaga)\
**Post date:** [February 7, 2026, 1:56am UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/21 "2026-02-07T01:56:11Z")

</div>

You entirely summarized my feeling toward the language in the last year. Thanks for this thorough explanation about tooling and unreliability. A recent example is the lag in the REPL TAB completion (v1.12.4). Although it seems to be fixed in the next release, it’s hard to persevere as the language grows, when the user experience is randomly and periodically affected like this.

I love the mix of runtime performance, interactivity and built-in linear algebra. But, after too much struggle, we get to a point where we wonder: is it worth it? Should I go back to the good ol’ reliable-but-bulky-and-expensive MATLAB ?

edit: love the watercolor painting BTW ❤

---

<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 7, 2026, 3:30am UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/22 "2026-02-07T03:30:49Z")

</div>

Is there many people who rely on REPL TAB completion? I’ ve never used that. If most people use vscode the completion experience is kind of OK. And the newly release [jetbrains plugin](https://plugins.jetbrains.com/plugin/29356-flexible-julia) is even more polished in the completion feature. I’ d encourage everyone to try it out and interact with the developer to make it even better.

---

<div class="post-metadata">

**Author:** ![franckgaga](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/franckgaga/32/218241_2.png) [@franckgaga](https://discourse.julialang.org/u/franckgaga)\
**Post date:** [February 7, 2026, 3:51am UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/23 "2026-02-07T03:51:20Z")

</div>

I don’t want to diverge too much on the main thread, but yes, it’s a new feature, but, once you get used to it, you get spoiled 😆. I rely on it heavily to explore what are the fields of a specific `struct`, or the sub-module of a module. In a perfect world as a user, we should not rely too much on the fields, but, hey, we are in an imperfect world (as I’ve heard frequently in the pythonic world, we are all consenting adults, private attributes are for the feeble XP). Also, if the tooling e.g. intellisense completion in VS code was working as intended (I assume issues with the LSP), REPL completion would not be as crucial as it is right now.

All this ramble to say that I need to test the new jetbrains plugin. It seems awesome, but I need to learn a new IDE once more, that may explain why I’m doing procrastination on this 😄

---

<div class="post-metadata">

**Author:** ![franckgaga](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/franckgaga/32/218241_2.png) [@franckgaga](https://discourse.julialang.org/u/franckgaga)\
**Post date:** [February 7, 2026, 4:40am UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/24 "2026-02-07T04:40:05Z")

</div>

> [@fonsp](#):
>
> ![watercolor of a twig](https://global.discourse-cdn.com/julialang/original/3X/c/1/c1acf5c32afb71c90abb2570266b70c14f38450b.jpeg)

Worth a repost ^^

---

<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 7, 2026, 5:10am UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/25 "2026-02-07T05:10:14Z")

</div>

> [@cuihantao](#):
>
> I don’t understand the need for such complexities.

It eventually got [an official history](https://docs.julialang.org/en/v1/manual/variables-and-scoping/#on-soft-scope). The global/local difference in variable scoping prevents unintentional reassignment of a global variable we forgot about in an earlier evaluated file or session history; we don’t need this protection for local variables because they’re visibly contained in one expression unless we’re abusing macros to paste variable assignments. Before v1, this applied to some scopes but not others (hard/soft), and v1.0 applied it to all scopes for consistency. But people complained about not being able to write or paste code between local and global scopes for equivalent behaviors and took measures to bring back the pre-v1 behavior, so v1.5 brought the pre-v1 rules back for the REPL and notebooks as a compromise.

The motivation for a unique explicit declaration is consistency: assignments in a local scope that doesn’t declare the variable as new or `global` must find the variable in the nearest outer scope, whether local or global. Two declarations in a scope is a potentially static error, but it needs to be a runtime error for `eval`s and conditional declarations. Obviously I didn’t think this through and there are reasonable debates over this; accidentally omitting an explicit declaration would silently reassign an outer, possibly global variable, and it needs to be easily written to avoid bloat (imagine writing code with only explicit `local` statements now). I don’t remember who, but a suggestion I liked was a reduced almost-inverse of BPCL: `x=...` would be strictly reassignment, and `x:=` would be shorthand for a typed declaration `x::Any=`. But that’s very breaking, type declarations on the left or right sides of assignments in v1 don’t declare new variables.

> [@bvdmitri](#):
>
> At this point, Julia without Revise is barely usable for iterative development. That raises the question of whether such a critical tool should really live outside the core language, especially if it can remain partially broken for extended periods.

It’s good for critical tools to live outside a core. Modularity means people can choose what they use and parts can be swapped out. However, they can be developed in tandem and promoted for better user experience.

---

<div class="post-metadata">

**Author:** ![jakobjpeters](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jakobjpeters/32/207797_2.png) [@jakobjpeters](https://discourse.julialang.org/u/jakobjpeters)\
**Post date:** [February 7, 2026, 5:53am UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/26 "2026-02-07T05:53:19Z")

</div>

> [@Benny](#):
>
> > [@Satvik](#):
> >
> > in Julia 1.12, apparently the way command macros worked changed, which broke [SQLStrings.jl](https://juliaregistries.github.io/General/packages/redirect_to_repo/SQLStrings)
> 
> Never wrote a command macro before, what change should I know about? (If it’s easier, could just add a link for me to read).

I second this question 😃

---

<div class="post-metadata">

**Author:** ![nilshg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nilshg/32/2283_2.png) [@nilshg](https://discourse.julialang.org/u/nilshg)\
**Post date:** [February 7, 2026, 7:50am UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/27 "2026-02-07T07:50:42Z")

</div>

> [@bvdmitri](#):
>
> Given how essential Revise is to productive Julia development, this is a serious issue. At this point, Julia without Revise is barely usable for iterative development. That raises the question of whether such a critical tool should really live outside the core language, especially if it can remain partially broken for extended periods.

There are plans to integrate Revise into core Julia and a standard lib, see

> <https://github.com/timholy/Revise.jl/issues/951>
>
> I seems well past time to move something as critical to the Julia experience as …Revise to an org and given how coupled it is with Julia internals and how fundamental it is to may workflows, JuliaLang seems like the most apt place for it. What do you think, @timholy?

---

<div class="post-metadata">

**Author:** ![biona001](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/biona001/32/16497_2.png) [@biona001](https://discourse.julialang.org/u/biona001)\
**Post date:** [February 7, 2026, 8:25am UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/28 "2026-02-07T08:25:51Z")

</div>

I share your sentiment. I’m fairly certain my packages 2-3 years ago will simply not run on the latest release.

This feeling definitely sucks, not just because fixing them takes more than a few minutes (so I prob won’t do it), but because it feels like all my efforts in the past have been wasted. My code was working at some point – then BAM somebody does something – and now it broke forever

---

<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 7, 2026, 2:28pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/29 "2026-02-07T14:28:11Z")

</div>

> [@bvdmitri](#):
>
> After fixing those another tests started to fail in a different code path. This appears to be a subtle interaction between `@test` and `@allocated`, but there is no straightforward way to diagnose it.

I have seen this too. The allocs were only present when running from `] test`, and even weirder, the number of allocs would change every time I re-ran `] test`! This started suddenly appearing in 1.12.3. How do you even debug something like that?

---

<div class="post-metadata">

**Author:** ![j-fu](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/j-fu/32/11373_2.png) [@j-fu](https://discourse.julialang.org/u/j-fu)\
**Post date:** [February 7, 2026, 3:26pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/30 "2026-02-07T15:26:41Z")

</div>

This might be connected with [Allocations in 1.12 with --check-bounds=yes · Issue #58634 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/58634) .  
It seems to be solved for 1.13. and I am not sure if a backport to 1.12 is possibe/planned.

---

<div class="post-metadata">

**Author:** ![LeePhillips](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/leephillips/32/205514_2.png) [@LeePhillips](https://discourse.julialang.org/u/LeePhillips)\
**Post date:** [February 7, 2026, 3:44pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/31 "2026-02-07T15:44:09Z")

</div>

I’m surprised to learn there are many people who _don’t_ use the REPL’s TAB completion.

---

<div class="post-metadata">

**Author:** ![bvdmitri](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bvdmitri/32/22935_2.png) [@bvdmitri](https://discourse.julialang.org/u/bvdmitri)\
**Post date:** [February 7, 2026, 5:10pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/32 "2026-02-07T17:10:01Z")

</div>

> [@Mason](#):
>
> Pluto is a project that had a lot of interest from developers early on, but various design choices and communications from you (which of course you are completely within your rights to make), have made it clear that you **dont** see pluto as a tool for developers

> [@Mason](#):
>
> it does have the side-effect that it makes it so that the people who tend to develop the language are not paying much attention to Pluto

This statement was somewhat frustrating to read. I’m not sure why it should matter whether a tool is explicitly aimed at developers or not. For example, ForwardDiff.jl isn’t really a tool _for_ developers of the language either and that’s perfectly fine. I could even argue that the REPL itself isn’t a developer-facing tool in that sense (Julia isn’t developed in the REPL, nor are most large packages), yet it still receives a lot of care and attention.

One of the reasons Python has become so widely adopted is that it successfully attracted beginners and people who were simply curious about programming. Today it’s a de facto **educational tool** in universities around the world. Its low barrier to entry make it very approachable before users dive into more technical details.

In that light, Pluto plays a very positive role. It lets people try Julia with minimal friction, and that alone creates meaningful _personal stake_ for Julia developers. From a Julia ecosystem perspective, that seems like a clear win: making it easier for more people to try Julia ultimately benefits the language and its developers as well.

---

<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 7, 2026, 6:23pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/33 "2026-02-07T18:23:10Z")

</div>

I feel you’ve missed my point. I was not making a normative statement about how I _wish_ julia was developed, I was talking about how it is developed in practice (at least as far as I can tell – note I am not a core language developer by any means).

I know you’ve [made it very clear in other threads](https://discourse.julialang.org/t/where-is-julia-heading-lack-of-clarity-about-priorities-long-term-direction-and-governance/133734) how you wish the language development was handled. The reality is that development of the language is highly decentralized, and there is no Czar barking orders and coordinating things according to some master plan.

The language’s development happens much more along the lines of individual people taking on projects that they themselves decide are important for them to work on. These people are often are not deciding to go and put extra effort or attention towards tools they don’t use or care about, even if they think the tool is somehow “important”.

There really does not seem to be much thinking along the lines of

> “if we develop \_\_\_, \_\_\_, and \_\_\_, it would have \_\_\_\_ effect on the community and help grow the language user-base”.

At least as far as I can tell, the thinking appears much shorter term, less strategic, and less coordinated than that.

Clearly something has to be done here. The question, given the apparent lack of coordination, is how to we reach some sort of agreement on what **should** happen, and then how do we make people actually **do** that thing that there’s some apparent consensus about?

---

<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 7, 2026, 6:28pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/34 "2026-02-07T18:28:43Z")

</div>

Sidenote, but this is a rather amusing example you chose:

> [@bvdmitri](#):
>
> I’m not sure why it should matter whether a tool is explicitly aimed at developers or not. For example, [ForwardDiff.jl](https://juliaregistries.github.io/General/packages/redirect_to_repo/ForwardDiff) isn’t really a tool _for_ developers of the language either and that’s perfectly fine.

because it highlights exactly the point I was trying to make (but probably I wasn’t clear enough).

Autodiff is super important to many many people in the julia community, and yet almost all of our autodiff tools except ForwardDiff.jl keep breaking. Zygote.jl was the latest fatality.

So why is ForwardDiff.jl working fine but Zygote.jl isn’t? Because ForwardDiff.jl is built on public, stable APIs, whereas all the “exciting” AD systems are built on the ever-shifting sands of internal compiler-APIs.

ForwardDiff.jl’s stability has nothing to do with the language devs trying to make sure they accommodate it, and a lot of people who rely on AD tools share very similar frustrations to the ones expressed by Fons above. Just a few weeks ago there was a kvetch-fest on the `#autodiff` Slack channel where people were making similar points, and wondering if there’s some way to convince the devs to stabilize the compiler internals, or at least communicate better when they do decide to change how compiler internal APIs work.

---

<div class="post-metadata">

**Author:** ![cuihantao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cuihantao/32/8783_2.png) [@cuihantao](https://discourse.julialang.org/u/cuihantao)\
**Post date:** [February 7, 2026, 7:09pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/35 "2026-02-07T19:09:49Z")

</div>

I guess some folks are more used to a file-based development workflow, where whatever runs is automatically saved to files. That is probably more common for library developers. In a REPL-based workflow, there is a separate step to go through the REPL history to save the working code. Sometimes, missing one or two things in the copy-paste will prevent the code from running in a new session.

---

<div class="post-metadata">

**Author:** ![affans](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/affans/32/11911_2.png) [@affans](https://discourse.julialang.org/u/affans)\
**Post date:** [February 7, 2026, 7:14pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/36 "2026-02-07T19:14:37Z")

</div>

Can someone explain to me how `semver` works? I thought the entire point of 1.0 is that there are no breaking changes, meaning if your code worked on 1.9 then it should also work exactly the same on 1.12. The changes between 1.9 to 1.12 may contain new features and underlying improvements to the compiler and so on, but shouldn’t break a package.

---

<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 7, 2026, 7:18pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/37 "2026-02-07T19:18:10Z")

</div>

> [@affans](#):
>
> I thought the entire point of 1.0 is that there are no breaking changes, meaning if your code worked on 1.9 then it should also work exactly the same on 1.12.

That’s only true of public, documented APIs. There is no guarantee that undocumented behaviors or undocumented internal functions and data structures will be stable.

---

<div class="post-metadata">

**Author:** ![LeePhillips](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/leephillips/32/205514_2.png) [@LeePhillips](https://discourse.julialang.org/u/LeePhillips)\
**Post date:** [February 7, 2026, 8:26pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/38 "2026-02-07T20:26:18Z")

</div>

I use a REPL-based workflow but with an editor attached. I write code in the editor and send lines to the REPL for evaluation (using [GitHub - jghauser/kitty-runner.nvim: A neovim plugin allowing you to easily send lines from the current buffer to another kitty terminal](https://github.com/jghauser/kitty-runner.nvim)). When I want TAB completion or other REPL interaction I focus the REPL. So it’s definitely file-based, but interacting with the REPL to try things out.

---

<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 7, 2026, 9:55pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/39 "2026-02-07T21:55:22Z")

</div>

Yeah, I feel that’s the pretty standard and recommended way to work with julia for the majority of devs, which is why this quote had me rolling my eyes pretty hard

> [@bvdmitri](#):
>
> I could even argue that the REPL itself isn’t a developer-facing tool in that sense (Julia isn’t developed in the REPL, nor are most large packages), yet it still receives a lot of care and attention.

The people developing julia _definitely_ are using the REPL as their main interface to the language, and if the REPL doesn’t work, a lot of their work would grid to a halt. It’s an essential developer tool. This might not be the case in other languages, but it’s certainly the case in julia.

The point I was trying to make above was that if more devs relied on Pluto do their work instead of a REPL, they’d probably open more PRs that help Pluto.

---

<div class="post-metadata">

**Author:** ![cuihantao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cuihantao/32/8783_2.png) [@cuihantao](https://discourse.julialang.org/u/cuihantao)\
**Post date:** [February 7, 2026, 11:16pm UTC](https://discourse.julialang.org/t/i-find-it-hard-to-develop-in-julia/135497/40 "2026-02-07T23:16:12Z")

</div>

I got around REPL by using `DaemonMode.jl` and a shell script in order to get an AI coder to work with a persistent Julia session. The shell script takes a `.jl` file or Julia code and pipes it into the daemon.

But I agree with you that REPL is essential for most people to develop in Julia. I used to do that and my students still do (Shift + Enter in VS Code). It works fine.

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

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