6 ms·

Julia 0.6.0-rc1 new language features

90 points by boromi 9y ago

boromi 9y ago
Still no static compilation, being able to make executables would be huge.
ceyhunkazel 9y ago
If you want to compare Julia with Python and Matlab here is the comparison cheatsheet https://cheatsheets.quantecon.org/ https://cheatsheets.quantecon.org/
- fiatjaf 9y ago
  Here are the code examples: http://rosetta.alhur.es/compare/python/julia/# http://rosetta.alhur.es/compare/python/julia/#
baldfat 9y ago
The list of breaking changes is pretty long. Hope that things can get to the point where a 1.0 release is ready as it is suppose to happen in Qtr 2 or 3????
- 3JPLW 9y ago
  That's precisely _why_ the list of breaking changes is long.
  - rspeer 9y ago
    Okay, but a lot of these changes don't sound like the final word, they sound like "hey let's try this new thing and see how people like it".
    - 3JPLW 9y ago
      Which points read that way to you? I see one feature that's explicitly tagged as experimental. Everything else reads very matter-of-fact to me.
- ssivark 9y ago
  I feel like there should be a programming languages analogue of this: http://www.stickycomics.com/computer-update/ http://www.stickycomics.com/computer-update/ Every time I see breaking changes in Julia (and the improvements they engender), I get excited! :P
- StefanKarpinski 9y ago
  Most of the breaking changes are effectively bug fixes in the sense that the old behavior was either not what you would want or not what you would expect. The single most breaking change is the first one listed: removing new lines from line-oriented I/O functions – but it really makes these functions more pleasant to work with. The next two most breaking changes are actual bug fixes: one was a macro hygiene fix which a lot of packages happened to rely on the broken behavior of, and the other was to make new method definitions reliably take effect (#265), which is a huge benefit but also breaks some code that was relying on the old wrong behavior.
  - killin_dan 9y ago
    You have such a way with words with stuff like this. Modern tech circles feel like such a minefield, there's always some guy waiting to scream ACK CHEW ALLY. Anyways, I'm so glad you are dedicated to the julians. Have our back, we'll always have yours. 0.6 is the highlight of my year so far.
jfaucett 9y ago
Sorry not to see a rehaul of the module system. I've talked to the devs and know its not a direction they want to take but I really wish they had tried to make Julia a language you can build modular applications around (like Python) instead of an all batteries included runtime (like R). IMHO I think thats the sweetspot that could have been what many scientific computing developers are looking for. Python is good but has its problems when doing scientific computing (most addressed and fixed by julia btw) but you still use python because its much better than julia for building modular applications, and you use R because its much better than julia at doing exploratative work. So in the end julia is in this limbo of having fixed most of the problems with python but not being able to be used as a replacement for python. Thats just my opinion though. I'm sure others will disagree :)
- coldtea 9y ago
  What is holding back the current module system they have?
- Gtifn 9y ago
  Are you talking about breaking modules (like linalg) out of base or changing the semantics and mechanics of modules? I think the former is planned before 1.0? If the latter, what do you think is the issue? Do you not like julia packages are separated into interface/abstract implementation and then concrete packages that can then have submodules that call each other? Seems more modular than working around a python inheritance mess.
  - jfaucett 9y ago
    "Are you talking about breaking modules (like linalg) out of base or changing the semantics and mechanics of modules?" Well, I'd be all for making Base as small as possible since I'm not big on monolithic standard libs and think everything possible should more or less be a package which you can include on a per project level. As for the semantics and mechanics, I'd like to have the ability to have true public/private like rust or go, so that you can have a tightly defined public api and be sure your users only have access to that. Also I'd like to see the whole thing simplified it is way more complex than it needs to be. Just have import act like a function for example it could take a module, a keyword, and a vector like this: import MyModule, :all # import all public defs import MyModule, [a, b, K] # use as MyModule.a, MyModule.b, MyModule.K import MyModule, :alias, [a,b,K] # use as a, b, K compare the above to https://docs.julialang.org/en/stable/manual/modules/ https://docs.julialang.org/en/stable/manual/modules/ as far as I can tell the functionality is the same. Anyway those were some of the things that I didn't like about it and would have changed.
3JPLW 9y ago
There are lots of exciting new parts to Julia 0.6. I believe the linked NEWS.md is still in the process of being compiled and refined throughout the release-canditate cycles. Some of my favorite parts: * Actually being able to safely redefine methods. Julia is now much more dynamic (and correct!). * Dot-broadcasting is absolutely amazing and way more capable in 0.6: https://julialang.org/blog/2017/01/moredots https://julialang.org/blog/2017/01/moredots * The `@views` macro is a very small addition but much appreciated.
kshyatt 9y ago
This is a small thing and probably not very publicly visible, but I'm really happy with the progress we've made on the libgit2 module in Base.
Tarrosion 9y ago
I wonder if one of the most important changes is pure nomenclature: the updated type definition keywords. In prior versions the "obvious" way to define a type gets you a mutable type, and going forward the obvious way gets you an immutable type. Of course this doesn't change what the language is capable of, but I hope/expect it'll encourage better practice.

90 points by boromi 9y ago

Still no static compilation, being able to make executables would be huge.

If you want to compare Julia with Python and Matlab here is the comparison cheatsheet https://cheatsheets.quantecon.org/ https://cheatsheets.quantecon.org/

fiatjaf 9y ago
Here are the code examples: http://rosetta.alhur.es/compare/python/julia/# http://rosetta.alhur.es/compare/python/julia/#

baldfat 9y ago

The list of breaking changes is pretty long. Hope that things can get to the point where a 1.0 release is ready as it is suppose to happen in Qtr 2 or 3????

3JPLW 9y ago
That's precisely _why_ the list of breaking changes is long.
- rspeer 9y ago
  Okay, but a lot of these changes don't sound like the final word, they sound like "hey let's try this new thing and see how people like it".
  - 3JPLW 9y ago
    Which points read that way to you? I see one feature that's explicitly tagged as experimental. Everything else reads very matter-of-fact to me.
ssivark 9y ago
I feel like there should be a programming languages analogue of this: http://www.stickycomics.com/computer-update/ http://www.stickycomics.com/computer-update/ Every time I see breaking changes in Julia (and the improvements they engender), I get excited! :P
StefanKarpinski 9y ago
Most of the breaking changes are effectively bug fixes in the sense that the old behavior was either not what you would want or not what you would expect. The single most breaking change is the first one listed: removing new lines from line-oriented I/O functions – but it really makes these functions more pleasant to work with. The next two most breaking changes are actual bug fixes: one was a macro hygiene fix which a lot of packages happened to rely on the broken behavior of, and the other was to make new method definitions reliably take effect (#265), which is a huge benefit but also breaks some code that was relying on the old wrong behavior.
- killin_dan 9y ago
  You have such a way with words with stuff like this. Modern tech circles feel like such a minefield, there's always some guy waiting to scream ACK CHEW ALLY. Anyways, I'm so glad you are dedicated to the julians. Have our back, we'll always have yours. 0.6 is the highlight of my year so far.

jfaucett 9y ago

Sorry not to see a rehaul of the module system. I've talked to the devs and know its not a direction they want to take but I really wish they had tried to make Julia a language you can build modular applications around (like Python) instead of an all batteries included runtime (like R). IMHO I think thats the sweetspot that could have been what many scientific computing developers are looking for. Python is good but has its problems when doing scientific computing (most addressed and fixed by julia btw) but you still use python because its much better than julia for building modular applications, and you use R because its much better than julia at doing exploratative work. So in the end julia is in this limbo of having fixed most of the problems with python but not being able to be used as a replacement for python. Thats just my opinion though. I'm sure others will disagree :)

coldtea 9y ago
What is holding back the current module system they have?
Gtifn 9y ago
Are you talking about breaking modules (like linalg) out of base or changing the semantics and mechanics of modules? I think the former is planned before 1.0? If the latter, what do you think is the issue? Do you not like julia packages are separated into interface/abstract implementation and then concrete packages that can then have submodules that call each other? Seems more modular than working around a python inheritance mess.
- jfaucett 9y ago
  "Are you talking about breaking modules (like linalg) out of base or changing the semantics and mechanics of modules?" Well, I'd be all for making Base as small as possible since I'm not big on monolithic standard libs and think everything possible should more or less be a package which you can include on a per project level. As for the semantics and mechanics, I'd like to have the ability to have true public/private like rust or go, so that you can have a tightly defined public api and be sure your users only have access to that. Also I'd like to see the whole thing simplified it is way more complex than it needs to be. Just have import act like a function for example it could take a module, a keyword, and a vector like this: import MyModule, :all # import all public defs import MyModule, [a, b, K] # use as MyModule.a, MyModule.b, MyModule.K import MyModule, :alias, [a,b,K] # use as a, b, K compare the above to https://docs.julialang.org/en/stable/manual/modules/ https://docs.julialang.org/en/stable/manual/modules/ as far as I can tell the functionality is the same. Anyway those were some of the things that I didn't like about it and would have changed.

3JPLW 9y ago

There are lots of exciting new parts to Julia 0.6. I believe the linked NEWS.md is still in the process of being compiled and refined throughout the release-canditate cycles. Some of my favorite parts: * Actually being able to safely redefine methods. Julia is now much more dynamic (and correct!). * Dot-broadcasting is absolutely amazing and way more capable in 0.6: https://julialang.org/blog/2017/01/moredots https://julialang.org/blog/2017/01/moredots * The `@views` macro is a very small addition but much appreciated.

kshyatt 9y ago

This is a small thing and probably not very publicly visible, but I'm really happy with the progress we've made on the libgit2 module in Base.

Tarrosion 9y ago

I wonder if one of the most important changes is pure nomenclature: the updated type definition keywords. In prior versions the "obvious" way to define a type gets you a mutable type, and going forward the obvious way gets you an immutable type. Of course this doesn't change what the language is capable of, but I hope/expect it'll encourage better practice.