Live data from Hacker News

Julia 1.6: what has changed since Julia 1.0?

oxinabox.net

111–120 of 212 posts

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

#111
post #105

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…

If you don't mind me asking, how are you using julia? Are you using modules to wrap your code and functions to structure it, or are you just running one big script in top level scope? Aside from compiler improvements, most caching related optimizations are happening on the module level, because that's where namespaces are seperated.

I'm not using modules. I usually start with one file with a demo or similarly named function that is called if the file is called as an entry point (like if __name__ == '__main__', except Julia makes it even worse). First the "actual" code is in separate functions in that file. No global state.

I tend to refactor code out of there to separate files, and then somehow import it. An ugly way is include, and I've tried Revise.jl with includet.

But I think the least ugly approach is the @from macro from here: https://github.com/Roger-luo/FromFile.jl Judging from some opinion in bug trackers, this is probably gonna get totally shunned by core devs and they'll keep on bikeshedding about the import stuff forever.

With this setup I have about 400 lines of code in three files. It compiles for 15 seconds. After every single change, and actually without any changes too.

I think performance wise this should be equivalent to using modules, but saving some pointless ceremony.

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

#112
post #98
post #71

Earlier quoted context omitted.

I've read a bit on type invalidation and I know it's a hard problem (in fact it's hard for me to even wrap my head around it, lol). Still, it's unfortunate. One thing I would like to know is if the difficulties with invalidation are a symptom of the dynamic semantics, or of the compilation model. Namedtuples are cool, but I'm not sure I understand the tradeoffs between using them and using structs. Can I just replace…

Note that I didn't suggest replacing structs with NamedTuples entirely - only during prototyping, while you're figuring out what you want your struct to look like. Structs most definitely will be faster.

> Structs most definitely will be faster.

I am not 100% sure this is true.

Structs will definately look cleaner in the code. Not sure they will be faster though.

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

#113
post #103
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…

>"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.

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

#114

> People often complain about the “Time To First Plot” (TTFP) in Julia. I personally have never minded it – by the time I am plotting something, I have done minutes of thinking so 20 seconds of compilation is nothing. This amuses me. I hadn't really considered the author's perspective, and now I think it aligns with my take on it pretty well.

If that's what you're used to it's fine probably, you'll often have no choice but to adjust your workflow to it and make it work. But if you've ever experienced an environment that instantly shows you results and lets you get into a fast iterative loop to explore your data, it can be hard to give that up again.

Source: my current and previous job were basically data viz programming jobs which were all about optimizing said iterative loop for scientists. Going from minute-long to sub-second rendering speeds is a game-changer for many.

EDIT: having said that, this kind of reminds me of what the biggest difference between analog and digital photography is for me, namely whether or not you get instant feedback. I do remember from my art school days that in my experience film was a much better option for training the skill of observation and composition than digital, because it forces you to essentially picture the photograph before you take it. However, once you get somewhat decent at that... I'd switch to digital and reap all the benefits it has ;). The same logic might apply to learning how to plot your data.

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

#116

Earlier quoted context omitted.

> (and for many good reasons you shouldn't) Could you elaborate on this? I'd say repl based interactive programming is one of julia's greatest strengths, and avoiding the repl is probably setting yourself up for pain. That said, if you do find yourself running lots of scripts and paying this penalty all the time, I'd suggest https://github.com/dmolina/DaemonMode.jl as a great way around these pains.

> Could you elaborate on this? I'd say repl based interactive programming is one of julia's greatest strengths, and avoiding the repl is probably setting yourself up for pain. 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. It's for me really like trying to write a book by dictating…

> 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 interact with julia, but I also don't mind the statefulnes and find it manageable.

For me, the most important thing is that when I'm writing serious code, I create a local package. Then, in the REPL I load that package and have Revise.jl active so that it can watch the the package source ode and constantly do hot code reloading for me so that I'm never stuck with old versions of code running.

Then I do all my interactive analysis in the REPL, and plumbing in the package module. This eliminates a lot of statefulness, but keeps restarts to a minimum.

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

#117

Earlier quoted context omitted.

> 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…

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 invalidation.

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

#118

Earlier quoted context omitted.

The plot is also very simple. No zoom, brush, save to file, label, title, regression etc that you need to process it in a GUI and save for a report. I would really like to use Julia as a "Matlab or Octave but with nice string concatenation" but the UI is just lacking for one off calculations and data processing.

> Octave but with nice string concatenation As a heavy octave user, I never felt a need to concatenate strings in any way. But I'd be happy if julia was an Octave but with fast loops , which it sort of is; but still not really there.

When you use Matlab/Simulink for c-code generation and use it for a lot of purposes Matlab was not really made for you might run into processing strings.

But ye for normal use it is not really a problem.

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

#119

Earlier quoted context omitted.

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…

> I'm a physics PhD student. I simply find julia very useful and pleasant to use and want to share that with others.

User base tends to be scientists and not seasoned Software Engineers. No offense to either one, just that the community inspires the language and its mechanics. This is exactly the reason it is not a general purpose language. You just proved my point.

Glad you find it useful for your endeavors. I reckon DiffEq and other hardcore math is great in Julia.

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

#120

Earlier quoted context omitted.

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…

> 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.
Post reply on HN