363
Sublinks Aims to Be a Drop-In Replacement for Lemmy (wedistribute.org)
submitted 11 months ago by deadsuperhero@lemmy.world to c/fediverse@lemmy.world
308 comments fedilink hide all child comments

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.

you are viewing a single comment's thread
view the rest of the comments
[-] Carighan@lemmy.world 8 points 11 months ago

And what's bad about that? As in, how is the verbosity a negative thing exactly? More so because virtually any tool can be configured to default-collapse these things if for your specific workflow you don't require the information.

At the same time, since everything is verbose, you can get very explicit information if you need it.

[-] Corngood@lemmy.ml 15 points 11 months ago

Here's an example:

https://github.com/sublinks/sublinks-api/blob/main/src/main/java/com/sublinks/sublinksapi/community/listeners/CommunityLinkPersonCommunityCreatedListener.java

IMO that's a lot of code (and a whole dedicated file) just to (magically) hook a global event and increase the subscriber count when a link object is added.

The worst part is that it's all copy/pasted into a neighbouring file which does the reverse:

https://github.com/sublinks/sublinks-api/blob/main/src/main/java/com/sublinks/sublinksapi/community/listeners/CommunityLinkPersonCommunityDeletedListener.java

It's not the end of the world or anything, I just think good code should surprise you with its simplicity. This surprises me with its complexity.

[-] BURN@lemmy.world 3 points 11 months ago

I find that Java is overly Verbose, but it’s much better than the alternative of underly verbose.

Java really follows the single class for single functionality principle, so in theory it makes sense to have these located in different classes. It should probably be abstracted to a shared method, but it shouldn’t be in the same file.

At least to me this looks like simplicity, but I’ve been writing Java in some capacity since 2012.

[-] Corngood@lemmy.ml 6 points 11 months ago

It's not just the visible complexity in this one file. The point of it is to keep a subscriber count in sync, but you have that code I referenced above, plus:

LinkPersonCommunityCreatedEvent LinkPersonCommunityDeletedEvent LinkPersonCommunityCreatedPublisher LinkPersonCommunityDeletedPublisher

And then there are things like LinkPersonCommunityUpdated[Event/Publisher] which don't even seem to be used.

This is all boilerplate IMO.

And all of that only (currently) serves keeping that subscriber count up to date.

And then there's the hidden complexity of how things get wired up with spring.

And after all that it's still fragile because that event is not tied to object creation:

  @Transactional
  public void addLink(Person person, Community community, LinkPersonCommunityType type) {

    final LinkPersonCommunity newLink = LinkPersonCommunity.builder().community(community)
        .person(person).linkType(type).build();
    person.getLinkPersonCommunity().add(newLink);
    community.getLinkPersonCommunity().add(newLink);
    linkPersonCommunityRepository.save(newLink);
    linkPersonCommunityCreatedPublisher.publish(newLink);
  }

And there's some code here:

https://github.com/sublinks/sublinks-api/blob/main/src/main/java/com/sublinks/sublinksapi/api/lemmy/v3/community/controllers/CommunityOwnerController.java#L138C31-L138C50

    final Set<LinkPersonCommunity> linkPersonCommunities = new LinkedHashSet<>();
    linkPersonCommunities.add(LinkPersonCommunity.builder().community(community).person(person)
        .linkType(LinkPersonCommunityType.owner).build());
    linkPersonCommunities.add(LinkPersonCommunity.builder().community(community).person(person)
        .linkType(LinkPersonCommunityType.follower).build());

    communityService.createCommunity(community);

    linkPersonCommunityRepository.saveAllAndFlush(linkPersonCommunities);

that is able to bypass the community link service and create links in the repository directly, which would presumably not trigger than event.

Maybe there's a good reason for that, but it sure looks fragile to me.

[-] Carighan@lemmy.world 3 points 11 months ago

Yeah but that's more on the coder. Like you indirectly say, they could just as well have had a single listener for community update events, since they all share the data structure for such events (I would assume, haven't looked around too much).

And to me as a professional java coder, I will say it's just not complex. The scaffolding you mentally discard after a week of working with Java unless you're looking for something related to do the scaffolding - and then it's cool that it's all explicitly there, this has helped me countless times in my career and is one of the big strengths of such verbose languages - and beyond that and some design choices I would not have made that way related to naming and organization, there's not much code there to begin with. In modern Java you might just do this in a lambda supplied in the place where you hook the events, anyways.

[-] hansl@lemmy.world 3 points 11 months ago

how is the verbosity a negative thing exactly

Fun fact, studies have found that the number of bugs in a program is proportional to the number of lines of codes, across languages. More lines of codes, more bugs, even for the same math and edge cases. So a more verbose language tends to have more bugs.

[-] Carighan@lemmy.world 7 points 11 months ago

Interesting, but did this include web code and code only one person really ever works on?

Because on the pure backend level, I have observed the reverse over my career. The shorter, the "smarter", the "cooler" the code, the more buggy it is. Not based on the code itself, but based on the developer inevitably leaving the company at some point. Meaning that what matters all of is a sudden is how verbose, how documented and how explicit the code is, because the bugs come from someone else messing with it as they get to take it over. It's a legacy problem in a lot of ways.

Hence me saying that if solo projects are included, they probably tilt this massively as they'll never really run into this problem. Like say, you just scan github or something. Of course most projects in there are solo, of course the more lines the more room for bugs.
But in an environment where you're not solo coding, the issue is not getting the code to run and having it have no programmed bugs, but to be able to have someone else understand what you did and wanted to do in a meaningful amount of time, especially as they have to mutate your code over years and decades. Or maybe it's just that the bugs no longer are what "matters", as fixing code bugs is cheap compared to the endless hours wasted from "clever" code being unmaintainable. 🤷

[-] kameecoding@lemmy.world 4 points 11 months ago

I have a similar experience, in that anytime I heard someone hating on the verbosity of Java it was never the good devs the ones who can write a code that's readable a few months later.

this post was submitted on 23 Jan 2024
363 points (96.7% liked)

Fediverse

28737 readers
297 users here now

A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).

If you wanted to get help with moderating your own community then head over to !moderators@lemmy.world!

Rules

Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy

founded 2 years ago
MODERATORS
ruud@lemmy.world
Xylinna@lemmy.world
MrCenny@lemmy.world
TragicNotCute@lemmy.world
automodbeta@lemmy.world
woelkchen@lemmy.world