Rust for enterprise grade systems?

language design
1

One thing that I am genuinely interested in rust, If same thing that I can generally do in Java building enterprise grade system, I can do in Rust.

Not a secrete Java and OOP become de-factor a standard for every enterprise solution.

And my step forward, trying to bring rust into that by exploring if I can do DI, something similar to Spring Boot but following Rust philosophy of zero-cost abstraction, that lead into research some code and article, and I think I've made some progress:

One thing that is still bothering me is the Object Orient Design. Classical OOP was proven many time in C++ in Java to manage complexity of real world system.

Rust has trait model, but it is not OOP is classical sense.

I have very clear understanding how complex solution could be built with OOP in Java and C++.

Rust don't have that OOP model, that feels as weakness, but rust still offers memory safety that C++ don't have, and it still has much smaller memory footprint that Java.

Considering that Java is hard to beat, it still offering very impressive capability for runtime optimization by utilizing Escape Analysis on JIT phase, and looks like this guys in Oracle very angry, to optimize Java further, if rust will not offer competitive capabilities it will stay behind.

Let me give me you an example in Java, what I am taking about:

language = java

interface Collection {
    int size();
    Iterator iterator();
}

abstract class AbstractCollection implements Collection {
   @Override
   public int size() {
      int size = 0;
      var iterator = iterator();
      while(iterator.hasNext()) iterator.next();
      return size;
   }
}

class ArrayList extends AbstractCollection {
    Object[] array;
 
    @Override
    public int size() {
       return array.length
    }

    @Override
    Iterator iterator() {
         ...
    }
}

What is important here:

  • I have interface Collection, which is pure of any implementation, just an interface that declares the interface and nothing more.
  • That I do have AbstractCollection, that defines some default behavior which could be sub-optimial, but they are generic one, particularly I gave example of size function, that uses slow and inefficient iterator, because it doesn't know enough about concrete implementation.
  • And lastly I do have specific implementation for ArrayList, since ArrayList already know that is array driven, it can simply take property for array to know the size.

In reality this chain of inheritance can be longer, so if we look on JDK, you will see something like:

LinkedHashSet < HashSet < AbstractSet < (AbstractCollection + Set) < Collection

And each layer provides it's own set of capabilities, by amount of information available on that level, which can be override as many time as need by being closer to concrete implementation.

I feels like something missing in rust here, because when it comes to manage the complexity of enterprise, something more complex than hello-world, we need this ability to override things, override, and override again.

Any real software if it will have more than few years of maintenance it will grow, grow and grow in complexity, if language can't manage complexity, that language would be dead.

UPD:

Let's define the problem a little bit more formally:

You need to implement library for collection.

  1. On base level you need a interface, that would define set of operation, for simplicity let's go with two operations.
    • Iterator and size
  2. Than in most generic way you can just iterator is count how many items you have, but it is slow and optimal.
  3. If you know that you concrete implementation Array, you can just use property of array.
  4. Let's say you have another implementation, which implements methods like Add and Remove - you can bring counter into here, however if we already know that it is Array than counter obviously is redundant.
4

Same question on reddit: Reddit

5

When cross-posting please indicate so: Rust for enterprise grade systems? - help - The Rust Programming Language Forum

1 Like
6

That's funny because in the Java production systems I worked on a lot of the complexity came from overusing overriding, while the most manageable ones where only using simple interfaces with one level of inheritance (interface -> class and nothing else), and that's pretty much what Rust gives you.

1 Like
7

You know having interface for ever class in Java, it was something often seen in old days, but rarely today.

Many people started using Java who had C++ experience, who worked with CORBA or COM or ActiveX, in C++ there were reason for ABI Compatibility where you need to have Interface and CoClass, like IUnknown with QueryInterface method, java offers same capability but you don't need to do interface for every class, because in C++ terms Java class acts as Interface and Class in the same time, and actual binding happens really late on JVM jitter, while in C++ when you make dynamic binding of two binaries like dll or so, you need to have a common vtable decoupled from concrete implementation, that essentially is intent, totally redundant for java.

Also old Java technology RMI which is not used nowdays, it had a hard requirement similar to CORBA to have interface for every remote object, really redundant for language capabilities, it mainly about proxy generation cglib made things easier, comparing to builtin proxy generator into JDK library.

In java we doing interface, but we doing this when it's semantically proven, I think Runnable is perfect example, you have one method run where you don't know anything about implementation at all and it stays as interface.

It feels like Rust traits, follows similar approach many time, but not exactly. In Rust trait is still rather a trait for type than interface in full sense like in java.

9

Let's keep the discussion limited to one of our forums for now; the (quite active) already existing (semi-)cross post fits there well, and many of our users look at both forums anyway, so you won't be missing out on any expertise even when the topic somewhat touches on language design questions as well.

1 Like