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

171–180 of 446 posts

Re: Julia 1.0

#171

Post by igouy »

rogerluo wrote: post #40
amrrs wrote: post #12

I use both R and Python in my work but when we move our models to production it's not real time, just a batch execution like once in a day. I'd like to hear from anyone who uses Julia in their actual job/work. Is it worth learning Julia, hoping to use it in work some day?

I think sometimes people are distracted by Julia's performance, according to https://github.com/JuliaLang/Microbenchmarks Julia is not the fastest language/compiler (maybe LuaJIT is). Julia is not only good for its performance, but also its multiple dispatch, its type system and more. Because of those features we have https://github.com/JuliaGPU/CUDAnative.jl , more elegant package interface, like https://github.com/…

> I think sometimes people are distracted by Julia's performance…

Perhaps because the Julia homepage distracts them :-)

"Julia is fast! Julia was designed from the beginning for high performance."

Re: Julia 1.0

#172

Post by mlthoughts2018 »

babahoyo wrote: post #99
mlthoughts2018 wrote: post #84

Earlier quoted context omitted.

I am a machine learning library developer and I don’t share your feelings. For example the specific example you cite, I feel, should never be something scientists or engineers actively think about, only language implementers. Once you make that distinction, then whether you write it as a Cython module exposed in Python or you can use native language features to do it in Julia, nobody cares. It’s encapsulated away fro…

Many scientists might have mathematical ideas about how an operation should be done, but dont want to learn C++ to implement them. We create a division between scientists and programmers that hurts productivity.

But this is what Cython already is...

Re: Julia 1.0

#174

Post by igouy »

celrod wrote: post #87
rogerluo wrote: post #40

Earlier quoted context omitted.

I think sometimes people are distracted by Julia's performance, according to https://github.com/JuliaLang/Microbenchmarks Julia is not the fastest language/compiler (maybe LuaJIT is). Julia is not only good for its performance, but also its multiple dispatch, its type system and more. Because of those features we have https://github.com/JuliaGPU/CUDAnative.jl , more elegant package interface, like https://github.com/…

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.

?

Re: Julia 1.0

#175

Post by mlthoughts2018 »

ChrisRackauckas wrote: post #97
mlthoughts2018 wrote: post #84

Earlier quoted context omitted.

I am a machine learning library developer and I don’t share your feelings. For example the specific example you cite, I feel, should never be something scientists or engineers actively think about, only language implementers. Once you make that distinction, then whether you write it as a Cython module exposed in Python or you can use native language features to do it in Julia, nobody cares. It’s encapsulated away fro…

It's offering something completely different because of the compatibility, compile-time controls, and ability to fully interprocedurally optimize. http://www.stochasticlifestyle.com/why-numba-and-cython-are-...

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 autogenerating implementations for multiple types or signatures.

But Cython fused types allow the exact same polymorphic multiple dispatch. Here’s an example pedagogical project illustrating that point.

https://github.com/spearsem/buffersort >

This pattern is quite easy and offers a lot of generic strategies in Cython, especially if you just want a bunch of overload options in a pure C backend with a thin entrypoint to Python.

Re: Julia 1.0

#176

Post by [deleted] »

peatmoss wrote: post #62
Q6T46nT668w6i3m wrote: post #44

Earlier quoted context omitted.

Yeah, I agree with your comments about error handling. It’s far from ideal in non-interactive contexts. It’s especially disappointing since you could easily imagine something like Julia replicating Python’s success at transitioning code from interaction (e.g. Jupyter notebook) to production. I initially defended the choice, but I now agree that 1-based indexing now seems like a poor choice since Julia has become some…

> 1-based indexing now seems like a poor choice since Julia has become something more than the original mission of a better MATLAB or Octave. It’s a, admittedly, minor tragedy of Julia’s success. I’m curious as to why this is a problem outside numerical computing. From my perspective, this is consistent with a long history of mathematics dealing with matrices that predates electronic computers. 0-based arrays are pop…

[deleted]

Re: Julia 1.0

#177

Post by kgwgk »

candhee wrote: post #119
LittlePeter wrote: post #112

Earlier quoted context omitted.

That makes sense. Maybe I was used to R (CRAN) where uploaded packages are actually tested against the version they declare to support.

JuliaDB declares support for 0.6 not 1.0 - http://juliadb.org/latest/ Which package declared support for 1.0.0 and didn’t compile?

A binary package will be available in CRAN for a given platform/version only if it works (it passes all the tests). It seems that Julia lets you install a non-working package without any warning (you will probably get errors when you run it, but I guess it may also fail silently which is worse).

Re: Julia 1.0

#179

Post by ChrisRackauckas »

StefanKarpinski wrote: post #166
ChrisRackauckas wrote: post #153

Earlier quoted context omitted.

For scientific computing, showing the package ecosystem is the most important thing. When you look at this thread, people are asking about dataframes and differential equations. Julia's site reflects this: yes there are things like Pandas, and for plotting, etc.

I do think we should add a code sample prominently on the page, however. I've always find it really frustrating when I look at a programming language and can't get a quick sense of how it looks. If a language looked like, say, APL, I'd be reluctant to use it even if it had an impressive ecosystem. Issue filed: https://github.com/JuliaLang/www.julialang.org/issues/115 .

Oh I thought the first tab had code and the complaint was it was too low. I guess that was a prototype build of the site. Yeah we should get that back.

Re: Julia 1.0

#180

Post by allenofthehills »

JorgeGT wrote: post #14

Ask HN: as a researcher using MATLAB daily, is there a Julia IDE that offers a similar experience?

While Jupyter is not technically an IDE, I've found it a more than adequate replacement for the MATLAB environment. When I used MATLAB, I didn't often need to use the debugger, so the "IDE" that I actually use/need is mainly just an integrated REPL and code editor. Jupyter serves that purpose and also has the benefit of providing a very literate history of your research
Post reply on HN