
Julia 0.6.0-rc1 new language features - boromi
https://github.com/JuliaLang/julia/blob/v0.6.0-rc1/NEWS.md
======
3JPLW
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.

------
jfaucett
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 :)

~~~
Gtifn
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
"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.

~~~
StefanKarpinski
Adding enforced access controls is certainly within the realm of possible
future language enhancements, as is some tweaking of the module and import
system (I'd like to collapse `import` into `using`, for example). But you seem
to be doing a bit of a bait-and-switch in your comparison here: is Julia being
compared with permissive, dynamic languages like Python and Ruby, or static
languages with strict access controls like C++, Rust and Go? In terms of
permissions and enforcement, Julia is quite similar to Python where access
control is entirely by convention. In terms of binding resolution and
modularity, it is quite similar to C++. People seem to be able to build large
systems in both languages fairly effectively.

~~~
jfaucett
"But you seem to be doing a bit of a bait-and-switch in your comparison here"

You're right I might be conflating the comparison but does it matter?
JavaScript is a dynamic language which allows strict access controls (although
its semi-hacky to do it).

Also, when is access control by convention a good idea? Sure you can live with
it as Python and Ruby devs like myself do, but compared to languages which
give you stricter controls like Erlang (which is also dynamic) its pretty
obviously worse when it comes to building large software systems because it
weakens the guarantees you can make about your libraries and the libraries you
use to build those libraries.

"People seem to be able to build large systems in both languages fairly
effectively."

People can and have built large systems in assembly. That doesn't mean
assembly provides the optimal means for building composable software. Why
settle for something thats mediocre when you're still unstable and change it
for the better?

~~~
one-more-minute
Your argument is deeply confused. First Python is "much better than Julia for
building modular applications", now it's flawed for the same reasons as Julia?
Feature requests are fine but let's make them coherent please.

------
kshyatt
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.

------
baldfat
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????

~~~
StefanKarpinski
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
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.

------
Tarrosion
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.

------
ceyhunkazel
If you want to compare Julia with Python and Matlab here is the comparison
cheatsheet
[https://cheatsheets.quantecon.org/](https://cheatsheets.quantecon.org/)

~~~
fiatjaf
Here are the code examples:
[http://rosetta.alhur.es/compare/python/julia/#](http://rosetta.alhur.es/compare/python/julia/#)

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

