suavesito
I like to think that societies in Latin America (and, importantly, all around the world) survived thousands of years not because of luck, but because the cultures (language, traditions) they developed had ingrained the "scientific knowledge" necessary to survive in the conditions that lived in. An important part of it was that they did not see only as rulers and owners of the world, but only as one part of it. That is one of the basis of what people call magical thinking, but it is sound once you stop disqualifying it just because the word "magical" is in it.
And, I mean, literally, only those who could adapt and understand their world to survive, survived. The knowledge maybe was not as fast evolving as the scientific methods allows to be, but it is, ultimately, the same method. Try, fail, and repeat. Those who were successful survived.
The knowledge ingrained in the culture, traditions and understanding accompanying it was, and _is_, a fundamental part of the solutions that allowed them not to only survive, but to thrive in their environments.
The first comment in this post says that you do not need the culture to carry out the solutions. That may be true, but it does miss that our culture is the strongest (after "basic necessities") incentives we have to choose some things over others. Or understanding of the world is our culture, and our understanding of the world is what makes us take some actions instead of others. You might be able to mimic technical solutions, but to fully understand them, you need the culture that developed them, as it is _literally_ the understanding of the world that allowed the solutions to exist.
What, aside from this argument (which I'd like to found an study providing evidence of what you wrote, and one providing evidence of exactly the contrary), you think explains _better_ the observations than their arguments?
You need not to use something expensive, only things that you think _looks_ expensive. But, what looks expensive, if not, obviously, the things that are expensive.
The problem is the Mexico is the most strict country (by law) in copyright terms, which is dead of last author plus 150 years and there is no fair use.
Shameless plug: The format (and the tool) has been used with great success in Veloren, an Open Source Voxel MMORPG written in rust (https://www.veloren.net/). The artist team has made great assets for the game and landscapes for the release parties.
Your should check out the project, it is really cool.
(Disclaimer: I'm part of the mod team.)
(Disclaimer: I'm part of the mod team.)
On garbage collection and real-time applications, there is this [2] talk where ASML (the manufacturer of photolithography machines for TSMC) uses Julia for it. Basically it preallocates all memory needed before hand and turns off the garbage collector.
On the same more about real-time, if your call stack is all type stable [3], the you can be sure that after the first call (and subsequent compilation), the JAOT compiler won't be triggered.
About static compilation, there are two different approaches * PackageCompiler.jl [4], which is rally stable and used in production today. It has he downside of generating huge executables, but you can do work to trim them. There is still work to do on the size of them. * StaticCompiler.jl [5], which is still in the experimental phase. But it is far from being completely brittle. It does puts several restrictions on the chide you can write and compile with it, basically turning Julia in a static type language. But it had been successfully used to compile linkable libraries and executables.
Some of the concerns you have about usability in your third paragraph have been worked on with the 1.9 and 1.10 (coming) releases. The LSP usage is better thanks to native code caching, maybe you can try it again (of you have time). The debugging experience I honestly think is top notch if you're using Debugger.jl+Revise.jl [6] [7], still I know there are some caveats in it. About stack traces, there is also a more of work done to make them better and more readable, you can read the with done in these PR's [8] [9] [10] [11, for state of Julia talk].
Still, I can understand that Julia might not be able (yet) to cover all the usecases or workflows of different people.
[1]: https://julialang.org/blog/2023/04/julia-1.9-highlights/#cac... [2]: https://www.youtube.com/watch?v=EafTuyy7apY [3]: https://docs.julialang.org/en/v1/manual/performance-tips/#Wr... [4]: https://julialang.github.io/PackageCompiler.jl [5]: https://github.com/tshort/StaticCompiler.jl [6]: https://github.com/JuliaDebug/Debugger.jl [7]: https://timholy.github.io/Revise.jl/stable/ [8]: https://github.com/JuliaLang/julia/pull/49117 [9]: https://github.com/JuliaLang/julia/pull/49959 [10]: https://github.com/JuliaLang/julia/pull/45069 [11]: https://www.youtube.com/watch?v=2D8oRtDJEeg&t=2487
Important detail that it runs on GPU.
This might sound counterintuitive given that latency is a normal problem mentioned everywhere else about Julia. But, if you think about it, Julia compiled to native code a plot library from scratch in 15- seconds every time you imported it (before Julia 1.9 where native caching of code was introduced, and latency was cut down significantly).
This makes that problems where you would like to (for example) generate polynomials in runtime and evaluate then a billion times each, Julia can generate efficient code for ever polynomial, compile it and run it fast those billion times. C/C++/Fortran would have needed to write a (really fast) genetic function to evaluate polynomials, but this would have always (TM) been less efficient than code generated and optimised for them.
Edit: typos and added some remarks lacking originally
[1] https://github.com/org-arl/InteractiveViz.jl [2] https://github.com/MakieOrg/Makie.jl
From my personal experience. I've done graphical apps in GTK3 in Julia with PkgC.jl cross-compiling from Linux to Windows. And they worked. :)
It does not fix processes to CPU's, or set kernel governor to performance, and there are fluctuations from usage of the computer. But it does run the function for several seconds and returns the distribution of the runs (the little graphics underneath the benchmarks). It calculates standard deviation and if some runs are too small (sub-nano seconds) it emits warnings saying the results might be caused by inlining and constant propagation.
The differences in runtimes you refer to are from use of different machines or different routines, which is completely expected. They also argue they need to run the Mojo code in the same machine as the Julia code to be able to give meaningful results and comparisons.
While to someone outsider it might be seen as done without care, I can asure you that this people are used to take extreme care on how they do benchmarks. Again, it might just be that you're not familiar with the tooling developed to do it.
I do think there is more benchmarks needed to be done, as the Mojo code hasn't be optimised yet and none in that thread was able to run both the Julia code and Mojo code in the same machine (outside of the OP). But I'm sure this will be done (I guess rather sooner than later). :)
[1] Documentation of the package used for benchmark https://juliaci.github.io/BenchmarkTools.jl/stable/ Here you can find all the information you have said in your comment, and more, about reproducibility of benchmarks in different environments. White paper about the strategies used by the package https://arxiv.org/abs/1608.04295
> I know I shouldn’t say so but I can’t help...
Remarking that the comment should not be taken too seriously, as it might be inappropriate.
Finally, saying the whole community is condescending given 1 in 32 comments is... a little rounding up from the statistics there.