Julia

Wolfram is write only.

The performance difference you are showing is negligible considering the large increase in development time and decrease in readability Rust would bring.
If Rust can something built in or on top of it that allows for formal verification of correctness, then I think it would be perfect for mission critical systems like avionics.
For pure number crunching with no real-time constraints, Julia is far superior.
Heck, the OP links to a blog by the creator of Rust (first link) where he states clearly that Julia is a great goldilocks language with tons of promise.
If he thought it was useless because of Rust (his creation), then I'm sure he would have said so.
Long story short, kys.
:^)

holy shit that font is unbelievable

No it won't. Python or bust

I think Python is fundamentally too dynamic to do what Julia does without losing correctness. Its strength is in its fast libraries. You can get faster than CPython, but there are limits.
My experience is mainly with CPython and scipy, though, not with other Python implementations and Julia.

Anaconda, the company that made the Conda containers (and the one who helped maintained the SciPy libraries and Jupyter notebook), has an incentive to make Python out perform Julia at all cost, as to not loose users. Anaconda is R-friendly BUT they are competing with Julia

I tried Julia once and the startup times due to the JIT were really really bad. Is the intended use case of this language for large calculations you start and let run for a long time? Because quick scripting does not appear to be the language's strong suit.

Lots of people have incentives. This job can't be done, and moreover it can't be done well. Read the stochasticstyle.com link in the OP.
and python is just a terrible, awful language. don't keep using just because you wasted some time on it.

this + the focus on number crunching + popularity are why I don't use Julia. I like that it's run from source (critical for sysadmin stuff) but I can't justify installing it or even running it on servers. I like that efficiency is possible but I don't do much that's actually focused on numbers. Even a statistical work (in-depth metrics for managers) was mostly webdev... and it relied on fast start-up times because I could use CGI. And all my free 'meme language' points are allocated elsewhere.

Well-written SciPy code is barely affected by the performance of the Python interpreter.

Benchmarks that show a language beating C by large margins are a huge red flag that it's propaganda.
- these benchmarks come from the Julia authors themselves.
- they're testing the most recent version of their shit vs an ancient version of GCC. Julia 0.6.x came out Jun 2017. GCC 4.8.x came out March 2013.
- they're not actually testing performance of optimized hot loops, instead it tests performance of subjective 'pretty' code by the Julia dev's standard:
- subjective 'pretty' code by the Julia devs' standard isn't like you'd actually write in C. For example, this is part of the "matrix_statistics" test above where they're writing C code like you would if it were garbage collected and allocations were cheap:
struct double_pair randmatstat(int t) { dsfmt_t dsfmt; dsfmt_init_gen_rand(&dsfmt, 1234); int n = 5; struct double_pair r; double *v = (double*)calloc(t,sizeof(double)); double *w = (double*)calloc(t,sizeof(double)); double *a = (double*)malloc((n)*(n)*sizeof(double)); double *b = (double*)malloc((n)*(n)*sizeof(double)); double *c = (double*)malloc((n)*(n)*sizeof(double)); double *d = (double*)malloc((n)*(n)*sizeof(double)); double *P = (double*)malloc((n)*(4*n)*sizeof(double)); double *Q = (double*)malloc((2*n)*(2*n)*sizeof(double)); double *PtP1 = (double*)malloc((4*n)*(4*n)*sizeof(double)); double *PtP2 = (double*)malloc((4*n)*(4*n)*sizeof(double)); double *QtQ1 = (double*)malloc((2*n)*(2*n)*sizeof(double)); double *QtQ2 = (double*)malloc((2*n)*(2*n)*sizeof(double));(cont.)
- the C code benchmarks free() per iteration but the Julia code's benchmarks don't include garbage collection.

As expected, the benchmarks are bullshit. Here's the source if you're curious:
github.com/JuliaLang/Microbenchmarks

Looks like we should redo all tests with state of the art C, Python, JS and Go.

why?

gonum.org/post/introtogonum/
github.com/timqian/scientific-computation-libs-in-javascript

Why?

lmfao

but they're not though, since they're
that's more like comparing code using linear types to control memory vs. GC.
1. use some alternate allocators and show how that affects timings
2. add idiomatic_randmatstat()

...

It's JIDF, Julia Internet Defense Force!

Go is not very good language and there are better alternatives.
github.com/ksimka/go-is-not-good

what did S/he mean by this?

That's quite the understatement tbh. Go was literally made for retards.

stallman.org/articles/genderless-pronouns.html

Why don't you just use assembly? lol

stackoverflow.com/questions/10268028/julia-compiles-the-script-every-time/10711762#10711762

IMO you are all too critical. Julia hasn't even had its 1.0 release and you are comparing it to mature languages like Python that have had 27 years to polish themselves and gain users/libraries etc...

Attached: mechajyo_mini.png (629x736, 178.18K)

Welp.

That's not that SJWy, as Stallman goes.
Do you know anything at all about the guy?

Yes, he is GNU/fucked, and he like birds and hates babies. He is also an autist.

...

What is perse implying?

You forgot that he's also Jewish.

I'm actually impressed by LuaJIT. Faster than Go and Java. I'm surprised people aren't writing full desktop applications and webservers in it.

Don't lie.

I don't think it's that great.

Way to miss the point, there are fundamental limits to how fast python can get due to its dynamic nature.
Using numpy and scipy or cython becomes like writing in a different language, it becomes verbose and doesn't look like standard python.
And the interpreter is still there between the byte code and machine code.
Julia is going to allow saving JIT'd code as .so files in the future if someone needs quick startup, like this guy

>>>/out/ is that way then

He's a faggot alright, but definitely not an SJW faggot.

Julia is a general purpose language. The initial focus on number crunching because they wanted to have an initial user base who are interested in serious HPC type stuff, since that domain currently doesn't have any good high level language solutions.

If the initial user base was web developers, well, I'm pretty sure we all know it would have become a monstrosity in design. The native number crunching semantics (basically MATLAB semantics) are actually going to become a library IIRC for 1.0

All that said, it can be used for web development. e.g. github.com/essenciary/Genie.jl
Because it is a general purpose language.

That's good. Nim and Rust have similar capabilities, far more sophisticated than the C/C++ preprocessor.

Rust is probably too low level, but I wonder if Nim will end up being a major competitor to Julia?

They were only slightly influenced by lisp, which is a good thing.

Metaprogramming is pure cancer and the part of a C++ project most likely to go malignant and kill it.

Okay, I just started using Julia the other day and it's great. Easily my new favorite language!

Because if you want to be a hipster and use a modern programming language that nobody else uses like Julia, Nim is a billion times better.

functional programming with imperative datastructures is a pretty sick feature performance wise, but dynamic typeing is pretty lame from a safety perspective. Also because memory management is so hidden from the programmer is make optimising for cache line length to avoid cache misses and timing allocations deallocations / garbage collection impossible if those are things which are important to you, and they ought to be if you're concerned with performance because cache misses are real hogs. Multiple dispatch and overloading are horrible features to have in your object model if you're interesting in optimising anything at all because they obfuscate what your program is actually doing where and the less clear you make what your program is doing the more impossible it becomes to optimise.

All in all Julia is great for non-programmers who don't know how to optimise code to right moderately efficient throw-away code in environments where safety isn't a priority, which is exactly what it's design for, but that's not my use case.

"metaprogramming" is almost exclusively used to mend the flaws of the programming language.
Prove me wrong.

sure.
and the most important flaw of a programming language is "it has no way to do this new amazing thing that we didn't even know was a good idea when the language was designed"

Julia doesn't even have buffered I/O, which is why people are on their gitter asking "why is this Python hello-world loop 500x faster than this identical Julia loop", and are getting answers like "oh that depends on the terminal. why do you want to do that anyway?".
The optimizations required are completely trivial, and wouldn't compromise Julia's focus, but Julia doesn't have them. So if you want to use your 'general purpose' language to write a simple unix filter, to turn 300G of logs into 30G of time-series data or something a number cruncher *could not even imagine wanting to do*, then the best way to start is to hack on Julia itself.

Most people on Zig Forums aren't anywhere close to HPC or mathematical computing. And if they were, all the docs are in Python, MATLAB, or R, even if there are bindings into Julia. It's just "why bother?".

Buffered I/O exists to cover for shitty programming. It's not necessary.

This. When I was in college we did everything in Matlab. Most papers I read were in Matlab or python. I didn't see any R, but my understanding is that R is better suited for statistical.analysis of large datasets, which wasn't really what I was doing. My datasets were fairly large though.

I don't think Julia metaprogramming is very similar to C++ metaprogramming.

I like lisp syntax.

Julia has hit 1.0 now, so code written now should work on future versions.
Python is finished!