Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia 1.6 Highlights

julialang.org

Post reply on HN
Print view View original

171–180 of 224 posts

Re: Julia 1.6 Highlights

#171

Post by pjmlp »

cbkeller wrote: post #152
eigenspace wrote: post #100

Earlier quoted context omitted.

Yes, I don't doubt at all that it's possible to make CLOS dispatch fast. What I'm saying is that because historically people using CLOS had to pay a (often negligible) runtime cost for dispatch, it limited the number of places developers were willing to allow generic dispatch. Julia makes the runtime cost of (type stable) dispatch zero, and hence does not even give julia programmers an *option* to write non-generic f…

In this context, I think there might be an argument to be made that Julia is to multiple dispatch (or multiple dispatch + JAOT) as the iPhone is to “touchscreen computers that can make phone calls”. It’s not that it’s the first, but it seems to be the first where the use of multiple dispatch throughout the community was sufficiently pervasive to kick-start the emergence of the strong network effects we’re now seeing…

Except everyone is forgetting that I also mentioned Dylan, from Apple, and whose goal was to be a system programming language for the Newton OS, with the Dylan team winning over the C++ one, but internal politics made the decision to go with the outcome of the C++ team alongside NewtonScript.

Re: Julia 1.6 Highlights

#172

Post by pjmlp »

dan-robertson wrote: post #142
pjmlp wrote: post #78

Earlier quoted context omitted.

I advise you to check Common Lisp CLOS and Dylan.

Common lisp’s typesystem is just not really as useful for this sort of thing. In particular it doesn’t have parameter used types so you can’t make eg a matrix of complex numbers. This breaks (1) a lot of the opportunity for optimisation by inlining (because you can’t assume that all the multiplications in your matrix{float} multiplication are regular float multiplications) or generic code (because you can’t have a ge…

Hence why I also referred Dylan, which was designed as a system programming language for the Newton.

Re: Julia 1.6 Highlights

#173

Post by newswasboring »

pansa2 wrote: post #168
tfehring wrote: post #167

Earlier quoted context omitted.

I think something to that effect was implicit in "the bundle itself includes a Julia runtime," but I vouched for this comment anyway since it's an important limitation and the parent comment evidently wasn't explicit enough to prevent confusion.

Elsewhere someone says “Fib was around 44kb with no runtime required”. Which is correct?

They are talking about two different systems. Static compilation is a separate project which is trying to include only those compiled code that is required. That isn't ready yet for normal people like me, but if you have the knowhow and your program meets certain requirements you can get a tiny binary.

PackageCompiler.jl just compiles everything and packages it up. It generates huge files, because it doesn't discriminate on which compiled stuff to include.

Re: Julia 1.6 Highlights

#174

Post by snovv_crash »

pron wrote: post #139
bbatha wrote: post #137

Earlier quoted context omitted.

Go has only concurrency of the features you talk about but is often competitive with Java in benchmarks. In my experience I’ll take administration of go processes any day of the week over Java — I’ve lost count of the number of hours lost to debugging gc stalls, runaway heaps and other garbage collector related issues never once had those problems in go. Go even reverted a generational collector because it had no per…

It's competitive in pretty forgiving benchmarks. And LLVM is way more advanced than Go's compiler, but not OpenJDK's. I'm not saying you have to prefer Java to Go, but its throughput is better. As to the stack-allocation claim, young generations might be hundreds of MBs; that might correspond to the stacks of 100K goroutines on some server workloads, but not of a few threads. So I'm not saying you must prefer Java to…

Having a Lamborghini racing a Toyota Corolla is of course going to show the Lambo winning. But if I need to maintain a fleet of them to move 1000 passengers around a city with certain availability guarantees, I'm going with the Toyotas every time.

Re: Julia 1.6 Highlights

#175

Post by tgv »

fermienrico wrote: post #22

Are the performance claims of Julia greatly exaggerated? Julia loses almost consistently to Go, Crystal, Nim, Rust, Kotlin, Python (PyPy, Numpy): https://github.com/kostya/benchmarks Is this because of bad typing or they didn't use Julia properly in idiomatic manner?

Idk, but just a few weeks ago I started looking at Julia, partly because of the performance claims. I wanted to write a program a bit heavier than your average starter program, so I wrote a back-tracker (automatic layout for stripboards, to be precise). It was

* interesting (not fun) to find out how Julia works

* annoying AF to discover that much of the teaching material was hidden behind some 3rd party website, presumably in videos (I didn't bother to register, but started browsing the manual instead). What's wrong with text?

* unnecessarily complex because the documentation for the basic functions is nearly inaccessible to beginners.

But, I managed to get a simple layout system up and running, and it wasn't fast. I rewrote it in Go (the language in which I'm currently working most), and it was literally >100x faster. And that should not be due to the startup costs, because a backtracker shouldn't have that much overhead JIT-ing.

I think I can now say that I can't see the use case for Julia. "Faster than Python" is simply not good enough, and for the rest there are no redeeming features. Perhaps the fabled partial differential equation module is worth it, but that can get ported to other languages, I guess.

Re: Julia 1.6 Highlights

#176

Post by [deleted] »

siproprio wrote: post #150
oxinabox wrote: post #145

Earlier quoted context omitted.

Window registry issues have been a thing. I have heard it is to do with how windows antivirus works. Since the registry is like 10,000 seperate files. It chokes on them. I have heard there is an upcoming feature to allow the package manager to work with the registry being kept inside a tarball, which is specifically being added to deal with this

It's not an av issue, at least not on my machine.

[deleted]

Re: Julia 1.6 Highlights

#177

Post by oivey »

tgv wrote: post #175
fermienrico wrote: post #22

Are the performance claims of Julia greatly exaggerated? Julia loses almost consistently to Go, Crystal, Nim, Rust, Kotlin, Python (PyPy, Numpy): https://github.com/kostya/benchmarks Is this because of bad typing or they didn't use Julia properly in idiomatic manner?

Idk, but just a few weeks ago I started looking at Julia, partly because of the performance claims. I wanted to write a program a bit heavier than your average starter program, so I wrote a back-tracker (automatic layout for stripboards, to be precise). It was * interesting (not fun) to find out how Julia works * annoying AF to discover that much of the teaching material was hidden behind some 3rd party website, pres…

Your relative skill and time invested in Julia vs Go makes that a not very fair comparison, I think. A 100x difference in performance is probably a sign of something that could be fixed in your code (common one: type instability). In general, Julia is being used to implement things like competitive versions of BLAS. Your Julia code can almost certainly be made much faster.

Coming from a Python and C++ background, I found it sufficient to just read the docs and do some Advent of Code problems to get productive in Julia. What videos are you talking about? https://docs.julialang.org/en/v1/manual/performance-tips/ I found to be a pretty good document on why and when Julia can be slow.

Re: Julia 1.6 Highlights

#178

Post by DNF2 »

wott wrote: post #148
systems wrote: post #86

Earlier quoted context omitted.

Its a suggestion to fix the awkwardness, one that will never get approved "Put your code into functions, people!" .. is the reason why most people dont notice the weird scoping rules You will only hit the weirdness face first, if you write scripts with global variables, which is usually what beginners do Most advanced users, and library writers, probably hardly notice it

> Its a suggestion to fix the awkwardness, one that will never get approved You were courageous to even try :-) From their refusal to see any use in explicit variables declarations, their (somewhat related) huge scope debacle, to its strange and irregular 'resolution', not to mention the original absurdly weird propositions they had made to resolve it: the scope and variable declaration subject is pretty hopeless in…

This is just a disagreement over basic design: should variable declarations be explicit or not. It is a choice, and something that reasonable people can disagree on.

Framing this as a case of irrational and illogical behaviour is unnecessary and unreasonable in my opinion. A lot of serious thought and debate went into the resolution. There is no need to disrespect and badmouth people because they have different priorities than you.

Re: Julia 1.6 Highlights

#179

Post by DNF2 »

tgv wrote: post #175
fermienrico wrote: post #22

Are the performance claims of Julia greatly exaggerated? Julia loses almost consistently to Go, Crystal, Nim, Rust, Kotlin, Python (PyPy, Numpy): https://github.com/kostya/benchmarks Is this because of bad typing or they didn't use Julia properly in idiomatic manner?

Idk, but just a few weeks ago I started looking at Julia, partly because of the performance claims. I wanted to write a program a bit heavier than your average starter program, so I wrote a back-tracker (automatic layout for stripboards, to be precise). It was * interesting (not fun) to find out how Julia works * annoying AF to discover that much of the teaching material was hidden behind some 3rd party website, pres…

I simply do not understand how some people are able to form so strong opinions in such a short time, and spew out disdain and negativity on the most flimsy basis. It's a matter of temperament, I guess.

Julia performance should be on par with Go, if it's slower, read the performance tips in the manual. As for teaching material on 3rd party websites, I don't know what you mean. The Julia manual is available from the julialang.org website.

As for re-writing DifferentialEquations, that is extremely strongly tied to the multiple dispatch paradigm, re-writing it would be hard. What you can get is wrappers like diffeqpy and diffeqr, which call out to Julia.

Re: Julia 1.6 Highlights

#180

Post by pjmlp »

snovv_crash wrote: post #174
pron wrote: post #139

Earlier quoted context omitted.

It's competitive in pretty forgiving benchmarks. And LLVM is way more advanced than Go's compiler, but not OpenJDK's. I'm not saying you have to prefer Java to Go, but its throughput is better. As to the stack-allocation claim, young generations might be hundreds of MBs; that might correspond to the stacks of 100K goroutines on some server workloads, but not of a few threads. So I'm not saying you must prefer Java to…

Having a Lamborghini racing a Toyota Corolla is of course going to show the Lambo winning. But if I need to maintain a fleet of them to move 1000 passengers around a city with certain availability guarantees, I'm going with the Toyotas every time.

Likewise if I do races for living I am picking the Lamborghini.
Post reply on HN