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
I have yet to hear a good argument for why the answer to "How do I get the third element of this array?" should be `arr[2]`
> Both R and Julia have their core functions written in C++. Absolutely nothing new.
What on earth are you talking about? This is at least a novel claim. Some deep parts of julia's compiler are written in C++ but that's about it. Nearly everything in the language is written in julia itself.
The only significant foreign codebases in the language are
* LLVM
* OpenBLAS
* LibUV
Ask a carpenter.
To get to the third pigeonhole in a racked series of one foot per pigeonhole unit you literally offset two feet from the origin.
In C (of course), arr[2] works as well as does 2[arr] as both are literally just syntactic sugar for arr+2
ie. The third pigeon hole begins after passing two whole pigeonholes.
I mean, that's an important low-level detail to know when you're working with assembly or doing pointer math, but it is not something that necessarily needs to be polluting the semantics of a high level language.
I find it much easier to think in terms of v[i] is the i-th element of my vector.
These sorts of things just feel like mental gymnastics people perform to post-hoc justify language quirks.
> but why are you trying to think about a list of elements in terms of offsets from the origin
I don't try to think about them in this way - I do and have always thought about them in this way - in software terms for 50 years, in real world cut, saw, and hammer ways for over 60.
> I find it much easier to think in terms of ...
Which is the crux of the issue really, that's how you think.
> v[i] is the i-th element of my vector.
I think of V as the start of a row of elements.
V+0 is equivalent to V and naturally the start of the first element.
V+1 is the start of the row, plus one - the literal start of the second element.
I've always thought of V[i] as offsets, "jump overs" if you will.
It comes naturally for many that have worked with their hands on physical objects and worked with tape measures.
> but it is not something that necessarily needs to be polluting the semantics of a high level language.
Either way of thinking works - I spent decades going back and forth from Fortran to C, and people are free to make their high level languages however they wish - it's trivial to move from one to the other.
There are even some funky (or eyeball gouging) tricks done to preamble a data run with meta data, leading to V[-1] indexing being commonplace (in some domains)
I don't see a good argument though, I just see adaption to a quirky convention.
> Either way of thinking works - I spent decades going back and forth from Fortran to C, and people are free to make their high level languages however they wish - it's trivial to move from one to the other.
Here I agree. I have no real problem using a 0-based indexed language, I adapt to it quickly (or as you mention a -1 indexed language. Julia itself actually stores type-level metadata at the -1 index of a pointer to a mutable struct)
I just dislike when people try and turn every conversation about julia into "oh it's 1-based indexed so that disqualifies it", and act like 0-based indexing is some god-given most natural way to do all indexing.
Of course you do - you very likely didn't start programming in assembler.
You literally asked "How do I get to .." implying you wanting street instructions, distances, etc.
In assembler the third element begins literally and straightforwardly at the address base plus two (element widths).
That's not "a quirky adaption" is it? It's a dull pragmatic address of the start of the third element - the answer to the question you posed.
> Of course you do - you very likely didn't start programming in assembler.
I did not, and I do not think that conventions from assembler should influence basic ergnonomic design decisions of modern high-level langauges.
Indexes start at 1, offsets start at 0.
And offsets are the measurements that get you to an element - the question was explicitly phrased as "how do I get to" ...
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
Zynq is super cool and strongly agree that it’s worth looking into, although starting with just a naked little FPGA board might be more approachable. On the other hand, if you’re sufficiently capable with both embedded Linux and Verilog to successfully implement a piece of hardware in the PL and build a driver and userspace for it in the PS, you’re definitely miles ahead of most candidates.
TI/Octavo chips with the PRUs are kind of similar; not that they’re asynchronous logic like the Zynq PL is, but they’re similarly powerful as far as doing hard real-time deterministic jobs driven by an attached Linux core.
https://www.analog.com/en/resources/evaluation-hardware-and-...
> I’ve never touched ladder logic
Depends what kind of work you do, as product development is different from factory journeyman. I don't see a chaotic market supporting many domestic product development projects for the next 2 years. =3
I started using python for various engineering analysis problems around 2001 and I loved it for how fast (due to minimal boilerplate and automatic memory management) I could code up some thought relative to using C or Java. I could tackle problems in ways I just wouldn't have tried otherwise because I couldn't afford the longer time to write it in other languages. However, for problems which needed speed, of course it bogged down.
I started using Julia for ODE stuff in 2018 or 2019 and was thrilled with the speed and conciseness. As others have said, it looks much more like math and a lot of better design choices were made.
Python obviously has a much larger ecosystem and probably always will, and it will remain a safe choice, but you don't set yourself apart by doing the same thing as everyone else.
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.
It is better than your code, which is probably a low bar.
why so rude and adversarial, especially when so misinformed? AI code is better than 95% of engineers at this point.