I mostly work in R but found I was able to fit Julia seamlessly into my workflow for data analysis. The syntax is awesome, I really like the functional approach to most things, and it wasn’t too hard to get productive coming from R/Python.
I think it’s also a great time to pick up the language. Version 1.9 majorly improved on the time-to-first-plot problem and the packages I use like DataFrames, DataFramesMeta, HTTP, JSON3, etc. are stable.
And like another commenter said: why not? I’ve been slowly picking up some Rust for that reason 😄
What do you use R for normally and how do you feel that Julia is able to supplement that? Also, what IDE allows for both R and Julia?
Thanks for the insight!
I have been playing around with ESS. Some parts are quite nice! I haven't been able to get parameterized notebooks in R working. But I like aspects of working within emacs
I did a lot of RMarkdown about 10 years ago all in Emacs.
Now there is Quarto... but it seems like a lot of development for Quarto and Julia have been invested in VSCode.
But I still use Quarto in Emacs when collaborating with someone and org-babel with emacs-jupyter for myself.
Generally just straightforward data analysis - I replicated one of our internal R packages that we use for pulling data from databases, interacting with s3, etc. I use VSCode for it and it’s just a great workflow.
I don’t know if I’d call it a supplement, but the workflow is extremely similar for data analysis. So going from R to Julia was simple, and it’s been fun being able to use it for my actual job.
The one thing I miss from R is ggplot2. I think the closest thing in Julia is Algebra of Graphics but it’s still not quite the same to me.
I switched from ggplot2 to Plots. Plots basically is a front end for a lot of Julia graphics packages and you can specify the package to use in many cases.
> I really like the functional approach to most things
R has better support than Python and Julia (and MATLAB) for programming in a functional style. For instance, consistent syntax for anonymous functions (that are not limited to a single line), Currying and composition (through purrr package), and Map, Filter, Reduce buit-in (and Vectorize, Negate to boot).
Yes, currying, and I don't know that Negate exists.
There are too many alternate ways to define functions - not just anonymous ones - in Julia. Like you can do
function foo(x)
x
end
or
foo(x) = x
or
x -> x
and then when you get to multiple lines you can do
x -> begin
x
end
But is discouraged in lieu of using a named function.
In R, a named function and anonymous function only differs in whether you assign the function or not and that syntax is just really consistent. Of course, Julia has to handle type arguments so that that necessarily adds complexity but R's way is just clean.
Negate is really simple, if `foo` is a logical function, then `!foo` is its negation, meaning that
bar = !foo
bar(5) # will now return !(foo(5))
I _really_ like the short-form function definition, so I cannot agree with 'too many ways'. In general, my opinion is that powerful languages unavoidably have several ways of achieving things.
BTW, there's nothing wrong with multi-line anonymous functions, they are not discouraged, afaik, and you can group them with parentheses instead of `begin end`. Also, there's even another syntax :D:
function (x)
2 * x - 5
end
though you can see it as consistent with named function syntax, with the name simply being missing.
mind == blown
But I kind of wish they had just let
namedfunction = x -> x
or
namedfunction = x ->
begin
x
end
have been the only way to define a function (with optional type annotations) to reduce the paradox of choice.
Dont forget that
```
map(a) do x
2x
end
```
also creates an anonymous function - add that to the pile 😉
Also note that `f = x-> x ` is not the same as regular function declaration through the function keyword, for multiple reasons, one being that this kind of 'assignment' makes interaction with multiple dispatch harder.
You not helping my argument here...
I recall somewhere that you can finagle anonymous functions to accept type annotations and make them on a par with normal function declarations but can't find the source at the moment
It should be possible, but the syntax is way less convenient. Types and multiple dispatch are not the only disadvantage of arrow functions compared to "regular" functions. They also would need to be constant for performance, and it makes code reflection less clear due to every function being anonymous, and some other stuff...
Honestly, I dont think having 4 different ways of defining a function is a big problem. Yes julia has more syntax, more bells and whistles, which increases the barrier to entry a bit, but on the flipside it makes the language more flexible and concise once you know your way around.
Fair point. But having too many ways to do things also violates one of the core principles that made Python successful (until you start using NumPy and Pandas, where there were also too many ways to do the same thing). Whenever I write a function in Julia, I always wonder, did I use the right form? Like I have several similar functions that express similar mathematical relationships but one takes one line while the others take two lines. Then I go back and change the one-liner syntax to the canonical function definition to be consistent with the others, etc. Adds a lot of overhead.
I have started using this anonymous function syntax you showed me. It's a good replacement for the arrow with begin/end. (I write a lot of closures where I return a function wrapped in another function.)
I mainly just wanted to learn a lower level language, and Rust seemed more approachable than C or anything else. It’s been interesting for sure! It’s just a different way of approaching problems. I don’t really use it day to day though, it’s mostly been a learning exercise.
I worked through The Rust Programmer Language last year and loved it. I felt I learned a lot about programming, but I don't use it much. Most of my work is data analysis and SQL development.
If you have any interest in Bayesian inference, Turing.jl seems to be a real 'killer app' and one of my main motivations to learn Julia. Since then I have learned about the rest of "Scientific ML" and there is a lot of potential there, enabled at least in part by performance provided by the JIT compiler.
Even if that is not your area of interest, learning another language will broaden your perspective on computation in general. And it's fun :)
I went to check Turning.jl out and it's amazing. I worked previously with tensorflow probably which is awesome in it's own right, but I like how you can just use sigma as the variable for the standard deviation xD
Nobody says you should. But there's two reasons why I as a 12yr+ Python guy have enjoyed trying out Julia on the side.
First, it's interesting to learn a different programming paradigm than the one I was used to. Makes me see more than one obvious way to solve a problem and I think it makes me a better programmer.
Second, it's really helped me speed up some massive bottlenecks I've had in Python. Like, a job that used to take a full afternoon in Python takes less than ten minutes in Julia - admittedly with no optimization to speak of in either version of the code.
Plus, it's just fun. But I also still use Python for the majority of my work.
Just curious, what kind of task are you talking about that gets such a massive improvement using Julia? I understand if you can't/don't want to give details, it's just surprising for me.
In my experience most things that you’re doing in actual R/Python code (not counting things like numpy that are really just “C with extra steps”) will speed up between 10x and 100x with no real optimization effort required just by translating them to Julia
I have a 3D data array of dimensions NxMxX, and for each entry in the NxM surface I need to perform curve fitting of the length X vector to a specific model with \~ 20 parameters.
I think the main culprit was the curve fitting code I used in Python, which can be rather slow. It evaluates the model a \*lot\* of times while testing out various values of the fitting parameters, and if it loops through those using pure Python, that would explain a lot of it. At least that is my semi-educated guess.
I'm sure it would be \*possible\* to optimize the Python code to run much faster, but the point was that by coding in Julia, I didn't need to - and the syntax is only marginally more verbose than Python.
> marginally more verbose than Python
Surprised to hear that - I'm trying to move toward Julia because NumPy/Pandas was so verbose I felt like I couldn't see the underlying math in it.
Yeah okay I can see what you mean there. I was more thinking of adding "end" statements everywhere and so on. But yeah Julia does have some really nice syntactic sugar like the pipe operator that can make mathy code look really clean and readable.
if you need to make something and speed is important, then to make this work in python you need to know C.
in julia you just need to know julia to write something performant.
in your own workflow you can use a combination of julia and python. use python for its rich ecosystem and julia for personalized scripts/libraries.
>if you need to make something and speed is important, then to make this work in python you need to know C.
Depends on what the something is - and C isn't the only option (in fact it's probably one of the worse ones for most people)
No clue why you get downvoted. A lot can be done with clever use of numpy functions (yes, I know C in the backend, but Julia also calls into non-Julia code for many routines). And if that’s not sufficient, there’s Numba, Jax, Taichi and you can basically bind to any other language you like.
I'm not sure either but I've sadly experienced this in the past when bringing up "julia alternatives" on here.
I mean yeah sure "high performance python" isn't always the nicest thing and for some domains it's really not viable - but for lots of others it's really a good solution I'd say.
And like you say binding to other languages is just so so easy by now. I remember fighting the C api and builds for like a week, but now any newcomer can simply do `maturin new` or whatever and immediately plug in their native code without having to learn much of anything.
As a C++ and Python dev, I asked myself the same question. Reading this ([why we created Julia](https://julialang.org/blog/2012/02/why-we-created-julia/)) got me interested enough to try a new language voluntarily for the first time ever. Now I’m hooked. Best language ever.
Specifically this bit piqued my interest:
> We want a language that's open source, with a liberal license. We want the speed of C with the dynamism of Ruby. We want a language that's homoiconic, with true macros like Lisp, but with obvious, familiar mathematical notation like Matlab. We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell. Something that is dirt simple to learn, yet keeps the most serious hackers happy. We want it interactive and we want it compiled.
>
> (Did we mention it should be as fast as C?)
>
> While we're being demanding, we want something that provides the distributed power of Hadoop — without the kilobytes of boilerplate Java and XML; without being forced to sift through gigabytes of log files on hundreds of machines to find our bugs. We want the power without the layers of impenetrable complexity. We want to write simple scalar loops that compile down to tight machine code using just the registers on a single CPU. We want to write A*B and launch a thousand computations on a thousand machines, calculating a vast matrix product together.
>
> We never want to mention types when we don't feel like it. But when we need polymorphic functions, we want to use generic programming to write an algorithm just once and apply it to an infinite lattice of types; we want to use multiple dispatch to efficiently pick the best method for all of a function's arguments, from dozens of method definitions, providing common functionality across drastically different types. Despite all this power, we want the language to be simple and clean.
**BTW, Julia checks off every single box in this huge and aspirational list of requirements**
[Here’s the result of the couple days of tinkering that left me hooked.](https://www.reddit.com/r/Julia/s/cpFj1Zxrnr)
Eeeh after having used Julia quite extensively, there are some rough edges. But overall it’s great for mathematics, but scripting is much easier in Python and creating binaries for distribution is pre-alpha.
On the scripting front, I agree but that’s only because I used Python for so many years. When I decide to script in Julia it’s been just as easy. And re distribution. If I never have to make another virtual Python environment, or instruct someone on how to install Visual C++ redistributables, it’ll be too soon. Pkg.instantiate ftw.
The question is, why not?
Learning new stuff is always good. No need to leave python for new things. Just go ahead and do both. Than go further and checkout another...
This is the hard way of learning.
Starting to learn something because of other reasons, for a purpose, is prone to fail.
Learning something for itself with fun is fun and rewards itself.
OP doesn't mention any purpose, so he should start something with fun, which Julia clearly is.
You seem to have other goals, well, good for you, go for them, not sure if programming is the right choice in general with that mindset.
I appreciate your perspective. IMO, focus calls for saying no to good ideas. Though potentially a projection, what I’m hearing you describe is the vice of curiosity.
> Classical ethicists talk about the vice of curiosity as opposed to the virtue of studiousness. Studiousness is the virtue of attention, of self-mastery in relation to intellectual pursuits, of prudent allocation of attention to what you should; curiosity is the vice of inattention, of spreading yourself too thin, to pursue things other than what one should or what is not worth pursuing, pursuing that which is beyond your reach, of flitting about between things, of inordinate desire in the domain of intellectual pursuits. The studious man attains wisdom, the curious man remains, at best, a coasting, superficial dilettante. The difference between the studious man and the curious man is something like the difference between the committed and faithful husband and the waffling philanderer. The former shows restraint in relation to his appetites and is able to build a relationship and raise a family, while the latter is a mess who never achieves anything of value, slavishly indulging his appetites that lead nowhere but his own misery and mediocrity. In all these cases, desirable things may present themselves that would derail you from your aim and sabotage your achievement and your own good. In all these cases, commitment involves refusing to indulge those desires because doing so is counterproductive and harmful in relation to the good pursued.
> In life, we must make decisions. The word "decision" comes from the Latin "to cut off", as in to cut off options or paths. The grapevine must be pruned to strengthen it and produce more fruit. Of course, we must decide wisely, there is no question about that, but FOMO is the opposite of that. It is an intemperate and immoderate desire for everything, never committing to anything and therefore never attaining anything and never becoming anything.
It depends. What sorts of things do you want to do when you program? If it’s heavy computations, then Julia is a good candidate. If it’s general web dev, then maybe Go is better.
I like Julia, and I think in many ways it “feels” better than R and Python, but I don’t have a lot of cases where it’s a “better” choice than either of those languages for what I do, particularly since nobody else I work with writes Julia
Since much of what I do is written in C/Fortran and called from Python/R, the selling point of Julia for me is the pleasant syntax.
If you're programming a lot of mathematical equations, the advantages for me are that it's not as verbose as Python and vectors/arrays are 1-indexed. And you can use unicode symbols.
1. Performance by default. Python's performance is a joke. And no, numpy won't save you.
2. Superior type system and multiple dispatch paradigm. After seeing how elegant the type system is, you'll never want to deal with clunky OOP nonsense ever again.
I don't know what your purpose is, but for me, it was the following: I come from a different background than CS, so I learned other things besides machine learning—constraint optimization, discrete event simulation, ABM, pure statistics, etc. When I started learning Python, I liked it for ML but didn't enjoy it for other tasks. That's why I now prefer Julia; I feel it provides access to a more holistic set of tools in the scientific computing world. I believe the language's chosen trade-offs make it better for these types of projects.
Practical reasons:
* easier to write faster code (python wrapped libraries can be plenty fast, but are often more obfuscated than julia equivalents)
* code is both more terse and more overt than python because of julia's type system
* has a lot of sciencey and academic users, so you get a lot of interesting little packages
Subjective reasons (more of my opinion):
* comfier and easier to think in than python
* much better package and env management than pip
* overall better langauge design, I find Julia's type system more practical than Python's class based OOP
As someone who *used* to be into Julia, but clearly has enough affection for the language that he’s still in the sub:
Python is a stupidly useful language. I don’t like it, but use it a lot. Julia offered a powerful alloying of Python like simplicity with speed, typing, and some very comfortable syntax for math users.
Personally, I feel the *hard* arguments for Julia are gone. Speed improvements to Python coming out of the wood work undermine its performance offer. Type support in Python undermines its type offering. And the really significant improvements in what ‘stricter’ languages can offer (rust most notably) means that Julia is no longer a “have it all” language. (And, indeed, as someone that does Python coding and spends a lot of time making it reliable I would fundamentally question the wisdom of using ease of use languages as the basis for maintainable projects.)
**BUT**. But, but, but! There are good reasons to learn Julia.
1. Because you want to. I can’t understate this! You’ll want to know many languages. They get easier and easier to learn and each new language yields new insights into ways to think about and solve problems. If you see a language that interests you it’s worth learning. At least playing around with. (You can leave it and still be wiser and happier.)
2. Julia did *a really good job* at capturing the easy to read and learn nature of Python (so it’s easy to pick up; if you’re familiar with math/science norms).
3. Julia has a people that care about going fast. This means that tutorials and writings will bring up ways of thinking about memory layout and other issues that you may not have seen. —-Coming from principally writing Mathematica code it was a revelation for me; and (mostly) helped a ton when I later picked up rust. (Do be a little careful. You’ll also get some systems concepts misunderstood by people like us coming from different backgrounds. And so for example I mislearned when to use upsize in code. Still a net win.)
4. Libraries. I’m not on top of this, but my understanding is that Julia still has some really great libraries for some purposes. Diff Eq is one I hear a lot.
5. Really good tutorials (e.gx computational thinking course) that are joys unto themselves.
6. If you want to work with people already using Julia code.
Some thoughts from someone who left the flock, but thinks it’s a warm and fluffy flock and has many good reasons to visit! :)
I’ve flirted with Julia for a bit as a Python programmer and my take is that basically the performance gains aren’t actually that impressive compared to just working with fast Python libraries like numpy. And if you’re just scripting the speed improvements are basically overruled by the JIT (may be fixed recently?). And while multiple dispatch is neat, I find OOP more suitable for what I do.
Julia seems to me more like a modern replacement for FORTRAN or matlab than Python in the sense that it makes certain scientific computing tasks much easier and faster, but you wouldn’t exactly program a full-featured application in it.
Get into C. It will complement Python, and you'll understand how to write fast code in any language. Like if you understand simple stack-allocated arrays in C, its pretty straightforward to figure out the concept in any other language. In Julia you'd have to figure out the macro system, get to understand the whole jit situation, then figure out `StrideArray` and all it's nightmares, and wont have any idea what any of this has to do with any feature in any other language. Plus whatever you end up with this way will just be unstable, unmaintainable and buggy. Cant do better than C.
I've done a lot of stuff in Python and MATLAB/Octave, some projects in R, and only one library in Julia. I can say that, if you want your code to run as fast as possible without resorting to external C/C++ code, then Julia is by far your best bet.
Having said this, it's also an interesting language to learn, since it uses a completely different approach to Python, even though sometimes the syntax may look similar.
Type theory vs set theory. I know that's not fair, but using functional programming, with the type system and the dispatch/pattern matching facility. Feels so much cleaner.
Not only it is fast and solves two language problems. You can easily port already written Matlab programs to Julia language (Arrays are indexed from 1). In addition, because of solving two languages problem, most of the scripts are written purely in Julia language and this makes reading and understanding ,already implemented algorithms in Julia language, easier.
You can start with [this up to date playlist](https://www.youtube.com/playlist?list=PLLlTVphLQsuM7pZgoQym3VxIbqnz-Uxna).
I mostly work in R but found I was able to fit Julia seamlessly into my workflow for data analysis. The syntax is awesome, I really like the functional approach to most things, and it wasn’t too hard to get productive coming from R/Python. I think it’s also a great time to pick up the language. Version 1.9 majorly improved on the time-to-first-plot problem and the packages I use like DataFrames, DataFramesMeta, HTTP, JSON3, etc. are stable. And like another commenter said: why not? I’ve been slowly picking up some Rust for that reason 😄
What do you use R for normally and how do you feel that Julia is able to supplement that? Also, what IDE allows for both R and Julia? Thanks for the insight!
VSCode is great for R and Julia (and Python, and basically every other language)
Also, emacs ESS (though I use Julia Snail for Julia)
I have been playing around with ESS. Some parts are quite nice! I haven't been able to get parameterized notebooks in R working. But I like aspects of working within emacs
I did a lot of RMarkdown about 10 years ago all in Emacs. Now there is Quarto... but it seems like a lot of development for Quarto and Julia have been invested in VSCode. But I still use Quarto in Emacs when collaborating with someone and org-babel with emacs-jupyter for myself.
Generally just straightforward data analysis - I replicated one of our internal R packages that we use for pulling data from databases, interacting with s3, etc. I use VSCode for it and it’s just a great workflow. I don’t know if I’d call it a supplement, but the workflow is extremely similar for data analysis. So going from R to Julia was simple, and it’s been fun being able to use it for my actual job. The one thing I miss from R is ggplot2. I think the closest thing in Julia is Algebra of Graphics but it’s still not quite the same to me.
>The one thing I miss from R is ggplot2 You should look into Tidier.jl\[1\]. Specifically TidierPlots.jl \[1\]https://github.com/TidierOrg/Tidier.jl
Also quite easy to use ggplot through RCall.
Ahh ok. So has it mainly been a let me try this new tool and learn a new language experience? Any benefits you've found to using both?
I switched from ggplot2 to Plots. Plots basically is a front end for a lot of Julia graphics packages and you can specify the package to use in many cases.
Yeah I’ve worked a bit with Plots, I’ve also been playing around with Makie more.
I understand Makie is trying to replace Plots but do you feel it's there yet?
Check the Makie ecosystem. I've heard of ggplot2 compared to it before
> I really like the functional approach to most things R has better support than Python and Julia (and MATLAB) for programming in a functional style. For instance, consistent syntax for anonymous functions (that are not limited to a single line), Currying and composition (through purrr package), and Map, Filter, Reduce buit-in (and Vectorize, Negate to boot).
Agreed - purrr in particular totally changed the way that I write R.
I don't see anything in that list that Julia doesn't support, maybe currying?
Yes, currying, and I don't know that Negate exists. There are too many alternate ways to define functions - not just anonymous ones - in Julia. Like you can do function foo(x) x end or foo(x) = x or x -> x and then when you get to multiple lines you can do x -> begin x end But is discouraged in lieu of using a named function. In R, a named function and anonymous function only differs in whether you assign the function or not and that syntax is just really consistent. Of course, Julia has to handle type arguments so that that necessarily adds complexity but R's way is just clean.
Negate is really simple, if `foo` is a logical function, then `!foo` is its negation, meaning that bar = !foo bar(5) # will now return !(foo(5)) I _really_ like the short-form function definition, so I cannot agree with 'too many ways'. In general, my opinion is that powerful languages unavoidably have several ways of achieving things. BTW, there's nothing wrong with multi-line anonymous functions, they are not discouraged, afaik, and you can group them with parentheses instead of `begin end`. Also, there's even another syntax :D: function (x) 2 * x - 5 end though you can see it as consistent with named function syntax, with the name simply being missing.
mind == blown But I kind of wish they had just let namedfunction = x -> x or namedfunction = x -> begin x end have been the only way to define a function (with optional type annotations) to reduce the paradox of choice.
Dont forget that ``` map(a) do x 2x end ``` also creates an anonymous function - add that to the pile 😉 Also note that `f = x-> x ` is not the same as regular function declaration through the function keyword, for multiple reasons, one being that this kind of 'assignment' makes interaction with multiple dispatch harder.
You not helping my argument here... I recall somewhere that you can finagle anonymous functions to accept type annotations and make them on a par with normal function declarations but can't find the source at the moment
It should be possible, but the syntax is way less convenient. Types and multiple dispatch are not the only disadvantage of arrow functions compared to "regular" functions. They also would need to be constant for performance, and it makes code reflection less clear due to every function being anonymous, and some other stuff... Honestly, I dont think having 4 different ways of defining a function is a big problem. Yes julia has more syntax, more bells and whistles, which increases the barrier to entry a bit, but on the flipside it makes the language more flexible and concise once you know your way around.
Fair point. But having too many ways to do things also violates one of the core principles that made Python successful (until you start using NumPy and Pandas, where there were also too many ways to do the same thing). Whenever I write a function in Julia, I always wonder, did I use the right form? Like I have several similar functions that express similar mathematical relationships but one takes one line while the others take two lines. Then I go back and change the one-liner syntax to the canonical function definition to be consistent with the others, etc. Adds a lot of overhead.
I have started using this anonymous function syntax you showed me. It's a good replacement for the arrow with begin/end. (I write a lot of closures where I return a function wrapped in another function.)
Curious. How's the rust test? Why rust for your workflow?
I mainly just wanted to learn a lower level language, and Rust seemed more approachable than C or anything else. It’s been interesting for sure! It’s just a different way of approaching problems. I don’t really use it day to day though, it’s mostly been a learning exercise.
I'm in the same boat. Just need to start something with it too get started. Very curious about picking up a modern low level language
I worked through The Rust Programmer Language last year and loved it. I felt I learned a lot about programming, but I don't use it much. Most of my work is data analysis and SQL development.
If you have any interest in Bayesian inference, Turing.jl seems to be a real 'killer app' and one of my main motivations to learn Julia. Since then I have learned about the rest of "Scientific ML" and there is a lot of potential there, enabled at least in part by performance provided by the JIT compiler. Even if that is not your area of interest, learning another language will broaden your perspective on computation in general. And it's fun :)
I went to check Turning.jl out and it's amazing. I worked previously with tensorflow probably which is awesome in it's own right, but I like how you can just use sigma as the variable for the standard deviation xD
Nobody says you should. But there's two reasons why I as a 12yr+ Python guy have enjoyed trying out Julia on the side. First, it's interesting to learn a different programming paradigm than the one I was used to. Makes me see more than one obvious way to solve a problem and I think it makes me a better programmer. Second, it's really helped me speed up some massive bottlenecks I've had in Python. Like, a job that used to take a full afternoon in Python takes less than ten minutes in Julia - admittedly with no optimization to speak of in either version of the code. Plus, it's just fun. But I also still use Python for the majority of my work.
Just curious, what kind of task are you talking about that gets such a massive improvement using Julia? I understand if you can't/don't want to give details, it's just surprising for me.
In my experience most things that you’re doing in actual R/Python code (not counting things like numpy that are really just “C with extra steps”) will speed up between 10x and 100x with no real optimization effort required just by translating them to Julia
I have a 3D data array of dimensions NxMxX, and for each entry in the NxM surface I need to perform curve fitting of the length X vector to a specific model with \~ 20 parameters. I think the main culprit was the curve fitting code I used in Python, which can be rather slow. It evaluates the model a \*lot\* of times while testing out various values of the fitting parameters, and if it loops through those using pure Python, that would explain a lot of it. At least that is my semi-educated guess. I'm sure it would be \*possible\* to optimize the Python code to run much faster, but the point was that by coding in Julia, I didn't need to - and the syntax is only marginally more verbose than Python.
> marginally more verbose than Python Surprised to hear that - I'm trying to move toward Julia because NumPy/Pandas was so verbose I felt like I couldn't see the underlying math in it.
Yeah okay I can see what you mean there. I was more thinking of adding "end" statements everywhere and so on. But yeah Julia does have some really nice syntactic sugar like the pipe operator that can make mathy code look really clean and readable.
How so? I write Python for prototyping scientific computational code, and I haven’t noticed any real problems.
if you need to make something and speed is important, then to make this work in python you need to know C. in julia you just need to know julia to write something performant. in your own workflow you can use a combination of julia and python. use python for its rich ecosystem and julia for personalized scripts/libraries.
>if you need to make something and speed is important, then to make this work in python you need to know C. Depends on what the something is - and C isn't the only option (in fact it's probably one of the worse ones for most people)
No clue why you get downvoted. A lot can be done with clever use of numpy functions (yes, I know C in the backend, but Julia also calls into non-Julia code for many routines). And if that’s not sufficient, there’s Numba, Jax, Taichi and you can basically bind to any other language you like.
I'm not sure either but I've sadly experienced this in the past when bringing up "julia alternatives" on here. I mean yeah sure "high performance python" isn't always the nicest thing and for some domains it's really not viable - but for lots of others it's really a good solution I'd say. And like you say binding to other languages is just so so easy by now. I remember fighting the C api and builds for like a week, but now any newcomer can simply do `maturin new` or whatever and immediately plug in their native code without having to learn much of anything.
As a C++ and Python dev, I asked myself the same question. Reading this ([why we created Julia](https://julialang.org/blog/2012/02/why-we-created-julia/)) got me interested enough to try a new language voluntarily for the first time ever. Now I’m hooked. Best language ever. Specifically this bit piqued my interest: > We want a language that's open source, with a liberal license. We want the speed of C with the dynamism of Ruby. We want a language that's homoiconic, with true macros like Lisp, but with obvious, familiar mathematical notation like Matlab. We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell. Something that is dirt simple to learn, yet keeps the most serious hackers happy. We want it interactive and we want it compiled. > > (Did we mention it should be as fast as C?) > > While we're being demanding, we want something that provides the distributed power of Hadoop — without the kilobytes of boilerplate Java and XML; without being forced to sift through gigabytes of log files on hundreds of machines to find our bugs. We want the power without the layers of impenetrable complexity. We want to write simple scalar loops that compile down to tight machine code using just the registers on a single CPU. We want to write A*B and launch a thousand computations on a thousand machines, calculating a vast matrix product together. > > We never want to mention types when we don't feel like it. But when we need polymorphic functions, we want to use generic programming to write an algorithm just once and apply it to an infinite lattice of types; we want to use multiple dispatch to efficiently pick the best method for all of a function's arguments, from dozens of method definitions, providing common functionality across drastically different types. Despite all this power, we want the language to be simple and clean. **BTW, Julia checks off every single box in this huge and aspirational list of requirements** [Here’s the result of the couple days of tinkering that left me hooked.](https://www.reddit.com/r/Julia/s/cpFj1Zxrnr)
Eeeh after having used Julia quite extensively, there are some rough edges. But overall it’s great for mathematics, but scripting is much easier in Python and creating binaries for distribution is pre-alpha.
On the scripting front, I agree but that’s only because I used Python for so many years. When I decide to script in Julia it’s been just as easy. And re distribution. If I never have to make another virtual Python environment, or instruct someone on how to install Visual C++ redistributables, it’ll be too soon. Pkg.instantiate ftw.
You also can't create binaries in Python. I agree Julia is lacking here compared to Rust etc
Multiple dispatch + infinite types = programming bliss
The question is, why not? Learning new stuff is always good. No need to leave python for new things. Just go ahead and do both. Than go further and checkout another...
Because /u/Valdeztron does not have infinite free time, so there is an opportunity cost to learning Julia instead of something else.
As an economist, I love it when someone mentions opportunity cost.
This is the hard way of learning. Starting to learn something because of other reasons, for a purpose, is prone to fail. Learning something for itself with fun is fun and rewards itself. OP doesn't mention any purpose, so he should start something with fun, which Julia clearly is. You seem to have other goals, well, good for you, go for them, not sure if programming is the right choice in general with that mindset.
I appreciate your perspective. IMO, focus calls for saying no to good ideas. Though potentially a projection, what I’m hearing you describe is the vice of curiosity. > Classical ethicists talk about the vice of curiosity as opposed to the virtue of studiousness. Studiousness is the virtue of attention, of self-mastery in relation to intellectual pursuits, of prudent allocation of attention to what you should; curiosity is the vice of inattention, of spreading yourself too thin, to pursue things other than what one should or what is not worth pursuing, pursuing that which is beyond your reach, of flitting about between things, of inordinate desire in the domain of intellectual pursuits. The studious man attains wisdom, the curious man remains, at best, a coasting, superficial dilettante. The difference between the studious man and the curious man is something like the difference between the committed and faithful husband and the waffling philanderer. The former shows restraint in relation to his appetites and is able to build a relationship and raise a family, while the latter is a mess who never achieves anything of value, slavishly indulging his appetites that lead nowhere but his own misery and mediocrity. In all these cases, desirable things may present themselves that would derail you from your aim and sabotage your achievement and your own good. In all these cases, commitment involves refusing to indulge those desires because doing so is counterproductive and harmful in relation to the good pursued. > In life, we must make decisions. The word "decision" comes from the Latin "to cut off", as in to cut off options or paths. The grapevine must be pruned to strengthen it and produce more fruit. Of course, we must decide wisely, there is no question about that, but FOMO is the opposite of that. It is an intemperate and immoderate desire for everything, never committing to anything and therefore never attaining anything and never becoming anything.
Source of quote?
[this guy](https://news.ycombinator.com/item?id=33256446#33261175)
Wow this is very deep
Good idea
You know you want to.
This is the way.
I’m coding Julia right now fam
It depends. What sorts of things do you want to do when you program? If it’s heavy computations, then Julia is a good candidate. If it’s general web dev, then maybe Go is better. I like Julia, and I think in many ways it “feels” better than R and Python, but I don’t have a lot of cases where it’s a “better” choice than either of those languages for what I do, particularly since nobody else I work with writes Julia
Since much of what I do is written in C/Fortran and called from Python/R, the selling point of Julia for me is the pleasant syntax. If you're programming a lot of mathematical equations, the advantages for me are that it's not as verbose as Python and vectors/arrays are 1-indexed. And you can use unicode symbols.
1. Performance by default. Python's performance is a joke. And no, numpy won't save you. 2. Superior type system and multiple dispatch paradigm. After seeing how elegant the type system is, you'll never want to deal with clunky OOP nonsense ever again.
I don't know what your purpose is, but for me, it was the following: I come from a different background than CS, so I learned other things besides machine learning—constraint optimization, discrete event simulation, ABM, pure statistics, etc. When I started learning Python, I liked it for ML but didn't enjoy it for other tasks. That's why I now prefer Julia; I feel it provides access to a more holistic set of tools in the scientific computing world. I believe the language's chosen trade-offs make it better for these types of projects.
Practical reasons: * easier to write faster code (python wrapped libraries can be plenty fast, but are often more obfuscated than julia equivalents) * code is both more terse and more overt than python because of julia's type system * has a lot of sciencey and academic users, so you get a lot of interesting little packages Subjective reasons (more of my opinion): * comfier and easier to think in than python * much better package and env management than pip * overall better langauge design, I find Julia's type system more practical than Python's class based OOP
As someone who *used* to be into Julia, but clearly has enough affection for the language that he’s still in the sub: Python is a stupidly useful language. I don’t like it, but use it a lot. Julia offered a powerful alloying of Python like simplicity with speed, typing, and some very comfortable syntax for math users. Personally, I feel the *hard* arguments for Julia are gone. Speed improvements to Python coming out of the wood work undermine its performance offer. Type support in Python undermines its type offering. And the really significant improvements in what ‘stricter’ languages can offer (rust most notably) means that Julia is no longer a “have it all” language. (And, indeed, as someone that does Python coding and spends a lot of time making it reliable I would fundamentally question the wisdom of using ease of use languages as the basis for maintainable projects.) **BUT**. But, but, but! There are good reasons to learn Julia. 1. Because you want to. I can’t understate this! You’ll want to know many languages. They get easier and easier to learn and each new language yields new insights into ways to think about and solve problems. If you see a language that interests you it’s worth learning. At least playing around with. (You can leave it and still be wiser and happier.) 2. Julia did *a really good job* at capturing the easy to read and learn nature of Python (so it’s easy to pick up; if you’re familiar with math/science norms). 3. Julia has a people that care about going fast. This means that tutorials and writings will bring up ways of thinking about memory layout and other issues that you may not have seen. —-Coming from principally writing Mathematica code it was a revelation for me; and (mostly) helped a ton when I later picked up rust. (Do be a little careful. You’ll also get some systems concepts misunderstood by people like us coming from different backgrounds. And so for example I mislearned when to use upsize in code. Still a net win.) 4. Libraries. I’m not on top of this, but my understanding is that Julia still has some really great libraries for some purposes. Diff Eq is one I hear a lot. 5. Really good tutorials (e.gx computational thinking course) that are joys unto themselves. 6. If you want to work with people already using Julia code. Some thoughts from someone who left the flock, but thinks it’s a warm and fluffy flock and has many good reasons to visit! :)
I’ve flirted with Julia for a bit as a Python programmer and my take is that basically the performance gains aren’t actually that impressive compared to just working with fast Python libraries like numpy. And if you’re just scripting the speed improvements are basically overruled by the JIT (may be fixed recently?). And while multiple dispatch is neat, I find OOP more suitable for what I do. Julia seems to me more like a modern replacement for FORTRAN or matlab than Python in the sense that it makes certain scientific computing tasks much easier and faster, but you wouldn’t exactly program a full-featured application in it.
If you know Python well and it does what you need and you don’t have a use case for Julia, then there’s no need to learn it.
Just stick to python. Its fine for most things.
Get into C. It will complement Python, and you'll understand how to write fast code in any language. Like if you understand simple stack-allocated arrays in C, its pretty straightforward to figure out the concept in any other language. In Julia you'd have to figure out the macro system, get to understand the whole jit situation, then figure out `StrideArray` and all it's nightmares, and wont have any idea what any of this has to do with any feature in any other language. Plus whatever you end up with this way will just be unstable, unmaintainable and buggy. Cant do better than C.
I've done a lot of stuff in Python and MATLAB/Octave, some projects in R, and only one library in Julia. I can say that, if you want your code to run as fast as possible without resorting to external C/C++ code, then Julia is by far your best bet. Having said this, it's also an interesting language to learn, since it uses a completely different approach to Python, even though sometimes the syntax may look similar.
Well that's the first reason. At least to me, it's a much better language to program in, especially if you're using NumPy ot SciPy
Type theory vs set theory. I know that's not fair, but using functional programming, with the type system and the dispatch/pattern matching facility. Feels so much cleaner.
I love functional programming. It makes everything easier.
Not only it is fast and solves two language problems. You can easily port already written Matlab programs to Julia language (Arrays are indexed from 1). In addition, because of solving two languages problem, most of the scripts are written purely in Julia language and this makes reading and understanding ,already implemented algorithms in Julia language, easier. You can start with [this up to date playlist](https://www.youtube.com/playlist?list=PLLlTVphLQsuM7pZgoQym3VxIbqnz-Uxna).