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.
> 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
This argument over indexing conventions is so tired.
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
all of which are extremely reasonable foreign things for a language to use (though we are gradually moving more and more of these things to the julia side)
Okay, but why are you trying to think about *elements* of a list in terms of offsets from the origin?
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.
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.
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.
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.
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.
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.
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.
I'm an electrical engineer and I use Julia for all kinds of analyses that I might have earlier in my career done in a spreadsheet (Lotus 1-2-3 at first!), or later in python (when I had to choose between Numeric or NumArray).
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.
Oh, my friend, I’m in my 40s now and while I’ve never touched ladder logic (mostly on purpose), I can honestly say I’ve been writing C since the last century and C++ only a few years less. I remember, with pain in my heart, what C++ looked like before C++11, C++14, and C++17. C++03 had just come out when I started and lots of features even there weren’t really all that baked in the toolchains at them time :).
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.
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
One thing that I find extremely annoying when I occasionally read Julia code is the pervasive usage of Unicode. I explicitly forbid agents to use any anything other than ASCII for that reason.
Nearly all languages designed for mathematics are 1-based - R, Matlab, Mathematica, etc. because that's the mathematical convention and allows using formulas directly. The fact that Python isn't is a drawback in the domain.
This is why AI is better at writing code than humans. They just write code and don’t complain about things that don’t matter, like indexing; or another classic, spaces vs tabs. Humans must learn to get past these things.
I guess IPFS is an artifact from the crypto craze. It's pretty silly if you think of it. However, I must admit, I got my first ever developer grant from Filecoin while they were flush with ZIRP era money.
btw,I thought it was an Initial Coin Offering, not an actual fundraise.
What's silly about it? Content-addressable decentralized storage -- not tied to a cryptocurrency -- is really valuable for censorship-resistant archiving of politically-sensitive data (such as climate change research).
Except it wasn’t censorship resistant at all, in that your node advertised itself as a node with a-z files on it. Separately you could put it behind a vpn or run a vps you paid for with monero, but fundamentally it’s more of a way just to pin a file to an address that works no matter what domain or IP the file is behind.
That's not what we were talking about here. But as long as we're on this tangent I hardly think using a VPN constitutes a high bar to clear. There are still plenty of jurisdictions remaining in the world that in practice don't care to enforce copyright law against individuals (or sometimes at all).
Evidence? But also, so what? By definition the VPN will be exiting in a country tolerant of the conduct in question. It's also possible to purchase from an operation headquartered there, or even to directly purchase a VPS.
In addition to that, this noble goal of being an insurance policy against censorship never played out.
How hard would it be for a country to block the clients and browser extensions you need to use it in the first place? Or to develop a firewall technology that’s capable of blocking the traffic?
Probably not that hard, especially since nobody uses IPFS for anything business critical since it’s not all that great at doing things that you need from file storage systems.
Most reasons you store files somewhere benefit from not being decentralized. You usually want some combination of performance, security, durability, and availability. Decentralization is not generally a demand of file storage.
The only reason it’s decentralized is because blockchain and crypto was hype 10 years ago.
> The only reason it’s decentralized is because blockchain and crypto was hype 10 years ago.
IPFS is not "blockchain" or "crypto"(currency).
It's much closer to git-over-bittorrent. Note that both of those things were decentralised long before "blockchain" and "crypto" existed.
The makers of IPFS also made a crypto thing called Filecoin; but that's a different project. Avoiding IPFS because of crypto is like avoiding the Web because of social media.
What people did or planned to do with IPFS is pretty silly, but the idea of content addressed storage with cryptographic (not in a crypo coin way) names makes a lot of sense. It would make for a great software distribution method e.g. your game downloads get faster the more people want to play the latest version. It's the combination of Git and BitTorrent and has uses far beyond just hosting warez and NFTs.
This. I also always imagined it be able to host some version of an Encarta/encyclopedia that would be so distributed it would probably survive world wide catastrophe.
IIRC IPFS was the latest in a long line of Distributed Content-Addressed systems that long predate crypto. AFAICT (obviously I wasn't paying much attention) they went crypto (FileCoin) to fund a base population of storage users to bootstrap its popularity.
Incredible counterexample, but oddly relatable.
I'd probably have achieved techbro 'post-economic' status earlier if I focused on Android dev instead of the shiny (and new at that time) Xamarin for Windows phones.
God I almost invested in Xamarin after Windows Phone got aborted, I did spend a lil time on UWP, but thank god Flutter came out not so long after that. After all these years I learned to stay away from Microsoft tech stack.
When you say "open-source crowd demanding features (and security updates) all without donating to the project" are you referring to the profitable companies who massively benefit from FOSS but don't contribute in any way back to the projects they leverage?
No, we just expect them not to be posted on link aggregators like HN. Because they are useless links for 99% of readers.
Did you know that video game piracy enhances video game sales? That's because if someone pirates a game and likes it, they might buy it, recommend it to friends, or buy the next one.
SOTA quantization aware training (QAT) techniques summary.
1. Bitnet weights are one of three digits (-1, 0, 1). This is the OG 1.58 bit network.
2. Sherry quantization constrains every 3 out of 4 Bitnet weights to non zero for SIMD optimization. Do the math and you'll see this is a 1.25 bit network.
3. Tequila quantization handles excess zeros due to gradient flow issues.
4. Fairy quantization is Bitnet plus an imaginary number {±i}. So it's a 2-Bit network, not a ternary network.
reply