Hacker News new | ask | show | jobs
by tanlermin 3617 days ago
"Given enough time, though, I think the paradigms that Julia is exploring will make it a killer general-purpose language."

I think its already a Killer general-purpose language (except for the module system).

I'm just not sure if it is good enough to unseat incumbents when there are things like rust with its deterministic memory management or python with all its momentum and compiler technology coming along.

Not sure whether to bet on it at this point.
1 comments
jballanc 3617 days ago
The thing about Julia is that it's playing a whole different ballgame than pretty much every other popular language today...it's just that most people don't realize it yet! The work and design that's gone into Julia's type system and multiple dispatch has the potential to be a real game-changer, but outside of a core community putting it to good use, I don't think it's potential has been fully realized.

This is also why I'm excited by what's coming next in v2.0. Some of the early ideas being explored at JuliaCon with respect to traits and interfaces will begin to really shine a spotlight on its true power.

link
Xcelerate 3617 days ago
> The thing about Julia is that it's playing a whole different ballgame than pretty much every other popular language today

I've noticed this. I've been using it the past four years for much of my dissertation work (starting right when it was released). Julia's type system has the potential for some extremely cool things.

I've been toying around with the idea of making a package that focuses on runtime static typing. This would be particularly useful when using the language interactively (like in a Jupyter notebook). The idea is to perform a check at runtime to make sure all variables in a function are assigned an immutable, concrete (non-abstract) type, and then compile an optimized version of that function on-the-fly . One source of pain in a lot of my Julia code is that unintentional type instability contributes to a lot of unnecessary performance penalties, and it takes quite a bit of poking and prodding before I figure out exactly which line is responsible. Forcing a check over the function would prevent these occurrences.

I also seem to have the problem of inadvertently calling functions that allocate and deallocate tiny amounts of memory on the innermost for loops.

(Then again, maybe nobody else has these issues and I'm just bad at deducing when AbstractVector can't be used.)

link
ihnorton 3617 days ago
It is unmaintained now, but you might want to have a look at [1], which builds on the type inference system to add some static checks. I believe there may also be some related work in [2].

> Then again, maybe nobody else has these issues and I'm just bad at deducing when AbstractVector can't be used.

Nope, not just you. This is definitely an issue.

[1] https://github.com/astrieanna/TypeCheck.jl [2] https://github.com/tonyhffong/Lint.jl

link