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

81–90 of 212 posts

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

#81

Post by DNF2 »

enriquto wrote: post #75
tomrod wrote: post #6

I come back every so often to check out Julia again. I have hopes for it. Some questions still in mind since I reviewed previously (1) How is its database connectivity? (2) Is there something like python's `requests` lib? (3) Are the features mature enough that I don't anticipate major rewrites for code each year?

> (3) Are the features mature enough that I don't anticipate major rewrites for code each year? There is a very good heuristic for that. Write a non-trivial program using the last version of the language and according to current conventions. Then look how far can you go into past versions of the language so that your program runs correctly. If the oldest version of the language that runs your program is X years old,…

No, this is incorrect, you are confusing backwards and forwards compatibility. Running your new code on old Julia versions could break immediately, just like in every programming language.

Backwards and forwards compatibility have very different horizons.

Running old code on new Julia versions should not break until the next major version. Packages, on the other hand, are different, and could break your code sooner, but that's the same in any language.

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

#82

Post by Certhas »

saiojd wrote: post #26
Sukera wrote: post #21

Earlier quoted context omitted.

The most important part about the releases since 1.0 is that compile time has been significantly reduced, the article touches on basically all ways how this has been done - may I ask when you've last tried it?

A few months ago. First time to plot is noticeably better than it was a few versions ago, but still extremely slow compared to Python. The article gives a benchmark of 9 seconds. I mean, come on. The main problem I had was simply that what any time I needed to modify a struct field, or anytime my program crashed, or any time the buggy IDE extension crashed, I needed to recompile everything. I also haven't found anyon…

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 bigger solutions/patterns, etc...

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

#83

Post by Certhas »

saiojd wrote: post #64
DNF2 wrote: post #34

Earlier quoted context omitted.

No one interested in interfaces? My impression is that interfaces is very commonly discussed, and is one of the most anticipated features in the language, though it may not come until v2.0.

OK, I was being hyperbolic. It's just that the interest is low compared to other features, as most people involved in the project are used to dynamic languages and don't feel the need. It's been in discussion for a long time, with no action so far. From what I've seen, the general attitude is a bit dismissive of the utility of static verification ("its different in our language because X" type attitude)

My impression with this is that it's mostly coming from a few academics that never work on code they haven't written themselves, and that have no understanding of use-cases other than their own...

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

#84

Post by the-smug-one »

saiojd wrote: post #72
DNF2 wrote: post #46

Earlier quoted context omitted.

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?

You can't possibly be serious. As things stand, even just redefining a struct field requires restarting the interpreter, which forces you to wait ~10-30 seconds for everything to compile, over and over again. Maybe you only use Julia for small scripts, and can afford to never restart the interpreter?

Dang, why can Common Lisp do this so well and Julia so poorly?

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

#85

Post by DNF2 »

superbcarrot wrote: post #79
saiojd wrote: post #16

I've tried Julia and really liked it, but the user experience was pretty bad. The language really needs faster interactivity or a strong type checker. I found myself waiting after than compiler a lot more than in some AOT compiled language like Rust... I fear the language suffers from being overused by people who are familiar with Matlab and Python and draws too much inspiration from them, much like how Rust draws to…

I'm trying really hard to like Julia but constantly chasing "ERROR: MethodError: no method matching" messages gets frustrating very quickly.

When do you run into this kind of problem? Is it possible that you are over-typing your function signatures? The generally recommended style is to write generic code with loose type restrictions, or even none at all.

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

#86

Post by eigenspace »

systemvoltage wrote: post #73
eigenspace wrote: post #65

Earlier quoted context omitted.

Doing these things in julia is very different from doing these things in R or Matlab. The tooling and ecosystem for non-scientific applications in Julia is growing rapidly and is quite competent. Julia is absolutely a general purpose language. It’s user base skews heavily towards scientific computing, but the demographics and ecosystem are broadening daily.

Having used Julia for 2+ years, I couldn't disagree more. Productionizing Julia code has been a total nightmare. The community library support has been growing but hasn't gone through the wringer. Just because things are improving doesn't provide a meaningful understanding against its competitors. I don't see any reason to use Julia over Go for backend webservers. Rust or C++ for systems programming. And frankly, I p…

> I don't see any reason to use Julia over Go for backend webservers. Rust or C++ for systems programming. And frankly, I prefer Python for scientific computing.

Sure, I would never claim Julia is being the best language for webservers or systems programming. If someone came to me saying they wanted to do this in Julia, I'd probably tell them "if this is important, I'd probably look at a more established language for this purpose unless you have a good reason to want to use julia for this"

That doesn't make julia not a general purpose programming language. It just means it's not the best language for every imaginable purpose (no language is).

I personally prefer Julia very strongly for scientific computing to it's competitors, and because of the amount of time I've invested in it for that, I also do many other things in it and I find it quite nice for this.

It's totally fair that you prefer Python for scientific computing. Python has a great ecosystem and huge community with tonnes of investment! It's an incredibly stiff competitor. I prefer Julia, and think I have strong reasons to do so, but everyone's needs and desires and different.

> No one wants to just complain

This is an empirical claim about human psychology and it's false. But regardless, yes there are a lot of totally valid criticisms of julia in this thread! Just because these criticisms exist and some of them have good points doesn't make julia a bad language though.

Please consider the fact that not everybody has the same needs, desires and temperament as you. Every language has major probelms with it, but different people feel these problems differently.

For many people (for example, me), Julia is a gigantic breath of fresh air! For others, it's painful and clunky. I think there's a lot of good here that people should see and check out and think about, even if they decide it's not for them. Especially because these things improve every day.

___________________________________________________

Just a disclaimer in case anyone is suspicious about my affiliations: I have absolutely zero financial stake in Julia's success. I am not employed by anyone who would benefit from more people switching to julia. I'm a physics PhD student. I simply find julia very useful and pleasant to use and want to share that with others.

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

#87

Post by ku-man »

eigenspace wrote: post #45
systemvoltage wrote: post #40

Earlier quoted context omitted.

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.

In what way is marketing julia as a general purpose programming language 'way out of line'? People use julia to make webservers, write programming languages, create plotting libraries, do scientific analysis, do compiler research, make video games, do HPC, etc. Julia has a design that's indeed strongly informed by scientific computing, but in order to actually meet the needs of the various people using it for scienti…

Video games in Julia?, come on. No one is going to make a video game in Julia (unless you consider the hang-man or sudoku a video game). Julia is already being oversold as a scientific programming language, so absurd claims that Julia can be used to develop video games are just going to damage even more its credibility.

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

#88

Post by jampekka »

DNF2 wrote: post #50
simias wrote: post #37

Earlier quoted context omitted.

I don't know how Julia fares but personally what bothers me with long compile times is when I can't context switch, waiting for the compiler's output. What I mean in practice is that if you take Rust for instance, the compile times can be fairly long but the type checking occurs early on and is quite fast. Therefore once I know that this step succeeded I can usually let the compilation continue in the background whil…

If it were 20 seconds for every plot, this would be a major problem for me, as I tend to make lots of plots. But it's only the first plot where this is an issue. Surely you're not in 'the zone' that soon? Seems to me like people are making a mountain out of a molehill.

If you don't use REPL (and for many good reasons you shouldn't) or some other such horror, every plot is the first plot. And it's pain. And not just plots really. Doing anything in Julia is pain if you try to use it as a programming language instead of an app for buggy, unreproducible and misunderstood ad-hoc analyses.

Seeing these answers makes me think Julia will never be fixed. I forecast Julia will be back in a niche within five years if they don't get their act together. And it's sad, because the alternatives are fundamentally broken. Julia isn't fundamentally broken, but the devs and the community seem to insist on superficial breakage.

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

#89

Post by fishmaster »

saiojd wrote: post #72
DNF2 wrote: post #46

Earlier quoted context omitted.

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?

You can't possibly be serious. As things stand, even just redefining a struct field requires restarting the interpreter, which forces you to wait ~10-30 seconds for everything to compile, over and over again. Maybe you only use Julia for small scripts, and can afford to never restart the interpreter?

> even just redefining a struct field requires restarting the interpreter

It really doesn't if you use a module.

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

#90

Post by jampekka »

dnautics wrote: post #43
oblio wrote: post #15

Earlier quoted context omitted.

That won't stop these people. It's the same discussion as the interpreted languages vs compiled languages or the editor flame wars. On one hand you have people that say "thinking takes a lot longer than waiting a bit for compilation or actually editing source code" (I'm in this camp) and people that go "I don't want to wait for compilation and I want my editing to be hyper-efficient even if I have to invest hundreds…

> People are just different but every camp thinks They're Right and The Others Are Dumb and Stupid And Dangerous. That's not quite right, I think. People are looking for excuses to not use Julia (r new technology X) because it serves as confirmation bias that their choice of is still good and there is no need to start thinking of their extensive training and investment in blub is sunk.

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 REPL. REPL is a fundamentally broken approach to programming, and REPL people just keep looking for excuses to keep using it.

Edit: And if you give me REPL, I can answer that I have tried it too. It's broken as well. Revise.jl breaks constantly with anything non-trivial. And with the effort going to horrible hacks like Revise.jl, I'm sure a simple caching of compilation results between calls would be nothing. It seems to be something ideological.

Post reply on HN