Sounds good to me 
Yeah that’s consistent with what I thought. Thanks.
1 Like
Yes! Most of my colleagues just use R to fit GLMs to smallish data sets. You wouldn’t notice whether the code is running fast or slow. But you would notice a long start up time, or time to first plot.
In fact I used R today, for consistency with earlier parts of a project. And it felt really quick.
5 Likes
Another example would be a frequently-run command-line tool like git (in C) or mercurial (in Python).
1 Like
Well… niche or not, Julia is just solving all my problems It is, at least, as niche as MATLAB with a big plus in performance.
DifferentialEquations.jl is the best ODE solver available for control systems high-fidelity simulation. Period. I tested a lot, I tried a lot, and it is just better The AOCS simulator of Amazonia 1 is written entirely in Julia using DifferentialEquations.jl and the accuracy we obtained is just fantastic.
Julia is being used as a computational core for a mission operational concept simulator. Using this, we can have infinite capability to customize the simulated mission (the configuration files are .jl). Hence, we can use the same code to check the simulation on the fly, and also to perform multi-objective optimization.
I also use Julia as a scripting language, to fetch the satellite telemetry, process, and analyze it.
Conclusion: to do all those things together, I would probably need C/C++, Python, and possibly Bash, or C/C++ and MATLAB plus some extension.
I know that Julia was supposed to solve the two-language problem, and not to be one language to rule them all. However, the “niche” he is referring seems to be the entire numerical computing community! In this case, the only thing the separate Julia from Python is time. In 8 years, we have this amazing community, with these awesome packages. What would we have 20 years from now?
36 Likes
Not to detract from your point, but there have been a few threads on not-so-competitive IO and string processing performance. From what I can tell, there aren’t any inherent trade-offs at play like you’d have with the compiler/GC and TTFP, just more development time/resources required.
1 Like
@oheil said they wanted to stop participating in this back-and-forth, I hope we can honor that.
2 Likes
I guess you can observe a lot quite negative responses for any topics on that site. 
I fairness, one cannot both make a last point, and declare the discussion over. One has to allow others to respond to that last point.
1 Like
These 2 statements look for me to be written by persons without deeper Julia knowledge because they cover mostly feelings / first impressions rather than concrete, valid points.
Every programming language has to make trade-offs which makes it better / worse suited for specific tasks.
In Julia, the main tradeoffs are imho just-ahead-of-time compiler and dynamic typing. On one hand, they enable the great flexibility, composibility and performance of the language.
On the other hand, they have some drawbacks compared to static compilers on one side and interpreted languages on the other:
- time to first plot (although I think that many people are overstating the importance of this point)
- it is difficult to compile to small portable libraries because the Julia runtime has to be included to deal with unexpected types
- type errors are runtime errors, not (mostly) compile-time errors like in statically typed languages
Some points just need more time / resources:
- documentation / examples / online QAs
- performance improvements of specific components (like IO, string operations)
- most important: people who know Julia, both programmers and decision makes in management, so that choosing Julia for a task it is well suited is natural, not an uphill battle.
Julia is my favorite language and I think that these points will be mostly mitigated in the (not so far) future.
5 Likes
Of course, I am only talking about me to stop my part in this discussion!
2 Likes
Juila is also my favorite language!
If I had a magic wand, it would enable static compilation of Juila to WASM.
( 
)
4 Likes
Automatic refactoring is usually a glorified text replacement engine with templates. The Julian solution to that problem is writing clean and small interfaces, at zero or near-zero cost.
This makes the boilerplate-management infrastructure that C++/Java programmers are used to unnecessary in Julia. Good riddance.
8 Likes
An extract method functionality is very useful for Julia (speaking from experience), you can write and test your code in global space and then turn in into a function with a shortcut. It actually promotes writing more small functions since it’s easier to turn any block of code into a function, and it’s also less error prone (it’s easy to miss a variable and leave it as an unintended global).
2 Likes
PS I like 0-based indexing more, but since we’re doing memes… 
31 Likes
Isn’t that just adding a function(...) and an end though?
I guess one could call that refactoring, but then at that point I will insist on tidying up my desk being refactoring.
2 Likes
Maybe. It’s supposed to be a compilation delay. I was also contemplating some google-translate mistranslation instead, but I couldn’t think of a suitable one.
It’s not perfect.
The third question for the Python et. al. could be “WHAT DO WE HAVE?”, and the answer “C++ AND FORTRAN”.
1 Like
The interesting part is figuring out which variables needs to be in “…”. Try to list of the variables that needs to be in there in that piece of code and see how long it takes you. The computer can probably do it faster and more reliably.
using Gadfly
mu = K1
const alpha = 1
const beta = (alpha+1)*mu
for i=1:10
x = rand(100, f(K2))
end
plot(x = K3, y = pdf(InverseGamma(K4,beta),K5), Geom.line)
ind, K7 = K6.asd
x = [K8[K7] for i=1:K6]
1 Like