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

181–190 of 212 posts

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

#181

Post by dnautics »

detaro wrote: post #179
dnautics wrote: post #43

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.

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

no, just for certain things. I don't use julia on a day to day, it is not the right tool for my job (CRUD apps).

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

#182

Post by krastanov »

ecnahc515 wrote: post #176
krastanov wrote: post #175

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…

I am pretty incredulous at this counting as "forcing you to use a REPL". It is a couple of extra characters compared to what pip, nvm, cargo do, and you can just make your own shell alias for it. And I am not even mentioning the significant advantages it has over pip, especially for binary dependencies.

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

#183

Post by eigenspace »

orbifold wrote: post #168
eigenspace wrote: post #94

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.

Why not just write a function? You can do this without restarting tour julia session every time...

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

#184

Post by _coveredInBees »

jampekka wrote: post #156
socialdemocrat wrote: post #155

Earlier quoted context omitted.

People have different style and preferences. I have programmed for over 30 years and I find that REPL based development in Julia beats anything else I have tried in term of productivity, and I have tried a ton of tools, IDEs and languages. But sure it may not fit your particular preference or it may be that you have simply not learned to use it effectively. It takes some time to work effectively in a REPL style. It t…

It probably depends also on what you program. If the task is simple enough and doesn't need much revisiting, REPL is probably fine. But OTOH, just writing the code for a simple case and running it isn't too bad either. How do you persist and document your code with REPL-development? Do you log the commands to some separate file? How do you recreate the REPL state if it crashes or you have to reboot? How do you make s…

I just don't think you've tried or been exposed to responsible REPL prototyping and development. Like sure, you could have all sorts of issues if you use REPL irresponsibly and pollute your state with undocumented code and side effects. But if you use it responsibly, it can be really fast and efficient when prototyping things... Even complex subsystems in a larger codebase. I've prototyped entire reimplementations of SOTA object-detection DNN algorithms in Pytorch with no issues and have been far more productive because I can develop functionality in small chunks while intimately understanding the problem at hand and associated data and then immediately graduate it to a working script/module/package as I go along.

For more complex things, I can even have a stub for a function I am developing and breakpoint into it and then I prototype the functionality in the REPL and that is wayyy faster and less bug prone than trying to go at it blindly in your IDE without being able to experiment and verify your code as you develop it.

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

#185

Post by ecnahc515 »

gugagore wrote: post #178
ecnahc515 wrote: post #176

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?

I don't use Julia regularly, it's just an example of making it clear how the REPL is core to using Julia.

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

#186

Post by ecnahc515 »

krastanov wrote: post #182
ecnahc515 wrote: post #176

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…

I am pretty incredulous at this counting as "forcing you to use a REPL". It is a couple of extra characters compared to what pip, nvm, cargo do, and you can just make your own shell alias for it. And I am not even mentioning the significant advantages it has over pip, especially for binary dependencies.

Shell aliases aren't as useful in a CI pipeline, or when trying to provide instructions on how new to Julia installs a new package. Also, with Julia being so different from everything else does mean everyone has to learn a new way of doing things. This isn't a bad thing, I like that Julia has a programmatic API for most of these things, but the UX is definitely not amazing.

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

#187

Post by systemvoltage »

gugagore wrote: post #161
systemvoltage wrote: post #73

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…

You're going from "don't call it a general purpose language" to "be receptive to complaints about its short-comings". There's quite a gap in between. I know that contributers are receptive about short-comings. And if you frankly prefer other languages, then that's totally fine too.

Short-comings are intrinsingly related to its general purposeness. Tiny standard library is one of them. Not being able to put things into production is another.

I guess I see general purpose languages such as Python and Go as rock solid. They have warts but they're well understood and wrinkles have been ironed out.

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

#188

Post by StefanKarpinski »

calebwinston wrote: post #169
celrod wrote: post #97

> (* Technically not all mutable objects live on the heap, because some never live at all, as they are optimized away so are never allocated in the first place.) The compiler will often stack allocate mutable objects in Julia. This is not the same as "never existed in the first place", because the stack pointer gets incremented and underlying data layout is you load from it is the same as that of the mutable object y…

If they are optimized away, are their destructors/finalizers still called? I'm really hoping the answer is yes...

Yes, that is guaranteed.

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

#189

Post by FridgeSeal »

systemvoltage wrote: post #52
eigenspace wrote: post #45

Earlier quoted context omitted.

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…

Do you think R or Matlab is a general purpopse language? Sure you could do all these things but should you? Julia is clearly positioned as a scientific computing language. Let's be clear.

Julia is a general-purpose language, with language and implementation features conducive to scientific computing.

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

#190

Post by jampekka »

_coveredInBees wrote: post #184
jampekka wrote: post #156

Earlier quoted context omitted.

It probably depends also on what you program. If the task is simple enough and doesn't need much revisiting, REPL is probably fine. But OTOH, just writing the code for a simple case and running it isn't too bad either. How do you persist and document your code with REPL-development? Do you log the commands to some separate file? How do you recreate the REPL state if it crashes or you have to reboot? How do you make s…

I just don't think you've tried or been exposed to responsible REPL prototyping and development. Like sure, you could have all sorts of issues if you use REPL irresponsibly and pollute your state with undocumented code and side effects. But if you use it responsibly, it can be really fast and efficient when prototyping things... Even complex subsystems in a larger codebase. I've prototyped entire reimplementations of…

I probably haven't. But I have seen quite a bit of irresponsible REPL development.

What I don't see is the benefit of the REPL. I effectively use my editor and the shell as a "REPL", but instead prefer to have the code in a program structure all the time. This means I don't have to have extra discipline for not accidentally polluting the state. Plus I can use version control, which means I can quite easily try out quite deep changes and still revert back to any state I had before. This is difficult with REPL. And with this workflow I don't have to do any extra "graduating" step; the code usually cleans up during the process.

A big additional benefit is that I can use the shell. I can e.g. pipe stuff from other programs, and I make a CLI for the program on the fly.

The main problem perhaps is when there are some longer computations, as there often are in analyses. For these I prefer memoization to the disk. The usual way to do this across REPL-sessions is to write ad-hoc temporary result files. This gets hairy really fast when you have to update these when the codepath before the dumps change.

I don't see much benefits of REPL over my workflow. Maybe some completions are nicer in REPL and you may get a bit nicer formatted output, but these are quite trivial. Perhaps people who are not accustomed to shell think that REPL is the only way to "rapidly iterate"?

Post reply on HN