Julia v0.7.0 Release Notes(github.com) |
Julia v0.7.0 Release Notes(github.com) |
Aside: implementing deprecations is often harder than implementing new feature themselves. We put in the effort because it is absolutely critical that people's code never just silently change behavior. Syntax and variable scope deprecations are particularly hard to implement, but all of the changes in 0.7 do have deprecation warnings – some of them with absolutely crazy implementations that we're very excited to get to delete when we release 1.0.
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.
edit: Well, I did end up learning quite a bit about Julia - which sounds awesome - and got the best answer I ever got on here, which it seems others benefited from too, so that was good. :-)
In case you're curious, the website is https://julialang.org/
> Julia is a high-level, high-performance dynamic programming language for numerical computing. It provides a sophisticated compiler, distributed parallel execution, numerical accuracy, and an extensive mathematical function library.
The Chinese Wikipedia entry on the most common form of 'Lang' is anemic in comparison: https://zh.wikipedia.org/wiki/%E9%83%8E%E5%A7%93
const MyAlias = NamedTuple{(:a, :b),Tuple{Int64,Int64}}
MyAlias((2, 3)) # (a = 2, b = 3)https://github.com/JuliaComputing/FemtoCleaner.jl
It's quite nice to have a bot give you an update PR!
I’m not surprised that deprecation logic is harder than the new features.
god that sounds sooo painful
Keep in mind that in the future this statement would be something like: if you have code that was written for Julia 1.x and want to upgrade to Julia 3.x, then you should upgrade through Julia 2 instead of just skipping it. This does not seem terribly unreasonable.
Did you understand what all of those meant? Probably not. I don't.
But your lack of understanding doesn't make it notable.
Not notable? Luckily it was just a HN comment not a wikipedia page. :-)
That's no doubt why your comment was downvoted.
Tell me, what do you expect from "Go 1.10 Release Notes"? You'll notice that link it's even less informative than this link to "Julia v0.7.0 Release Notes".
For future reference, here's how to the information you wanted. First, go to the link, which you can see is to github. It uses the standard github layout. On the top is a hierarchical list of names showing "julia" / "NEWS.md". The "julia" is a hyperlink to the github project page.
Click on that and the top says "The Julia Language: A fresh approach to technical computing. https://julialang.org/". Lower down it says "Julia is a high-level, high-performance dynamic language for technical computing. The main homepage for Julia can be found at julialang.org." If that is not enough information for you, both URLs take you to the language page.
Figuring out what you wished for, from the information given, takes less time then writing your HN comment.
And much less time then it takes to pass on HN cultural norms to new accounts.
Actually want to qualify this a bit. Nothing gets automatically fast by just picking a fast language. That Julia is close to C in performance mainly means it is possible to achieve this through optimization without too much effort. However you still need to have some idea of what makes something slow or fast in Julia.
Personally I find it very easy to optimize Julia code because you can quickly see how the JIT transforms an individual function and what you may need to change.
Then finally, the kicker is that Julia, especially on v0.7, doesn't optimize functions separately: it optimizes them together. It will inline small functions into others, perform interprocedural optimizations and utilize compilation-time constants, etc. Thus when the code is Julia all the way down, it can and will compile everything together to optimize it a lot more than functions compiled separately, giving a lot more performance benefits. When you add in the macros to turn off things like bounds checks and adding in explicit SIMD, you truly get to C-level of performance and many times beyond because your code is so architecturally and vertically optimized (it's like you put on the flags to say "compile code that only works for this current machine with this current codebase", and it can safely make this assumption because it's JITing).
Because of this, it goes much further than Cython, and this also makes the type system and multiple dispatch central to the language. So I would say at a surface level it's "fast Python" (or "more productive C", that's how I usually think of it). However, at a deeper level the type system is so central that larger software architectures will be different to accommodate this multiple dispatch style as opposed to OOP.
Python is much more of a black box, performance wise.
Also something like Cython is radically different from Julia. Cython is compiled to C code. Julia is based on JIT so while you have an interactive session in the REPL, functions are continously compiled as you make them.
I wouldn't say it's a fast Python.
Edit: Grammar
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." :-)
Loooking forward how it evolves.
edit: Ahhh hehe I just noticed the title is now "Julia v0.7.0 Release Notes"! When I commented yesterday it was "Julia Lang v0.7" I think. So I've been wondering why on earth the comments about 'Release Notes', and the late commenters must have been wondering why the earlier talk about 'Lang'. So.. there was confusion. That makes more sense of why people were getting weirder and weirder about this—false assumptions. I learnt something, hopefully the people lecturing me about not understanding how HN works learnt something too. Apologies not expected, but that would be lovely. p.s. Yes, the new title is much much better!
The change means that the person who submitted the post was in error. HN guidelines call for using the original title, with a few exceptions.
The page's title when the posting was made was "Julia v0.7.0 Release Notes", which you can confirm from this snapshot of 4 days ago: https://github.com/JuliaLang/julia/blob/eb94b8c3d8e8ee2294ed... .
This suggests that you did not even click on the link to learn more about the project before complaining about the lack of context.
The practice I try to do in situations like this is not to complain about the problem, but to figure out the solution to my complaint, and post that. For example, you could have written: "The submitter used the wrong title. It should be 'Julia v0.7.0 Release Notes'. Julia is a programming language for technical computing. More at http://julialang.org/"
That would be helping. Complaining about such a basic topic is not helping.
Cython's parallelism is via OpenMP which is shared memory multithreading. Of course multithreading is faster, but it's restricted to a single computer. Julia does have multithreading as well via `Threads.@threads`. This is shared memory and restricted to a single computer just like Cython, and will have a lot lower overhead than `pmap` and `@parallel`. If you want to directly compare something to Cython's parallelism, this is what you should be looking at.
On a side note, it looks like Cython doesn't have any native multiprocessing or multinode parallelism that would be the direct comparison to `pmap` or `@parallel`.
I did try Threads.@threads, but the overhead was way too high. I might look into it again soon.