Sukera

> There are so many problems with trying to adopt it for real projects it isn't even funny... Good for researchers sometimes, but even then... It's got issues.

Can you expand on that, so that it's possible to improve on them?

Aside from me disagreeing with this article here in that I don't think "all of julia is incorrect" is a valid take from Yuri's original article, I'm not sure how you arrive at "if branches don't do what I think they do" from that sentence. Are you referring to one (already fixed) bug[0]?

[0]: https://github.com/JuliaLang/julia/issues/41096

[0] is already fixed on master but can't be backported to LTS due to the fix introducing other problems specific to LTS. [2] is closed. [3] should be fixed, but doesn't seem trivial to do. [4] is a regular ol' bug (again, not a language but a library bug). Same goes for [5].

From the linked stuff, only [0] is a true correctness problem of the language and not a bug in a library.

> Some commenters seem exhausted by what they perceive as a continual stream of lies about these topics, which has left them less inclined to post about them.

How is differentiating bugs in the language (parser, compiler, type system, ...) from bugs in libraries implemented in the language "lying about these topics"? It's not like julia is claiming to prevent logic bugs, or am I missing something.

True in principle, but that is neither related to multiple dispatch nor a common feature in other languages. Dependent typing is very much active research in PL academia. The @inbounds kerfuffle was all about incorrectly using a tool that's explicitly documented to take off the existing bounds checking safety, similar to `unsafe` blocks in Rust. So even with dependent types, if you explicitly opt out of those checks, they wouldn't have helped.

The point is not limited to Int though. Say you have this struct:

    struct MyStruct
        a::Int64
        b::Float64
    end

Since the size of each field is known (8 bytes), the size of the whole struct, and thus the size of each instance of that struct, is known - 16 bytes. This is crucial information for inlining, loop unrolling, copy elision, deciding which register(s) to place the object in, getting rid of indirections through pointers.. If you'd allow to subtype MyStruct, the compiler wouldn't be able to know ahead of time what the size of a MyStruct object is and would either have to box every access (introducing pointers which have to be chased on access) or defer A LOT of work to runtime. With boxing, you almost immediately lose lots of opportunities to SIMD or otherwise optimize your code, because you have to keep a whole lot of extra type information around at runtime that's just not necessary when all your objects in a e.g. Vector{MyStruct} have the same size anyway.

I may be missing some context, but what correctness bugs exactly are you referring to that are caused by multiple dispatch?

Took a while, but email is sent - thanks again, and I hope shipping will work itself out!

I'm not as familiar with how C++ does allocations compared to julia, but I'd imagine the limitations would be similar - if `new` can allocate memory on the stack, I can't imagine why it wouldn't work out of the box.

C++ really isn't my forte though.

That'd be awesome, sure! I'll shoot you an email.

PlatformIO is nice, yes - I've already been suggested linking/using that, but I haven't looked into it yet. I also haven't worked with that before, so it'd be completely new territory for me.

I didn't know about FreeRTOS, interesting!

I don't think CBinding.jl is an option, since the whole point of the arduino is that the julia runtime can't run there (and doesn't fit in the first place - there's not enough RAM and swapping to the SD seems bad). Linking with C created .o files should work though?

I don't own any ESP32, but if that happens, yes I'd very much like to try!

Haha, thank you!

Yeah, this was mostly an experiment to see what kinds of problems I run into - I didn't expect this to actually work out! It's still very finicky, relying on LLVM to remove dead runtime calls and so on, but non-allocating stuff with immutables should work, though I haven't actually tested it.

To expand on the "interfaces are not enough" part: Defining an interface on an abstract type only gives you that a implementation exists, not that it is correct, i.e. that the specific implementation for a subtype guarantees the same properties the interface specifies.

On top of this, you really want to be alerted to when you expect more of an interface than the interface guarantees - this is what happened in the case of `1:length(A)` being assumed to give the indices into `A`, when the `AbstractArray` interface really only guarantees that a given set of methods exists.

I feel like these sorts of issues more or less require more formal models being provided & checked by the compiler. Luckily for us, nothing in this space has been implemented or attempted in & for julia, while there are a lot of experiments with formal methods and proofing systems being researched right now (TLA+, coq,..). There are of course a lot of footguns[1], but the space is moving fast and I'd love to see something that makes use of this integrated into julia at some point.

[1]: Why specifications don't compose - https://hillelwayne.com/post/spec-composition/

Do you have an example? I'd like to know more about this - it must have been quite egregious if it makes you stop learning a language.

Most of these seem to be about packages in the ecosystem (which, after clicking through all links, actually almost all got fixed in a very timely manner, sometimes already in a newer version of the packages than the author was using), not about the language itself. Other than that, the message of this seems to be "newer software has bugs", which yes is a thing..?

For example, the majority of issues referenced are specific to a single package, StatsBase.jl - which apparently was written before OffsetArrays.jl was a thing and thus is known to be incompatible:

> Yes, lots of JuliaStats packages have been written before offset axes existed. Feel free to make a PR adding checks.

https://github.com/JuliaStats/StatsBase.jl/issues/646#issuec...

EDIT: Since this comment seems to gain some traction - title is editorialized, original is "Why I no longer recommend Julia".

I don't think that matters here - the FFI interface hasn't changed and I wouldn't expect it to differ significantly.

Disclaimer: I'm not even a physicist.

As I understand it, the trouble is with "what happens to the information inside the black hole?", not with whether it's there at all or not (which isn't disputed - we see stuff fall in, so it's gotta go _somewhere_ and it isn't in our observable part anymore). In addition, because of the nature of a black hole, how would an experiment trying to test any theory about what happens in a black hole even work? As far as I'm aware, we don't know of any mechanism where stuff inside the black hole affects stuff outside the black hole (hawking radiation doesn't, as far as I'm aware, explain _how_ the spontaneous quantum fluctuations come to be - they're just theorized to happen to satisfy the equivalence principle near the event horizon), but that's exactly what we'd need to confirm or deny anything about whatever happens past the event horizon.

On top of this, just the existence of hawking radiation means black holes vanish over time - but without us being able to say that e.g. a book with mass 1kg or a bag of sugar with mass 1kg was once thrown in. We can't distinguish the two cases - the information (as far as we know today) is lost.

The article addresses that:

> This problem is far too small to saturate the GPU, even with such a large batch size. Time is dominated by moving batches from the CPU to the GPU. Unfortunately, as the batch sizes get larger, we need more epochs to reach the same accuracy, so we can hit a limit in terms of maximizing accuracy/time.

The batch size in their example is 2048.

I think this is a great opportunity - actually being able to show real-world (though small) nets in an educational context is great. This means students can try & tweak the net without requiring access to a big cluster or tons of beefy GPUs.

Not necessarily, no - the "perfectly efficient" algorithms often have prohibitively high constants in front of the theoretically perfect big-O, making them only useful/faster for numbers with so many digits that you can't realistically represent a lot of them, even on modern super computers. On top of that, caching effects and different implementations can make algorithmically "worse" code perform better for longer than naively assumed when comparing their big-O.

I've been using this over the past few months and so far, the only thing that really bothers me is that there's no UTF-8/Unicode category selectors support in their self-rolled regex engine, citing not wanting to ship a unicode character database to keep the editor small (only mentioned on IRC, sorry). This makes writing syntax highlighting extensions a pain/difficult to maintain[1].

---

[1] https://github.com/mawww/kakoune/issues/4411

I think they're saying the planes in particular are the tangent vector space in 3 dimensions. They're no longer the tangent vector space in 2,4,5.. dimensions, but they're still a thing there as well.

Another alternative is to use the Base.Checked.* family of functions, though they have different names than (+) like checked_add and thus have to be explicitly used.

Ah, that link doeesn't seem to be in the paper (at least my searching for `github` didn't turn up anything), thank you! I did however find the same code as part of the visualization, so I got what I was looking for.

If you're thinking about how in e.g. python, integer addition never overflows and is always a big integer, then yes. If "small"/machine integers and big integers are seperated each have a distinct type, promotion on overflow would introduce a type instability on every addition (not only the overflowing one!). This is precisely because the type would depend on the result of the addition, not only the input types (which may both be machine integer types).

A "solution" to this conundrum is to have big integers by default, which sadly isn't feasible for performance reasons - you can't then take advantage of hardware, because every operation necessarily has to do more work than would be required for machine integers.

--

To add on to this, when encountering overflow (which doesn't happen often in the first place), it's usually sufficient to go for 128 bit integers first instead of jumping directly to big integers. They're still quite a bit faster and offer a much larger space to work with.

Hi, thank you! The paper mentions that the dynamic analysis code is written in julia and could be used by package developers to study instabilities in their code, but I couldn't find a link to the code in the references. Did I just miss it or is it contained in the zip containing the visualization data?

--

EDIT: Nevermind, found it in the zip!

Which part of that long list of things specifically rules out possession of nmap, a tool used by sysadmins all over the world to help ensure that their own systems are more secure, by ensuring that only specific ports are open for communication?

Mapping a network is not an activity exclusive to criminals.

> The main pain point is probably the lack of standard, multi-environment packaging solutions for natively compiled code.

Are you talking about something like BinaryBuilder.jl[1], which provides native binaries as julia-callable wrappers?

--

[1] https://binarybuilder.org

According to this[1], Julias threading/task model is in part inspired by Go. I don't know about any detailed analysis on similarities and/or differences though.

[1] https://julialang.org/blog/2019/07/multithreading/

Not sure if it's still relevant (article is quite old after all), but does [1] still hold true in regards to /boot on ZFS on linux, even with zfsbootmenu? What kind of issues can I expect? Is there a newer/better knowledgebase compared to the one on pthree.org?

I'm guessing the newness/missing features of zfsbootmenu is in regards to beadm [2]?

[1] https://pthree.org/2013/01/03/zfs-administration-part-xvii-b... [2] https://vermaden.files.wordpress.com/2018/11/nluug-zfs-boot-...

The julia version also does that though