Rendered at 07:31:22 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
prof-dr-ir 28 minutes ago [-]
Julia is fantastic if you do numerical work and want to write out your inner loops explicitly without sacrificing too much performance, either for pedagogical reasons or because you want to fiddle with the algorithm.
It is a lot of fun to start from an empty file, add maybe an import LinearAlgebra, and develop things like a convolutional neural network or a Markov-chain Monte Carlo algorithm completely from scratch. And then it is very rewarding to have such a program be fast enough (looking at Python here) to train on the MNIST dataset or find reasonable estimates for critical exponents.
I am not sure there are languages better suited than Julia for these kind of things.
ashton314 3 hours ago [-]
Julia is my go-to when I need a fast language that I can reason about in a functional way. The type system is fine, the pattern matching is pretty darn good, the metaprogramming story could be significantly better but it’s not bad and boy howdy it’s fast. So stinking fast.
maxall4 4 hours ago [-]
I really want to like Julia. It has a nice type system, a good ecosystem, reasonable syntax, and it’s far faster than Python. But there are several issues with its DX that prevent me from using it: the most severe of which being the complete lack of a cache for the JIT (or JIT like system), inducing multi second compile times for scripts that run in <100ms. There are some external packages that try to solve this issue, but they are far from first-party quality, and, in my experience, are quite buggy.
(I last tried Julia a few years ago; perhaps this has been improved since?)
adgjlsfhk1 4 hours ago [-]
a between session cache had been merged for 1.14 (release expected within 6-12 months).
JanisErdmanis 3 hours ago [-]
What is this magic, how does it differ from PkgImages Julia already has?
Joel_Mckay 39 minutes ago [-]
> tried Julia a few years ago; perhaps this has been improved since?
The pre-compiled binary outputs are much smaller, and load a lot faster. =3
bandrami 4 hours ago [-]
[dead]
hn_submit 1 hours ago [-]
Safe for BASIC I believe it's very difficult to make a programming language which is easy-to-learn like the creators of Julia proclaim. It may be somewhat easier to implement specific scientific functionality in the language but does that warrant the creation of yet another language?
Scanning the language it doesn't strike me at all as "simple."
Joel_Mckay 33 minutes ago [-]
Julia abstracts entire programming paradigms in single characters.
BASIC "made simple things easy, and hard things impossible..."
Julia is the first language I've seen in years that implicitly abstracts parallelism cleanly. =3
Alien1Being 4 hours ago [-]
Thought that it would be about Lisp....
manwe150 4 hours ago [-]
It was about lisp ;)
Secret mode: ./julia —-lisp
4 hours ago [-]
muragekibicho 4 hours ago [-]
Julia uses 1-based indexing. It's competes with R and Matlab for the same set of users. Both R and Julia have their core functions written in C++. Absolutely nothing new.
From my experience, grad students use Julia when their PI thinks a new programming language will help differentiate their next NSF proposal among vast funding requests.
adgjlsfhk1 4 hours ago [-]
> Both R and Julia have their core functions written in C++. Absolutely nothing new.
imo this isn't really a good summary. Julia is one of the 3 languages to have done an exascale HPC run https://arxiv.org/pdf/2309.10292v1 (Fortran and C are the other 2). Some parts of the compiler are written in c++ (the llvm interface), but doing codegen with llvm is much more similar to C/Rust/Fortran than R/Matlab
skew-aberration 3 hours ago [-]
It kinda feels like Julia competes for the people who write the libraries for R and Matlab. Writing fast and elegant ODE solvers, etc in Julia seems to be easier than the others and they've attracted a lot of academics for that reason.
tonyarkles 2 hours ago [-]
I'm currently split between Python and Julia, having used R happily in the past for data analysis and Matlab for this and that in my EE program. For me, Julia crushes one niche that the rest of them are not good at: making the math look like the math.
If you've used something like SciPy or symbolic Matlab or Maxima or whatever, it always feels like I'm very carefully converting the equations I've scribbled down on paper into code and always a little nervous that I've accidentally split one variable into two names or used the wrong equality operator and am going to end up hating life, or accidentally assigned x = sp.Symbol("y") somewhere.
The Julia version is just plain beautiful. There's no ceremony other than the three @parameters, @variables, @mtkcompile macros. It lives in its own little world where you don't have to constantly watch your back to make sure you haven't duplicated a symbol somewhere.
hasley 52 minutes ago [-]
Getting linear algebra in a programming language close to math formulas was, for a long time, my reason to use Octave.
When I first read about Julia, I was really amazed - especially the type system with its multiple dispatching and not automatically converting between types (e.g., between integers and floats). Though, I do not know, how Julia is today.
Today, I use Python instead of Octave (or Julia) - just because it has a large ecosystem and is widely adopted. An additional advantage is that Python has much better OOP features than Octave had back then.
However, I wished Julia had the status that Python has today.
skew-aberration 36 minutes ago [-]
I definitely agree. And the common performance optimization metaprogramming (like 'do it this way for this type of input') works so much better with multiple dispatch, tag structs. Way ahead of C++ expression templates and much more pleasant than macros, concepts, etc.
Some of the lower-level APIs like those for concurrency were quite poorly thought out though, at least when I last used Julia. Condition variables don't have equivalent of pthread_timed_wait. Condition variables and channels APIs are not well integrated, design wise. I found so many such issues that it convinced me Julia wasn't general purpose enough. It felt like the features were a bit half-baked and had been hacked together by someone who knew their value but lacked the deep experience/knowledge to pull them all together into a single cohesive vision. Same issues as python, POSIX, etc.
tonyarkles 13 minutes ago [-]
Yeah, the nifty part is instead of trying to write your whole multi-threaded high performance tool in Julia, there is excellent support for taking the math work you’ve done and codegen C out of it. Am very happily using that in prod today for a thing and it works awesome.
Joel_Mckay 4 minutes ago [-]
Julia is fun, but is still mostly an academic language. Very few shops will use it in the private sector. Python is also more common as a prototype integration language, and rarely seen in industrial areas.
If you are an EE that wants to remain employed... than make sure you have documented hours with C/C++, Verilog on Zynq, and ladder logic for Rockwell automation products.
Best of luck =3
jhoechtl 37 minutes ago [-]
> Julia uses 1-based indexing.
That rules it out to become a successor to Python. It sounds reasonable until you start interacting with other libraries.
I do know the attemp to justify it for Lua and I don't buy it.
bretnach 3 hours ago [-]
Yet another example of MIT taking far too much credit for something...
slwvx 3 hours ago [-]
I've seen JuliaHub taking credit for all of Julia before. I don't think there's anything new in this article
It is a lot of fun to start from an empty file, add maybe an import LinearAlgebra, and develop things like a convolutional neural network or a Markov-chain Monte Carlo algorithm completely from scratch. And then it is very rewarding to have such a program be fast enough (looking at Python here) to train on the MNIST dataset or find reasonable estimates for critical exponents.
I am not sure there are languages better suited than Julia for these kind of things.
(I last tried Julia a few years ago; perhaps this has been improved since?)
The pre-compiled binary outputs are much smaller, and load a lot faster. =3
Scanning the language it doesn't strike me at all as "simple."
https://juliahep.github.io/Hands-on-Julia-for-particle-physi...
BASIC "made simple things easy, and hard things impossible..."
Julia is the first language I've seen in years that implicitly abstracts parallelism cleanly. =3
Secret mode: ./julia —-lisp
From my experience, grad students use Julia when their PI thinks a new programming language will help differentiate their next NSF proposal among vast funding requests.
imo this isn't really a good summary. Julia is one of the 3 languages to have done an exascale HPC run https://arxiv.org/pdf/2309.10292v1 (Fortran and C are the other 2). Some parts of the compiler are written in c++ (the llvm interface), but doing codegen with llvm is much more similar to C/Rust/Fortran than R/Matlab
https://docs.sciml.ai/ModelingToolkit/stable/tutorials/nonli...
If you've used something like SciPy or symbolic Matlab or Maxima or whatever, it always feels like I'm very carefully converting the equations I've scribbled down on paper into code and always a little nervous that I've accidentally split one variable into two names or used the wrong equality operator and am going to end up hating life, or accidentally assigned x = sp.Symbol("y") somewhere.
The Julia version is just plain beautiful. There's no ceremony other than the three @parameters, @variables, @mtkcompile macros. It lives in its own little world where you don't have to constantly watch your back to make sure you haven't duplicated a symbol somewhere.
When I first read about Julia, I was really amazed - especially the type system with its multiple dispatching and not automatically converting between types (e.g., between integers and floats). Though, I do not know, how Julia is today.
Today, I use Python instead of Octave (or Julia) - just because it has a large ecosystem and is widely adopted. An additional advantage is that Python has much better OOP features than Octave had back then.
However, I wished Julia had the status that Python has today.
Some of the lower-level APIs like those for concurrency were quite poorly thought out though, at least when I last used Julia. Condition variables don't have equivalent of pthread_timed_wait. Condition variables and channels APIs are not well integrated, design wise. I found so many such issues that it convinced me Julia wasn't general purpose enough. It felt like the features were a bit half-baked and had been hacked together by someone who knew their value but lacked the deep experience/knowledge to pull them all together into a single cohesive vision. Same issues as python, POSIX, etc.
If you are an EE that wants to remain employed... than make sure you have documented hours with C/C++, Verilog on Zynq, and ladder logic for Rockwell automation products.
Best of luck =3
That rules it out to become a successor to Python. It sounds reasonable until you start interacting with other libraries.
I do know the attemp to justify it for Lua and I don't buy it.