Radicle: peer-to-peer collaboration with Git

Posted Apr 5, 2024 23:20 UTC (Fri) by Curan (subscriber, #66186)
In reply to: Radicle: peer-to-peer collaboration with Git by mirabilos
Parent article: Radicle: peer-to-peer collaboration with Git

Oh, come on. You can do better. (And I might just be taken the bait as a fellow DD here, though you are way more active than me.)

Rust has several very good concepts. And it does promise some solutions for issues in other languages (especially C/C++, ASM or similar). That said: Rust also has a ton of issues, not least of it being based off LLVM and not having any other implementation (the project for adding Rust to GCC is many versions behind and has major hurdles to climb yet).

But I would always expect a better critique than "written in $language".

Radicle: peer-to-peer collaboration with Git

Posted Apr 6, 2024 15:56 UTC (Sat) by mirabilos (subscriber, #84359) [Link] (1 responses)

If “written in $language” is a problem (we have massive trouble with librsvg, python-cryptography and now also gstreamer on *numerous* ports architectures *on top of* the t64 transition), then, yes, merely that is a good enough argument in my book ;)

Radicle: peer-to-peer collaboration with Git

Posted Apr 10, 2024 22:05 UTC (Wed) by Curan (subscriber, #66186) [Link]

GStreamer I find a really bad example, though that is probably best discussed in person and not over any kind of chat. What I will say here is: the concept in general is nice, in practice it fails so much that I never used it productively anywhere. FFMpeg was always better (though, maybe, that says more of my target audience than GStreamer? I don't know. To me, in my requirements, it always felt at least somewhat hacky). Anyway, I do concede, that this is not really something a distribution like Debian can argue, once it accepted a certain piece of software.

Of librsvg I was not aware and I must admit I am surprised. A SVG parser might be messy because of its standard (and extensions), but not being able to compile everywhere was not what I was expecting.

Python I have – very personally – no interest in. So I do not have any knowledge in this space. Sorry.

That said: I can accept the argument of "needs to compile to all the platforms I/$entity" care for. That was not clear to me from your initial post. Because I do also think, that having some software available ob one system and not necessarily on all others is not an issue in all cases. That being said: that Rust is limited by its implementation/LLVM is an issue. I wish there were more resources available to the gccrs developers [0], who aim for a better and long-term hopefully better platform.

----

[0] <https://rust-gcc.github.io/>

Radicle: peer-to-peer collaboration with Git

Posted Apr 10, 2024 21:43 UTC (Wed) by intgr (subscriber, #39733) [Link] (2 responses)

> being based off LLVM and not having any other implementation

This is not technically true any more. There is a working, stable Cranelift backend. Though it generates less optimized code than LLVM/GCC and supports far fewer ISAs. https://lwn.net/Articles/964735/

Radicle: peer-to-peer collaboration with Git

Posted Apr 10, 2024 22:08 UTC (Wed) by Curan (subscriber, #66186) [Link]

Hm, I should have been clearer, I think. There are other projects like ggcrs [0], but none of them can claim – AFAIK – to be 100 % compatible with the official `rustc`. In fact: there is not even a standard – again: to the best of my knowledge – that other compilers could implement. In this regard Rust is far inferior to eg. C or C++.

---

[0] <https://rust-gcc.github.io/>

Radicle: peer-to-peer collaboration with Git

Posted Apr 10, 2024 22:19 UTC (Wed) by mirabilos (subscriber, #84359) [Link]

> supports far fewer ISAs.

The lacking support in Rust itself and LLVM was the issue in the first place, so anything supporting even *less* is… quite unhelpful.

Not to forget Cranelift itself is also written in Rust…

gccrs and even rust_codegen_gcc or what’s it’s called are also not helpful yet. They _might_ become somewhat helpful once they are available in Debian so that standard package building picks them up when building Rust packages on nōn-rustc/llvm architectures, automatically, and they are supported on all architectures and can build all the codes.

So, perhaps in a decade or something.

It’s worse than ghc, and as bad as pre-Zero Java was, no, even worse, with the GCJ situation we had a stopgap.