Live data from Hacker News

Julia 1.6: what has changed since Julia 1.0?

oxinabox.net

171–180 of 212 posts

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

#171

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 think you are being unfair. Just look at the various Julia forums: addressing startup latency has been the main focus since 1.3 and each of the version since then (especially the 1.6 beta) have had significant improvements. Same with the REPL comments: you can easily just write scripts instead of using Revise/Pluto/IJulia or another REPL approach.

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

#174

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.

I and probably many others intend to develop reproducible figures. The way to do that in python / matlab is to have a script which loads data from disk and then produces a figure (a png / pdf). You then execute that file many times each time tweaking one aspect of the figure. Julia makes that workflow almost impossibly slow.

Then write a function that does everything your script would do in the clean local scope of that function, and call it many times as needed. I mean heck, that’s a more elegant solution even if script latency wasn’t in the equation.

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

#176

I really wish the language doesn't force me to use the REPL.

How is it forcing you!?

I'm assuming you may not be familiar with Julia, but basically every "tool" you use in Julia is a library.

It requires importing it in the Julia REPL or activating a new contextual REPL within the Julia REPL. You can then start calling the functions from the imported module. You don't really get standalone Julia tools, it's all libraries and you're always starting the REPL, importing something, then doing stuff from inside the REPL.

For example, installing a package in Julia is the following steps:

    julia
    ] # keybinding which activates pkg mode
    add StaticArrays
You could do it also like this:

    julia -e 'use Pkg; Pkg.add("StaticArrays")'
There is no `julia-pkg add StaticArrays`, unfortunately.

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

#177
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.

> It also can't catch trivial stuff like misspelling a struct field on a variable of known type.

The default definition is

`getproperty(x, f::Symbol) = getfield(x, f)`

and `getproperty` can be overridden for a type, so `foo.a` can succeed even if `getfield(foo, :a)` fails. (`getfield` cannot be overridden).

So it's not trivial to determine, given the the of `foo`, from the syntax `foo.a` whether that code errors.

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

#178

Earlier quoted context omitted.

How is it forcing you!?

I'm assuming you may not be familiar with Julia, but basically every "tool" you use in Julia is a library. It requires importing it in the Julia REPL or activating a new contextual REPL within the Julia REPL. You can then start calling the functions from the imported module. You don't really get standalone Julia tools, it's all libraries and you're always starting the REPL, importing something, then doing stuff from…

Why do you want `julia-pkg add StaticArrays` when you can do `julia -e 'use Pkg; Pkg.add("StaticArrays")'`, though?

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

#179
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.

You really think "Julia is always superior and people just look for excuses" is the more likely option?

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

#180

Earlier quoted context omitted.

I'm assuming you may not be familiar with Julia, but basically every "tool" you use in Julia is a library. It requires importing it in the Julia REPL or activating a new contextual REPL within the Julia REPL. You can then start calling the functions from the imported module. You don't really get standalone Julia tools, it's all libraries and you're always starting the REPL, importing something, then doing stuff from…

Why do you want `julia-pkg add StaticArrays` when you can do `julia -e 'use Pkg; Pkg.add("StaticArrays")'`, though?

it looks a lot more annoying to type. Would be an easy shell alias or script though, if one prefers that command style.
Post reply on HN