Good day.
I’m new to “Julia” and maybe overly excited. Any language evolves, it either moves away from the original idea or pupates and dies. For example, “Python” was originally a zen language, and now it is a plug in every barrel. “C” was an engineering language and became the basis for many things. “Mathematica” was an ordinary computer algebra system, but now it is turning into a mathematical combine. I have a question: what was “Julia” intended to be and what will it become? Scientific calculations, computer mathematics, data science, speed and flexibility, greedy programming, fast research… The potential is great, but how feasible is it and will it result in something iconic and unattainable for others? Perhaps this is not a question, but my personal reflection, but I would like to hear the reflections of people who are also interested in similar questions. I used to think that “Python” would become the language of housewives, but it didn’t work out, although it became a step into the world of high-level programming. “Julia” is presented as high-level and general application, but contains a lot of low-level and niche orientation and requires a lot of skill and ability. And this is its main problem in my opinion - it does not make calculations more accessible, because it makes the programming process more complex, i.e. the target audience is greatly narrowed and it makes sense and will only exist in a world, where complex calculations are a clear necessity. And it is in this spirit that “Julia” is developing, with the burden on the developer?
I would say Julia is already unattainable in many ways. But I know you are referred to as being renowned for something.
So, I think the whole deal is (again) reduced to the popularity aspect.
I don’t think you’ll find a consensus at this time. Also, the goals are a broad spectrum that covers the cumulative objectives of each user (e.g., there is no such thing as Julia’s goals).
We cannot deny that there are entities in the Julia ecosystem that (already) have a more significant weight in this matter than many small users combined… and they won their place fair and square. But I’d say let’s wait and see.
Enjoy the language in the meantime!
If you haven’t come across it yet , the “why” of Julia was written about at its first release: Why we created Julia.
It’s not only feasible, its currently being done! The prime example is the SciML ecosystem that powers all kinds of research using all the attributes you mention.
I think this is where there can be misunderstandings, in part because of all the things that Julia allows. Writing fast code in Julia is can be very easy for beginners with very little low-level fiddling simply by following the performance tips, which themselves are mostly beginner level (don’t use globals, write functions, etc.). Writing the fastest code can be hard and low-level, and a true beginner probably should not expect their first ever Julia algorithm to beat an optimized C library.
If you have the time (and the energy!) to read the “popularity” mega-thread, some of the questions you asked are discussed, but mabye not answered…
Another recent statement on goals is for Julia to be able to be the last language someone needs to learn. And this is indeed possible because of Julia’s flexibility.
In the end though, @algunion is spot on with “enjoy the language”, join in the Discourse community discussions, and the rest will take care of itself.
It is high-level, and general (I could expand on that, and some practical limitations for now), but on “requires a lot of skill and ability”. All programming requires that. It’s not clear others are better.
E.g. Python isn’t better, its education ecosystem may though still be. Julia is arguably better for first users, if you limit to inherent advantages of the languages.
I would say the goal of Julia is simple, readable code, not just fast. Simpler because of e.g. garbage collection (GC), simpler than e.g. Java.
Languages like Rust and C++ without GC have their uses but are more complex. C is simple to the point of being dangerous for most uses.
If you want to look at languages that are in some sense better (e.g. safety-wise; for concurrent code) then you need to look at non-mainstream like Clojure, Agda and Rust. But none of those are simpler, maybe Clojure claims that. None are faster if you really know what you’re doing with Julia.
I think I picked up something new. The example you gave is a “framework” for a certain pool of research. But I agree, the future… we must live to see it.
I agree that Julia strives for greater simplicity and readability, picking up everything better that was in the same Python. And that Python is no longer the same. And that you can write in Julia in different ways. but I don’t have enough experience to talk about fine details.
But unformalized multiple dispatch with the abandonment of OOP and extensive typing leads, in my opinion, to not very readable codes. Cloud computing, in my opinion, was not particularly successful.
I appreciated it
- a tendency towards the development of an ecosystem, which was not so acute during the formation of previous languages, and therefore today it is a pain
- the ability to integrate projects in many other languages in Julia, and that it stands on the shoulders of successful and major predecessors
- preservation of the initial approach to quickly providing complex calculations.
But in general, my reasoning is on a slightly different plane - what has changed in the world thanks to Julia, what has become better, easier, more possible.
OOP is a failed paradigm. What is unformalized about Julia’s multiple dispatch? Are you talking about the specificity rules?
My personal preference for Julia is to become a replacement language for scientific/engineering applications currently written in C++ and Fortran. I am not interested for an alternative to Python to achieve higher performance and write code once in a single language.
But for this to happen Julia needs some changes so that it can be used with ease and efficiency to write large in size applications which do use external packages but they also contain a lot of code written specifically for the application itself. For this to happen Julia must change its hard to use and error prone module system and allow for the generation of a standalone binary executable of modest size.
I don’t believe that this is what the designers of the language have in their mind but as an engineer in the field of Computational Fluid Dynamics this is what I would like to see. Because the current state of the field with C++/Fortran, OpenMP, OpenAAC, OpenMPI, CUDA, oneAPI and Python gluing different pieces of code together, desperately needs a modern high level programming language which can help with the management of large pieces of code, has easy access to quality libraries, a simple building process and it is designed from the ground up to support parallel computing build into the language but interpreted in different binary code depending on the hardware.
I don’t think that a faster alternative to Python is the basic and most important need for today’s scientists and engineers. Python is slow but it has access to all these highly optimised libraries in C/C++ so that its own performance limitations are irrelevant. Researchers who want to test their ideas can do it in Python but they can also build large applications in Python where performance is not affected because all numerical work is done by libraries. The real need, at least from my perspective, is a new modern and high level language to use for creating these libraries but also the large in size applications needed.
In the beginning I was very excited about Julia but then I realised that its target was different to what I hoped it would be. Perhaps, this will change in the future. I hope it does.
To me, multiple dispatch leads to readable, and performant, code, unlike OOP which is horrible for performant code, also OOP code not too readable.
But it doesn’t rule out OOP if you want to opt into it. In fact Julia has at least 2-3 OOP systems available (see also Jeff’s small hack on OOP StackOverflow), i.e. with emulating Python’s OOP variant fully, as far as I remember:
and the newly already registered, despite there showing “open” (sadly the developer didn’t know of the other available, why I proposed in that comment documenting at least availability of both in Julia’s docs here):
OOP is about how you structure your programs, and its polymorphism can be very slow. That’s one reason OOP is optional in C++, i.e. you don’t pay for what you don’t use", but you DO pay if you opt into OOP/polymorphism/virtual functions.
There is one aspect that people like about OOP, which is that you can TAB-complete code (it also works in Julia, there have been discussion about improvements, I think Julia can match OOP, if not already), i.e. it’s helpful to find methods and maybe OOP-style is (currently) more writable that way. Code should be optimized for readable, for humans. I believe OOP leads you to write too much code, scattered, not too readable code-bases. It may not be obvious to begin with.
Julia also has features you may think missing. Many have pattern matching, even Java, and recently Python added support for it. Julia has had it available for many years in e.g. Match.jl and Rematch.jl. I’m not sure which package is best, but this is also optional to use, and some do not like pattern matching e.g. Rick Hickey developer of Clojure language. He usually knows what he’s talking about. The main idea of that language is persistent data structure (and Lisp [non]syntax), and using such (and functioanl programming) is the most important thing you can do for program correctness, and whe have such with Air.jl, FunctionalCollections.jl, PureFun.jl (I thought there was at least one more important package, where is HAMT?).
I do not know what the one and only goal of Julia is, but for me it solves the issue to write software that is easy to install on different operating systems, that can still be used in many years…
With Python or C++ this did not work out, and it still does not work out… I am currently writing a review of 8 different open source software projects for airborne wind energy, and most of them are very difficult or impossible to install, only the Julia version can easily be installed (well, unless you have OpenGL issues on your computer or not enough RAM)…
To be honest, I talk about software that is used only by a small number of people… If you have thousands of users things might look differently…
Around 2002, US DARPA launched the High Productivity Computing Systems program. Two programming languages emerged: Fortress and Chapel.
Fortress funding was discontinued. Chapel continues to this day, and in a way more directly addresses exactly what you just described, including binaries of a modest size.
I’m not sure if languages such as Fortress and Chapel are clearly what I personally want. Much of what draws me to Julia is its dynamism because I find this tends to make me more efficient as a programmer.
I’m not sure exactly what you are referring to with regard to modules. Depending on the complaint I usually either refer people to FromFile.jl or encourage them to use packages rather than just modules. Either way it seems that the Julia’s module system is quite flexible to accomodate various patterns.
The other direction of module system arguments in this space is to make a particular paradigm standard. In contrast, the direction of Julia development seems to be making standard packages not special at all so that people could assemble their own “standards”.
Julia as a whole is particularly challenging for standalone binary executables. There are quite a few dynamic elements which would be difficult if not impossible to implement in a standalone binary executable without linking in a bunch of things.
That said it should be possible for a subset of Julia to made into a standalone binary executable. We see some early efforts in this direction. See StaticTools.jl for example.
In some ways, you could even use PackageCompiler.jl and minimize the build size by removing standard libraries that you are not using, adding in sufficient precompile statements or example workflows, and then removing LLVM from the build. You still have a handful of binaries, but their overall size is “modest”. I suppose with some additional effort one might be able to statically link all of that together.
Personally, I do not really want to use standalone binary executables in any language at the moment. I much prefer to dynamically link in at least a standard library if not other modular components. pkgimages is almost what what I want, and I think some modest improvements are around the corner. For example there is some work being done on formalizing entrypoints in Julia programs. That seems like a clear prerequisite to creating self-executing binaries.
I’m a bit confused reconciling your desire for “standalone binary executable of modest size” with “management of large pieces of code”. For projects of a sufficient size, I really prefer modularity over monolithic binaries despite some potential extra pain in assembling the modules. These days containers seem to overcome any remaining challenges with modularity, although Julia’s project and package management system seems to fairing quite by itself in my hands.
In the various discussions here, “standalone binary executable” has slightly different meanings to different people. It ranges from just removing dynamic just-in-time compilation to actually fully static binaries. It would be useful to advance the discussion if you could elaborate.
At the end of day, it’s quite possible that Julia is not for you. If truly standalone binary executables is the highest priority, then several other languages focus on that end goal.
In particular, Fortran is still around and the community is still actively developing tooling. For modern alternatives, it’s not clear to me that it Rust, Zig, or a modern subset of C++ is terrible for this kind of work.
My take away from “Why we created Julia” is that the goal of the language is to mix dynamism with high performance. That dynamism makes static analysis and static compilation challenging to implement, though not impossible. As for implemetning “standalone binaries of a modest size” the main question is “How much dynamism do we need to sacrifice to accomplish that?”.
I believe we had a a quite extensive discussion about the challenges posed with the current module system and common/recommended usage on slack a few weeks back.
I agree with @panos.asproulis that is is hard to use, error prone, and remains one of the largest turn-offs to users from other languages. If you read through some testimonials in #4600, you will see the two of us are certainly not alone
Everytime I read another iteration of this discussion, my conclusion remains the same: FromFile.jl seems to work quite well. What is an actionable change at the moment that is not going to result in breaking language?
it’s useful, but a big downside is that it’s not very compatible with VSCode autocomplete
not going to result in breaking language?
imo if anything at all is worth breaking changes it’s this one
That sounds like a problem with the VSCode extension. I’m not clear how that is at all related to introducing a breaking change into the language. If this is the actual problem, then I recommend focusing on that problem.
it is hard to do that on package side without better integration into the language
see:
It seems quite possible to add this to the julia-vscode extension. They just did something similar for Revise.jl:
Interactive development of fast libraries with Revise.jl is unattainable in C++. A tiny change in a large codebase can be instantly picked up by Revise.jl, but in C++ you’ll need to re-build the project, which can take a long time if there are several compilation / linking steps involved or if you’re using templates heavily.
I totally disagree as a researcher who wrote C++ programs and used Python as a glue language. It is a pain. I hate programming in C++. Julia enables me to write high-performance advanced algorithms in my field which with my knowledge of C++ should not be possible to do before. To me, standalone binaries are irrelevant. In Julia, you can partition your large code base into several packages.
What will you do when these libraries do not yet exist? Develop them in C++ is a big NO for me!
@panos.asproulis Interestign that you work in Computational Fluid Dynamics. What are your thoughts about the future of Julia in this field?
At the moment, that field ahs the ‘biggie’ commercial codes like Fluent and Star-CCM+ Also big communities behind open source OpenFOAM and Code Saturne.
Do you see a ‘biggie’ code framework ever being devveloped in Julia?
Or do you see julia being used more as a development/plugin language like Java is used with Star-CCM+