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.

  • spiderman@ani.social
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    there are no Nullpointerexceptions makes Rust infinitely better than Java for me.

    what’s wrong with having null pointer exception?

    • Tom
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      11 months ago

      Null is terrible.

      A lot of languages have it available as a valid return value for most things, implicitly. This also means you have to do extra checking or something like this will blow up with an exception:

      // java example
      // can throw exception
      String address = person.getAddress().toUpperCase();
      
      // safe
      String address = "";
      if (person.getAddress() != null) {
          person.getAddress().toUpperCase();
      }
      

      There are a ton of solutions out there. Many languages have added null-coalescing and null-conditional operators – which are a shorthand for things like the above solutions. Some languages have removed the implicit nulls (like Kotlin), requiring them to be explicitly marked in their type. Some languages have a wrapper around nullable values, an Option type. Some languages remove null entirely from the language (I believe Rust falls into this, using an option type in place of).

      Not having null isn’t particularly common yet, and isn’t something languages can just change due to breaking backwards compatibility. However, languages have been adding features over time to make nulls less painful, and most have some subset of the above as options to help.

      I do think Option types are fantastic solutions, making you deal with the issue that a none/empty type can exist in a particular place. Java has had them for basically 10 years now (since Java 8).

      // optional example
      
      Class Person {
          private String address;
          
          //prefer this if a null could ever be returned
          public Optional<String> getAddress() {
              return Optional.ofNullable(address);
          }
          
          // not this
          public String getAddress() {
              return address;
          }
      

      When consuming, it makes you have to handle the null case, which you can do a variety of ways.

      // set a default
      String address = person.getAddress().orElse("default value");
      
      // explicitly throw an exception instead of an implicit NullPointerException as before
      String address = person.getAddress().orElseThrow(SomeException::new);
      
      // use in a closure only if it exists
      person.getAddress().ifPresent(addr -> logger.debug("Address {}", addr));
      
      // first example, map to modify, and returning default if no value
      String address = person.getAddress().map(String::toUpperCase).orElse("");