Viral Instruction

this post on union types versus sum types is worth a read (the tl;dr is that they both have their uses and one is not strictly better) https://viralinstruction.com/posts/uniontypes/

https://viralinstruction.com/ It's mostly about Julia programming, though I originally intended for it to also be about molecular biology. Posts tend to be relatively long.

Very interesting post, thanks for sharing. Do you have a link to your project code? Your experience seems to be in line with this post I read recently: https://viralinstruction.com/posts/badjulia/ It's written by a Julia fan, so it's a very lucid and measured take on the not so great side of Julia.

The "feedback and answer" below the gist already covers a bunch of things I wanted to mention. So I'll skip those and only talk about the rest: > You can't make it a CLI script, because it compiles the whole code WITH dependencies every time The "with dependencies" part is mostly untrue nowadays, with constantly better pre-compiled caches for dependencies with every release. The overall issue of compile times getting in the way of interactive development still has some truth to it, but much less than the comment implies. > https://viralinstruction.com/posts/badjulia/ 1. The subheadings in the ToC are mostly based on comparisons with the best-in-class: for eg. "Julia can't easily integrate into other languages [compared to C]", "Weak static analysis [compared to Rust]". 2. Seeing this actually gave me hope about Julia's progress, based on how many of these issues have been largely mitigated or have been actively worked on in the last three years since the post. 3. As a side note, the author of the post is still an active user of and contributor to Julia, so I think this kinda falls under the "There are only two kinds of languages: the ones people complain about and the ones nobody uses" banner. As in, the complaints are there because they like and actively use the language enough to want it to be the best in every way. > Even though Julia 1.6 was a lot faster than 1.5, it still took too long. I agree - I think pre-1.9 Julia experience sucked, and overselling the…

> A major goal of Clang was to be a “compatible replacement” for GCC, MSVC and other existing compilers. It is hard to make a direct comparison, but the complexity of the Clang problem appears to be an order of magnitude bigger than implementing a compatible replacement for Python. The journey there gives good confidence we can do this right for the Python community Is it though? For Mojo to be a compatible replacement for Python, it would need to match the Python C ABI and the greater set of the standard library in a bug-for-bug compatible way. The real question is whether it's bug-for-bug compatible or whether it's not. Numerical functions have a lot of nuances that effect that performance quite a bit. Are they constrained so that Python numpy log(x) gives the same as Mojo log(x)? Will C bindings act the same way as in CPython? Whole list of related questions. If there is a no to any of these questions, then code acts subtly differently in a way that is sometimes hard to detect. These differences are of course what have held back "standard code" from being numba/pypy/etc. compatible in many instances. That said, if the answer isn't yes to anything, then it is very difficult to make optimizations. Not allowing hard to optimize Python behavior is precisely what has allowed Numba, Julia, etc. to achieve accelerations. There were some attempts at that kind of thing with R, which Jan Vitek gives some very interesting talks about…

Note that union types are not the same thing as sum types, even if they're somewhat similar. https://viralinstruction.com/posts/uniontypes/

there exist many high quality criticisms of Julia's type system, but this article does not contain them if I'm being totally honest. I think this writeup here https://viralinstruction.com/posts/badjulia/#the_type_system_works_poo… contains more valid gripes about the type system than the one you linked.

> ...I still want that kind of system, but I expect it would fail catastrophically in the real world Julia has its own version of the orphan rule called Type Piracy, which is merely discouraged instead of disallowed: https://viralinstruction.com/posts/latency/#a_brief_primer_on_invalida… It's not a net gain, but rather a different tradeoff.

This has been very helpful to me: https://viralinstruction.com/posts/hardware/#74a3ddb4-8af1-11eb-186e-4… It’s really not specific to Julia, though the language does let you drill down into the details nicely.

see https://viralinstruction.com/posts/mojo/. this compares a Rust parser that does some validation to a Mojo "parser" that doesn't do any.

This is quite a good intro: https://viralinstruction.com/posts/badjulia/

An opposing viewpoint on the issues of Julia from a user of Julia: "What's bad about Julia?" https://viralinstruction.com/posts/badjulia/

This is an interesting read, thanks! I'm a bit surprised by https://viralinstruction.com/posts/badjulia/#julia_cant_easily_integra… - I've been considering embedding Julia (as opposed to LuaJIT) in a project I'm working on that requires fast, mostly numerical computation. Based on https://docs.julialang.org/en/v1/manual/embedding/, this seemed fairly simple, and as though I could avoid repeatedly paying the compile time latency cost by just calling my embedded functions at least once before the performance-critical loop (to ensure that they're compiled). Is that not the case? There's definitely still the high memory overhead to consider, but (admittedly without having tried it yet), embedding Julia doesn't seem too terrible to do. Worse than e.g. compiling a shared object library or something, but not at all unreasonably hard.