DNF2

Why are you saying that? The Mojo code seems to have the same optimizations as the Julia code.

Are you sure the Mojo code hasn't been optimized? It seems to be hand-tuned with simd operations and multi-threading.

Please actually read the Mojo code. It is full of complex hand-optimized simd instructions.

By comparison, the simd-optimized Julia code (especially the first version) is significantly more elegant and transparent.

Impressively, the ComplexSIMD Julia class was defined in a few simple lines, from scratch. I wonder what the, apparently built-in, complex simd functionality in Mojo looks like under the hood.

I'm curious about the "language instability". What kind of stability is that? Are talking about package instability, or the core language?

Compute power can directly influence developer hours. Developers/researchers spend a lot of time twiddling their thumbs waiting for a simulation/calculation to finish and plots to render. It directly costs time, and it also messes with your focus and progress in general.

The compiler is free and open source, not proprietary. It is built on LLVM, which is also FOSS.

And Julia code is not Fortran/C/C++, not sure what you are asking.

I don't think this has anything to do with whether 1e-300 and 10.0^-300 is parsed differently (and perhaps that is a mistake). The poster seems to want to parse 1e-300 directly as a BigFloat in the call `BigFloat(1e-300)`, because of the function it is passed to.

Yes, I got that argument, and that is exactly what I was arguing against. You cannot and should not parse the literal double `1e-300` differently dependent on which function it is later passed to. This is what `big"1e-300"` or `BigFloat("1e-300")` is for, where the BigFloat constructor parses the string.

But Julia _does_ have namespaces, and you can import everything with the `import` statement, or you can retrieve only the functions you need. This is also what is generally done during package development, while dumping everything is for interactive use.

This is a problem for non-dispatch or singular dispatch languages, it's significantly different in the context of multiple dispatch. Namespaces are, well, not bad, but sometimes they are a solution to a problem that does not necessarily exist.

The argument isn't silently treated as a double, it is explicitly and loudly treated as a double, because it is a literal double.

And this is not an advantage to the designer exclusively, it is very much an advantage for the end user that the treatment is explicit, consistent and predictable, instead of 'magically' reinterpreting the meaning of literals based on guessing the intent of the user.

Basically, you seem to be saying that when passing x to BigFloat, x should not be treated as the value x, but as some nearby value that might be the one the caller intended (based on some rounding logic perhaps?) Or are you perhaps saying that

    x = 1e-300
    y = BigFloat(x)

should be different from

    y = BigFloat(1e-300)

? In other words, completely discarding referential transparency?

I actually find the string macro syntax even more convenient: `big"1e-300"`.

And now this comment is one of those, even though it's not actually based on trying out the new release.

How do you figure that, when the CFD software is already built and available, and the premise in the question is that that the asker is already in a position to start using it? It's pretty clear that the background of the asker is aligned with a software approach.

> Building a physical model, on the other hand, merely requires 3D printing the desired shape, doing some sort of casting process to get that out of metal, putting it on a boat, and seeing if you get a noticeable performance impact.

I love how you sneak the word "merely" in there, when for people like me, and presumably the asker, this would be a Herculean task :D

Indeed there are no special operators, :. and ==: etc. They are just :, . and ==

And macro definition code looks quite different from 'regular' code since it works so much with expressions and symbols.

I would guess the majority of users never write a single line of macro definitions or expression evaluation.

Is building and testing an actual propeller going to be easier? I would have thought that setting up and running a simulation could be done in a moderate amount of hours, and could then be quickly iterated on. The only requirements are a laptop and an internet connection.

Building a model, on the other hand, could potentially involve a multi-year effort to re-educate yourself to learn how to build models, having to acquire hardware and materials, and setting up a lab for testing. And then building many different actual models.

After clicking trough to the repository, I found this part a bit perplexing: "running on a GPU requires initializing the Simulation memory on the GPU, and care needs to be taken to move the data back to the CPU for visualization."

The original purpose of GPUs were visualization, so that seems backwards to me. And, GLMakie is used, which makes it even more counter-intuitive, isn't that specifically built for GPU visualization?

> Also this is the first time I saw examples of Julia code and the syntax looks worse than C++.

For someone who writes both Julia and C++, the above comment comes across as an obscene joke.

Possibly, you object to the programming style in that library, the choice of identifiers or whatever? But that has nothing to do with language syntax.

So you gave up the language after someone gave you a flat out wrong answer to a single question? That's too bad.

Just to manage expectations: As far as I understand, v1.9 doesn't by itself solve TTFP/precompilation. The tweet seems slightly over-enthusiastic. But it puts tools to solve it in the hands of package developers.

In that sense, one can perhaps say it is a turning point.

I know no one who uses Matlab for the uses you mention. Basically everyone is using it for algorithm development, that includes both students and companies. And the way I understand it, algorithm development/prototyping also its core application.

Not that I like doing this in Matlab, but that's what everyone uses, though some are moving to python.

> In that regard, Julia code reads like someone’s manuscript about the issue and not a program written by a programmer. To you, that’s desired. To me, that’s my actual worst nightmare

That's a pretty dubious attribution of intention, though, that I desire this. I want clean, maintainable code.

> You mention not taking all argument types, it’s just so stereotypically mathematician of an assumption that the code will just work with whatever garbage you send it.

But that's not what I said, and it's not what multiple dispatch means. You are talking about generic functions and duck typing -- essentially, code that has no type restrictions. Multiple dispatch means that types of all arguments are considered, and you are free to be as restrictive as you wish. You can specifically and concretely type every single input, and probably make the code much more predictable and to your liking.

The amount of genericity vs type safety is a trade-off between different advantages, and you have a lot of freedom to choose.

> I don't stay plugged in beyond reading the changelog whenever a new version comes out ... > I've also noticed a distinct and crucial lack of long-term vision for Julia from the co-founders.

Don't you find those two statements contradictory? There's a pretty striking contrast between your claim to ignorance and your confidently sweeping generalization (sadly, those two often do come in pairs.)

> I've also read some dramatic (unverified) claims that I won't repeat here about one of them.

If this is what I think it is, the claims were not substantiated in any way (even though it would be easy), and seemed quite outlandish, frankly.

> I've been unfortunate enough to read some .jl code in '22, and it was dreadful. I truly don't understand how multiple dispatch makes anybody's life easier

It's really hard for me to understand this opinion, given that Julia code, to me, is far more appealing than all the most common alternatives. In particular, multiple dispatch is such an obviously natural paradigm, that it's just hard to fathom why everyone don't just 'get it' right away. I mean, not taking all input argument types into account now seems to me like a completely artificial, even perverse, restriction. Why?

I guess this is why people argue on in the internet.

In Julia you can go low-level, but there is no requirement. You can write purely high-level, generic, untyped code, with good performance. So I'm a bit reluctant to accept the claim that it's lower level.

What are the things where low-level code is required in Julia, but not in Python/R?

Maybe it's all floats in R, but in Julia, `return 500` means an Int is returned. But it's really hard to determine whether the Julia code is unstable based only on the R code.

The dispatch is based on the "runtime type", but that does not necessarily "happen at runtime", because the runtime/dynamic type can often be determined statically.

I'm not that good at reading R. But if the Julia code is similar, then this code is type unstable, sometimes returning an Int, sometimes a Float. That harms performance.

Generally, it looks like a function where Julia could have a significant performance advantage.

Of course, this is piques one's curiosity. It might be, if the function is simple enough, that there is little advantage to Julia here.

But if you are combining multiple operations on a vector, there could be opportunities for Julia, in-place operations, fusing, simd. Maybe even StaticArrays.

Any chance of sharing that little piece of code?

There's another issue. In addition to the open source license and what it promises, when you accept contributions from others it isn't just your work anymore. LightGraphs had 100 contributors, what about their efforts? Not to mention additional work that others have done on top of that in other libraries.

Who would contribute to a software library if they knew that the main dev could just mothball their efforts at any moment.

If you have donated a ball, you can no longer just pick it up and go home. If you don't want to donate work, don't do open source and invite others to join in.