[zz865]

Wow I hadn't seen deno before, looks great. I dont like js/ts, but if you have to learn it for front end dev, it makes sense to use it at the back too.

I'm not sure what advantage Julia has over Python. Yeah it has some typing and can be faster, but its too similar. Still single threaded.

[hpcjoe]

Most definitely not single threaded. From one of my codes

# Threaded inner loop, each thread has no dependence upon others

  Threads.@threads for t=1:Nthr

        inner_gen_cpu1!(psum,ms,me,cls,2)

  end

That's all you need. You don't need pthread create/join, you don't need installable language extensions, you don't need to appeal to external tools/libraries to enable threading. Its built in to Julia. And it is trivial to use.

[bjourne]

But is it real kernel threading or the same kind of cooperative threading that Python also supports?

[elcritch]

It's real kernel threads. Julia also supports cluster computing too.

[bjourne]

According to this discussion thread, Julia requires the number of kernel threads to be specified at startup: https://discourse.julialang.org/t/does-multithreading-requir... This seem to be more like pyprocessing and much more limited than the pthreads interface.

[ddragon]

I didn't go deep on Julia's multithreading, but what he is saying is that Julia uses an MxN threading (I think nowadays if you don't specify it at startup it will just use one for each cpu thread), which is the same as a language I did most of distributed programming (elixir/erlang), and as far as I know it's the same as Go.

Having 1 kernel thread for each CPU thread means that your program can use all available CPU threads at the same time (so you get all the parallelism available within the machine), and having a language based scheduler for each thread means you can have minimal overhead (no need to do a system call) to create a new concurrent execution (meaning lightweight/green threading similar to what python allows, except being automatically distributed by the language within all kernel/cpu threads). In Elixir this means you can create millions of processes even though the OS will only see one thread per logical cpu thread, and I never felt the limitation of this abstraction over multiprocessing (of course, Julia is definitely nowhere near as mature - and maybe never will due to stuff like preemptive scheduling and parallel garbage collection that is easier to implement in a language with only immutable types, though it seems to be moving along, and in Julia 1.7 the processes being able to move between kernel threads solving the issue mentioned in that discussion you linked).

[bjourne]

But that scheme is the same as green threading and has the same faults. Start Julia with one system thread. Run one infinite loop in one green thread and another in another green thread. One of the loops will run while the other will wait until the other completes (which it never does). This is inferior to Java and C# which both uses system threads by default, allowing both infinite loops to run. Erlang/Elixir has the same problem. You can run thousands of green threads, but if one of them is stupid enough to call a blocking C function then all others have to wait.

[d0mine]

Python threads are built on top of "real" preemptive OS threads. The presence of the GIL does not change that.

GIL can be released and it is released e.g., for IO, during heavy computations in C extensions--Python program can utilize multiple CPU cores.

[RemoteControlr]

As has been pointed out, Julia is not limited to a single thread. It's actually got a pretty good support for parallelism both at the thread and process level.

And no, Julia is not too similar to Python. Julia has multiple dispatch, Python does not.

[xbpx]

Another point that is often lost is how mathematical Julia code can look, especially for matrix functions.

Yeh this is superficial, but so are 200 dollar sneakers and they do just fine.

Honestly there is a real pleasure writing code that looks like it could be on the blackboard. The numpy / numba world in Python just feels... not great.

[Tarq0n]

I actually consider that a negative. Mathematical notation is fine when you're dealing with limited space on a blackboard, but if you're programming please name your name variables and take the time to model your domain explicitly.

[chaxor]

I don't understand - what is wrong with condensing the python representation `sum_of_lambda_for_each_psi` to `Σλ∀φ`? It seems that 4 symbols is much quicker and easier to read than a slew of snake case stuff.

[joconde]

I'm not completely sure that you aren't joking. Maybe for a mathematician the latter would be "very readable"?

[mbeex]

Indeed it is (slight improvements not excluded). I would love to be able to write things like M^TA (w/o the HTML rubbish seen here - flavour of the same problem) for two matrices directly as code (can Julia do that?). Instead, I've been forced to learn row and column precedence in OpenGL, DirectX, Numpy, and whatever, paying attention to it in endless constructs.

Even after 25 years in the business, it's still a pain.

[TheRealKing]

So, one-letter English labels were deemed bad coding-style for decades, but suddenly one-letter Greek labels are good because some X-language (Julia) supports it. Seriously? How about single-letter Chinese labels? because that is my background and that is what I am comfortable using.

[dTal]

One-letter variables aren't always bad coding style. Some single letters are meaningful. It's conventional to use 'i' for an array iterator, for instance - or i and j for two dimensional iteration. x,y, and z are cartesian coordinates. It would be downright perverse not to call the base of the natural logarithm 'e'.

And so it is with greek letters. Many of them carry intrinsic meaning, or a loose collection of related meanings - they effectively are labels. It's not that people want to write dense and impenetrable code, it's that they would rather write μ than coefficient_of_friction because that is its proper name and how it appears in formulas and textbooks.

[fault1]

well, you can always program in wenyan: https://github.com/wenyan-lang/wenyan

But seriously, it's 2021. We are no longer slave to ASCII, or even English.

Most of the newer math oriented langs have heavy use of unicode (julia, agda, lean, etc).

[hnarayanan]

For each phi?

[fault1]

Completely disagreed. I was skeptical originally, because I wasn't used to seeing unicode symbols in code, but in certain types of mathematical code, it makes it /far/ clearer because your brain can link to the appropriate symbols in textbooks.

To me, it's a matter of familiarity. clearly human brains can process large amount of symbols. Just look at some east asian languages. Historically, there has been an ASCII bias in computer languages, but that is history.

Mathematics is a /language/, and one of the most universal in humanity because it models certain human reasoning.

[jkhdigital]

To your point, for personal projects in Elixir I’ve started using Japanese characters for function names because they can be so much more terse.

[sgt101]

This is really useful when relating Julia code to a paper or providing it as part of a paper - there is very little lost in translation.

[Mikeb85]

Julia is much, much faster than Python. For numeric code it's almost as fast as C++. They've used lots of cool tricks to become crazy fast on numeric workloads. It's also definitely got support for multithreading, clusters, etc...

[longqzh]

For numeric code, comparing to pure python makes no sense, since people use numpy+numba to do that. Is julia much much faster than numba? I don't think so :)

[adgjlsfhk1]

Julia is generally in the same ballpark as Numba (depending on the application they should be within 2%). The difference is that Julia is a full language, while Numba breaks if you try to use it with anything else.

[rfw300]

Yeah, Numba usually delivers on its performance promises when used right, but can be such a huge hassle oftentimes as to make it not really worth it.

[jjoonathan]

Yes, Numba is just barely less awful than managing a C build process.

Julia is a much better solution to the two language problem, here's hoping it can overcome the ecosystem inertia.

[jolux]

Probably not faster in an absolute sense but things like loops in Julia can be properly optimized and will sometimes be more readable than structuring your program entirely around NumPy constructs.

[longqzh]

For numpy, it's correct. But numba can optimize the loop. So optimized and readable loop is not an advantage of julia compare to numba.

[ChrisRackauckas]

Not in real-world contexts. This is spelled out in Julia for Biologists (https://arxiv.org/abs/2109.09973) which does the operation counting to show why using Numba with SciPy is still an order of magnitude slower in scientific operations like solving differential equations compared to Julia. An order of magnitude on widely used scientific analyses is pretty significant!

[dnautics]

yeah, then you try to use numba + scipy and then sure many things work but you're never too far away from a tableflip and wanting to curse your fucking life out.

[ur-whale]

> I'm not sure what advantage Julia

While I'm really not a fan of 1-based indexing, Julia's multiple dispatch is not something easy to match in Python.

[EDIT]: one thing that's still not solved in Julia is code startup time.

Many people will sell you some sort of workflow that works around the problem, but it's the same old tired arguments people would use to defend traditional compiled languages, and I'm not buying.

I really wish they would find a way to truly solve this.

[fault1]

I would say the almost every version of Julia 1.x has better in terms of code startup.

as in 1.7 > 1.6 > 1.5 > 1.4 > 1.3 > etc...

it's especially goten way better since julia 1.5, so really mostly in the last few years.

In julia 1.8, what's interesting to me is that the julia runtime will be separated from the llvm codegen; https://github.com/JuliaLang/julia/pull/41936

the immediate effect is to allow small static binaries without a huge runtime (namely the LLVM ORC), but the side effect is probably that the interpreter will also get better in cases where you don't want JIT.

[Mikeb85]

> [EDIT]: one thing that's still not solved in Julia is code startup time.

> Many people will sell you some sort of workflow that works around the problem, but it's the same old tired arguments people would use to defend traditional compiled languages, and I'm not buying.

I mean, Julia has a REPL so you can basically edit code as the process runs, which definitely makes startup time less of an issue. The fact Julia can produce such fast code is also pretty nice.

Starting a new process every time you want to run a snippet of code isn't getting the best out of a dynamic language...

[huitzitziltzin]

https://docs.julialang.org/en/v1/manual/multi-threading/

[adgjlsfhk1]

this is just false. Julia has partir based threading (like go).

[edgyquant]

I do like JS quite a bit, I was a hater until a few years ago when I had to start working with it more than a snippet here and there, but I still prefer python on the backend. I think JS makes a lot of sense for frontend with the way everything is async.