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

141–150 of 446 posts

Re: Julia 1.0

#141

Post by AriaMinaei »

Never had a proper look at the documentation until now. This language is very interesting!

One thing I found is that types in Julia are first-class values [0]. You can put them in variables, pass them around, inspect them, even produce new ones in runtime. Opens up all kinds of metaprogramming opportunities. Very Lispy! (Well, Julia is Lispy). It's also interesting that types are optional, yet they're significant for the optimising compiler. Like, if you do type the arguments of a function, the optimising compiler will have less work to do.

It also looks like much of the compiler pipeline is exposed to the user [1]. You have access to the parser, can tweak the AST. Macros also there of course.

[0] https://docs.julialang.org/en/stable/manual/types/ [1] https://docs.julialang.org/en/stable/manual/metaprogramming/

Re: Julia 1.0

#142

Post by kmm »

currymj wrote: post #51
typon wrote: post #42

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

Apart from being close to MATLAB, a goal of Julia is to make it easy to just type mathematical formulas straight off the page and into your code. 1-based indexing makes this so much easier, even if it seems somewhat depraved to a computer scientist.

In my experience, 0-based indexing is way more common in mathematics. Maybe it depends on the field you're working in. Off the top of my head, dimensions are numbered from zero in relativity and particle physics, Fourier series only make sense with 0-based indexing, coefficients of polynomials are numbered from zero, Taylor series, indexing by taking the modulo ...

Re: Julia 1.0

#143

Post by BeetleB »

ur-whale wrote: post #90
stellalo wrote: post #81

Earlier quoted context omitted.

1-based indexing is a non-issue

It most certainly is for the vast number of folks who code in C, C++, Java, Python, etc ... It will for sure hurt adoption.

>It will for sure hurt adoption.

Reminds me of the complaints my friends had about Linux when I first showed them a fantastic window manager.

"This will never get anywhere. It has no Start button."

If I were in a team that refused a language just because it is 1 based indexing, I would really worry about the abilities of the team.

Re: Julia 1.0

#144

Post by KenoFischer »

driverdan wrote: post #123
ChrisRackauckas wrote: post #105

Earlier quoted context omitted.

It was literally released today. Of course the packages don't work yet...

I've never used Julia but why would a language make breaking changes on each release? It doesn't have backwards compatibility? That sounds like a nightmare to work with. Is it because it was pre-1.0?

Pre 1.0, we've generally provided backwards compatibility for one version with deprecations. Somewhat ironically that has often led to people just living with walls of warnings until the version that actually broke it came out, which led to a worse experience. We also have automated upgrade tools now, which can do many of the simple (and some not so simple ones) automatically. The situation on 1.0 is slightly worse than in previous releases because we released 0.7 and 1.0 simultaneously to avoid having to ship 1.0 with active deprecations. Of course that means that people will have to fix their packages now, rather than waiting until next year.

Re: Julia 1.0

#145

Post by simonbyrne »

gjm11 wrote: post #138

I wanted to give this a try with Jupyter (having played a bit with earlier versions of Julia that way) but haven't had much success. It seems that the first step in getting Jupyter to know about a new version of Julia is to do Pkg.add("IJulia") in Julia. Except that that doesn't work; it seems that now you're supposed to use some special pkg mode in the Julia REPL. So, I hit ] to enter pkg mode and type "add IJulia",…

No, just need to wait for IJulia to be updated. I imagine it will be a day or two.

Re: Julia 1.0

#146

Post by StefanKarpinski »

KenoFischer wrote: post #110
bsdubernerd wrote: post #39

I'm a quite happy Julia user, however I feel there are still some warts in the language that should have warranted a bit more time before banging 1.0 on the badge. Exception handling in julia is poor, which reminds me of how exceptions are (not/poorly) handled in R. Code can trap exceptions, but not directly by type as you _would_ expect. Instead, the user is left to check the type of the exception in the catch block…

Exception handling is one of the few subsystems that hasn't really had a revamp. It's probably one of the areas that'll get a good bit of thinking post 1.0.

Also: not allowing the expected `catch e::ErrorType` syntax leaves it open for a better design without breaking existing code which means it can be done in the 1.x timeframe instead of needing to wait until 2.0. This is why that syntax hasn't yet been added with the expected meaning.

Related: https://github.com/JuliaLang/julia/issues/7026

Re: Julia 1.0

#147

Post by athenot »

As an outsider, I'd like to see somewhere near the home page a few short snippets of code to get a feel for Julia and hopefully show the kind of uses for which it is a natural choice.

Nim's home page¹ shows a piece of sample code right at the top. Perl6's page² has a few tabs quickly showing some patterns it's good at. Golang³ has a dynamic interpreter prepopulated with a Hello World.

Julia's home page shows a nice feature list and links to docs to deep dive but it doesn't do a good job of selling it.

¹ https://nim-lang.org

² https://perl6.org

³ https://golang.org

Re: Julia 1.0

#148

Post by jebej »

renox wrote: post #80
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…

> I initially defended the choice, but I now agree that 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 Especially since it would have been very easy to 'do it like Ada' and allow any start index by default (I have use Lua and it's really annoying to use an extension languag…

You can use whatever start index you like: https://docs.julialang.org/en/stable/devdocs/offset-arrays/#...

For a pre-baked solution: https://github.com/JuliaArrays/OffsetArrays.jl

Re: Julia 1.0

#149

Post by AlexCoventry »

29galoseats wrote: post #57
bsdubernerd wrote: post #39

I'm a quite happy Julia user, however I feel there are still some warts in the language that should have warranted a bit more time before banging 1.0 on the badge. Exception handling in julia is poor, which reminds me of how exceptions are (not/poorly) handled in R. Code can trap exceptions, but not directly by type as you _would_ expect. Instead, the user is left to check the type of the exception in the catch block…

I had a similar reaction about this being a little premature. On the other hand, I'm wondering if this will help a little with the dependency hell that's caused me to drift away from Julia over the last year or so. At first I was fairly excited about Julia, and greatly preferred it over R or Python for numerical work, library resources aside. It was fast and I liked the language design itself. Over the last year or t…

That's really disappointing to hear. Dependency hell is what drove me away in 2016. I hope it clears up eventually.

Re: Julia 1.0

#150

Post by StefanKarpinski »

AriaMinaei wrote: post #141

Never had a proper look at the documentation until now. This language is very interesting! One thing I found is that types in Julia are first-class values [0]. You can put them in variables, pass them around, inspect them, even produce new ones in runtime. Opens up all kinds of metaprogramming opportunities. Very Lispy! (Well, Julia is Lispy). It's also interesting that types are optional, yet they're significant for…

> Like, if you do type the arguments of a function, the optimising compiler will have less work to do.

Giving types for function arguments doesn't actually have any effect on performance: the compiler specializes on concrete runtime argument types anyway, so completely untyped code is just as fast as fully type annotated code—since the types are known when the code is compiled. On the other hand, giving type information is essential for performance involving memory locations, i.e. field types and the element types of collections.

Post reply on HN