borodi

I'm not anti nuclear or anything like that. It's just the financial comparison one has to make. Currently competing with solar + batteries is hard since unlike SMRs which hypothetically will get cheaper, they are getting cheaper at a quick rate and don't have the history of cost overruns that nuclear does.

The gemini solar project in Nevada is 700 MW power + 4 hours of batteries at 380MW and cost 1.9 billion. Took 2 years and that was in 2022

LLVM has range flags and things like nnan that could in theory be used to replace a minimum intrinsic into a minimumnum (iirc x86 has a instruction for the latter but not the former) https://llvm.org/docs/LangRef.html#floating-point-min-max-in... I'm not sure if the optimizations use this but in theory they could

Fun fact, Julia's parser and part of its compiler are implemented in femtolisp, and you can access it using a not so secret option in the Julia CLI.

I havent tried Tsan with rr but msan and asan work quite well with it (it’s quite slow when doing this) but seeing the sanitizer trigger then following back what caused it to trigger is very useful.

Chaos mode is an option when invoking rr that can expose some concurrency issues. Basically it switches which thread is executing a bunch to try and simulate multiple cores executing. It has found some race conditions for me but it’s of course limited

There is, it's called count_ones. Though I wouldn't be surprised if LLVM could maybe optimize some of these loops into a popcnt, but I'm sure it would be brittle

So it was a bit more pervasive than this, the issue was that flushing subnormals (values very close to 0) to 0 is a register that gets set, so if a library is built with the fastmath flags and it gets loaded, it sets the register, causing the whole process to flush it's subnormals. i.e https://github.com/llvm/llvm-project/issues/57589

btw, there has been a pretty nice effort of reimplementing the tidyverse in julia with https://github.com/TidierOrg/Tidier.jl and it seems to be quite nice to work with, if you were missing that from R at least

LLVMs API is the c++ one. The C one while more stable also doesn't support everything. Keeping up with LLVM is annoying but it's not the source of bugs or anything of the sort. PS(it's not actually stable. Because if the c++ code it calls is removed it just gets removed from the C one)

I say this as one of the devs that usually do the work of keeping up the latest LLVM.

Julia follows semver, so code written in 1.0 should work on the latest release (packages notwithstanding)

It tries to show you the type information on the source itself, instead of on the IR.

I do believe this is an issue of not having explicit dependencies. Julia takes the approach of, we build and ship everything for every OS, which means Pkg (the package manager) knows about binary dependencies as well. Making things more reproducible in language

Julia does have really nice GPU support, being able to directly compile julia code into CUDA, ROCm, Metal or other accelerators. (Being GPU code it's limited to a subset of the main language)

You can try and build your own toy language for fun, or try to compile lox to some assembly/llvm ir.

Another option is to try and contribute to an existing language (Julia ;) ).

We used the chromium snapshot file format (https://learn.microsoft.com/en-us/microsoft-edge/devtools-gu...). If firefox uses the same format then it should work, but I haven't tested.

I'm sure there are reasons for it, but Chris Lattner has been jumping around a bit. Remember swift4TF. But hopefully this one is seen through with lots of open source too.

One interesting thing is that if julia can prove what types a function will be called with at compile time, it doesn't have to do dynamic dispatch, so it has no overhead. It's what the julia folks call type-stable code

That's one of the cool things about Julia. If it can prove the types of the arguments to a function, or at least reduce them to a small set. It can do the dispatch at compile time.

Well, Julia has better than semi decent support for generics, since every function is by definition a generic.

Veritasium has a recent video that goes into the algorithm a little bit. So does 3blue1brown. But basically anything that processes signals digitally will probably use the FFT somewhere. But even outside of that, you can use it for some kinds of matrixes in linear algebra and probably many other places :)

Julia has many of the features one expects of a lisp. But it has a more "normal" syntax

SemVer is very important for me. If the language has binary dependencies the package manager should also handle them. Depending on the system for them leads to hard to debug issues. An easy way to reproduce environments is also important via a toml file or something similar.

Pop has pipewire since 22.04 IIRC.

LDP(load 2 registers) was switched in place of LDM, it seems that instructions that could touch so many registers at once made out of order/superscalar harder.

source: https://community.arm.com/support-forums/f/architectures-and...

The group working on it, (Valentin, Tim Holy etc) agree with you, which is why we are tending to call it TTFX(time to first X) instead of TTFP, so it includes everything, not just plotting. It's just that when plotting the delay is very visible.

--lisp mode just lands you in the REPL of femtolisp, which is used for the parser and lowererer. It's kind of an easter egg for sure.

The syntax sugar you are looking for "mutating" the immutable stricts is basically what Accessors.jl does. I don't really see a reason to bring it into Base Julia if it doesn't need special things to work. The compiler can and will optimize out the stack allocation

Yes and no. There are ways around that for development like https://github.com/BeastyBlacksmith/ProtoStructs.jl. But changing the definition of actual structs isn't very feasable because what happens with the structs that use the old definition, i.e an array of them.

Julia has an IR called Julia IR that is used before compiling to LLVM IR, it's a bit higher level than LLVM ir

Theoretically yes, rust binaries can have C-apis and other code can call them just fine.