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

211–220 of 446 posts

Re: Julia 1.0

#211

Post by Accipitriform »

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.

> Julia Computing is largely made up of people they've hired from the community straight out of grad school.

Where do you think most companies get "professional programmers" from, exactly?

Julia's been designed and implemented by some very bright people, and it shows.

Re: Julia 1.0

#212

Post by cultus »

ur-whale wrote: post #195
DandyDev wrote: post #173

Earlier quoted context omitted.

Examples?

You just have to look at the most popular programming languages on 2018. They're all 0-based (with maybe R as an exception, but R is a niche language. If that's what Julia aims to remain -- their loss). The folks who designed these languages knew how not to alienate their future market.

Matlab is 1-based. That's what the vast majority of scientific programmmers still use. Worrying about 0 vs 1 is just useless bikeshedding, really. I've done lots of index heavy operations in Julia and in Python, and it's easy either way.

Re: Julia 1.0

#213

Post by eigenspace »

taliesinb wrote: post #53

I'd love to know from any resident Julia experts: what are your favorite examples of active, high-quality Julia packages? And perhaps more importantly, what is missing?

The thread Chris linked to has some great discussion on the state of the art packages.

With respect to your question about what’s missing: Coming from Python, I think one might be surprised by how much less one feels the need to rely on packages in Julia. The language has some very powerful abstractions that really makes one rely less on packages than you’d expect.

Julia has really inhereted a lot of great lessons from Lisp and that’s made the language an absolute treat for ‘rolling your own’. Meanwhile, some lessons from more modern languages have also made Julia much more effective at sharing your abstractions with others much easier and effective than any Lisp I’ve ever seen.

Re: Julia 1.0

#214

Post by dangom »

ChrisRackauckas wrote: post #160
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…

This is what 0-based indexing looks like in data analysis: >In order to read a csv in that doesn't have a header and for only certain columns you need to pass params header=None and usecols=[3,6] for the 4th and 7th columns: https://stackoverflow.com/questions/29287224/pandas-read-in-... Just reading that hurts me.

This is very much a non-argument. Call the columns the 4th and 7th is as arbitrary as calling them the 3rd and the 6th.

Again, 0-based indexing exists to fit a purpose: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EW...

In my opinion, reading `a = b[1:n-1]` hurts much more than reading `a = b[:n]`.

Re: Julia 1.0

#215

Post by billchristian »

Svenskunganka wrote: post #168
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.

The blog mentions that Julia is supposed to be a general purpose language, and not a language built specifically for scientific computing. Is that wrong? The first impression does leave me thinking that using Julia for different programming domains like distributed internet-facing servers or web services is not something it was built for.

On a similar note, I continue to be interested in Julia. However, the examples and videos shared by the community are predominately scientific or mathematical in nature. The material is too dense for the layman programmer such as myself. Not specifically a compliant, but more of a call to action for the community to share more traditional usage examples to intrigue others like myself.

And of course, I should really assist to solve this problem myself. But, I thought to encourage other language experts.

Re: Julia 1.0

#216

Post by tomkwong »

Congrats to the Julia dev team for making it happen!

Julia v0.6 was already very functional/usable release but having 1.0 allow me to write code and have confidence that it will continue working in the same, solid foundation in the years ahead.

I started my coding career over 25 years ago and I had done much work in C, Java, JavaScript, and PHP. Julia is the best language that I have worked with so far. Fast, dynamic, and highly productive!

I'll be moving to 1.0 release when my dependent packages are upgraded to support 1.0.

Re: Julia 1.0

#217

Post by jernfrost »

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

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 to the language design of Python. You cannot fix it without breaking the language.

Julia in contrast required minimum effort and resources to get fast. It is almost a toy project compare to Python. It is all down to clever language design which allowed them to use a rather dumb and simple compiler while letting LLVM do most of the heavy lifting.

Every advance of Python is going to require 10x the effort of advancing Julia. It will just be a question of time before Julia catches up. Python has a huge lead so that will still probably take years but it will happen.

Re: Julia 1.0

#218

Post by eghad »

Glad they've finally gotten to 1.0, been using it on and off since .3 with the same optimism I had when Rails jumped onto the scene. I really hope the community can start to mature beyond the bikeshedding that is typical of early language days, and start cracking more significant issues necessary for wider acceptance. Speed and multiple dispatch are great, but ability to roll standalone binaries (just don't mention it on Discourse/Gitter or risk Karpinski's wrath), streamlining documentation/onboarding, and more native/active package development are pretty big todos to tackle.

I've been working on updating a wide variety of engineering software apis/wrappers and a large informatics library for .7/1.0, but I'd love to hear any suggestions of must-need technical packages that users want from MATLAB, Python, or R.

Re: Julia 1.0

#219

Post by srean »

mlthoughts2018 wrote: post #175
ChrisRackauckas wrote: post #97

Earlier quoted context omitted.

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 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 Julia offers that Cython and Numba doesnt is the option of a programmable syntax for the low level manipulation. Cython has improved, but for the longest time it was always a forced decision between operating at a the higher level of array/sub-array manipulation in Python or down to tedious index manipulation in Cython with nothing in between. Not to mention fighting the Cython compiler and Python's C API to get the 'yellows' out.

Re: Julia 1.0

#220

Post by staticfloat »

tavert wrote: post #181
stabbles wrote: post #75

Earlier quoted context omitted.

Many things in Base have moved to separate packages to make it light-weight. FFTW is available in a package under the MIT license [1]. Also its author is a top contributor to Julia ;). [1] https://github.com/JuliaMath/FFTW.jl

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] https://github.com/JuliaMath/FFTW.jl

Post reply on HN