If anyone is interested, I was snooping around and found one of the co-creator's PHD thesis that explains in detailed terms some of the ideology behind Julia: https://dspace.mit.edu/handle/1721.1/99811#files-area
Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
31–40 of 249 posts
Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
#32Can't wait for the language to be as widely used as Python or R. Been playing around with it at home since the 1.0 release and it really is a joy to use.
I think Python has a large advantage in this space since it is not as specialized. For many projects that I work on the actual core number crunching code is small (or part of a library I don't have to worry about). The rest of the code could be scraping data, or a web application. These are things that there are numerous packages available for in Python but seem to fall outside the focus of Julia.
Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
#33Julia deserves way more attention than it's currently getting. I'm hoping now that it's past 1.0, a few big-name companies will start using it and raise its profile.
Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
#34what good is philosophy if you choose arrays based on 1? https://groups.google.com/forum/?hl=en#!topic/julia-dev/tNN7...
Fun fact: arrays in Fortran are also based on 1 by default, but they can be defined to start at 0, or even arbitrary negative numbers. The following are all valid: integer :: array1(5) integer :: array2(0:4) integer :: array3(5:10) integer :: array4(-4:4)
Julia also supports this (called Offset Arrays)
Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
#35Multi-methods really are a lot of fun, but I'm missing the Trait system (instead of the object hierarchy) that makes Rust so modular. I know that there are some tries to put it into Julia, but none of them is well supported.
Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
#36Julia deserves way more attention than it's currently getting. I'm hoping now that it's past 1.0, a few big-name companies will start using it and raise its profile.
Attention is better in small doses, I think it's clear to many that Julia is a strong project, let it grow peacefully.
Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
#37With computational power becoming cheaper and cheaper - will we have two-language problem anymore?
Yes (if you're asking what I think you're asking). Computers are never fast enough. Even if they get 1000x faster, we'll want to squeeze every drop of performance out by using C or whatever.
Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
#38Can't wait for the language to be as widely used as Python or R. Been playing around with it at home since the 1.0 release and it really is a joy to use.
I wish that Python feels a bit of Julia's heat, as that might be the only way for more PyPy love.
Python without GIL to provide real shared-memory threading would address 90% of my issues with the language.
Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
#39I built a very simple neural-network app a few years ago with Julia, and while the project was fun and I didn't think the language was bad by any means, as someone who does software for a living I had trouble seeing why compsci people really got into it.
I could totally see someone like my dad using it (he's an aerospace engineer, not software), but I have friends who work in compsci in academia trying to evangelize the language.
Not trying to start a war here, but I'm curious what more-seasoned Julia vet might have seen that someone with only ~12 hours with the language wouldn't.
Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software
#40I personally don't like the fact that you have structs but no classes and no instance methods, but I know this is personal and don't want to start a religious war this morning
You mean you don't like that the methods are declared outside of the struct?
Or that you have to say foo(x) instead of x.foo()?
The latter makes writing code using autocomplete less doable, but reads more naturally in many cases.
I can't think of compelling pragmatic reason to mind the former, but if you have one I'd like to hear it.