Sublinks Aims to Be a Drop-In Replacement for Lemmy - programming.dev
programming.dev
Seems like an interesting effort. A developer is building an alternative Java-based backend to Lemmy’s Rust-based one, with the goal of building in a handful of different features. The dev is looking at using this compatibility to migrate their instance over to the new platform, while allowing the community to use their apps of choice.

Link to the thread: https://programming.dev/post/8969747

Hello everyone, I’ve followed this thread yesterday and noticed a few very negative reactions towards the choice of Java. I follow Java evolution from far away, but it seemed like it was evolving in a good direction since the last few years, and that performance-wise it would make sense for the back-end of a Lemmy-like platform.

Is it indeed the case? I was just curious to see that much negativity towards one of the most popular languages.

  • AlmightySnoo 🐢🇮🇱🇺🇦@lemmy.world
    13·
    9 months ago

    The reason I said to use rvalue references is because otherwise it is an apples-to-oranges comparison: in the C++ code you have implicit ABI decisions around the call convention and whose responsibility it is to destroy the temporary.

    Yes, sure, compiling in one translation unit helps, but as I mentioned above, passing an owning pointer between translation units shouldn’t be inherently inefficient

    https://godbolt.org/z/9875qMM6Y (or alternatively: https://godbolt.org/z/9xehs3sYP)

    The assembly is identical, the ownership is clearly transferred, and this doesn’t need LTO or looking at the function bodies and is entirely done by the C++ compiler. It involves using (when available) a vendor attribute (see trivial_abi, shouldn’t be an issue given Rust devs are fine with having only one compiler anyway) and writing a UniquePtr class (shouldn’t be used in production code, what I’ve given there is only for illustration purposes) that assumes that the custom deleter cannot have an internal state.

    This is a zero-runtime-cost abstraction. Now whether the zeroing of that cost can depend on what ABI assumptions you’re ready to make, or whether you want to depend on LTO is another thing. We’re literally discussing a “problem” that is not really a problem because Rust doesn’t have the luxury yet to have that problem: you’re easily forgetting that Rust has only one compiler.

    Carbon was announced in 2022

    A project like that usually takes years, so again, very likely that they began working on it years before that. For instance, Google designed Go in 2007 and announced it in November 2009.

    • BatmanAoD
      1·
      9 months ago

      So…you had to make your own version of unique_ptr to make it zero-cost? Doesn’t that just confirm the original statement you were disagreeing with, that unique_ptr has a small runtime cost? Or was there some other reason you thought the creator of the video you shared has “no idea” what unique_ptr is?

      I also don’t understand why the standard library can’t use the trivial-abi attribute. Different implementations of the standard library aren’t required to be interoperable, are they?

      I still don’t understand what you think is “apples-to-oranges” here. If you change the Rust code to require the C ABI, there’s no difference in the generated code: https://godbolt.org/z/1xf9qG3n8