# We as a community should be more understanding of Julia's flaws

**URL:** <https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030>\
**Category:** Community\
**Created:** [August 19, 2022, 5:42pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030 "2022-08-19T17:42:29Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://discourse.julialang.org/u/jules)\
**Post date:** [August 21, 2022, 1:52pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/21 "2022-08-21T13:52:14Z")

</div>

> [@johnmyleswhite](#):
>
> My overall suspicion is that these issues around how newcomers feel are actually much less important than they seem for a language’s success.

Maybe if there are lots of people paid by corporations to drive the language forward, not if the language relies on attracting volunteers.

---

<div class="post-metadata">

**Author:** ![alfaromartino](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/alfaromartino/32/52986_2.png) [@alfaromartino](https://discourse.julialang.org/u/alfaromartino)\
**Post date:** [August 21, 2022, 10:16pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/22 "2022-08-21T22:16:45Z")

</div>

Just want to show you the other side of the coin, so you can get a grasp of what new users sometimes feel. I wrote [this post](https://discourse.julialang.org/t/is-this-a-bug-nested-functions-and-nlsolve/86085) yesterday.

After two days of struggling with that, someone defending Julia or providing an answer that says nothing ends up irritating you.  
I also think that sometimes putting a title that says “HUGE BUG” is kinda strategic, so that people try to explain in depth what’s going on. Otherwise, the post becomes unnoticed.

---

<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:** [August 21, 2022, 11:22pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/23 "2022-08-21T23:22:51Z")

</div>

I think I can guess which answers you’re referring to. I don’t think that person was trying to defend Julia, I think they were very confused and didn’t communicate that well. They mentioned a bug (with a discourse thread that I had actually commented on), but deleted the comment when they realized that bug was entirely unrelated to the post. The argument on what counts as a bug wasn’t helpful at all because it didn’t make clear the aforementioned bug was unrelated until very late, nor did it actually explain the original issue. My suggestion for discourse etiquette there is: 1) if I were to ever contradict myself, I would write strikethroughs instead of deleting the text, 2) always link the _section_ where something is documented, if possible, or name a search phrase specific enough to jump to that section.

You refactored to best workarounds in cases 3 and 4, so you actually got half the answer on your own. I think another commenter was onto something, so I’ll comment on that post later to try to reach the finish line. No promises though, this is an unintuitive issue and I’m not very smart.

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [August 22, 2022, 5:50am UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/24 "2022-08-22T05:50:00Z")

</div>

> [@alfaromartino](#):
>
> After two days of struggling with that, someone defending Julia or providing an answer that says nothing ends up irritating you.

That poster was clearly trying to be helpful, while also having a different opinion than you. If simple disagreement or honest mistakes are going to be out of bounds for posting at this board, I think that would not create a very healthy atmosphere.

And now one can expect ones posts to be held up as examples of negative behavior in other contexts? I don’t like this at all.

---

<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:** [August 22, 2022, 6:59am UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/25 "2022-08-22T06:59:41Z")

</div>

So basically, “we should be more understanding of Julian’s flaws”, at least some. But I don’t think the implication was this should be prohibited, just that there could be improvements. We have a post for how to ask questions (e.g. no screenshots, MWE if possible), maybe we should have a post for how to communicate answers (how to reference sources, avoiding links that may break, descriptive text, strikethroughs avoid confusion better than deletion).

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [August 23, 2022, 12:11pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/26 "2022-08-23T12:11:47Z")

</div>

> if doing things the Julian way still leaves much to be desired [then in our …] Time to first plot is unavoidably long and writing code that “runs like C” can sometimes be frustrating because it requires almost as much knowledge (sometimes in the form of cool tricks) as writing C code, but you don’t actually have full control over memory.

Yes, TTFP is slow by default but avoidable completely, I believe (e.g. with a sysimage, already, even better with tool below), and true about “requires almost as much knowledge” (of low-level machine details, but only for fastest code, hard for any language, not to beat C). In short I think you have all the “control over memory” you need, e.g. Libc.Malloc (and disabling GC), while default use good enough. Only Alloca is missing?

What I would like when I make a method/function, is a warning:

> That code is not as optimal, as it could be, because of type-instability, memory allocation etc.

It might require you to use the REPL (or some tool for, first, as a prof-of-concept, I would thought want the the default REPL), but would ne needed e.g. in Visual Studio Code, not just for REPL. [Some code might be type stable if called with e.g. Float64, but type-unstable for non-default, say Float32, so this isn’t trivial, or clear how complainy the REPL should be, but it should be possible.]

@mike’s package(s) for sysimages seems excellent, and I’m still waiting for an announcement, not sure why delayed or not done:

> **[GitHub - MichaelHatherly/CuratedSystemImages.jl: Julia package providing...](https://github.com/MichaelHatherly/CuratedSystemImages.jl)**
>
> Julia package providing curated system images. Contribute to MichaelHatherly/CuratedSystemImages.jl development by creating an account on GitHub.

> Currently the following system image bundles are provided:
> 
> - `AlgebraOfGraphics`, contains the [Algebra of Graphics](https://github.com/JuliaPlots/AlgebraOfGraphics.jl) plotting package along with the Cairo-based `Makie` backend, and `DataFrames`.
> - `DataFrames`, contains the `DataFrames` and `DataFramesMeta` packages.
> - `JuliaFormatter`, contains [`JuliaFormatter`](https://github.com/domluna/JuliaFormatter.jl), with latency reduced enough that users may consider using it as the basis for a command line formatting script for Julia source code.
> - `JuliaSyntax`, contains [`JuliaSyntax`](https://github.com/JuliaLang/JuliaSyntax.jl) and uses the provided precompile scripts to reduce latency and enable `JuliaSyntax` as the default parser for all code.
> 
> Requests for additional images can be made to [`curated-system-images`](https://github.com/MichaelHatherly/curated-system-images) repo where the manifests and build scripts are located for the above images.

Almost all the tech flaws (not doc flaws), can be fixed (or already have been, e.g. 9 KB Julia binaries, still with limitations though). It’s just a matter of knowing the non-default ways.

---

<div class="post-metadata">

**Author:** ![digital\_carver](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/digital_carver/32/33818_2.png) [@digital\_carver](https://discourse.julialang.org/u/digital_carver)\
**Post date:** [August 23, 2022, 12:24pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/27 "2022-08-23T12:24:05Z")

</div>

> [@Palli](#):
>
> [GitHub - MichaelHatherly/CuratedSystemImages.jl: Julia package providing curated system images](https://github.com/MichaelHatherly/CuratedSystemImages.jl)

I didn’t know about this, this is great. I’d wanted to initiate an effort towards exactly this, so it’s great to see it already in motion.

---

<div class="post-metadata">

**Author:** ![mike](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mike/32/39_2.png) [@mike](https://discourse.julialang.org/u/mike)\
**Post date:** [August 23, 2022, 1:21pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/28 "2022-08-23T13:21:19Z")

</div>

> [@Palli](#):
>
> @mike’s package(s) for sysimages seems excellent, and I’m still waiting for an announcement, not sure why delayed or not done:

I don’t yet consider it stable, hence why there’s no official announcement yet. If people like living on the edge then they’re welcome to give it a go and report issues if they want to 🙂

---

<div class="post-metadata">

**Author:** ![lobingera](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lobingera/32/211_2.png) [@lobingera](https://discourse.julialang.org/u/lobingera)\
**Post date:** [August 24, 2022, 12:14pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/29 "2022-08-24T12:14:34Z")

</div>

> [@ptoche](#):
>
> Well you’re allocating like crazy

this is actually a quite good example of “not understanding Julia’s flaws” - it’s not the programmer who is allocating like crazy, it’s the compiler. So in a certain way as julia developer you need some understanding how code is translated into execution and (something like) local assignments create local memory impact. This is clearly a flaw of the julia compiler.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [August 24, 2022, 12:28pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/30 "2022-08-24T12:28:28Z")

</div>

> [@lobingera](#):
>
> This is clearly a flaw of the julia compiler.

Is it? In a language like C (or Zig), heap allocations are never automatic, so on the flip-side you need to be explicit and have malloc all over the place. Some say it’s a feature of those languages, others would say Julia (and Go) have clarify and less clutter. Julia is this way by design, and I’m not sure what else the compiler could do. Well it can stack allocate more (and that’s already done in 100% or 99% of cases possible, but wasn’t historically).

If you mean the compiler should act as a linter, I think that might be valuable, while a misplaced criticism of a compiler. For other languages those are separate tool (while often you might have some warnings). I could see the the compiler/Julia/linter-in-REPL warning about allocations, at least for ! functions (the bang means modify in-place, so allocations less appropriate, or never?).

It’s perfectly valid for other functions to sometimes allocate, not always a concern, more though if in a loop. Some language e.g. D, have `@nogc` annotaion, to disallow allocation and thus GC (but also disallow calling other non-`@gc`-annotated functions). Then it IS a defined job of the compiler, but only for such annotated functions.

---

<div class="post-metadata">

**Author:** ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)\
**Post date:** [August 24, 2022, 1:30pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/31 "2022-08-24T13:30:39Z")

</div>

> [@Palli](#):
>
> I’m not sure what else the compiler could do.

The compiler could be better at escape analysis and stack allocate more. Actually this is being pretty much worked on, so it is not only something where Julia could be better, but probably will.

(a similar thing, of the past, was the allocations caused by views. Julia just got better, good for us).

---

<div class="post-metadata">

**Author:** ![jacobusmmsmit](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jacobusmmsmit/32/217669_2.png) [@jacobusmmsmit](https://discourse.julialang.org/u/jacobusmmsmit)\
**Post date:** [August 24, 2022, 1:30pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/32 "2022-08-24T13:30:53Z")

</div>

Holding a similar view to @Palli I would firmly call Julia’s allocation/freeing mechanisms a feature of the language. Of course, almost every new Julia user will at some point run into unexpectedly slow code as a result of this feature, but perhaps this signals that Julia would strongly benefit from heavily advertised, accessible (purposefully overexplained) content specific to these sorts of issues.

While content like this exists, it’s clear that (most) people don’t look for it because they don’t expect it to be a feature, so we might want to have this flagged/warned somehow in the REPL/compiler itself. Additionally, content _like_ this exists, but if we want young people\[1\] to learn the language (which we should imo) then we can’t expect them to know how to dig through documentation or watch overly formal videos to find it.

On compiler flags/warnings, I feel like this is where a commercial IDE from a company like JetBrains could be so beneficial. Imagine PyCharm for Julia, call it JuliaSpell\[2\] or something. A heavily integrated linter/static analyser like [JET.jl](https://github.com/aviatesk/JET.jl) could potentially be what I’m after, it would just need a lot of work to make it as smooth and easy to use as possible.

* * *

1. I’m both talking teenagers and kids younger than this 

2. I looked up “charm synonym”, one of which is fetish, but I don’t think JuliaFetish has particularly relevant search results

---

<div class="post-metadata">

**Author:** ![jdad](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jdad/32/4739_2.png) [@jdad](https://discourse.julialang.org/u/jdad)\
**Post date:** [August 24, 2022, 2:34pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/33 "2022-08-24T14:34:44Z")

</div>

I would propose that, rather than the compiler, the runtime could give a warning if there are « too many » allocations at a moment during the run.

This could be detected by the GC as « abnormal high activity », and possibly reported at end of the run ( rather than at the moment it is detected)(easy to implement with `atexit`. Advantage is that it doesn’t clutter the run. For the REPL, could be reported when coming back to REPL prompt?

It could also be enabled/disable by functions or macros, or glabal state flag. Could also be prototyped as a package, if there is a GC callback? (I don’t know of any at the moment 😅 )

HTH,

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [August 24, 2022, 2:52pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/34 "2022-08-24T14:52:36Z")

</div>

> [@jdad](#):
>
> rather than the compiler, the runtime could give a warning

New in 1.8:

> The new `Profile.Allocs` module allows memory allocations to be profiled. The stack trace, type, and size of each allocation is recorded, and a `sample_rate` argument allows a tunable amount of allocations to be skipped, reducing performance overhead ([#42768](https://github.com/JuliaLang/julia/issues/42768))

It’s not on by default, nor should it be (because profiling has an overhead).

Note, also new (likely only CPU profiling, not memory profiling, but could allow for latter too?):

> A fixed duration cpu profile can now be triggered by the user during running tasks without `Profile` being loaded first and the report will show during execution. On MacOS & FreeBSD press `ctrl-t` or raise a `SIGINFO`. For other platforms raise a `SIGUSR1` i.e. `% kill -USR1 $julia_pid`. Not currently available on windows ([#43179](https://github.com/JuliaLang/julia/issues/43179)).

and not new:

> can be enabled with [`GC.enable_logging(true)`](https://docs.julialang.org/en/v1/base/base/#Base.GC.enable_logging), which causes Julia to log to stderr every time a garbage collection happens.

Allocations can be a performance flaw, but not all are, and it’s hard to make a program without heap allocations. I think it would be crazy talk for say to expect C program to emit warnings for malloc, even if many in rapid succession, because they are normal in a program.

I realize you’re proposing only logging for “high activity”, and that changes the picture a bit, but then ou need to keep track of time, wen was the last one, or in space, if in a loop, and I can see it as a non-default option, not on my default, though maybe allowed to trigger collecting data by default with CTRL-T?

> easy to implement with `atexit`  
> The reporting at that time isn’t the hard part, if/since you have the structure, but filling it at runtime will slow down, more than emitting to a log as we go along?

---

<div class="post-metadata">

**Author:** ![jdad](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jdad/32/4739_2.png) [@jdad](https://discourse.julialang.org/u/jdad)\
**Post date:** [August 24, 2022, 3:08pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/35 "2022-08-24T15:08:24Z")

</div>

I agree that it is complicated to define « high activity ». So, may be just report highest allocation activity (and source line location) at exit?

Highest activity could be e.g. a smoothed value of « number of allocations per second » (on a 1 sec or 5 sec rolling window?

As you said, may be it is too complicated? And we already have (manual) procedure in 1.8. My initial idea was to help the newbie in some simple way, but to have an idea of reasonable threshold warning values, we should have a passive instrumentation … which has no infrastructure and whose result could vary a lot.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [August 24, 2022, 3:58pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/36 "2022-08-24T15:58:46Z")

</div>

> [@jdad](#):
>
> So, may be just report highest allocation activity (and source line location) at exit?

You would still need to keep track of all the other lines that allocate, so that you can rank later to show the one with highest.

---

<div class="post-metadata">

**Author:** ![lobingera](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lobingera/32/211_2.png) [@lobingera](https://discourse.julialang.org/u/lobingera)\
**Post date:** [August 24, 2022, 4:00pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/37 "2022-08-24T16:00:25Z")

</div>

i might do the wrong example here and pseudocode, because i have not written julia code in years and didn’t really run into a ‘you allocate too much’ problem.

let’s loop over a long list of indexes, calculate something, and copy the results into an available array  
for k = 1:1e6  
value = function(constant parameters, k, some data)  
% do something else  
% do something else  
result\_array[k] = value  
end

isn’t this allocating a bunch of values? If yes, the compiler should reduce to result[k] = function(etc.)

And for heap/stack allocations: Sorry, if i want to differentiate this, i go to a low level programming language (aka C - a form of macro assembler). In a high level language with memory management (aka GC) i don’t even want to think about managing this.

---

<div class="post-metadata">

**Author:** ![ronubi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ronubi/32/4085_2.png) [@ronubi](https://discourse.julialang.org/u/ronubi)\
**Post date:** [August 24, 2022, 4:05pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/38 "2022-08-24T16:05:09Z")

</div>

The JuliaCon22 keynote by Jeremy Howard was an eye-opener for me. I’ve been trying to evangelize Julia to my engineering colleagues, and only a few younger folks seem open to it. I think if we can solve the issues so that “Julia could have Go’s things” as Jeremy puts it here - [JuliaCouldHaveGosThings](https://youtu.be/s6pjxCuNGjc?t=1604) - the language would take off in popularity. Here’s a screenshot that hammers home a major point:

 ![julia-go-things](https://global.discourse-cdn.com/julialang/original/3X/2/4/24044ce8850baf201b691d26c365ecceacc0bfe3.jpeg)

The inadequate answer offered in the lower-left bubble is admittedly from 2019, but unless I’ve missed some news, the _status quo_ currently isn’t a lot better.

If we don’t solve these issues, I think Julia will be relegated to a niche language that few of us can use in our jobs. I reluctantly work mostly in Matlab, Python, and shell-scripting (bash / csh) in my day-to-day work. I can’t easily give someone a Julia program to run, and it’s not trivial to get a working environment set up.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [August 24, 2022, 4:09pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/39 "2022-08-24T16:09:01Z")

</div>

PackageCompiler.jl is I believe still the go to package to compile, but no longer the only one. Yes, the binaries aren’t small with it (but can be tuned smaller), but with other compiler package 9KB small binaries is possible (then you have some limitations).

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [August 24, 2022, 4:13pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/40 "2022-08-24T16:13:34Z")

</div>

> [@ronubi](#):
>
> The inadequate answer offered in the lower-left bubble is admittedly from 2019, but unless I’ve missed some news, the _status quo_ currently isn’t a lot better.

PackageCompiler was completely rewritten in 2020, and then StaticCompiler was completely rewritten in 2022. To say it’s not much a lot better is just plain incorrect. These days PackageCompiler works quite well with just one line of code and is actually documented (the version way back then was… bad). StaticCompiler is still limited in application but is quite good for what it handles now. Are they perfect? No, but they have improved at least 10-fold and are used in real industrial applications all of the time (they are used in all applications of JuliaSim for example, which could not have been possible with the old versions).

For details on PackageCompiler’s transformation, see

> <https://github.com/JuliaLang/PackageCompiler.jl/pull/304>
>
> This PR completely replaces PackageCompiler.jl with that of PackageCompilerX.jl.… The maintainers of this package as well as those of PackageCompilerX.jl feels like this is the best way forward.
> A few options were considered:
> 
> \- Just deprecate this repo, rename PackageCompilerX to something else (AppCompiler.jl). There are some drawbacks to this. Firstly, this package name is already pretty good and it would be a shame to waste it. Secondly, it is a bit confusing to have a lot of references spread out over the internet and then have it be deprecated. Also, it would remove the history of everyone contributing to this package which is a shame.
> \- Just repoint the URL in the registry to PackageCompilerX. This would cause existing manifests to break so it is a non-starter.
> 
> Instead, just putting a complete rewrite on top of the existing history felt like the best choice.
> 
> 
> Some improvements / changes in PackageCompilerX.jl vs the current PackageCompiler:
> 
> \- Support for artifacts in Apps. This allows one to distribute apps that depend on e.g. libraries via the artifact system to other machines.
> \- More CI, including e.g. ARM support.
> \- Better defaults for cpu targets, matching those that Julia itself uses
> \- Proper documentation including some examples, tutorials and developer docs.
> \- No command line interface, this felt like adding a lot of code for little benefit.
> \- Uses the Artifact system to get a compiler for Windows instead of the largely deprecated WinRPM.
> \- Drops pre 1.3.1 Julia support.
> \- There is no need to annotate the entry points of apps with \`Base.@ccallable\` since that is done automatically.
> \- The \`julia\_main\` function no longer take any arguments. Just like in normal Julia code, just access the global \`ARGS\`.
> \- An app needs to be structured as a package. (project file and \`src/Package.jl\` file)
> 
> 
> I will go through earlier issues and add here which are either fixed by this PR, no longer relevant due to fixes in Julia or changes in PackageCompiler functionality:
> 
> 
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/52
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/83
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/108
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/129
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/131
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/289
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/297
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/290
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/281
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/192
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/277
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/276
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/272
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/271
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/270
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/258
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/255
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/252
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/234
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/233
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/230
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/236
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/228
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/225
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/223
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/222
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/221
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/220
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/215
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/212
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/208
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/202
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/201
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/194
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/193
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/190
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/184
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/223
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/182
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/180
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/163
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/151
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/155
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/154
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/152
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/145
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/141
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/226
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/140
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/138
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/117
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/76
> Closes https://github.com/JuliaLang/PackageCompiler.jl/issues/59
> 
> Got kinda lost with isues at this point. Will take another pass after this PR is merged.
> 
> 
> After this PR is mergd, we should transfer over issues PR from PackgeCompilerX to this repo.

[Previous page](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030.md?page=1)

[Next page](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030.md?page=3)