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

Julia v0.7.0 Release Notes

github.com

Post reply on HN
Print view View original

41–50 of 61 posts

Re: Julia v0.7.0 Release Notes

#41

Post by karmakaze »

AboutTheWhisles wrote: post #8
karmakaze wrote: post #6

Earlier quoted context omitted.

When I first used named tuples in Swift I thought they'd be so great, no more _1 _2 or whatever. After using them a while, it gets a bit tiring and litters with repeated type info. A type alias for a named tuple would help with that. Any others have similar experiences? Or would they play out differently in Julia?

Wouldn't that just be a struct?

Like an ad-hoc anonymously typed struct. Only the members are named, so each time the type is specified it is with the member names, hence just using a type name is preferred. If it is really just used at one or two call sites and not propagated all is well, but invariably things tend to expand in use.

Re: Julia v0.7.0 Release Notes

#42

Post by 3JPLW »

sixbrx wrote: post #39

Is there anything in Julia yet or planned, that would allow to specify that "implementations" (in some sense) of an abstract type must provide certain method implementations, which would be checked before any attempt to call a missing function at run time (such as just after all definitions have been read maybe)? I realize that this issue can be thorny under multiple dispatch so maybe no solution is practical. But th…

Yes, there have been lots of discussions about this — typically referred to as "formal interfaces." This would be a 2.0 (or later) feature addition, and it's not yet certain how it would be approached.

https://github.com/JuliaLang/julia/issues/6975

https://github.com/JuliaLang/julia/issues/5

Re: Julia v0.7.0 Release Notes

#44

Post by nalimilan »

zmk_ wrote: post #43

Removing eye() in favour of a new construct is weird after all this time. It seems to me like v0.7 will break a lot of my current code.

Existing code won't break as a deprecation is in place. And the replacement is very simple: Matrix(I, m, n), Matrix{Float64}(I, m, n) or even just I depending on the use case.

Re: Julia v0.7.0 Release Notes

#45

Post by mwfunk »

yesenadam wrote: post #9

That heading gives someone who doesn't already know, absolutely no clue what it is or why they should click on it.

If you feel that way and want to contribute, the thing to do is to spend 30 seconds with Google (if that) answering your own question, then posting a summary of what you've learned for other HN readers who may not have heard of Julia.

The thing NOT to do is get mad because people are talking about something that you personally have never heard of.

The thing to REALLY not do is to actually expend energy posting a public statement about how you're upset because people are talking about things that you personally have never heard of and can't be bothered to spend a few seconds learning about. No good will ever come of it, especially when you could have spent that same time and energy answering your own question.

Re: Julia v0.7.0 Release Notes

#46

Post by yesenadam »

ChrisRackauckas wrote: post #24
yesenadam wrote: post #23

Earlier quoted context omitted.

Ok thanks. Lately been using Cython with its near-C speed and Python convenience. Just quickly had a look at Julia wiki page, seems like a fast Python, is that fair?

Python doesn't have multiple dispatch though. It's central to making Julia's type system fast. I.e., it's not just loops that are fast, but also code that uses Julia-defined data structures are fast. Additionally, you can write generic code and have it automatically compile fast code for large classes of types. Also, the whole Base library is written in Julia, mostly generically, so this will be compatible with your…

Thank you! :-D Such a great answer, wish I could +100 that.

Re: Julia v0.7.0 Release Notes

#47

Post by yesenadam »

doodpants wrote: post #31
yesenadam wrote: post #21

Earlier quoted context omitted.

Hehe no. It said "Julia Lang v0.7" but I'm not insider enough to think of Julia the language when I read that. I wondered "Who is Julia Lang? Hmm must be some software?" etc

I'd think that most regular readers of Hacker News would naturally interpret "____ Lang" as referring to a programming language, but clearly there's some ambigutity. I would have the opposite problem; if a Hacker News item was titled "Fred Lang Has Died", my first thought would be: "I didn't even know there was a programming language called Fred. It must have died from obscurity." :-)

I guess the problem is with the name Julia, which is lovely but you have to specify that you mean the language—no-one ever mistakes what "C++" refers to.

Re: Julia v0.7.0 Release Notes

#48

Post by wallnuss »

karmakaze wrote: post #41
AboutTheWhisles wrote: post #8

Earlier quoted context omitted.

Wouldn't that just be a struct?

Like an ad-hoc anonymously typed struct. Only the members are named, so each time the type is specified it is with the member names, hence just using a type name is preferred. If it is really just used at one or two call sites and not propagated all is well, but invariably things tend to expand in use.

I still don't quite see why you wouldn't just use a named struct, but you can create a alias for the NamedTuple type

    const MyAlias = NamedTuple{(:a, :b),Tuple{Int64,Int64}}
    MyAlias((2, 3)) # (a = 2, b = 3)

Re: Julia v0.7.0 Release Notes

#49

Post by xiaodai »

wallnuss wrote: post #36
kmundnic wrote: post #35

Earlier quoted context omitted.

Thanks! From the documentation and all the threads I searched in discourse, it was never clear to me that @parallel and pmap where aiming towards the direction you just described. I did try Threads.@threads, but the overhead was way too high. I might look into it again soon.

Threads.@threads is still consider a bit experimental and there are a few performance pitfalls that one can stumble into. I talked about this for a bit in http://slides.com/valentinchuravy/julia-parallelism , but if you still have issues after reading that feel free to reach out on https://discourse.julialang.org and we will figure out what is going on.

Very technical presentation, but it contains nuggets of that I can't wait to try once I get home! Do you have a blog that lays this out in a way that is aimed at the general Julia programmer?

Re: Julia v0.7.0 Release Notes

#50

Post by xiaodai »

wallnuss wrote: post #36
kmundnic wrote: post #35

Earlier quoted context omitted.

Thanks! From the documentation and all the threads I searched in discourse, it was never clear to me that @parallel and pmap where aiming towards the direction you just described. I did try Threads.@threads, but the overhead was way too high. I might look into it again soon.

Threads.@threads is still consider a bit experimental and there are a few performance pitfalls that one can stumble into. I talked about this for a bit in http://slides.com/valentinchuravy/julia-parallelism , but if you still have issues after reading that feel free to reach out on https://discourse.julialang.org and we will figure out what is going on.

unfortunately slides.com is blocked at work....
Post reply on HN