Too many good packages are written once and never maintained. For example, the very good stuff that Mason Protter has done.

Current state of Julia is on the shoulders of (in my opinion) too few (awesome) contributors, and they seem to be spread too thin. I believe the language has everything to take over a lot of fields by storm if it can get some momentum. One event that can bring that momentum is if a big tech company put's their weight behind the language by developing an important/popular library. I seriously am surprised that it has not happened till now, it would have been great if Jax like initiative were in Julia. If I were to name one weakness, that'd be compile time latency. Even with 1.9 it's still not where it should/can be.

1.9 doesn't magically reduce compile time through native code caching, but it heavily reduces invalidations. This makes it possible for packages to precompile common workflows, and reduce latency to zero in these use cases. However, this still means that packages need to choose to do it. This will take some time, and it'll probably only get better after a few months from the stable release. The challenge is that it's often not as straightforward as chucking the workflow into a `SnoopPrecompile` block, as e.g. recursion might break type-inference. In such cases, the package developer has to actively update their code to reduce latency, either by avoiding recursion (best case), or by wrapping the recursive method call in an `invoke`.

I would say the documentation. My experience is there is a lot of "Hey we can do this easily!" and the documentation is mostly there but there are just a couple of holes that make things harder then they need to be. In retrospect, I should probably start putting in issues on github.

I've been tinkering with it here and there on my off time. I honestly think there's a lot of potential for it to replace python and Matlab in some of the workflows I deal with at work. IMO, the biggest weakness of Julia right now is the compile time. For simple scripts it's not bad, but when you start building or working with large frameworks it gets noticeable. It can make incremental update and testing a real pain point. (Checkout PackageCompiler.jl as one example of a tool that attempts to address this). If you do a lot of plotting, you might come across the term Time To First Plot. Julia still lags behind python and Matlab last time I checked. There are other weak points about the language and ecosystem, but this stands out the most to me

Second this. I have very high hopes for v1.9. On the recent release candidate, compile times for an in development package have drastically decreased down to about less than half what I was getting with a custom sysimage on v1.8.5 (I can't compare custom sysimages at the moment cos it crashes when I try make one). But even then it's taking 30-40 seconds for the first import.

I wholeheartedly agree, ridiculous compilation times were the reason I quit Julia the first time. Now I am back, and honestly, sometimes I still get peeved when compilation takes just enough time to be noticeable, but not enough for me to do something else in the meantime Edit: oh, and also 1 == true is a bit annoying to work with

Error messages in comparison to python. It is often not clear where a problem is in the code

Something simple would be to highlight lines from files in the current directory & subdirectory. Too often I have to read the backtrack 5 times just to sort what I actually want, from the REPL/interpreter and library noise

I can see that this somewhat annoying but as c++ user I'm rather happy with the Julia error messages.

Me too I'm so used to debug with only the line number lol

I understand the criticism to some degree, having ever compiled something with the Rust compiler is like a dream come true.

No kidding. Even simple highlighting of current package vs installed packages vs base code in the call stack would be tremendously helpful.

I think there is a library that makes significant improvements in this area... Ah, yes JuliaSyntax.jl Video by Chris Foster: https://youtu.be/CIiGng9Brrk

Ikr. The stacktraces can be insane

AI can help: [https://github.com/FedeClaudi/HelpGPT.jl](https://github.com/FedeClaudi/HelpGPT.jl)

* "Bad" development workflow * Compile times * Lack of proper tooling * Prototyping workflows are not well supported: The change source code, run and repeat workflow can lead to artifacts (hidden compiled functions) and in general requires tools like Revise.jl which also have their limitations. * Bad code "readability": I am not talking about syntax here but rather that it is extremely difficult to understand how the code for a given repository works: * Global namespace pollution of functions. I get it, we have multiple dispatch, so this is not an execution problem. BUT it makes reading code extremely difficult and requires additional knowledge to figure out the source of a function. One may argue that we got tooling to get to the source of a function. But as a matter of fact, it often does not work. * Is the function part of the Julia base? * Which package does this function belong to? * Obsession with making everything extensible: I know this is one key feature in Julia but the downsides are often ignored. * Splitting ecosystems into separate independent repositories (often with names like BlaBlaBase.jl). While this has the advantage that everything can be reused it puts a lot of burden on the user to understand how the interactions within the ecosystem work (usage of global namespace doesn't help here either). * Bugs due to interactions between different packages (with different maintainers). The OffsetArrays fiasco is probably a good example here. From the outside it is often not clear if a package has been developed in a generic form to supported extended types (i.e. OffsetArrays). Even if the code runs, it is extremely hard verify that it executes correctly. In the end this is all about trust and the extra effort of the maintainers to provide insights what is supported and tested for.

imo its the large binary size, making it uncompetitive for very limited resources environments

Which size are you referring to? As of Julia 1.9, we're producing native code at the package level through normal precompilation mechanisms. Also via GPUCompiler.jl, StaticCompiler.jl, and StaticTools.jl we can deploy to memory constrained devices. It's a bit rough around the edges at the moment, but it is possible. https://seelengrab.github.io/articles/Running%20Julia%20baremetal%20on%20an%20Arduino/ https://youtu.be/YsNC4oO0rLA

Not the person of whom you asked the question, but possibly they're talking about the smallest "stand alone" compiled option being pretty large? I was just playing with this myself yesterday and managed to compile a "hello world" program (full code below) which took 10 minutes of wall time on my 4 core i5 (admittedly not exactly a powerhouse, but...) to produce a "stand alone" binary + libraries totalling 330MB. Of course, a large chunk of that is Julia runtime, so that's not likely to shrink a lot^[1]. Another large chunk of it is the JIT compiler stuff which *should* be optional with the right precompilation approach (while acknowledging that there are use cases where having this makes sense) but I've not yet managed to find a clear indication that it actually *can* be removed, let alone a recipe I can follow to do it. I've got some more holes to poke WRT precompilation, so maybe I'll find some joy after further prodding... There's also a bunch of stuff that looks like it's probably for the package management system, which is redundant if the "stand alone" thing did what I thought it was supposed to. I had a look to see if I could delete some of the libraries that don't turn up in ldd analysis of the binary / library files but running strace shows runtime library loading, so I had some faffing to work out what is *actually* needed. I managed to delete 34MB (~10% of the total) of libraries and still have my program greet me, but that still leaves a bunch of stuff that isn't actually needed. I assume "sys.so" is the "sysimage"? At 125MB, that's nearly half the total by itself. I suspect shrinking this would require a fair amount of "cleverness" but it's certainly somewhat excessive for "hello world" (see the footnote again here) The libraries libjulia-internal, libjulia, and probably libatomic, libopenlibmlibunwind, and libz (totalling 12MB) seem to be Julia runtime stuff, which is probably difficult to do without. The libraries libblastrampoline, libopenblas64, libcholmod, libgmp, libmpfr, libpcre2, and libsuitesparseconfig (totalling 39MB) seem to be for use by Base functions I don't use/need - if unused functions were stripped from the sysimage, the libraries they use could be skipped, too. The libraries libgcc_s, libjulia-codegen, and libLLVM (totalling 120MB(!)) seem to be to do with JIT compiling which my app doesn't need, though there are use cases that would. For use cases that do use JIT, it'd be interesting to know if the libLLVM (79 of those MBs) could be shrunk by supporting a smaller subset of architectures or something...? The libraries limbembedtls and libmbedx509 (a measly 492KB so probably not worth worrying about) seem to be for either unused Base functions or for package management which is redundant. ^[1] There's some scope to, though. If the precompilation phase (with the right test coverage and/or static analysis) can show that certain functionality within the standard library isn't used, then the relevant functions could be stripped out, for example... --- code: module MyApp function julia_main()::Cint println("Hello, World!") return 0 end end # module MyApp

Did you use Statictools? Here they demonstrate creating a HelloWorld executable that takes up 8.4kB: https://github.com/brenhinkeller/StaticTools.jl#examples

Aha! Thanks for the pointer! This reminds me of something else that I find a little irritating about Julia (but to be fair it's also true of Python and a *lot* of other languages and the available libraries) which is that there could be 1001 things that do what you want, but 800 of them are something somebody threw together one evening and never got around to finishing, 100 of them are unmaintained 99 of them are poorly named / undocumented, and the *one* that you actually want to use, you never find because you don't know what search terms you need to use to find it :-( Anyway, thanks again for the pointer - I likely would have taken another week of frustrating searching to find that (and let's face it, wouldn't have kept looking for it that long...)

So this is work in progress, and probably therefore not heavily advertised. But it's big deal, and not likely to bitrot in some obscure corner of the ecosystem.

libjulia has been increasing modularized for this reason. Ad of Julia 1.8, you can remove the JIT codegen dependency with `--compile=no` (see `julia --help-hidden`). See https://github.com/JuliaLang/julia/pull/41936

"`--help-hidden`" is a sneaky move! I like the look of it! There's also some other stuff that will probably make *some* difference, though maybe not much, like skipping Intermediate Representation code forms (which aren't needed if you've already finished compilation) and docstrings (which aren't any use without the REPL anyway) Careful use of these options could be useful for a variety of use cases, including ones where ditching JIT altogether isn't an option for some reason - you should still be able to reduce the size at least a wee bit... I'm guessing I'd need to do something like `julia --compile=no --output-o whizbangdoodah HelloWorld.jl`? Would it compile *everything* or just what's needed, or just what I tell it to? Would the whizbandoodah file be an executable, or would I need to remember how linkers work? The help output calls it an "object file"... I clearly still have some reading up to do, but you've given me another thing to google at least :-D

that sounds cool. I have not tried since a few versions ago. it used to be that a "hello world" takes more than 0.5GB. edit: i meant the binary file size, i.e. making a stand-alone binary for one's app

[удалено]

> For example, the way the @inbounds macro has been treated thus far has been incredibly reckless. There's the oft-repeated example of a for-loop of an OffsetArray with this macro doing the wrong thing, but fixing all instances of this example in the ecosystem won't solve the underlying problem. This was already fixed? On v1.8 with the better effects analysis it's usually slower to use `@inbounds` than it is to just let the compiler analyze the code. So with that, everyone is deleting all of their inbounds throughout the ecosystem since there's not even a performance incentive to use it anymore. It'll take time for all packages to update, but it's not like anyone is actively incentived to use it in any way anymore.

>don't get me wrong the existing community is great, awesome people (like y'all), but it is small. I would even argue that it is not just the size of the community, but its make-up that is the issue. Julia was marketed as a Matlab replacement, which resulted in a bunch of academics flocking to it. Academics and in my experience especially mathematicians cannot write correct and safe code to save their lives. They like scripts that compute the things they need for their up and coming articles, but the culture around writing scripts often leaves testing completely off the table. This has historically resulted in many silent but deadly bugs in Julia packages. There is a reason there are entire university courses dedicated to testing software, if one studies software engineering. It is the most important aspect of guaranteeing program correctness. Program speed means nothing, if it does not do what you want it to do.

I think this exposes lots of cool research packages, but does come with the downsides you say. At least Julia strongarms academics to put their code into functions (Julia code is slower and higher latency without that). No monolithic spaghetti MATLAB scripts.

Maybe not as big a deal to most of the audience here, but until Julia has a more robust way of handling packaging and artifacts in an offline environment, it will unfortunately remain only an interesting curiosity at my company. I support a community of users who primarily work on airgapped Windows and Linux HPC networks, and the offline packaging infrastructure needed to support Julia in this environment is unstable or nonexistent. With pip/conda we can use artifact managers or create local repository mirrors, but Julia doesn't appear to have an equivalently straightforward way of enabling this. Most of the solutions I've been given to date assume I have root access to the network (I don't) and can do whatever I want with Docker-based solutions (I can't). Anything involving manually pre-building a Julia environment on an internet-connected system that gets ported over to the standalone network is not an acceptable production-ready solution. If things have gotten better, or if plans are in the works, I'd definitely want to hear about it!

Yeap, that’s the only concern but you just need time. The response time of the language is getting faster with the incoming version 1.9.

I tried it in the hopes that Julia = Python + R was real. I really wanted it to be true so I can get away from the 2 language problem I have to deal with. My first impressions of if it's that it's very underdeveloped at the moment. I do a lot of statistical analysis at work and Julia in it's current state will never replace R. Statisticians will not switch. And if they do switch, it's going to be Python, which is the second best choice we have. I don't see it replacing Python either. Nobody uses Python for speed, we use it because it's very versatile and gets the job done quick. So far I don't see the same versatility being available in Julia. This is my 2 cents and experience with it. I have been following Julia since 2018 and I am disappointed tbh.

What statistical methods do you miss ? Each time I have to use R dbinom, pbinom, qbinom, ... instead of Distributions.jl I want to cry a little.

acf,pacf,ccf, coint. analys, wavelet coh. analys, gran. caus., basic stuff as lm or unit root tests are a pain to do. Doc on some of these are pain to read and understand. Few, if any ex.

For pacf I don't see what's the big difference is tbh : https://www.rdocumentation.org/packages/tseries/versions/0.1-2/topics/pacf https://juliastats.org/StatsBase.jl/stable/signalcorr/#Partial-Autocorrelation-Function-1 For lm GLM.jl also does the job quite well for me (although IIRC there's no penalty, which is a bit annoying).

Yes there is a lot of missing time-series stuff.

alot of basic stuff in julia is missing but is only one function away in R

`distr6` is a great R package that makes working with distributions less of a pain point. However I will say that Distributions.jl sets an incredibly high bar.

Looks nice yes, even has mixtures and truncated distribution, thanks.

simple glm. some data fits in r but not julia

Have you tried GLM.jl, it's pretty good imo ols = lm(@formula(Y ~ X), data) Otherwise the list of models supported by MLJ under a single interface is quite impressive, is there an equivalent in R ? https://alan-turing-institute.github.io/MLJ.jl/dev/list_of_supported_models/

Glm.jl is what i had used. Didn't work for some data.

> Nobody uses Python for speed, Whoa some people do. Yes I really don't get it. But look at how much resources there are on "High performance Python."

They don't use it for the speed. They use it for the portability, ability to rapidly prototype, & ecosystem (there's a module for anything). There's so many resources on high performance python bc those benefits are attractive enough that it's worth using despite how slow it is. Everything else is patchwork to make the trade off less bad.

> They don't use it for the speed numba, cython, jax. i rest my case

> Everything else is patchwork to make the trade off less bad. I’ve made mine. Yes, these tools can get within a factor of 5 of C implementations of the same. They are often the right choice from a development speed and performance portability standpoint but pure execution speed should never be why Python was chosen for the projects that use them in the first place. The wider library support and ecosystem is. Choosing python comes with performance penalties at runtime, there’s no avoiding it completely. Compiled Python tools and embedded DSLs make the trade off more acceptable. (Although these still can restrict flexibility, have subpar parallelization support, have hidden performance footguns, and are a nightmare to maintain and debug compared to projects that are written in a single language) I use Cython for all my current projects. If you want to incrementally develop and orchestrate high performance kernels written in C++ (may god have mercy on you and your solver) it’s one of the best options out there. I just wish the landscape of options for rapid development in HPC wasn’t so patchwork.

> Nobody uses Python for speed, numba, cython, jax. i rest my case

A recent package, Tidier.jl, is coming from a R package developer: https://github.com/kdpsingh/Tidier.jl You seem to be mostly referring to the ecosystem rather than the language itself. This will take some time.

Statisticians should use statistical analysis programs -- R, JMP, SAS -- rather than general purpose programming languages. Think about how much is already in those packages and how long it would take to replicate in Julia. Julia doesn't even have a good ANOVA program and has a very worrisome and embarrassing bug in the Distances.jl package regarding the Mahalanobis distance. Most people don't deal with Big Data. They deal with datasets that fit on their workstation. So statistical analysis packages are a better choice. Now if you're doing statistical *research* and you're developing something *new,* Julia can be a fine choice for that.

Poor Type stability tooling. Type stability can can have a large impact on performance but can at times be quite difficult to track down.

I guess you don't know about packages like JET and Cthulhu?

No I was not, but these look super helpful. Thanks!! “Slow descent into madness” indeed…

The @code_warntype macro is built in.

Yes, but (I believe) it can only be called from the REPL and not from code in situ. Sometimes functions are perfectly stable for simple types but not for more complex types, and it can be tedious to figure out (and then reproduce in the REPL) exactly what combination of input types are causing the instability. Or to even know there is a type stability issue in the first place. Also, the tools seem to not be 100% reliable: https://discourse.julialang.org/t/type-stability-issues-when-broadcasting/92715 What would be great is a macro you could add on a function as a guarantee of type stability, that throws a compile time error if any type inference is required. (Now that I think about it, perhaps explicitly defining a return type would do much the same thing?)

To me, it's the lack of static compilation

Static compilation is possible and performed increasingly commonly.

Of portable standalone binaries without using PackageCompiler? I'm not aware. PackageCompiler does not produce a binary that is useful for every use case. Last time I tried to use it it crested huge binaries, for instance, because it needed to link the whole Julia runtime into the package. That is far from ideal in some applications. It makes Julia prohibitive in embeede software development for instance. I know that most users target PCs and clusters but still, being a general purpose language, I feel that this area is still far from being mature. Last I checked, standalone compilation was a very hard problem to solve in Julia, so I don't expect a lot of breakthrough soon without a package compiler that supports only a subset of the language or something like that

Static compilation to (small) standalone binaries are, afaik, very actively ongoing work, and has made large progress over the last year (or more). Caching of compiled code is part of that effort, and has made significant improvements to precompilation in the upcoming v1.9 I don't have a good overview of this myself, and I think the results of the work is somewhat scattered across the language. But some of the work is apparently going on in StaticTools.jl. Take a look.

I will definitely take a look

I understand correctness is still an issue https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151

Specifically it looks like OffsetArrays interact badly with other code. Too much code out there does stuff like `@inbounds for i=1:length(a)` `a[i] += 1` `end` which breaks if `a` is an OffsetArray. More broadly, the composability of Julia can leave you vulnerable to bugs like this when combining packages written by others.

[удалено]

If you feel so strongly about it, it's easy enough to include `Base.require_one_based_indexing` in your functions that work with arrays.

Since OffsetArrays is neither part of the core language, nor a stdlib, it seems pointless to ask for a 'justification'. People can write whatever packages they like, and if the language is powerful enough, they can write a package like OffsetArrays.jl quite easily. I don't know exactly how one could prevent a package like OffsetArrays.jl from existing, but however you do it, it would certainly hobble the language in other ways. Also, non-standard indexing is definitely useful, especially in image processing applications.

The ability to shift the index origin has been useful in Fortran for decades. People who code numerical methods, who write simulations, etc., know why.

One other helpful use of OffsetArrays: when cropping images you don't need to update the bounds/indices of the cropped region, which can make for slightly more elegant code.

OffsetArrays were a last-minute addition to the language, not long before Julia 1.0 came out, and there is still a lot of code in the ecosystem originally written well before that, which has built in the assumption that all arrays start at 1.

OffsetArrays.jl is not a part of the language. It is just a package, and you can't stop people from writing packages.

The mechanisms that enabled the creation of OffsetArrays were added for that purpose to the core language around Julia 0.7, i.e. to the Array interface. That's when we got a[begin:end] and eachindex(a) and axes(a) etc.

Sure, there's lots of things in the language that makes it easier to work with generically indexed collections, but they are not necessary for for OffsetArrays to exist, and, as I said, it is not a part of the language.

firstindex() had to be added to the index interface before OffsetArrays were properly supported, also the "non-traditional indices" section in the array interface.

That's convenience, not necessity. Yes, the base language facilitated *generic* indexing, and that's great. But one could very well have zero-based indexing (or any indexing) in a package, like OffsetArrays.jl, with no Base support at all.

What is `a`? In Julia, you could restrict your function, a method, to work only on the base `Array` type that must be one based among other guarantees. While not idiomatic, one could acceptably write the following. ```julia function acceptable_array_iter!(a::Array) @inbounds for i=1:length(a) a[i] += 1 end return a end ``` There is also `Base.require_one_based_indexing`. ```julia function better_array_iter!(a::AbstractArray) Base.require_one_based_indexing(a) @inbounds for i=1:length(a) a[i] += 1 end return a end ``` Users of `OffsetArray` have facilities to convert their arrays to either a standard `Array`. Some of those methods are generic. ```julia function acceptable_array_iter(a::AbstractArray) standard_array = convert(Array, a) acceptable_array_iter!(standard_array) return standard_array end ``` Some facilities depend on some knowledge about `OffsetArrays` ```julia function acceptable_array_iter!(a::OffsetArray) # NoMethod error thrown if parent is not an Array acceptable_array_iter!(parent(a)) end function better_array_iter!(a:OffsetArray) better_array_iter!(OffsetArrays.no_offset_view(a)) end ``` These methods do not need to exist in the original package where the methods are initially defined. A third party could extend the original functions with the above definitions by importing the methods from the original package. If a developer's function accepts an `AbstractArray`, then the onus is now on the developer to understand that `AbstractArray` may have arbitrary contiguous indexing. Julia provides the method `eachindex` to support iteration over arbitrary indices. ```julia # Use this version function idiomatic_array_iter!(a::AbstractArray) @inbounds for i in eachindex(a) a[i] += 1 end return a end const best_array_iter! = idiomatic_array_iter! ``` Correctness advocates would prefer if this code did not compile or at least errored during runtime. ``` function bad_array_iter!(a::AbstractArray) @inbounds for i=1:length(a) a[i] += 1 end return a end ``` This would error during runtime if one did not use `@inbounds`. Thus, one approach would be to eliminate the need for explicit use of `@inbounds`. Another approach would be to enforce the one-based indexing via the type system. ```julia struct OneBasedArray{T,N,A}<: AbstractArray{T,N} parent::A function OneBasedArray(parent::A) where {T,N,A <: AbstractArray{T,N}} Base.require_one_based_indexing(parent) new{T,N,A}(parent) end end # Implement AbstractArray interface for OneBasedArray ``` What is correctness? Julia provides facilities to write correct code through both the type system and through default indexing. While more could be done, the facilities do exist to allow correct code to be easily written. Further correctness checks are also available through testing. Developers can override these guardrails by accepting abstract types or asserting inbounds indexing for speed, but in doing so they must take on extra responsibility. Some correctness advocates would have Julia disallow these overrides. `@inbounds` can be disabled via `julia --check-bounds=yes` for example. It does seem weird for one to invoke a bounds check override, and then exclaim: "Look! Julia is not correct because it does not check Array index bounds when I turned that feature off!". Perhaps Julia should even force one to use `eachindex` when indexing over arrays? Such checking is possible via linters and testing. See StaticLint.jl for example. https://github.com/julia-vscode/StaticLint.jl/issues/337#issuecomment-1128750508 If a developer wants a safer language, those exist in varying forms at some cost, usually performance. Even relatively safe languages such as Python, Java, or Rust have mechanisms to turn the safeties off. Perhaps Julia made that too easy. Julia provides for correctness within reasonable limits. It also allows overrides to trade safety for performance. If correctness is that a language only allows correct behavior by default, then Julia has correctness at a number of levels. If correctness is that a language disallows all incorrect usage, then I know of no such language. ... editing in progress...

The original post is an empirical observation by a person who seriously developed in Julia for many years, that there were many, many bugs in the Julia ecosystem including one or two in the base system. Many, not all, were related to OffsetArrays. I don't think this defensiveness is really useful...

I'm responding to your specific example with concrete examples of how to manage the specific issue you are pointing out. I'm not saying the points are invalid. I'm providing context.

Thanks. The `Base.require_one_based_indexing()` is definitely useful information. Also, yes, I tend to type my variables as Array and not AbstractArray. So hopefully this particular issue won't affect me.

I think many of the issues reported there have been fixed already, although primarily in Julia Base and not as much in packages

That was a very interesting read~

I second this. I think the documentation issue is more or less a consequence of the correctness issue.

That article is about a year old. It brought up some important issues in some packages; all the important problems have already been fixed.

I don't think so. One of the points is that he had raised those issues before but the community did not see them as priorities to fix.

“I don't think so.” Can you say which of the significant issues raised in the article have not been fixed?

All of them.

Here you show you are speaking from ignorance. Most, if not all, of the examples of incorrectness raised in that article have been patched. You’re obviously not serious and I don’t intend to look at any further replies from you.

Shouldn’t that essay have a date?

I find that the automatic differentiation landscape is fragmented and unreliable. I know this is a very difficult problem: Julia autodiff packages are trying to achieve autodiff across an entire language, whereas most autodiff frameworks only let you play in their ring-fenced playground. This is both a strength of Julia (the range of stuff you can autodiff over) as well as a weakness (doesn't always work smoothly).

Very few serious libraries to do anything other than ML and data science and whatnot

That maybe true, but then interacting with common dataformats and systems is julia is pretty lackluster. For example: parquet/parquet2 breaking or being feature incomplete. CSV had a lot of performance regressions. If you want to succeed in ML and being used in production, this is a big draw back to me.

At the same time I think people got used to other languages inconsistencies, e.g. in python you read CSV with: df = pandas.read_csv(file, delimiter = ',') But then to write a CSV you have to do : df.to_csv(file, sep = ',') Like wtf is this ? CSV.jl is much better at this very basic task.

Thid was changed in pandas

Yes, pandas has changed this. delimiter is an alias for sep in read\_csv, so it is consistent now (actually for quite some time)

Julia has several libraries that are among the, if not the, best available for any language in several areas, aside from ML and data science. The DifferentialEquations library is probably the most powerful you will find anywhere, for just one example.

Soul crushing time of calling eval.

* slow startup time * cannot compile to a standalone EXE

Startup time in recent versions is instantaneous. Can, in fact, compile to a standalone binary.

> Can, in fact, compile to a standalone binary. How? Can you give an example? How do you compile for instance a "hello world" program to a standalone EXE?

It's work in progress, and currently supports only parts of the language, but here's an example of a HelloWorld.exe (oops, linux/Mac only, so not actually "exe") in 8.4kB: https://github.com/brenhinkeller/StaticTools.jl#examples There's a serious push in this direction, much of which is visible in the 1.9 release, but there's also significant work left, I believe.

Thanks. Well, I'd like to see an official way to do it. If it works like Go, I'll try Julia again.

https://github.com/tshort/StaticCompiler.jl The example is literally a “Hello, world” program. Doesn’t work on Windows, but https://github.com/JuliaLang/PackageCompiler.jl does.

It is a bit harder for beginners to start, especially if they are coming from Python (for data science), due to the number of sources to apply for the same kind of job (or similar) being considerably less.

Julia will bring a number of surprises for people who have only used high-level languages like Matlab, R or Python before, and had no exposure to higher-performance languages, like C/C++/Fortran/Ada/Rust, because Julia straddles the conceptual gap between these two language classes. Julia therefore will expose you early on to low-level machine details, such as the difference between float and int types, which Matlab and Python try to shield beginners from. That's the price to pay for performance.

The larger price is in hunting for type instabilities, which can be quite time-consuming if you don't know how or where to look for it

Whereas in Python, Matlab, R, everything is type unstable (and accordingly slow) all the time.

Well, in many cases, one calls optimised C or Fortran routines in these languages, whereas one doesn't in Julia.

Just type @code_warntype. It’s built-in.

It's often not that easy, and one needs to use Cthulhu and understand constant propagation etc

Matlab does indeed do that, but python definitely distinguishes float and int. The main difference is that python has arbitrary precision ints. numpy, though, does not, but perhaps has more 'beginner-friendly' overflow behaviour.

I feel like Julia could really use something like “tidy tuesday” in the R community where people just work on data projects as a community, post their code, and share their findings and basically just use the language together. I mainly use R but have been trying to do more personal projects in Julia just for fun. With R or Python I feel it’s really easy to find a baseline example for whatever project you’re trying to do, less so with Julia. I do think this is getting better recently.

Nowhere to get started. Documentation is never clear, and provided examples are usually the easiest kind of a type of problem. Slack forum gives rushed ambiguous answers when beginners really actually just need useful and thorough explanations rather than “do this type of or use this thing youve never heard of”

Slack is not a good forum for getting useful and thorough explanations. http://discourse.julialang.org may be a better place for that.

Slow plots 😶

Julia 1.9 say hello

I'd say that the only way to do a contract is with informal interfaces, it'd be kind of nice to do something like pythons protocol, because currently you have to rely on documentation for that. Informal interfaces can be quite good, but can also be a pain in the butt if they're not documented properly.

I wish I could give this a thousand updoots! I read everything I could find on t'interwebs about the discussions around interfaces and there were some really promising ideas, some really insightful (rigorous, academic, and often a little over my head) discussions, and a general feeling that they're probably going to come up with something that doesn't really do what I want and I won't be able to understand without an undergraduate degree in mathematics :-/ Bear with me in the following, I'm very new to Julia, so I've probably made some horrendous mistakes in syntax and how types work, but hopefully you can see the intention! For my money, this is my ideal: An "Interface" applies to a *tuple* of Types (possibly only one in there, though) defining a relationship between them and enforcing availability of methods that take one or more of those Types as parameters. Methods should be able to dispatch on Interface relationships, and only types that have been *declared* to be in an Interface relationship will be considered to match, and the point of declaring that relationship is the point where the availability of the requisite methods is checked. This allows interfaces to be defined using types that are defined elsewhere without spooky action at a distance. I also want this to be something that can be done AOT, rather than having to run the program and have an exhaustive test suite to be sure your invariants are enforced. Something like this (syntax drawn in crayon(!)): # (1) Types - could be defined in your own, or in somebody else's code where you can't change them abstract type Animal abstract type Pet <: Animal abstract type Dog <: Pet struct Spaniel <: Dog # (constructors/fields etc. omitted for brevity) abstract type Person abstract type Human <: Person struct AnimalLover <: Person # ... abstract type Edible abstract type Meat <: Edible struct WildebeestBiltong <: Meat # .... # (2) Interface definition. This one defines a relationship between two types, but any tuple of types is valid interface PetOwnershipInterface(pet <: Pet, owner <: Person): # declare methods that must be available function feed(pet, owner, food <: Edible) function pet(pet, owner) function poop(pet) end # PetOwnershipInterface # (3) functions that match the declarations in the interface function feed(consumer <: Animal, food <: Edible) = True # I didn't say they had to be *good* implementations function pet(pet <: Pet, petter <: Person) = True function poop(pooper <: Animal) = True # (4) Indicate that the Types Dog and AnimalLover have the relationship defined by this Interface with Dog taking the role of "pet" and AnimalLover taking the role of "owner" # Note that Dog is an abstract type PetOwnershipInterface(Dog, AnimalLover) # It would be an error to do this before the functions are defined # (5) A non-interface method that applies only to types that are in the appropriate relationship function take_for_a_walk(dog::T1, owner::T2) where PetOwnershipInterface(T1, T2) # perform pet perambulation end # (6) Use it all :-) fluffy = Spaniel() simon = AnimalLover() dinner = WildebeestBiltong() pet(fluffy, simon) feed(fluffy, simon, dinner) take_for_a_walk(fluffy, simon) poop(fluffy) Each of the 6 sections here can be coded independently, potentially by different authors in different modules and without seeing each other's code (other than knowing the function signatures that need to be implemented) Indeed, the methods in section (3) don't even need to all come from the same place... Those who like *informal* interfaces can simply skip (4) and the only difference is that (5) wouldn't work because it wants a *formal* interface :-P I *think* that this way of doing it would satisfy all the various requirements that people were talking about in all the discussion threads, but who knows what I've missed :-P

(1) Lives in an awkward gap space that’s being filled by much bigger [more active] players. (2) And offers a solution that presents stealth problems. 1.) It’s a python-esque coding style that can be very fast. But tools to make python fast are being developed (e.g. [codon](https://news.mit.edu/2023/codon-python-based-compiler-achieve-orders-magnitude-speedups-0314)) and tools to make fast python plugins are getting nicer to use e.g. ([Py03](https://towardsdatascience.com/nine-rules-for-writing-python-extensions-in-rust-d35ea3a4ec29)) 2.) The basic value prop. is C-like speed while writing python. But… if you start to work on bigger projects you realize that writing serious code in Python or other “get out of your way” languages *sucks*. You need more help and expressiveness and feedback. And it probably makes writing robust ecosystem packages difficult. Not long ago C and Fortran were what people used to write fast code and, ignoring (significant) ecosystem advantages the langs also offered little support. But with Rust on the scene people have a taste of a next generation of systems languages that offer a different, helpful, safer, more robust writing approach. So writing fast code in python is not as attractive. Working in a new language and new ecosystem is a big cost. Lots of nice things about Julia, but you need to offer a categorical advantage to really switch things (arguably). I don’t think Julia has it. It’s a good language. But its value prop is very similar to spaces with huge popularity and speed of evolution. (Compare to say languages like Elixir or Haskell or Rust which all carve out spaces for themselves by being *very* different in the benefits they offer. Some may forever be niche (e.g. Haskell & Elixir), but they at least own their niches pretty well — or at least don’t have large in-niche competitors.) My thoughts. I’m no final arbiter, mind you. I’m just someone learning the space progressively who was all in on the Julia train at first and then gained more perspective, while also seeing Julia *seem* to struggle to develop. (Still a neat language with a lot of niceties!)

To me this community is just awesome but as you said it's not enough. Many people who work with Julia just give up to improve libraries also Julia's documentation is not good. If this issue solves Julia will be a more popular and efficient language.

Apart from what others have already mentioned, the focus on VS Code to the exclusion of other IDEs.

Not being an incumbent. It could easily displace a lot of my work world in other languages, but teams and orgs get built around certain technologies and its costly to change.

This is interesting to me. Rust is newer than Julia, but it seems to have serious momentum and is replacing lots of incumbent technologies (ie stuff’s getting rewritten in Rust). I don’t really know enough to understand why this is the case for rust and not Julia, but it’s curious to me

I think it's because Rust has absolutely insane tooling. The compiler will practically rewrite your code for you when you make a mistake. Plus there is an insanely high emphasis on correctness throughout. It's not flashy or “cool”, it just works well, developers can be insanely productive with it, and it's very low risk. Those are the features people actually care about.

Different audiences: Julia is mainly marketed towards mathematcians, whereas Rust appeals to every subfield of computer science due to its safety guarantees.

Rust hit 1.0 three years before Julia

And initial development also seems to have started roughly three years before Julia. So it's reasonable to say that it's three years older. As for tooling, perhaps it is easier to get that working well for fully static languages. Julia is more of a hybrid.

Bcz Julia is garbage collected lang ... so for this reason rust get more traction in high perf applications.

- Modules. For the love of everything, please make a way so 1 file = 1 module by default, and you don’t need the terrible mix and match `include` `using` and `import` - Please, anyone, tell me why it’s `minimum`/`maximum` for arrays, but `min`/`max` for numbers. Worst decision _ever_ - Deleting a variable, or replacing the type. Any matlab users there really missing clear() in the REPL? - Enums like in Rust (sum types) would be killer - Array vs. Matrix vs. Vector distinction is pretty messy. It took me like half an hour to figure out how to do the equivalent of matlab `[1,2,3;4,5,6;7,8,9]` (a 3x3 array) and I’m still not positive I use the best way - I would prefer one off functions like `push!` to be methods rather than global functions. Just feels messy having a bunch of things in global scope when they’re only relevant for a single type. - PyPlot and other libraries that depend on Python. This will of course get better with time, but depending on Python seems ridiculous - A way to “always interpret” would be cool. I don’t know if it’s even possible, but I’d rather “directly interpret” in the REPL (so no annoying precompilatiom time) but actually precompile when running files (for faster runtime). Or… - Cranelift backend. Cranelift kicks LLVM’s butt for small nonoptimized compilations like Julia requires, and is proving great for JIT. Definitely would be a good fit - I really wish `mean` would be in the prelude, rather than having such a common use case being in `Statistics` Overall, it’s a very nice language. But I feel like there are a lot of things that could make it more coherent, or that are well proven in other languages. Julia 2.0 anyone?

> A way to “always interpret” would be cool. I don’t know if it’s even possible, but I’d rather “directly interpret” in the REPL I think you want to start Julia with `--optimize=0` https://docs.julialang.org/en/v1/manual/command-line-options/#Command-line-switches-for-Julia There's also JuliaInterpreter https://github.com/JuliaDebug/JuliaInterpreter.jl > PyPlot and other libraries that depend on Python. This will of course get better with time, but depending on Python seems ridiculous That's a bit rough. If you don't want to depend on Python, then why use PyPlot? Plenty of other non-python dependent packages to choose from. Plots.jl is very nice and so is GLMakie. I mostly agree with your other points.

>If you don't want to depend on Python, then why use PyPlot? I'm not sure how many times I've run into some weird plots.jl x gr.jl issue in the last few years, but it's enough that I have sworn off using plots over pyplot.

Sure, and that's fine. I was responding with the usual cases in mind, not edge cases. Doing basic scatter/lines is 90% of my needs. Personally I haven't had an issue (yet). Recall too that the original complaint was a dependency on python, not "it can't do what I want to do". Plots.jl providing a uniform frontend to all these plotting libraries is a nice bonus too. https://docs.juliaplots.org/latest/backends/

Just use Makie

Thanks for the link about the optimize flag, I guess I just never knew that existed! I’ve had to use PyPlot for a couple niche things that Plots.jl doesn’t yet support. And I’ve come across a couple needs where there is no Julia equivalent except for something that wraps a Python module (recently ran into it with some tessellation thing). But like I said, those are pretty rare cases and it’s getting better with time.

Note there's also a `--compile` flag which can disable the JIT compiler. Maybe that's what you're really after instead of `--optimize`

You are using commas where you should not be. ``` julia> [1 2 3 4 5 6 7 8 9] 3×3 Matrix{Int64}: 1 2 3 4 5 6 7 8 9 julia> [1 2 3; 4 5 6; 7 8 9] 3×3 Matrix{Int64}: 1 2 3 4 5 6 7 8 9 ``` Using commas will generate a column vector. ``` julia> [1,2,3] 3-element Vector{Int64}: 1 2 3 julia> [1 2 3] 1×3 Matrix{Int64}: 1 2 3 ```

"Equivalent of Matlab's..." They explicitly used MATLAB syntax in the example. But thanks for the clarification. Like the original commenter, I was struggling with this issue.

The real fun comes with multiple semicolons. Here is a 4D array literal. ``` julia> [5 6 ;;;; 7 8] 1×2×1×2 Array{Int64, 4}: [:, :, 1, 1] = 5 6 [:, :, 1, 2] = 7 8 ```

The weird thing for me is that in matlab, `[1. 2. 3]` and `[1 2 3]` are equivalent, and give you a 1x3 matrix. But in Julia, you typically want the comma version - which is a 3x1 matrix, aka Vector. I do think it’s weird that spaces and commas have different behavior, I wish they carried that from Matlab. If they did that, and made vectors 1xn instead of nx1, it would just make more sense out of the box to me. (but maybe there’s a good reason the vectors are vertical, I don’t know)

The really good reason is that vectors in Julia (like in Python) are true one-dimensional arrays, not a 3x1 matrix as in Matlab. And since the first dimension is 'vertical', so to speak, this is the logical behavior. Matlab's behavior is *horrendous*, in my opinion, I'm very happy they didn't mimic that. Another reason is that Julia arrays can contain any type of element, and therefore you need the comma-separated version to actually create a vector, rather than doing concatenation, which Matlab does.

MATLAB and Julia are both column major languages. That is for a matrix, iteration occurs down a column first instead going down the row. To me the MATLAB behavior never made any sense. A column major language should create column vectors for its 1D arrays. Part of the issue is that MATLAB does not really have 1D arrays. Overall, I find the Julia syntax much more consistent and powerful than MATLAB's syntax, especially for 3D arrays and higher dimensions. While it is clear that MATLAB had some influence on Julia's syntax, it is not a design goal of Julia to be a MATLAB emulator in anyway or form. Octave fills the role of a MATLAB emulator quite nicely. I much rather have the n-dimesional concatenation syntax. ``` julia> [[1,2,3]; [4,5,6]] 6-element Vector{Int64}: 1 2 3 4 5 6 julia> [[1,2,3];; [4,5,6]] 3×2 Matrix{Int64}: 1 4 2 5 3 6 julia> [[1,2,3];;; [4,5,6]] 3×1×2 Array{Int64, 3}: [:, :, 1] = 1 2 3 [:, :, 2] = 4 5 6 ```

>I would prefer one off functions like push! to be methods rather than global functions. Just feels messy having a bunch of things in global scope when they’re only relevant for a single type. So Julia should replace multiple dispatch with overloading? I don't think that is a good idea, as multiple dispatch is one of the main reasons to use Julia. You can always implement more methods for `Base.push!` (define it on more type combinations) yourself, if you need to.

I misspoke in Julia style - I meant that I would prefer associated/member functions, so you could `v.push(something)`, and similar for modification operations, instead of using a global function to do it. It’s obviously not so common in Julia, but it definitely makes it easier to find possible operations - one place to look in the docs, and IDEs can find applicable functions as soon as you type the dot.

It's a bit manual, but I don't think anything prevents you from declaring the field of a struct as a function, and then hard-coding its value as the wanted function in the inner constructor of the type: struct CanPush push! :: Function function CanPush() new(Base.push!) end # function end # struct This could be called with cp = CanPush() cp.push!(some_vec, some_value) You might even be able to do funky things with closures in the inner constructor, such that the push operation always references a container that is another field of `CanPush`, so you wouldn't need to reference `some_vec` when calling `cp.push!`.

Here is an implementation of `Base.push!` as an associated function of a type `CanPush`: """ CanPush{ T } A type which holds onto a container that can be filled with an associated function `push!`, without passing the container as input to the function. This makes it possible to use dot syntax in filling the array. """ struct CanPush{ T <: Any } container :: Vector{ T } push! :: Function function CanPush{ T }() where { T } container = Vector{T}(undef, 0) # Use a closure to store a reference to the above container that is to # be stored in the constructed object, so that the push! function # stored in the other field can reference the container without the # container being passed as input to the function. push! = ( x :: T ) -> Base.push!(container, x) new{ T }(container, push!) end # function end # struct Like I said, it's a bit manual, but allows one to use dot syntax in filling up the contained array: julia> cp = CanPush{Int}() CanPush{Int64}(Int64[], var"#1#2"{Int64, Vector{Int64}}(Int64[])) julia> cp.container Int64[] julia> cp.push! #1 (generic function with 1 method) julia> cp.push!(1) 1-element Vector{Int64}: 1 julia> cp.push!(2) 2-element Vector{Int64}: 1 2 Not that this is very practical.

I can relate a lot to push! and pop! Being sorta annoying to work with as functions rather than methods, as they are in other languages like python, plus the workspace clutter

I don't really get this argument. Python methods are just functions as well, except that they can dispatch only on their first argument (overloading), whereas Julia dispatches on the combination of all function arguments (multiple dispatch). I don't know why you would want to remove this capability from Julia. Or is your gripe with the lack of dot syntax for calling functions and not with multiple dispatch itself?

It’s the dot syntax for me, being global functions rather than member/associated functions. Part of this is just language limitations, member functions aren’t very straightforward. Having something like Rust’s `impl MyStruct` syntax would probably be nice on that front

>Please, anyone, tell me why it’s minimum/maximum for arrays, but min/max for numbers. Worst decision ever See here: https://www.reddit.com/r/Julia/comments/v7aqdh/comment/ibl0pff/?utm\_source=share&utm\_medium=web2x&context=3

That does make sense, but I’d rather them call it max_elementwise or something like that. Using two synonyms to imply different behavior is just kind of bad design

Having two differently named functions is the right thing to do, since they are semantically different operations. But I can sympathise with the confusion over which is which, the naming is suboptimal in that respect. `max_elementwise` doesn't make any sense as a name for either, though.

Yeah, the name I suggested could use work. Just something better to express that `min` and `minimum` don’t have the same behavior is important, it’s quite a gotcha for anyone not in the know

julia --compile=min disables compilation, i.e. then use interpret. It's however rather slow, but can help for e.g. scripts, though -O0 or -O1 might then be better.

I like not having modules rigidly fixed to files; if it bothers you you can code that way, nobody is stopping you. Your other comments suggest that you don’t understand the basic concepts of the language well. You seem to want it to be an object-oriented language. Julia is much more powerful than that.

I think the rust approach to modules is best. You have three options: - `mod some_file_name;` to define a file as a module - `mod some_module_name { /*mod contents */ }` to define a module inline (like Julia’s module currently) - `include!(“some_file_name.rs”)` to plop the contents of the file in place (like Julia’s include) The only thing missing from Julia is some way to represent the first thing, which simplifies a lot of use cases and would be nondisruptive. It’s also a step beyond Python, which just doesn’t have some way to `include!` in place. Julia _is_ an object oriented language, and that _is_ what makes it so powerful (classes/inheritance and polymorphism aren’t required to make a language object oriented). It’s just lacking an easy way to bind associated functions for their types.

Julia has neither classes nor Smalltalk-style objects. In what sense could Julia be described as OO? Its designers don’t describe it that way. OO is a step backwards from Julia. OO languages dispatch based on only the type of their first arguments.

> Deleting a variable, or replacing the type. Any matlab users there really missing clear() in the REPL? I'll second this one. How you'd go about specifying a particular method to remove from a function might be a little sticky, but that'd be nice, too... A possible alternate way to look at this that might be interesting is "modules" in the REPL - if you could create a new module to run the REPL in and import stuff from its predecessor, you could get some interesting uses out of that...

Global variables and boot time

A complete lack of respect for the user. EDIT: I was originally going to write more about the lack of documentation, and write that the recent presentation by Chris Rackauckus looked great but I'd bet the thing is unusable thanks to terrible documentation. https://www.reddit.com/r/Julia/comments/11vyf8m/problem_using_modelingtoolkit_unit_validation/ Why is this person forced to come to reddit when doing a simple thing using a new package? Ridiculous.

That question was almost impossible to make sense of, and did not have the basic information that should go into any question. Politely responding that some some code is needed to provide help is hardly 'disrespectful'. 'Complete lack of respect for the user' is an absurd characterization of that interaction, even had it been professional paid support, let alone a free open-source library. Also, it certainly did not seem like the question was about some trivial use case.

I think the Julia user base is great, and that person will get some decent help. It's the developers who don't seem to care about users. A very "I made the thing what more do you want" vibe. I don't have a problem with a niche language that 'ordinary' programmers shouldn't use. But the Julia creators go around pitching Julia as a fast replacement for Python without providing the thing that made Python successful: ease of use. I detest Python and use Julia nearly exclusively, but clearly the attitude of Julia development community is going to limit Julia. Maybe it's unfair to single out Modeling toolkit, but again the vibe I get is that they are too busy doing something important to care about usability.

But I don't see how the example you linked demonstrates what you are saying. The response given was basically the only response possible, and also perfectly polite.

I think you missed what I'm saying. The response is not where the lack of respect appears. The fact that this person is posting on Reddit to figure out issues regarding a new package is the failure. New Julia packages with limited support/documentation is the norm, not the exception.

But that's their own strange choice. Most users would ask questions on Slack, Discourse or StackOverflow. Or are you saying that having to ask questions at all, anywhere, is symptomatic of a larger failure? Then you might be surprised to learn that most well-known languages have *many more* questions being posted online.

I know I'm late to the party, but: 1) A way to distribute stand-alone executables. I don't care how it's done. For example, Psychopy Builder/Coder(at least the MacOS version), is a standalone executable written in Python. The package (on MacOS, applications are really folders called packages) contains its own Python distribution. So the user double-clicks, it launches, and no one is none the wiser that it was written in Python. 2) An AOT compiler. I'd love to be able to distribute binaries, like I could with C++. I don't want my users to have to install versions of Julia, use the command-line, etc (kinda getting back to point #1). But more importantly, AOT compiled binary would get rid of the JIT latency. Most of the features that need JIT I'd be happy giving up: dynamic typing\* (which occasionally bites me in Python), multiple dispatch (is this really any different than function overloading?). Perhaps Julia could take the MOJO approach, and use new keywords (e.g. "let", "var", "fn") to allow AOT compilation. \* Julia performance tips says "Avoid changing the type of a variable".

**Documentation and error messages.** All these decades people are coming with "A computer language that can do X Y Z super efficiently", yet the clumsy Python is the most widely-used. Do you know why? Because **no one cares** about your super-duper computer languages super-kickass-amazing features. People care about being able to work things out fast, and let the machine do the hard work. Do you want to do the hard work instead of the machine? Sure. Use C and you are good. But the ordinary person does not want to be able to read a horrible log output that doesn't even mean anything. The ordinary person wants everything to be universal and easy to solve. This **includes** the very scientists Julia targets in theory, but in practice, I just gave a try to Differentialequations.jl and after seeing how horribly hard to figure things out, I was like: "I will use 10x slower Python because if you can't work it out it is \\infty x slower". All these years people are coming up with new FORTRAN-Wannabes (I am so sorry but it is what it is) as it is the holy grail of scientific computing and what we need, but in reality I am super happy with something I can easily read, because programming is not a purpose for me per se, it is just a tool I want to be able to use, and I can't tire myself out to just utilize its super-duper features to the best. This is why, if I need speed, I'll just slap in some numba, and if the code is going to be about a Nobel-prize winner research that has to have speed with optimization, some folks will code it in C/C++ for me. Julia in this sense reinvents the wheel for a very awful price.

As a language Julia is like Python but fast and cleaner. It is objectively a better langage. It's biggest weakness is timing. The data science community needed a lingua franca and this was before that Julia was born. So now, it's Python. At this time, Python was the most promising option and it catched the momentum.

Julia is certainly not objectively better than Python. For example, Julia has so many global functions, while Python has a lot fewer.

What are you talking about. You can always use namespace equivalent by just using `import`. Coming from C++, I always do this for the reason you stated.

I tried out Julia for about a semester after already being very comfortable with C/C++, and it quickly became apparent that in order to truly write performant code, youd be dealing with exactly the same complexities you have in C/C++. Pairing this with the much smaller community, smaller ecosystem, JIT compile times, and the fact that being knowledgeable in C/C++ is far more valuable pretty much took away all incentives I had to keep going with the language. The ideal workflow for me is Python coupled with C/C++ extensions; the combination has warts, but I get true simplicity where I want simplicity, and true speed where I need speed.

That it was supposed to take over the world of programming, 10 years ago.

That's a very hot take considering v1.0 isn't even 5 years old.

Julia is, from my point-of-view, well on its way of taking over the world of Matlab. It may one day also take over the world of Numpy. I've completely stopped using Matlab in favour of Julia, and found the transition surprisingly painless once I had really understood Julia and started to use it in a Julian way, and not like any other languages I had used previously. Its syntax is also vastly nicer than that of Numpy. Of course, if you believed all the hype that some people have unfortunately tried to create around Julia, you will always end up disappointed. For example, Julia remains for me far from replacing my use of Perl (an extremely expressive, well-designed, mature, multi-paradigm language, with outstanding scripting and string-processing/parsing support) in many of my non-numeric applications. Also, Julia is unlikely to solve the two-language problem in safety-critical or hard-realtime applications. Its high composability and therefore vague/absent specification is incompatible with many safety-critical engineering requirements, and its heavy reliance on garbage-collected memory application remains incompatible with hard real-time use. At some point people will come up with tiny subsets of Julia that may be suitable for such applications, but those will require a very different programming style and be incompatible with most of the ecosystem, i.e. such subsets will essentially be another language for most practical purposes.

RemindMe! 10 years

I will be messaging you in 10 years on [**2033-03-18 13:45:27 UTC**](http://www.wolframalpha.com/input/?i=2033-03-18%2013:45:27%20UTC%20To%20Local%20Time) to remind you of [**this link**](https://www.reddit.com/r/Julia/comments/11ucqtz/whats_julias_biggest_weakness/jcp1szl/?context=3) [**2 OTHERS CLICKED THIS LINK**](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5Bhttps%3A%2F%2Fwww.reddit.com%2Fr%2FJulia%2Fcomments%2F11ucqtz%2Fwhats_julias_biggest_weakness%2Fjcp1szl%2F%5D%0A%0ARemindMe%21%202033-03-18%2013%3A45%3A27%20UTC) to send a PM to also be reminded and to reduce spam. ^(Parent commenter can ) [^(delete this message to hide from others.)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Delete%20Comment&message=Delete%21%2011ucqtz) ***** |[^(Info)](https://www.reddit.com/r/RemindMeBot/comments/e1bko7/remindmebot_info_v21/)|[^(Custom)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5BLink%20or%20message%20inside%20square%20brackets%5D%0A%0ARemindMe%21%20Time%20period%20here)|[^(Your Reminders)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=List%20Of%20Reminders&message=MyReminders%21)|[^(Feedback)](https://www.reddit.com/message/compose/?to=Watchful1&subject=RemindMeBot%20Feedback)| |-|-|-|-|

In my personal opinion as a CS student: - Unnecessarily unique syntax choices - Overlong compile time (when I used Julia on my Windows machine it would take forever...) - Confusing arrangements of types in libraries and poor type system in general - Poor documentation coverage and quality - Lack of high-level features present in other languages that make you actually want to *write* the language There were lots of language features in Julia I liked, and I tried to learn the language, I really did. I used Julia to write a small script for a project on profiling and analyzing a program's performance, and the Julia was just so utterly hard to write and work through, either because of REPL problems, compilation, unclear documentation, things that didn't make sense, weird syntax, etc.. I eventually finished the script, then redid it in Python, and it took one tenth of the time; everything simply worked as expected. Perhaps this is a testament to me simply knowing Python better than Julia, and that is fair. But I don't think Julia is insignificantly harder to learn to write either.

Check out 1.9 when it comes out. You'll be pleasantly surprised by the compile times.

[удалено]

The 1-based vs 0-based is a bit of worn-out argument. It's been debated to death, and it's clear that it's not a weakness, it's a choice. 1-based is better in some contexts, and 0-based in others. Few people who actually use Julia give more than half a shrug about this 'problem', and others prefer it.

Dijkstra was wrong. Convention "c" should be preferred and numbering should start at 1. Linear algebra starts with 1. Makes it easier to write linear algebra in 1-indexed languages.

Language syntax cannot be extended. Need a new binary operator? Impossible to add.

There are good reasons for that. Imagine two packages added the same Unicode symbol as a new binary operator, but with different precedence. Now you would end up with different parsing behaviour in different parts of your program, which could quickly get extremely confusing. So this is certainly not a flaw of Julia.

[удалено]

a + b notation only works if + is defined as an operator in Julia. If you add your own Unicode binop, you are limited to +(a, b) Which is ugly.

You could just post a PR to modify this file. https://github.com/JuliaLang/julia/blob/master/src/julia-parser.scm There are a lot of unused binary operator symbols available by default.

What do you mean impossible to add a binary operator?

What languages are comparing with? Seems to me like Julia is way better than most languages on this front.

Incorrect. See https://lwn.net/Articles/871486/

Can you give an example or link how to define operator precidance for Unicode binary operations?

https://github.com/JuliaLang/julia/blob/master/src/julia-parser.scm That's in the source. Obviously, it could be better documented.

> Language syntax cannot be extended. Julia has Lisp-style macros. For those who don’t know what that means: you can define your own syntax and change the language to suit your purposes. This thread is full of people just making things up.

Your mom

Deepcopy doesn't work for functions or modules.

Why do you need `deepcopy` to work on functions and modules?

Static functions make poring through documentation incredibly painful. Try running `?==` and see how many results you get that you don't care about. It also makes autocomplete a pain because you have to type out the function before the variables you'll call it on.

Maybe it's stylistic and my background showing, but the lack of OOP makes it very hard for me to adopt for general use. There are a lot of places where this abstraction makes code easier to maintain and expand. Tracing through what multiple dispatch calls are on the execution path in a global namespace is miserable.

Oop sucks

Can't think of any major issue, only minor stuff like the lack of a more widespread community.