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

241–250 of 446 posts

Re: Julia 1.0

#241

Post by mlthoughts2018 »

srean wrote: post #219
mlthoughts2018 wrote: post #175

Earlier quoted context omitted.

The article you link is severely wrong about both numba and Cython. I frequently use Cython to quickly wrap calls to other C++ implementations of tools I want to try and have a working Python module in a matter of minutes, and I have almost no knowledge of C++. Modern numba can also do a lot more for huge scale projects than what the article suggests. Julia docs also seem very smugly proud of multiple dispatch and au…

I use Cython a lot, yet heartily welcome Julia. I think you are over reacting a shade here. With some persistence Python-Cython-Numba can get the work done, but to me it has never felt like a consistent whole, usually a tagged on hodge podge. Numba is cherry picky on what it will and will not optimize, I totally understand why it is so. It has always been a 'will it or wont it" with Numba. I think the potential that…

I think one of my points is that what you call a “tacked on hodge podge” is actually a desirable trait, isolated and targeted optimization of only subcomponents. This is preferred to working a language where the whole thing inhabits that same space.

Re: Julia 1.0

#242

Post by mlthoughts2018 »

ChrisRackauckas wrote: post #188
mlthoughts2018 wrote: post #175

Earlier quoted context omitted.

The article you link is severely wrong about both numba and Cython. I frequently use Cython to quickly wrap calls to other C++ implementations of tools I want to try and have a working Python module in a matter of minutes, and I have almost no knowledge of C++. Modern numba can also do a lot more for huge scale projects than what the article suggests. Julia docs also seem very smugly proud of multiple dispatch and au…

The points that you mentioned are not relevant to what's in the article. Cython fused types are required to be known at the package's compile time, and that's exactly the point that makes it less composible. Not requiring this is exactly the advantage of Julia which is demonstrated. The article doesn't say Numba cannot do huge scale projects. It just talks about the difference in the compilation strategies. If you re…

The first and second paragraphs under “Point 1” are specifically saying Cython & numba work just as well as Julia for single functions, then saying the problem where they are inferior to Julia is large code bases.

Re: Julia 1.0

#243

Post by celrod »

igouy wrote: post #174
celrod wrote: post #87

Earlier quoted context omitted.

Those benchmarks draw a lot of hate, because anyone coming from language X will get offended at how unoptimized code in language X is. Also true if X == Julia. For example, they never turn off boundschecks, which disables vectorization. The point is mostly to (a) show the difference between fast languages compiled to efficient assembly and (b) represent code someone new to a language may bang out to get something don…

> … and avoid the benchmark game. ?

Escalating benchmarks that add increasing optimizations to continuously one up one another. In the "logical conclusion" of this left unchecked, the Fibonacci benchmark for example (d)evolves into a lookup table. Which is missing the original point, hence the desire to just leave everything un-optimized.

Re: Julia 1.0

#244

Post by tavert »

staticfloat wrote: post #220
tavert wrote: post #181

Earlier quoted context omitted.

That MIT license only applies to the Julia wrapper code. The package downloads and dynamically links into an FFTW shared library, which means any code that uses it needs to be GPL if distributed as a whole.

The README for that package [0] states: > Note that FFTW is licensed under GPLv2 or higher (see its license file), but the bindings to the library in this package, FFTW.jl, are licensed under MIT. This means that code using the FFTW library via the FFTW.jl bindings is subject to FFTW's licensing terms. If you have an idea on how to make that clearer, we would be happy to review a PR to the FFTW.jl repository. [0] htt…

My mistake, docs there are fine. A few other BinaryBuilder-using packages have neglected to mention this issue, last I checked. And BTW BinaryBuilder is violating even MIT licenses if you don't package and include the license file along with the shared-library download.

Re: Julia 1.0

#245

Post by baldfat »

celrod wrote: post #208
tavert wrote: post #202

Earlier quoted context omitted.

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 hope that if/as Julia gets adopted in industry, more libraries get written and maintained by professionals. If the language is successful, that may change. Although AFAIK it hasn't really in the case of R, outside of tidyverse. As a grad student without a CS background, I don't think I'm qualified to say much more on this.

The issue isn't "Professionals" it is domain specialist. In the past data specilist didn't have Computer Science specialty. They were awesome in stats and numbers but lacked strong programming skills.

Hadley Wickham is special because he has both the stats, data science AND programming skills.

data.table is also an amazing library. R to me is the most improved language in the history of programming languages over the past 5 years.

Also R allows anyone with basic hackery R skills to create libraries easily and that is why so many of them are not optimal.

Re: Julia 1.0

#246

Post by e12e »

ur-whale wrote: post #169
mikec3010 wrote: post #122

Earlier quoted context omitted.

> for a computer and how it functions And what about for a human and how it functions? Are humans here to make computers' lives easier or vice versa? Humans think from 1...N inclusive and this is the source of a litany of bugs when users first learn a language. And what you described in asm is just one implementation. In fact, the array documentation says Julia doesn't guarantee tight packing so it doesn't even apply…

>Humans think from 1...N I think you're assuming everyone thinks the way you do. I assure you that's not the case. There are legions of people (and not just programmers, math folks do it too) who don't "think from 1 to N"

If I arrange five biscuits on a plate, you'd prefer to eat the one at zero offset from the edge, rather than take the first biscuit?

As for "a computer" - unless your actually writing code for memory allocation - you are (should be) writing to an abstract machine anyway (trivially, if you want to sum numbers in a dense 10^6 by 10^6 matrix - wouldn't it be nice to utilise 1024 cores if they are available? Unless you have side effects happening, do you really care about the order of additions? And if the numbers are 256 bit integers - do you want to care if they're stored big or little endian, in 8 or 16 bit words? In two's complement?).

Re: Julia 1.0

#247

Post by srean »

marmaduke wrote: post #228
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…

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

> What happens for that scientist when they have to dive into Julia’a stack to debug something weird?

The same things that happened when we had this conversation about what happens to the Fortran writing scientist when Python and Numpy came along, even at that time it wasnt the first time. I am sure it would not have been a whole lot different when a COBOL alternative had come along.

Re: Julia 1.0

#248

Post by ivarru »

As someone who should be in the target audience for Julia, I am sad to see that they have not switched to 0-based arrays before launching version 1.0. I consider this is an indication of a broken design process and thus a reason to stay away from the language. (The fact that ranges include both endpoints - rather than being half-open as in Python - is another such indication.)

Re: Julia 1.0

#249

Post by celrod »

marmaduke wrote: post #228
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…

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

It'd probably be a lot easier to debug something somewhere in the Julia stack, than in the C/C++/Fortran code that many R libraries run through.

My point with the rewrite was not garbage in, garbage out. It was that even though the original R code was using a library written in C, that library had to call a function he wrote in R millions of times. That R function being inherently slow is part of the problem. (The easiest fix for that is just writing the function you pass to that library in RCpp, but the overhead on that is still close to a microsecond -- not sure how it is in R. Numba is probably easier.) It is nicer to not have to worry about that.

An alternative approach some libraries provide, like my Stan example in RStan or PyStan, is the DSL they implement to make it easier for end users in R or Python to write fast C++ code.

But, now lets say you're working on an optimization problem. You want to use a gradient-based optimization method, while your code is heavily dependent on the FooBars and Widgets libraries. If these libraries are written in Julia, you can write code in Julia using these libraries, and automatic differentiation will just work as you pass it to Optim.jl.

If FooBars and Widgets were Cython libraries, optionally wrapping C/C++ code, would this work? Could you write functions making use of these libraries, and get efficient gradients for optimization for use with an optimization library and have everything be fast?

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

I gave Stan as an example of a less than ideal situation, because people normally use Stan from R or Python, not from within C++. Therefore there R and Python don't integrate well. If you're already working in C++, Stan seems ideal. You can use arbitrary templated C++ code with Stan, include external libraries, etc. It needs to be C++ because of their autodiff.

Re: Julia 1.0

#250

Post by liquid153 »

ivarru wrote: post #248

As someone who should be in the target audience for Julia, I am sad to see that they have not switched to 0-based arrays before launching version 1.0. I consider this is an indication of a broken design process and thus a reason to stay away from the language. (The fact that ranges include both endpoints - rather than being half-open as in Python - is another such indication.)

lol, get over yourself dude.
Post reply on HN