Live data from Hacker News

Don't write Rust like it's Java (2023)

jgayfer.com

21–30 of 45 posts

Re: Don't write Rust like it's Java (2023)

#21
post #2

Of course this is on point, you shouldn't write Rust like it's Java, however looking at Java, you shouldn't write anything like it's Java. Java has brought forth the biggest madness of tacking on OOP to everything that is still making 3 billion software projects unreadable.

Even in Java, the interfaces everywhere style was never great. Somehow Java got picked up by Architecture Astronauts that love writing enterprise pattern layer cake. Nothing in the language makes this style necessary, it's perfectly possible to write short and sweet code, and yet the Java culture got infected with this overcomplicate everything culture.

I kinda prefer the interface everywhere to the inheritance everywhere crowd.

But I've mostly used/debugged groovy code so maybe I'm partial.

Re: Don't write Rust like it's Java (2023)

#22
I find myself defining my own traits very rarely these days. Traits enable polymorphic actions on data. Most of the time, you simply don't need that.

An enum often suffices to express the different combinations.

Of course, from a pattern perspective, that is "not extensible" but it often ends up being easier to maintain and in Rust, often compiles down to more efficient code.

Re: Don't write Rust like it's Java (2023)

#23
post #16

I’ve also had some success writing Java more like as if it’s rust, using Java Records instead of classes to create immutable types. I’m not sure if I would recommend it if you’re working as part of a team though, other java devs will hate your code lol.

Hasn't the use of behaviourless value objects (essentially structs) been commonplace in both the JVM and the related .NET-world for the better part of a decade now, maybe more?

From my experience, "anemic DDD inspired architecture" is fairly common in enterprise .NET codebases. These do heavily use all kinds of value object, DTO and DTO-like objects with the logic that processes them being defined separately.

Unfortunately, most of them still suffer from premature and very unnecessary abstraction bloat. Luckily, the trend for terseness and minimalism is gaining more and more momentum each year, with just a single 100 LOC Program.cs microservices with asp.net core's minimal API no longer raising eyebrows and causing arguments in the teams as much as it used to. Extensive support for pattern matching, records, closures (since a long time ago) and other ways to define strict and terse data structures is also helping to preserve functional nature of this approach.

Note that JVM does not have structs and has a long way to go until project Valhalla becomes a reality. FWIW it has been less of an issue thanks to quite strong escape analysis as implemented by OpenJDK and GraalVM, but it does not afford the same guarantees and degree of control the structs do (not to mention lack of monomorphized struct generics as in Rust and .NET). In the "average codebase", structs in .NET have not been as popular historically, but with heavy focus on "close to the metal" features in both compiler optimizations and syntax, and increasing awareness of C# being a viable and effective systems programming language, this also is changing.

Re: Don't write Rust like it's Java (2023)

#24
post #2

Of course this is on point, you shouldn't write Rust like it's Java, however looking at Java, you shouldn't write anything like it's Java. Java has brought forth the biggest madness of tacking on OOP to everything that is still making 3 billion software projects unreadable.

Nah, the architecture space astronauts just changed from Smalltalk, C++ into Java.

Re: Don't write Rust like it's Java (2023)

#25
post #2

Of course this is on point, you shouldn't write Rust like it's Java, however looking at Java, you shouldn't write anything like it's Java. Java has brought forth the biggest madness of tacking on OOP to everything that is still making 3 billion software projects unreadable.

Even in Java, the interfaces everywhere style was never great. Somehow Java got picked up by Architecture Astronauts that love writing enterprise pattern layer cake. Nothing in the language makes this style necessary, it's perfectly possible to write short and sweet code, and yet the Java culture got infected with this overcomplicate everything culture.

[deleted]

Re: Don't write Rust like it's Java (2023)

#26
post #17
post #2

Of course this is on point, you shouldn't write Rust like it's Java, however looking at Java, you shouldn't write anything like it's Java. Java has brought forth the biggest madness of tacking on OOP to everything that is still making 3 billion software projects unreadable.

> Java has brought forth the biggest madness of tacking on OOP to everything It was C++, if we are being historically accurate. It’s actually a positive in Java’s case that it managed to make these systems even run.

I love how everyone likes to blame Java for OOP, when most of the stuff that eventually ended up in enterprise OOP patterns, predate Java for 10 years.

Including those stupid "coding Java in C++" remarks, when Java OOP model is based on a mix of C++ frameworks, and Objective-C features.

Re: Don't write Rust like it's Java (2023)

#29
Generally good advice is: Don't program Rust like nearly any other programming languages you know.

If you try to program Rust like C you are going to fight and lose.

If you try to program Rudt like and Object Oriented Language you will eventually go mad.

If you like a Zen master let all previous knowledge and pre-conceived notions of what beautiful code has to be out of the window and do it the Rust way, suddenly things flow and stop being a pain.

And that experience will help you be a better programmer, period.

Re: Don't write Rust like it's Java (2023)

#30

Everybody worth their salt should know that those languages have completely different working models in mind. Java puts everything into the heap and creates easy expressability by having pointers everywhere. In contrast, Rust often avoids pointers, prefers the stack and is very stingy with memory access. These languages are completely orthogonal to each other and it has consequences in their usage. Not that a good ch…

Primitive types are placed on the stack, as are those classes proven to not escape current scope, thus not everything.

When Valhala is finally merged, then value class and value record will also not be on the heap by default.

Finally, even without Valhala, Unsafe and Panama allow for off heap allocation, thus again, not everything.

Post reply on HN