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

Julia 1.0

julialang.org

Post reply on HN
Print view View original

221–230 of 446 posts

Re: Julia 1.0

#221

Post by conjectures »

dnautics wrote: post #194
conjectures wrote: post #107

Julia is a great language and was really useful in my PhD. The #1 requirement I have is the ability to make binaries for some program. You can compile a C program and get a binary. There's no practical equivalent for Julia at the moment and I think this limits its production potential.

these days you can just put it into a container, though! If docker is a problem bc no ability to install root daemons, I can attest that julia works great with singularity ("with one small problem - you can't trivially have both in-container and in-home-directory libraries") and I have deployed to supercomputers for real research purposes, using it.

Interesting environment.

One of the reasons I used Julia in academia was slurm manager ;)

Re: Julia 1.0

#222

Post by 3JPLW »

swdunlop wrote: post #210

Julia 1.0 will be rough until major packages have caught up with the deprecations introduced in 1.0 and 0.7. 1.0 does not tolerate these deprecations, while 0.7 will warn about them. This makes a poor first day impression for new users who expect Plots.jl, IPython.jl, Juno.jl or other prominent packages in 1.0. The package maintainers are scrambling to catch up. I recommend using 0.7 for a couple weeks until the comm…

The core devs are in on the scrambling, too! This is now one of my favorite interactions on GitHub: https://github.com/JuliaStats/StatsBase.jl/pull/404

Re: Julia 1.0

#223

Post by marmaduke »

jernfrost wrote: post #217
marmaduke wrote: post #186

Earlier quoted context omitted.

I see your comment grayed out, and I just want to chime in, as some who does a lot of numerical stuff (more than a decade, published stuff, support multiple lab research projects etc), I want to second this point of view. When it’s time to get real work done Python is more than good enough, and there’s plenty of strategies for acceleration where required. And when I want Julia’s promise of fast loops, I use Numba. If…

The point is that Python presents a very complex environment where you have to deal with different languages and technologies. For package developers it is a lot eaiser to use Julia. Saying one should focus more on Python and we would not have these problems is missing the point. Enormous resources by countless companies has been poured in to solve the performance problems of Python. It is almost impossible to do due…

I’m not missing the point: I’ve tried doing the same thing in Julia before as I do in Python, and it’s not a 10x difference. No language (relevant to this discussion) is ever going to cut down on lines of code required to do error checking, code gen, plotting etc. Sure, Julia is great as a high-level interface to LLVM, but so is Numba.

Python’s design leaves something to be desired performance-wise for those coming from JVM or native languages, but it’s a trade off, not an obvious win (for Julia), and the problem goes away as programmers get wise to performance strategies in Python.

Re: Julia 1.0

#224

Post by johnsea »

tavert wrote: post #202
celrod wrote: post #200

Earlier quoted context omitted.

I think it is easier to write fast, complicated code in Julia than in C, C++, or Fortran. Not just the syntax, but because of great support for generic code by default and metaprogramming making it relatively simple to write code to generate the code you actually want for any given scenario. Interactive benchmarking and profiling are a boon too. An example of the value of generic code is that forward mode AD is extre…

The reason I ran away from Julia and don't plan on ever using it again, and don't recommend anyone use it outside of academia, is that so much of the community is made up of grad students. So you get a lot of research code and people who have never been professional programmers maintaining most of the ecosystem. Julia Computing is largely made up of people they've hired from the community straight out of grad school.

I don't see your point of academia and about hiring from the community?

What I see on Github is as professional as it can get. Issues, discussions, triage, review, CI-tests for example.

Maybe you started too early, before Julia was settled? And/or were too over-enthusiastic to begin with? I think Julia had to grow, find the 'correct' solution with e.g. NA/Missing/Nullable. Break things b/c it didn't work out as expected. Postpone things, debugger (maybe?), for more important areas or because base was not stable yet.

Two years ago in a project I hoped that people would switch immediately from R to Julia. But in retrospect it was good they didn't. Julia was not ready for them and too much ecosystem stuff missing/unclear still. (This said, Julia would in principle have been much much better suited for that project).

Re: Julia 1.0

#225

Post by Accipitriform »

peatmoss wrote: post #52
typon wrote: post #42

Reading through the docs, looks like they have 1-indexed arrays..?

For a numerics-oriented language this is a good choice. It’s more consistent with mathematical conventions for matrices. 0-based indexes are commonplace in programming circles because of the C language, however 1-based indexes are the earlier standard set by Fortran. EDIT: If Julia becomes popular outside data and numerics circles, it will have pulled off nothing short of a miracle in getting people to adopt 1-based…

Julia supports 0 based indexes if desired, similar to Ada and other languages.

Re: Julia 1.0

#226

Post by meanmrmustard92 »

Are there any updates to Juno forthcoming that don't butcher the existing install of Atom on the system? I use Atom with Hydrogen for Python and R, and was curious about julia and made the mistake of opting for the 'batteries included install', which promptly overwrote all my atom settings. Seems a bizarre oversight.

Re: Julia 1.0

#227

Post by [deleted] »

samuell wrote: post #83

Does it support light-weight threads (co-routines) channels yet? (and if it does, does it multiplex them on mulitple CPUs?). I had a look a few years ago, and then it did not. I think this is so badly needed to get an easy route to pipeline paralellism, which is simply everywhere in today's data analysis "pipelines".

[deleted]

Re: Julia 1.0

#228

Post by marmaduke »

celrod wrote: post #200
marmaduke wrote: post #186

Earlier quoted context omitted.

I see your comment grayed out, and I just want to chime in, as some who does a lot of numerical stuff (more than a decade, published stuff, support multiple lab research projects etc), I want to second this point of view. When it’s time to get real work done Python is more than good enough, and there’s plenty of strategies for acceleration where required. And when I want Julia’s promise of fast loops, I use Numba. If…

I think it is easier to write fast, complicated code in Julia than in C, C++, or Fortran. Not just the syntax, but because of great support for generic code by default and metaprogramming making it relatively simple to write code to generate the code you actually want for any given scenario. Interactive benchmarking and profiling are a boon too. An example of the value of generic code is that forward mode AD is extre…

What happens for that scientist when they have to dive into Julia’a stack to debug something weird? In Python and C, you have established debuggers, semantics etc, which means that, yes, there are two languages instead of one, but neither is a moving target compared to a language which just had a 1.0 release.

I get the issue with scientists writing poor code, but Numba has largely solved this problem, by packing an LLVM JIT into a decorator which can be applied to any numerical code to get same speed ups as Julia, except no language switch required.

Citing slow code in the wild with a fast rewrite is a hilariously poor anecdote performance wise. I’ve rewritten Fortran code into Python and gotten speed ups. Regardless of the language, garbage in, garbage out.

Stan is an example where the modeling is “just” a DSL implemented as C++ templates. Does that make that a good choice?

Re: Julia 1.0

#229

Post by srean »

samuell wrote: post #83

Does it support light-weight threads (co-routines) channels yet? (and if it does, does it multiplex them on mulitple CPUs?). I had a look a few years ago, and then it did not. I think this is so badly needed to get an easy route to pipeline paralellism, which is simply everywhere in today's data analysis "pipelines".

Thank you for asking the question I was about to ask.

I am ambivalent over whether it has multiplexing or not. When I need parallelism I fall back to OS threads if available or processes. One or the other is usually always a first class citizen. Whats not that common, are real lightweight coroutines.... I want my laptop to be able to simulate the transport layer over a sizeable portion of the internet, while I watch youtube.

Re: Julia 1.0

#230

Post by marmaduke »

johnsea wrote: post #203
marmaduke wrote: post #186

Earlier quoted context omitted.

I see your comment grayed out, and I just want to chime in, as some who does a lot of numerical stuff (more than a decade, published stuff, support multiple lab research projects etc), I want to second this point of view. When it’s time to get real work done Python is more than good enough, and there’s plenty of strategies for acceleration where required. And when I want Julia’s promise of fast loops, I use Numba. If…

> And when I want Julia’s promise of fast loops, I use Numba. This only works (easily) as long as you don't have user-defined types > If all the effort gone into Julia had instead been spent on fixing remaining warts in Python workflow for science, we wouldn’t even havee this conversation. Python is too dynamic, you cannot just fix remaining warts. From Julia documentation I know that Julia language has been designed…

Numba has user defined types,

https://numba.pydata.org/numba-doc/dev/user/jitclass.html

No one intends to fix Python but it’s straightforward to do things like Numba: use a decorator to read out the AST for a function, reimplement it however you like and pass back the compiled function, and document the semantics.

Post reply on HN