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

Julia 1.6: what has changed since Julia 1.0?

oxinabox.net

Post reply on HN
Print view View original

131–140 of 212 posts

Re: Julia 1.6: what has changed since Julia 1.0?

#131

Post by jampekka »

cbkeller wrote: post #117
jampekka wrote: post #90

Earlier quoted context omitted.

I've tried it dozens of times. I tried it this week and gave up again after several hours. As a language and technology it's way better than the alternatives, but usability of Julia as a programming language is broken by the ridiculous startup latency. I'm sure it's not even really hard to fix (at least by some caching hacks), but for some reason the Julia community is actively resisting such fixes. And don't give me…

I’m always amused to see these “I’m sure caching wouldn’t even be a hard fix, the community must be resisting it” takes. Feel free to show me the PR’s that have have been rejected that would have solved the problem. Or if you think it’s easy, feel free to make that PR yourself. As the quote goes, “There are two hard problems in programming: cache invalidation, naming things, and off-by-one errors”. This is cache inva…

I will probably give it a go when I have some time to spare. I don't expect to get a PR through, or even want one. Perhaps I'll release it as a package if it works at all.

Cache invalidation is not always that hard. For example pure functions are more or less trivial to cache, and you don't even have to do any explicit invalidation. Perhaps do some LRU type pruning if the disk starts to fill up.

I know next to nothing about Julia's internals, but given packages like Revise.jl, PackageCompiler.jl and SnoopCompile.jl are even possible, I don't think it can be that hard. Dumb caching should be a lot easier than any of these.

I may well be wrong, and that nobody has done this yet is a hint to me being wrong. But I think another scenario may be that Julia ecosystem is so hung up on REPLs and notebooks that this case just gets no attention. And very few non REPL-or-notebook people hang around long enough to get to know the internals at all. Maybe I'm just desperate enough?

There's also another possibility, which may sound bizarre but I think is possible. At some level people who come from scripting language background think that long compile times is a sign of a "real language". This is somewhat prevalent in e.g. Javascript scene, where more and more byzantine compilation systems are introduced for a language (or platform) that works just fine without compilation (or can do very fast on-the-fly "AOT" if needed).

Re: Julia 1.6: what has changed since Julia 1.0?

#132

Post by adgjlsfhk1 »

systemvoltage wrote: post #40
oscardssmith wrote: post #25

Earlier quoted context omitted.

It's a better time to first plot than matlab, which is one of the other major contenders. On my computer it is about 3 seconds, which is noticable, but far from disqualifing.

Julia oversells itself as a general purpose language which I find absolutely out of line. Their marketing needs to be a lot more humble until they figure out the kinks. Also, my guess would be Python and not Matlab as it’s main competitors.

Julia has a lot of main competitors. I would consider Julia a competitor to Fortran, C, Matlab, R, and python. If you look at DifferentialEquations.jl or the clima.jl package, these are packages that are competing with low level libraries that would traditionally be written in C or Fortran. It competes with these by offering comparable performance, while having much better quality of life features (like automatic PGO, a package system, metaprogramming, and not having to deal with make files). It competes with matlab by having an incredibly rich linear algebra library, while being free and not making you do dumb stuff like 1 function per file.

Re: Julia 1.6: what has changed since Julia 1.0?

#133

Post by whateverwhynot »

DNF2 wrote: post #46
cmeacham98 wrote: post #41

Earlier quoted context omitted.

You seem to be falling into the same trap you lament in your comment: - The other side is "these people" that "won't stop" - They're striving for "hyper-efficiency" at the cost of "hundreds and thousands of hours" - People who complain about this issue don't (or do significantly less of) reading documentation/code/etc People talk about TTFP because it is a real issue that is off-putting for many programmers that woul…

I cannot fathom how ttfp is important. It's time to first plot, not to every plot. After it's down to ~10 seconds, why on earth does anyone care?

Well, with Julia it is time to first plot for every new session. So if your typical workflow is to start Julia and just do a single plot of the recently acquired data (quite common workflow in my field), Julia is an order of magnitude slower than python or scilab.

Re: Julia 1.6: what has changed since Julia 1.0?

#134

Post by Certhas »

BadInformatics wrote: post #92
Certhas wrote: post #82

Earlier quoted context omitted.

I feel your pain on interfaces. As it stands, Julia simply doesn't encourage carefully thinking/documenting about what assumptions your code makes and just banging things together, hoping they work. Good luck dealing with any obscure MethodErros that result if they don't. It still, at the end of the day, is a mostly academic language. So mostly small projects with very few people working on them. No need to architect…

I'm not sure that's a fair characterization. Core team members have expressed serious interest in getting more static verification, interfaces and other type goodness into the language, but if you try to force the issue it turns into a Python 2->3 problem. Not to mention that there are few if any examples of how to fit type checking alongside multiple dispatch (e.g. C# punts with dynamic). I personally find static ty…

One thing is the Core Team Members and their long term plans, which I'm not privy to. The other is the impression generated by interacting with others in the community online, where people disagree with the very premise that there is a problem.

I also see your point that not too much is known in this design space, but I also think that's why it would be good for the community to step up and experiment with this more. Figure out what works. I had plans to do that last summer but life intervened so I am stuck commentating from the sidelines. :P

Re: Julia 1.6: what has changed since Julia 1.0?

#135

Post by eigenspace »

jampekka wrote: post #123
eigenspace wrote: post #116

Earlier quoted context omitted.

> With REPL you have an invisible global state, can't reproduce what you have done, changes earlier in code path don't propagate to results, you don't have documentation of what you did. Mhm, that's fair. I think Pluto.jl has a really neat approach to this, using reactivity (and technically even more state) to actually eliminate that experienced state. If I could use it from emacs it might even be my goto way to inte…

I briefly looked at Pluto.jl, and I think it's probably a good way. As I understood it it's a "notebook" that always runs the whole file. Like e.g. RMarkdown or sweave. All good. The state is fine too if it's explicit. But I'm fine with just CLI and print and occasional plot, which should be a lot simpler use case for development. I create a "local package", meaning a file from which I relatively import. During devel…

> I briefly looked at Pluto.jl, and I think it's probably a good way. As I understood it it's a "notebook" that always runs the whole file.

Not quite. It builds a dependancy graph of your code and can figure out what definitions depend on others. So depending on what you change, maybe only one or two cells need to be rerun. Or in other circumstances, the whole notebook will have to re-run. It just depends on what changes.

> I have to repeat that I really don't see how caching of the compilation results is even close the complications that Revise.jl or Pluto.jl have to do.

I think the main trouble with the caching is that the native code you cache can depend very strongly on the exact combination of packages you have loaded. This means you can hit a combinatorial explosion of different methods to cache pretty quickly, so you'd need to find a very clever way to find the right methods to keep and which ones to delete once the cache gets too big.

I think there's also other potential issues that I understand less. This is being actively worked on though.

Re: Julia 1.6: what has changed since Julia 1.0?

#136

Post by whateverwhynot »

DNF2 wrote: post #59
enriquto wrote: post #51

Earlier quoted context omitted.

> I cannot fathom how ttfp is important. I personally do care for my concrete usage pattern. This is my use case: A long shell script that does a lot of things. At some point, inside a loop that runs hundreds of times, it needs to solve a couple of small linear systems and plot a simple graph. There's hundreds of png graphs, that are then combined into a video sequence. Right now, the computation is done by calling o…

But this is really the worst conceivable use case for Julia. Why are you interested in making this change, when Julia offers no advantage in this scenario?

I'm not the parent, but I faced exactly the same issue when I tried to switch to Julia from scilab. As for why I'd like to switch: Julia is a better language, it is way easy to run your script on a cluster and I've been bitten more than once by the two language problem... So Julia seems better for everything but for one of my most common use cases...

Re: Julia 1.6: what has changed since Julia 1.0?

#137

Post by adgjlsfhk1 »

aliceryhl wrote: post #113
sgt101 wrote: post #103

Earlier quoted context omitted.

>"strong type checker"???? I like julia because of the super powerful and super strong type checking. Have I misunderstood what is meant by strong type checker?

What do you even mean? It doesn't even catch that an argument's type doesn't match on a function call with types specified. It also can't catch trivial stuff like misspelling a struct field on a variable of known type. If you want to be called a "super strong" type checker, you really have to catch that kind of simple issue at compile-time, _not_ when I run the code.

Technically it is catching the type error at compile time (but compile time is Just Ahead Of Time). If you want something that feels more like type checking in a statically compiled language, you should definitely check out https://github.com/aviatesk/JET.jl

Re: Julia 1.6: what has changed since Julia 1.0?

#138

Post by adgjlsfhk1 »

jakobnissen wrote: post #68
295310e0 wrote: post #61

Can someone comment on the ease of distributing Julia code? Can I easily take a bit of code I write (w/o external libraries) and produce a single binary I can ship to someone or do they require a full Julia environment to run it?

They require the full Julia environment to run it - and it's a heavy environment. It is possible to compile a binary that includes the environment and the compiler, but IIRC, that will result in a >400 MB hello-world script taking 150 MB of RAM to run. The core devs have mentioned they are going to add the capacity to compile to actual static binaries, but that does not seem to be a top priority, so I wouldn't hold m…

Note that this feature doesn't necessary require work by the core devs. It is completely feasible (at least in theory) to write a library that can output static exectuables.

Re: Julia 1.6: what has changed since Julia 1.0?

#139

Post by ChrisRackauckas »

systemvoltage wrote: post #120
chrispeel wrote: post #96

Earlier quoted context omitted.

> Most people are allured by Julia's overhyped marketing ... Wikipedia says "Marketing refers to activities a company undertakes to promote the buying or selling of a product, service, or good." Julia is not a company; I think what you're calling "marketing" would better be labeled "user enthusiasm" :-)

The founders of Julia do have financial interest though! I think they're part of Julia Foundation. Same people wrote the marketing material I presume.

> The mission of The Julia Foundation is to provide assistance to those in need while creating awareness of the power of art to heal and inspire.

http://www.thejuliafoundation.org/

I didn't think they were, but now it makes sense why Jeff Bezanson's voice is so soothing.

Re: Julia 1.6: what has changed since Julia 1.0?

#140

Post by ChrisRackauckas »

adgjlsfhk1 wrote: post #138
jakobnissen wrote: post #68

Earlier quoted context omitted.

They require the full Julia environment to run it - and it's a heavy environment. It is possible to compile a binary that includes the environment and the compiler, but IIRC, that will result in a >400 MB hello-world script taking 150 MB of RAM to run. The core devs have mentioned they are going to add the capacity to compile to actual static binaries, but that does not seem to be a top priority, so I wouldn't hold m…

Note that this feature doesn't necessary require work by the core devs. It is completely feasible (at least in theory) to write a library that can output static exectuables.

It's actually done all of the time. GPUCompiler.jl, the core of the CUDA and AMD GPU stack, builds static binaries (compiled to .ptx by LLVM for CUDA for example, but the choice is just a switch), then stashes those binaries to use with a ccall in a Julia function. You could in theory use that stack to statically-compile anything that's GPU compliable, and it's really well-tested.
Post reply on HN