Great. But I also want to point out the obvious in my post: there are scenarios with a nice tone when some experienced users go with the big guns when the OP only has a small knife. Oh, yes - they are talking civilly, but the very fact of ignoring the main issue and derailing the discussion is a disrespectful act (I would say that it can hurt even more than a direct insult - which usually says more about the one using it).
And there is the total ignoring of the main subject just because they feel that some misconception must be corrected.
And all the discussion is then directed towards those irrelevant misconceptions - and when the OP gets angry, the moderation finds the user guilty
At least, in my opinion, strawman and red herring (both wrapped in a civil tone) are more disrespectful than a direct insult and an aggressive tone.
So maybe we should show more respect to the OP and not start our own agora that totally ignores the main topic (like we already did here - myself included).
Make things. Build great packages. Make great tutorials. Put things on real devices. Launch a satellite with Julia. Donāt tell people that they use Julia then it will make them more efficient. Show them how efficient you are and enjoy using it yourself.
Hereās the issue for me - Iād love to show people how efficient I am, except I really am not efficient with developing stuff. Pretty much anything Iāve done so far could be done more efficiently in another language. For my microcontroller stuff, half the time Iām fighting a lack of tooling around debugging why the language decides to allocate something somewhere (VERY hard to find and mostly intuition based). Or finding a type instability and fixing that (at least somewhat debuggable with JET). Or trying to figure out how to use a specific function from somewhere in a way that doesnāt cause error paths to be included (nigh impossible). Itās not the microcontroller specific stuff thatās generally an issue, perhaps surprisingly. For PropCheck, Iāve spent countless hours already on trying to figure out how to best read docs to MAYBE infer what the actual pre-/postconditions of some code are, so that they can be tested with fuzzing (itās really difficult - we barely actually guarantee anything anywhere).
The ācommon threadā among all of these is very reliable developer tooling. I think thatās what most software engineers are missing, and that would not only help software engineers, but our existing community immensely too (because spoiler alert, even scientists are programmers! Good tooling helps you too!!).
So, my (repeated) answer to āhow do we win big?ā can only be summarised by what Steve Ballmer already said about .NET, way back when:
I wasnāt trying to defend the angry OP and critique the scolding guys. I actually tried to point out that the moderation might need to start earlier - because there are more things that can be hurtful/disrespectful than the aggressive tone.
My suggestion might benefit from some clarity - so here is a simple (and imaginary) example:
When somebody asks about some real issue with string concatenation and the responders are getting obsessed that OP slipped and used + instead of * (an artefact from previous langs that the OP used).
And in this obsession, nobody even bothers to answer about the real issue. Some even start discussing some philosophical reasons why * is better than + for string concatenation. The discussion branches and people are now discussing Rust slices on the space of this topic. Others are discussing the StringBuilder from C# - and some experienced Julia users are making jokes about R vectors.
Now imagine that the OP gets angry at some point and uses an aggressive tone. I donāt need to defend that tone - that is not defendable. I am just saying that we should also have rules about OK, we get you are smart, but stay on f&king subject.
P. S. Iāll not continue to answer in this space (to the branched discussion, I mean). It doesnāt look well in the context of the opinions I already expressed (we can start a dedicated topic - if needed. Personally, I donāt feel the desire/need to go in more depth - it seems @mbauman is on the right path with this).
A pretty hefty and common misconception implied in the OP is that because Julia is performant in fewer lines of code and extensible and etc. that Julia can simply replace other languages in all contexts. Thatās just not true, Julia made fundamental design choices with tradeoffs like any other language. Juliaās advantages are demonstrated in particular contexts, and while those contexts arenāt as narrow as people tend to make it out to be (e.g. āitās scientific computing, not general-purposeā), it also demonstrably does not cover everything. It should not be surprising that in contexts where dynamic allocation is all but disallowed, itād be very helpful if the language plainly declared any allocations, not needing runtime profiling on a more powerful system. Itās very plausible that Julia can get the tooling to be competitive in more contexts, but it wonāt necessarily resemble the workflow in other languages. And thatās fine.
In another word: make stuffs.
Hereās a big problem. Making stuffs is humanity mindās biggest fear. Otherwise, why would the big corporations of the world do what theyāre doing?
Assuming that adoption by big corporations is the criterion for success, it seems unreasonable to make a sales pitch with āweāre afraid to make stuffā. Fortunately, thatās obviously not an issue for everyone. Maybe one day enough stuff is made in Julia to catch the interest of more corporations, maybe not.
Of course I did not mean to point to people that were not nice, but at least to a level where we can check how to improve that would be nice. Otherwise I am not sure what the intention of your post was.So I am unsure how to further contribute here Maybe it is also me not being friendly and I am just not aware of itā who knows? Then I should stop contributing anyways?
I think programming languages become very popular when they are known to be easy to learn, easy to code and easy to deploy. As some testimonials have shown, Julia is not there for everyone yet, but it is on the right track to get there soon.
Hopefully the new tooling is helpful [ANN] AllocCheck.jl: Static code analysis to prove allocation-free behavior, and please open issues to help it improve. We are also targeting microcontrollers with hard real-time guarantees and we are using this to audit and enforce that all package code that we use (i.e. all SciML solver loops) are allocation-free and thus safe for these applications, and then using it in the end application itself. The genesis for this was actually to improve the workflows of the recent controls course we put together:
It also has a mode that checks for whether error paths are possible (again, because thatās not allowed on a control system). Itās not a battle-hardened checker yet but itās something to start building off of and improving by good solid issues and examples.
I donāt think thatās the case. Programming languages become very popular when thereās an application built on it that does well. Ruby is synonymous with Rails. Javascript is the backbone of the internet. People didnāt touch Python for science until Numpy/Scipy. R is universally agreed upon to be a pretty crazy language but has great stats packages.
Most people put very little thought into what hammer they are using, they just use whatever hammer the Kardashians are using. They are physicists, data scientists, chemical engineers. They wake up and read the news not on programming languages but on the latest dark matter paper or new single-cell RNA-seq results in zebrafish cranialfacial development. They care about doing their work, and what is most directly in their face isnāt language but frameworks, packages, and landing points for their kind.
Donāt treat these communities as homogeneous because they are anything but a single crew, each of them have different needs, and those needs are not language but a tool designed for their science and tutorials that speaks to them in the language of their scientific background. Some of these domains donāt even need a good package, āgoodā in the definition of 100% performance with multi-GPU MPI support and all of that, they just need a good entry point with good documentation that covers the types of problems they run into. Popularity comes by building one friend at a time, and we need to go case by case building front end tooling for each community that is interested.
Backing up @ChrisRackauckas āTime to Scienceā or āTime to Resultsā are important.
If you are designing a new satellite there is a time for it to be launched. You will have time to do N simulation runs before that time. Or in Formula 1 you need results back in time before the race.
Getting on my hobby horse here, āTime to Resultsā comprises more than the programming language. Time to access datasets and write out datasets is important - the quicker you can do that the ore flexible you can be.
Workflows are important - you can be organised and get your results quicker, and in a reproducible fashion.
Iām trying to learn C++, and hereās what I miss from Julia:
(1) Revise.jl instantly reloads a package Iām modifying. Recompiling a C++ project, with many compilation steps or template usage, can take a long time.
(2) Julia doesnāt have the object copying problem as early C++, so thereās no need for move semantics as a fix, which for C++ adds a lot of syntax noise (double ampersands) and boiler-plate definitions (ārule of fiveā).
(3) There are default printing and serialization methods for everything in Julia. For debugging, printing out a dictionary in Julia is much easier than inspecting the values of similar data structures (maps) in a C++ debugger. Serialization requires external libraries in C++ and is a pain according to people (I havenāt bothered to try).
(4) Conveniences like Juliaās @time macro versus C++'s std::chrono.
(5) In Julia, I donāt need to worry about inline, static, extern keywords required for proper scoping and linking of variables across multiple headers and source files in C++.
(6) Learning the syntax of Juliaās Project.toml (including complications like optional test dependencies and package extensions) is much easier than learning C++ build systems.
(7) Besides writing performance-sensitive programs, I also (ab)use Julia for interactive scripting tasks like analyzing log files. C++ seems too much pain for these quick and dirty tasks.
In my experience, c++ with a few libraries work fine as a one-off benchmark language with some competitive programming tricks. Writing large project might be painful though. I have lots of experience competitive programming in c++ but not a lot of experience with c++ projects really.
Sure, but thatās also why the OP asked āhow can we win big?ā, not āwhere is Julia bad?ā. I only gave my view on what certainly isnāt a typical Julia workflow, and yet all of the issues I mentioned are a shared experience with the rest of the community I encountered pretty much the exact same issues while working on PropCheck, except there all of those problems manifested as bad performance instead of not even compiling. Iām not saying we should have the same tools & workflows other languages have, but that we can certainly learn from other languages that do have good tooling for their ecosystem about WHY that helps them being successful.
THAT is why Iām convinced we have a tooling/debugging problem. Not just because itād benefit my particular niche.
I think Julia has a good opportunity to shine in the AI industry if we port TensorRT (there is already a jll) so people can run deep learning models at a big production scale using Julia.
How often do you really need a double-ampersand definition?
You can often = default; most of these, e.g. Foo(Foo&&) = default;.
A by-value definition, e.g. Foo(Bar bar) should also generally mean you donāt need a Foo(Bar&& bar). Calling with an rvalue bar will just call the by-value definition, using the most constructor instead of making a copy.
Personally, I much prefer C+Ā±style memory management over Juliaās.
I often define dump() functions to print an object, and have it callable from gdb.
Otherwise, youād have to actually define pretty print methods in python.
I suggest using Google Benchmark, or maybe nanobench (I briefly tried nanobench but found its results relatively noisy [it runs for fewer iterations so you get results quicker], so I stuck with google bench, but it has config options).
I think all the different meanings of static in C++ are a bit silly, but I think scoping is something that would be nice in Julia.
Iāve encountered tons of breakages due to packages depending on one anotherās internals. Would be nice if that could be forbidden.
It of course also enables more optimizations, i.e. a function with internal linkage doesnāt have to exist, so it can be inlined more aggressively if thereās known to be only a single callsite.
I think this and related issues of building/dependencies/getting a compiler toolchain together are one of Juliaās two biggest advantages (the other being the REPL/interactivity).
I encountered pretty much the exact same issues while working on PropCheck, except there all of those problems manifested as bad performance instead of not even compiling. Iām not saying we should have the same tools & workflows other languages have, but that we can certainly learn from other languages that do have good tooling for their ecosystem about WHY that helps them being successful.