What are your opinions on the future of back-end web development? Is the Java ecosystem going to wither away as more modern and better solutions are emerging and maturing?

If so, which language/framework and/or programming paradigm do you think will become the new dominant player and how soon?

Personally I would love to see Rust becoming a new standard, it’s a pleasure to write and has a rapidly growing ecosystem, I don’t think it’s far away from overtaking Java. The biggest hurdle imo is big corporations taking a pretty big risk by choosing a relatively new language that’s harder to learn compared to what has been the standard for decades.

Playing it safe means you minimize surprises and have a very large amount of people that are already experts in the language.

Taking the risk will definitely improve a lot of things given that you find enough people that know or are willing to learn Rust, but it also means that you’re trading off Java flaws with Rust flaws. That’s the case however with every big change, and Java flaws are a good enough reason to make a big change.

  • @keef
    link
    2410 months ago

    I’m surprised no one has mentioned golang. We have the usual dichotomy of java and rust but there’s a very very good option for those who are worried about rust adoption.

    I vastly prefer writing rust code but go on its own gets you very very similar performance at the cost of developer experience. I think sum types are the #1 requested feature so once that comes I’ll be a much happier boy.

    • @[email protected]
      link
      fedilink
      1110 months ago

      I think Golang had the potential to take over just because it’s so easy to pick up and start contributing.

      My last position was Golang focused and our hiring was never focused on experience with the language because we knew that if you understood programming concepts you would succeed in Golang.

      Today, I’m working on Rust and while I enjoy it for what I’m using it for (Systems level instead of Web Services) I’d be hesitant to suggest it for most backend application just due to the ramp up time for new developers.

      tl;Dr Golang will have an easier time hiring for because no language specific experience is required.

      • @philm
        link
        510 months ago

        I’d be hesitant to suggest it for most backend application just due to the ramp up time for new developers.

        I would probably suggest Rust for that exact reason, you’ll have to fight the language a little bit at the beginning (at least if you’ll have a very “interior mutable” experience instead of a functional background), but it teaches you how to write your code in a nicely relatively uniform compositional safe style, that IMHO can be read quite well between different people (team) and I think is easier to review (as long as it’s not some super magic trait-heavy/proc-macro code of course, but I think for actual applications (vs libraries) that part will be rather low)

        Also I think nowadays the barrier into the language is much lower than it was a few years ago. The tooling, specifically rust-analyzer (and probably Intellij Rust too, never tried it though) and the compiler itself got really good in the meantime (I actually think Rust-analyzer is by now the best LSP for any language I know of), so that getting into Rust is likely not that hard anymore (you’ll have to learn/understand a few concepts though, like heap/stack and the lifetime system, but I think that it’s not that hard to learn).

        Go just often feels very hacky to write with a lot of quirky things like handling errors, and a lot of missing features like pattern matching or a relatively good type system, I don’t think it really promotes that nice architectures (or limits the programmer kinda).

      • @keef
        link
        310 months ago

        Yeah it’s pretty crazy how fast you can get going in go. As long as you are aware of a pointer you are mostly good to go.

        Just wish it felt better 😫

        • @echindod
          link
          210 months ago

          What is it about go that doesn’t feel good? I have this feeling myself.

          I didn’t enjoy parsing JSON with Go, and I the documentation sucked. But it was really really easy to stand up a simple API endpoint. I would have reached for go for the project I am currently working on, but it didn’t have the libraries I needed. It’s interesting.

          • @keef
            link
            310 months ago

            It’s the usual if err != nil return err critique.

            If you could yoink the question mark operator from rust AND support sum types that would be the dream.

            The marshaling isn’t too bad unless you need to do more specific things. I vastly prefer how rust’s serde does it but that language is the forbidden fruit

    • @[email protected]
      link
      fedilink
      410 months ago

      I’m on the boat that rust is a bit more cumbersome to write that Java/C#. I work in .Net and I really want to give Kotlin a go now.

      I guess I’ll just have to wait for MS to add the current trendy feature to C# again for the sum types though lol.

      • @philm
        link
        -310 months ago

        I actually think java is more cumbersome to write, Rust is definitely higher cognitive load though (get the typing right, fight the borrow-checker etc.).

        With cumbersome I mean, that the language limits yourself with a relatively bad type system (compared to Rusts) and often results in a lot of boilerplate and IMHO generally promotes the wrong patterns (I think https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition brings this on point in a comical way). But I’m biased, I much prefer functional programming vs object oriented programming…

        • @[email protected]
          link
          fedilink
          110 months ago

          I remember reading the Hello World edition of that one. I haven’t gone through a big project and a couple of small ones with rust so I’ll have to stop talking hahaha.

          But yeah writing inheritance heavy code in Java is the absolute worst and not everything needs an interface and not everything has to use the strategy pattern for a single use case. Java promotes overkill dependency spaghetti so I get that, however interfaces work the same as Rust traits and can be used in the exact same way with POJOs so I’m on the fence.

          I’ll have to wait and see which one I’ll like more I guess.

          • @philm
            link
            110 months ago

            Well just program a little bit more Rust, at some point you don’t want to look back haha. It’s almost like a curse for me, I can’t really enjoy programming in another language anymore (ok not completely true, but at least the major languages I had to use before like C# or Typescript etc. feel dirty and limiting now ^^). I would enjoy something like Haskell with better tooling anonymous sets, less laziness and a slightly more opinionated syntax though (having all kinds of weird operators sometimes looks a little bit brainfuck). Sometimes Rust is a little bit boiler-platy and gets complex when you’re overusing fancy trait-based generic code (but it’s kinda fun, you can do a lot of fancy stuff with traits), and often the type system is limited compared to Haskells, if you’re approaching higher-kinded types territory…

    • @CodeMonkey
      link
      110 months ago

      I have not done much GoLang development, but I am working on automating some dependency updates for our kubernetes operator. The language may be good, but the ecosystem still feels immature.

      Too many key libraries are on version 0.X with an unstable API. Yes, semantic versioning does say that you can have breaking changes in minor (and patch) releases as long as the major version is still 0, but that should be for pre-release libraries, not libraries ment for production use.

      • @keef
        link
        110 months ago

        Too many key libraries are on version 0.X with an unstable API

        Sounds like my rust experience but then again it’d be non-existing for some of them.