This is somewhat achievable with separate languages. But it ultimately takes a very similar shape with additional tooling/ceremony and diminished benefits particularly from colocation.
but there's a better way, there's a better way.
like python used to be less popular than perl but look at where perl is now vs python. things do take time to change though
they didn't get range composition right
for(int k = 0; k != N; ++k) { dowork(k); }, similar in Python
ranges are [0...N). If I want just a sum, and would like to split work among multiple CPUs, I could write
s = sum(0...N) or s = sum(0...N/2) + sum(N/2...N) or s = sum(0...N/3) + sum(N/3...5N/7) + sum(5N/7...N)
and it will work beautifully. Ranges are decomposable and composable with any number(s) splitting original range.
[0...N/2) + [N/2...N) = [0...N)
When I first looked at Julia, I was ... unhappy. They didn't get simple ranges composability right. You could do it, sure, but it looks so ... unnnatural.
Want to use NumPy? Better hope you have code that can be expressed as array computations (a tiny minority of performance sensitive tasks in my field of work).
Cython? Now you're just writing another language, and get the joy of having to distribute compiled code in your Python package - for example, like the very fun segfaults I experienced because Conda will automatically override the system linker, breaking all compilation including my Cython modules.
Numba? Hope you don't make custom classes - you know, one of the basic features of the language.
If you look at ML, Python is completely fine because all the processing that happens with matrix multiplication, even on CPUs, far, far, FAR outweighs all the setup stuff in volume of operations.
On the other hand, if majority of your application relies heavily on processing speed (i.e you need compare/jump operations rather just add/multiply/load/store of the GPUs), Python is going to be slow. In this case, if you want custom performant code, you write C extensions for the performant critical code, and launch them from higher level python code.
That being said, there is generally a library (like Taichi) that already does this for you.
>> Reference Implementation >> None as yet.
> but they're still slightly janky
maybe you're from the future?
i bet the python macros will be ugly af too.
also walrus operator = bdfl no more.
Julia is a great niche language for what it is good at. It will survive but won't gain much popularity.
[1] https://discourse.julialang.org/t/very-slow-time-to-first-pl...
Packages need to precompile, and they don't. They need to fix invalidations, and they don't. They need to fix inference issues in their packages and they don't. "Using" time remains quite high.
These are all real limitations, but users of these languages learn to live with them. Rustacenans learn to start a build, then so something else while it builds. That is, on its face, totally unacceptable to a Pythonista. Pythonistas learn to always ship performance sensitive applications with _another language_ doing all the hard work: Totally unacceptable for a Rustacean.
If someone tries out Python, spends five minutes getting package management to work and fails, they have not seriously thought about Python as a language. I feel people do just that with Julia: Try it out, then reject it on the first rough edge.
Fair enough: There are many people for whom lack of static type checking or Julia's latency is a showstopper, making the language unsuitable. But I'm still firmly convinced that for scientists/engineers at least, Julia, on balance, offers a better language than Python. I hope you're wrong that it won't gain much popularity.
when we looked at it, it was because c++ is hard af to learn and the developer dont use it to its full potential. they just use some quantlib which where you look under the hood has many unoptimized parts.
with julia, the code is so simple and clean we even put in some GPU code in one place using CUDA and complete blows the C++ out of the water.
I did achieve some good performace with numba once thought with the avx so pythoni snot all bad but numba is only a small subset of python but with julia i can do crazily fast stuff that looks like python and is readable.
I don't doubt that what you say it's true, but to me, it comes down more to lack of familiarity with other languages than any actual merits of Python syntax and semantics. Frankly, I am glad the didn't take more from Python.
Still, most things worked in Julia, and there have been many improvements since then so I suspect the few remaining rough spots are being smoothed out. In the future I will be happy if I get to work with Julia more.
But then there's not enough users... so the cycle continues until one day Julia hits critical mass and a tipping point is reached.
all serious numerical languages have that. it's more natural
0 base indexing is only good for calculating memory offsets. Nothing else. like in go `vec[a,b]` is indexing `a` to `b-1` which is purely because it's more convenient due to 0-indexing. this `b-1` is hugely confusing and big gotcha for the layman.
And almost all serious general-purpose languages use 0-based. It is more natural at least to me. You see, this is exactly why 1-based index of Julia is disliked by many.
you may not like rachel macadams, but she was never gonna be urs anyway. so meh
Style aside, you can't simultaneously complain that Julia doesn't get the resources of a general-audience language and then talk down to "general-purposes folks". Julia could be the bees knees for math-y stuff. And if so, good for it. But Python's success is because its flexibility makes it pretty good for a wide range of things, even if it'll never be great for any one of them.
i love python. in fact, in my daily run on cloud run it's one of the key component since it has a decent gcp client library for writing query code to bigquery.
but then i glue it up with bash and run some other analysis in julia.
i think you can have python, julia, bash, r, whatever. heck, i even dabled in go and react.
just saying julia is aimed at numerical first.
and i think 0-based indexing was merely a historical accident anyway due to lack of memory in early computers so use every last bit including the 0 even though it's not suitable for indexing but is suited for calculating mem offsets.
whatever, use whatever u like, not trying to promote julia to you or anyone else. just having a good argument on friday afternoon
Python has classes, so it’s pretty straightforward.
Julia has type instability, which can make debugging performance issues not only difficult, but unpredictable. Python is very easy to debug, and typically straightforward to call out to Cython, Numba, Taichi, or soon Codon. There’s a wealth of incredible tools to choose from.
The Julia language is suitable for mathematical programming for mathematically minded people, it’s NOT at all suitable for producing high quality software that may pass through dozens or hundreds of sets of eyeballs, for many years.
Also, retrofit isn’t really an applicable word here because basically every piece of software out there is retrofitted, in a certain sense. Nobody uses v0.0.1 of anything…
But, I’m replying to a Chinese spam account, so what does it really even matter?
as opposed to Python? where type hints are just that. Hints. It's not even enforced. But u can use mypy... right.... yeah, retrofit more stuff on python. why not? (sarcastic).
I am not a Chinese national btw, I am from Malaysia.
My mistake, I saw your name was xiaodai and assumed.
My point is, Julia is not suited for general software, and it’s questionable as a tool for technical computing as well.
For running simulations and models where the code can be written and never looked at again, maybe it’s okay to use. But for anything else, Python is a lot nicer, and a lot more practical to write proper software in.
Oh my bad, I disregarded your comment based on your assumed Chinese nationality and “spam” (also assumed?). Since you’re not Chinese you’re worth my time.
I don’t get it.
Maybe this is just an issue of not having years of OO habits influencing the way I reason about dispatch in Julia?? Honestly not sure.
I appreciate that you have lots of good points to make but we need you to abide by the site rules: https://news.ycombinator.com/newsguidelines.html. Please don't create accounts to break those rules with.
If you look at compute in general, it can be pretty much be summed up as add/multiply/load/store/compare/jump (straight from Jim Keller). All the other instructions are more specialized versions of that, with some having dedicated hardware in CPUS.
If you need to do those 6 things as fast as possible, on single piece of hardware, you are most likely writing a video game. Thus video game development is pretty much C/C++ with a few things of Swift/C# sprinkled about.
If a single piece of hardware requirement goes away (i.e you are writing a distributed system to serve a web app), people quickly figured out that hardware is cheaper than developer salary, and also network latency is going to be the dominant thing for speed. This is the reason Python took off - its super quick to write and deploy applications, and instead of paying a developer $10k+ a month, you can just spend half that on more EC2s that handle the load just fine, even if the end user has to wait 1.5 seconds instead of 1.1 for a result.
If you don't need compare/jump, your program is essentially better off suited to running on the GPUs. OpenCL/CUDA came about because people realized that a lot of applications simply need to do math without any decisions along the way, and GPUS are much better at this. The paradigm is that you write kernels that you then load onto the GPU - this can be done in any language since you really just need to run the code once. I.e Python, despite being slow is used primarily for ML because of this.
Then there is multiply/add only, which you probably best know in implementation as ASICs for bitcoin mining that blew GPUs out of the water. When you don't have memory controllers and just load/store from predefined locations, your speed goes through the roof. This is the future of ML chips as well, where your compiler looks a lot like the verilog/hdl compilers for FPGAs.
Furthermore, with ML, the compare/jump and even load/store is being rolled into multiply/add. You have seemingly complex algorithms like GPT that make decisions, but without any branching. Technically speaking, a NAND gate is all you need to make a general purpose CPU and you need 2 neurons to simulate a NAND gate. So you can build an entire general purpose CPU from multiply/add.
So in the end, its absolutely worth investing in Python and making it better. Languages like Julia are currently better suited to performant tasks, but the necessity of writing performant code to run on CPUs is going away slowly with every day. Its better to have a high purpose language that allows you to put ideas into code as quickly as possible, and then have different specializations for more generic tasks.
I don't care much about how the interface over LLVM looks like. As soon as I have the same result in the end, I'd rather stick to whatever has more users.
Julia language features are really weak.