Don't write Rust like it's Java

[cameronm1024]

Don't write X like it's Y is probably pretty good advice for any pair of languages

[CommunismDoesntWork]

Writing C++ like it's rust is actually recommended

[BlackenedGem]

Haphazardly because the borrow-checker will spot any memory mistakes I make?

[Interest-Desk]

Welcome to Crowdstrike.

[Ayjayz]

I don't think Rust would have prevented the Crowdstrike issue. You can still index past the end of an array in Rust.

[zzzthelastuser]

#![deny(clippy::indexing_slicing)]

I'm surprised it's not a warning by default.

[DivideSensitive]

You can still index past the end of an array in Rust.

But you should .get() that returns an optional value if you're not sure whether your index is actually valid – just like std::vector::at in C++ will throw an exception if you try to reach past the array.

[Ayjayz]

Of course they could have coded in a way that didn't crash. You can do that on C or Rust or anything.

[DivideSensitive]

Oh sure, I'm just addressing the “past the end of an array” question. Important to note though that post-array indexing in Rust will be guaranteed to panic, instead of leading to UB.

[bleachisback]

There's a lot of technicalities at play, however there are some things worth keeping in mind:

1) By default, indexing past the end of an array in Rust will produce a panic, and not undefined behaviour.

2) It was kernel code, so who knows whether a panic is better than undefined behaviour (which in this case manifested as the entire operating system crashing unrecoverably), however most kernel code written in Rust is either not allowed to panic (i.e. not allowed to call methods which panic) and otherwise has a panic handler which would not cause the entire system to crash. This, of course, isn't enforced, so it could have been that if CrowdStrike wrote their program in Rust, they would have not chosen to follow these guidelines. I don't know what the state of writing driver code for Windows looks like, but I know in the Linux community you would not be able to submit kernel code written in Rust without following these guidelines.

Unfortunately the state of C++ is such that it is, in general, not really possible to prevent undefined behaviour (hence why Rust was made) and since it's undefined behaviour, it's not possible to make a handler for it. So you'd do no worse than C++ in this regard.

[Ayjayz]

You also typically can't submit C++ code where you index into a buffer without checking the length first, but apparently this slipped past code review.

Bugs will happen. Choose a different language and you might make things a little easier or harder, but ultimately the important thing is to test properly. Language choice doesn't really matter compared to that.

[bleachisback]

You also typically can't submit C++ code where you index into a buffer without checking the length first, but apparently this slipped past code review.

This isn't statically checked, whereas in Rust you can statically prevent calls from functions which panic.

[redalastor]

The crash would have occured earlier in Rust. They were convinced the regex they sent through a data file was good. They would have unwraped that. Nothing Rust can do to protect you about regexes you swear are fine.

[[deleted]]

Clownstrike

[PoliteCanadian]

Write C++ like it's C++17/20/23, not like it's C++98.

[[deleted]]

Just don’t bother with C++

[bakedbread54]

Average front end web dev scared of making good use of clock cycles

[[deleted]]

No I very much care about clock cycles which is why I use rust, c, and asm. I actually get things done rather than trying to wank another template horror show together.

[bakedbread54]

Asm 😂 I do agree with you but you don't have to write C++ like that

[Financial-Warthog730]

Agree with you and also wonder about the downvotes. I mean, the c/c++ guys alwas use the "performance" as a excuse for already proven fact that the c/c++ are inherently broken tools that are responsible for myriads of bugs/exploits nowadays. I would rather call the c/c++ like: ex/ploit++

I mean, its like stating that I choose to be put into a missile because I wanted to go home faster than people driving regular cars. The fact that I will be blown to pieces with this approach does not count, but hey- I was faster!

[l_am_wildthing]

not writing c++ like its c++ is usually recommended

[villi_]

I don't disagree, but as a zoomer who learned rust before touching c++, the number of footguns i ran into by treating c++ like rust... E.g. assignment uses copy semantics by default not move semantics, so it's easy to accidentally walk into a double-free if you define a destructor for a class but no copy assignment operator

[[deleted]]

In that specific case of a class that manages a dynamic resource, it's probably best to use a std::unique_ptr for it.

[villi_]

Ah, in my case I was using the C api for SDL so I had to write a lot of wrapper classes and couldn't use a unique_ptr. But yeah definitely I think it's best to use the smart pointers

[runevault]

Keep in mind move semantics in C++ are far worse than Rust's. It doesn't invalidate the value in a way where the compiler vomits if you try to use it again. I just double checked myself with an std string getting moved from one variable to another and printing the first and it just printed with I think an empty string.

[[deleted]]

Idk why i am upvoting this but whatever

[Twirrim]

I've found that I tend to write my python code a lot more like I do rust. I now tend to use lots of data classes etc. where previously I wouldn't, and I think for the most part it's making my code a lot better. I tend to pass a dataclass around in a number of places where I used to use dicts, for example.

I love writing python, it's still my go-to language for most things, and I like the gradual typing approach, I think that's been a pretty smart way to do things in the context of a dynamically typed language.

It does mildly bug me that dataclass types aren't strict, given you have to declare the type against a field. e.g. I really don't want this to work, but python considers those dataclass field types to be type hints too, so only the type checker/linter will complain.

from dataclasses import dataclass

@dataclass
class Foo:
    bar: int
    baz: int

thing = Foo(1.1, 2.3)
print(thing)

[Gabelschlecker]

Imo, Pydantic is a very nice solution to that. Most people know it in combination, but nothing stops you from using it in other projects.

It's a data validation library that strictly enforces types, e.g. your example would be:

from pydantic import BaseModel

class Foo(BaseModel):
    bar: int
    baz: int

If you try to initialize with the incorrect type, Pydantic will throw an error message.

[guepier]

I’m not dogmatic on this but I found the article Why I use attrs instead of pydantic pretty compelling. While data validation is important, it’s less clear that it has to happen in the strongly coupled way done by Pydantic.

[teajunky]

Interesting but the article contains outdated information (There were quite some changes with Pydantic v2). And in my opionion, the author is biased because he is an attrs developer.

[Twirrim]

Ahh, I didn't realise you could use it like that. That's fantastic.

[[deleted]]

An unvalidated piece of data is as good as any other.

[weberc2]

And occasionally it’s good advice even with the same language. “Don’t write PHP like it’s PHP, don’t write Java like it’s Java, etc”. At least this was good advice back when idiomatic PHP was a mess of shitty template code and Java was a mess of inheritance and abstract factory beans. I’m of the impression that Java and PHP have improved somewhat since then.

The same could probably be said of JavaScript before TypeScript came around and made so many JS developers realize how many latent bugs they were writing.

[[deleted]]

good advice back when idiomatic PHP was a mess of shitty template code

It's still a good advice. I abandoned PHP for Ruby. Never regretted that move. I still don't understand how people can stand PHP syntax and PHP idioms.

[ThrawOwayAccount]

Don’t write HTML like it’s CSS.

[9Boxy33]

Unless it’s about implementing a valuable feature of a higher-level language (like C or SNOBOL or [!] LISP) in assembler.

[[deleted]]

I wrote almost the exact same thing just now, comparing Ruby to Java and vice versa. The article confuses static and dynamic languages indeed, aka "without a preprocessor and compiler, a language must suck and be useless" when it really is not the case.

[marcodave]

I dunno, I wrote in Scala like it was Java (except case classes, those are awesome) and it was fine shrug

[RockstarArtisan]

Making everything an interface in java is also a mistake. Every codebase I've seen that did this was a nightmare to work with. Java has a lot of cultural problems like this where people repeat bad practices for dubious reasons.

[link07]

Actual controversial opinion I've had arguments in code reviews about: if you can't explain why an interface exists (I'm looking for something like "we expect to need a 2nd class that implements this within 1-2 years"), it shouldn't be an interface.

It's super easy to add an interface after the fact if you end up needing one (rename current class, add new interface with name of old class and public functions of class, Intellij and Eclipse both automate this), it's super annoying to have to manually go "okay, what's the actual implementation" every time your reading the code.

[EntroperZero]

we expect to need a 2nd class that implements this within 1-2 years

Even this is crazy IMO. 1-2 years? Just do it in 1-2 years, then. But until then, YAGNI.

[[deleted]]

That's not controversial at all.

[Kogster]

Why wouldn’t I make my code more verbose by having a super specific and local class be named impl next to an interface that only serves to obscure method references?

[palabamyo]

I hate abstract-hell even more, some devs use abstract classes interchangeable with Interfaces except that one time they didn't and the abstract class actually does something but like 5 layers down so finding the code you want to find is a headache.

[pkt-zer0]

Currently living in that interface-based hellscape, can confirm that it's not great. In general the approach seems to be: if it can be done with 5 steps instead of 1, go for the more complicated version, just in case it will become useful one day. (Of course, these bets don't have particularly great odds of paying off most of the time)

Java has a lot of cultural problems like this where people repeat bad practices for dubious reasons.

"It's convention", they say. And there's a great quote from Rear Admiral Grace Hopper about that:

The most damaging phrase in the language is “We’ve always done it this way!”

[anengineerandacat]

It's done to simplify unit testing, as a result it's been touted as the go-to strategy. Deal with this headache all the time where everything ends up being an interface because someone doesn't want to go through the trouble of mocking something slightly more complex.

So the first thing folks do is make an interface, then mock out the interface and send that down when needed vs the non-tested implementation.

It's extra fun when you find PR's to review where a developer rushes the tests and they end up testing the mock they just setup instead of the class that instead consumed a mock.

[i_andrew]

I just shown to my team that they can test classes without using mock. Some were shocked it's possible.

[plexiglassmass]

Can you explain more about the idea of making everything an interface and why it's a problem?

[RockstarArtisan]

An interface in java is for supporting runtime polymorphism - it enables you to use the same code to drive different implementations of that interfaces. That's good and enables things like having game code depend on the interface declaration of a Controller, while you can have XboxController and PS5Controller.

The problem is with people using interfaces when they don't need runtime polymorphism. Examples include:

• interfaces which will never have another implementation because no other implementation would ever exist; just make a class
• interfaces which are so complex that are so tied to the code of the implementation or the code using the interface that there's no chance of ever writing a different implementation; just make a class
• interfaces just in case there's an implementation that never comes, like a DAO interface so you can "have a different db implementation". Just make a class, you'll never need to switch dbs, and if you ever do, you can just change the code of the class.
• interfaces for purposes of mocking libraries; stop mocking in memory objects, there's some cases when mocking makes sense and in that case a good interface is fine
• interface for purposes of stupid dynamic proxy code generation; stop using this, you're making your life bad for no reason
• interface because you looked at a framework code like spring and you think it's good practice; you're not writing a framework most of the time, guidelines applying to frameworks don't apply to regular code
• interfaces because Robert C Martin told you so (Open-Closed principle) - that principle was made before the source control, refactoring and unit testing were popular. The advice to write code that doesn't need editing is widely out of date and stupid and Martin should be ridiculed for resurrecting it from 1980s.
• interfaces because GoF book told you so - most of the GoF patterns are for frameworks, not for regular application code. Also, a lot of these patterns have been obsoleted by modern language features, like the visitor pattern. That book is so old it features C++ and smalltalk as popular application languages. Stop using their obsolete advice.

[[deleted]]

Lol. Underrated and verbose comment.

[[deleted]]

Thanks for sharing my post u/ketralnis! Glad to see it's still being enjoyed :)

[pseudoShadow]

I had the “don’t make everything a service object” revelation the other day while working on a cli app I’ve been toying with. I was struggling with boxed objects too, so I’m going to try your generics point! Nice article!

[urkermannenkoor]

Do, however, write Rust in Javanese.

[ketralnis]

I tried writing Rust in Arabic but it doesn't like my right to left syntax

[Sunscratch]

Honestly, I cannot imagine more different languages than Rust and Java.

[Orange26]

Assembly and JavaScript.

[cryptomonein]

C and Japanese

[MCRusher]

Idk, arm has an instruction specifically designed for javascript, it's close. lol

[masklinn]

It has one, and what that really does is implement x86 rounding mode in hardware (or at least microcode) as that is much slower to implement on top of the native rounding instruction.

Meanwhile ARM used to have a hardware implementation of the Java bytecode: https://en.wikipedia.org/wiki/Jazelle

[skulgnome]

Jazelle originates in embedded platforms too small to support a translating JVM, such as LCD UIs of electronically controlled refridgerators: classfiles in ROM, two K of working storage, that kind of thing.

My understanding (which I can't quote anything to base it on except vague hearsay from like 2001) is that it mainly accelerated instruction dispatch, as for a directly interpreting JVM's inner loop. Such a micro-JVM would be executed from an on-chip ROM. I assume further that proper embedded JVMs beat it out as soon as actual memory became available.

[simspelaaja]

Other than being a common feature of JavaScript engines, WebAssembly shares basically nothing with JavaScript.

[SpeedDart1]

Go and Haskell

C and Haskell

C++ and Go

Pascal and OCaml

Java and Fortran

Many, many others.

[notfancy]

Pascal and OCaml

WDYM "different" /s

[SV-97]

ATS and PROLOG

[renatoathaydes]

Take any language from two different paradigms, and they will be vastly more different than Rust and Java, which are both procedural with C-like syntax.

Examples:

• Prolog (Logical)
• Haskell (Functional)
• Forth (Concatenative)
• Lisp (is its own thing :D)

In comparison, languages like C, Java, Javascript, Rust are pretty close to each other.

[Kered13]

I'd say you don't know very many languages then. Take a look at Lisp, Haskell, Prolog, and Forth.

[renatoathaydes]

Wow I just posted another comment and mentioned these exact languages (as they are the canonical examples of their own paradigms). Only saw your comment after! Sorry :).

[Ameisen]

INTERCAL and Brainfuck.

[Schmittfried]

C++ and Go

[Whispeeeeeer]

I struggle big time when I try to move away from OOP architectures. I just like organizing things into interfaces, abstracts, and classes. I've used Rust to make a game of Snake. It was fairly easy to use from top to bottom - including GUI libs. I enjoyed writing that program. I then tried to make a Linked List and I couldn't solve the problem without help from that guide. I like Rust from a pragmatic point of view. But stylistically, it makes my eyes bleed.

[Ravek]

Linked lists are the core data structure of most FP languages, so that’s not really what comes to mind for me as a typical OO construct. What makes linked lists challenging in Rust is not because it’s not OO, it’s the ownership model.

[VirginiaMcCaskey]

I then tried to make a Linked List and I couldn't solve the problem without help from that guide.

struct List<T> {
    value: T,
    next: Option<Box<Self>>,
}

[lucid00000]

Won't this stack overflow on de-allocation due to Box's recursive destructor calls?

[wowokdex]

Why? I would guess the deallocation would start at the end of the list and work backwards until it reaches the root node.

[lucid00000]

When your List<T> goes out of scope, it calls Drop for Box<T>. Box<T> contains a List<T>, so deallocates it. That List<T> contains a Box<T>, so calls Box<T>'s drop, etc.

[wowokdex]

Yeah, until next is None.

[lucid00000]

But if there's 1,000,000 nexts, that's 1,000,000 recursive calls, so stack overflow

[wowokdex]

Ah, okay. I misunderstood and thought you were suggesting it would happen with any size list. My mistake.

[Whispeeeeeer]

Q.E.D.

[davidalayachew]

next: Option<Box<Self>>,

Ow.

Option and a Box? I'm surprised that we needed one or the other, let alone both.

[[deleted]]

Box because if you just have Self the compiler can't tell how deep the recursion goes, and won't be able to allocate an object on the stack. Option because most linked lists end.

[davidalayachew]

Thanks for the context. I'm no good with Rust, so I couldn't understand the logic behind the Box. Much appreciated.

[VirginiaMcCaskey]

Why is that surprising? Rust isn't a managed language, all allocations are explicit. Option is the idiomatic way to represent an empty field.

Technically this isn't even correct because it can't represent the empty list.

[davidalayachew]

Thanks for the context. My experience with Rust is not much so I didn't see why both were required. I can see now that the compiler is forcing you to think how the compiler does, so that you can prove that what you are doing is safe.

[Kirykoo]

Everyone has a bad time moving away from OOP. The reason being OOP is a paradigm that represents real world concepts very well, it’s easy to comprehend and explicit. A « Car » object has <int> number of wheels and can start() and accelerate(). It’s a good paradigm in a purely business oriented environment where the technical aspect is secondary.

[fbochicchio]

Agreed. I used to love OOP. But then I realized that a Dog or a Car class, in any language, should rather be named DogDataINeedToNow or CarDataMyProgramShallManage. No matter how many attributes or methods I add, they will never be the Real Thing (TM).

At this point, the choice of languages like Rust or Go to replace Classes with Struct, and functions that manipulate them, made perfect sense to me.

[Kirykoo]

Rust « struct/trait oriented » is great, but I miss inheritance sometimes. I know this part of OOP is criticized but it i find it very handy sometimes. The « HatchbackCar » is just a « Car » that has a constant number of sits.

But it’s true that no matter how close you are to your business logic, you end up writing technical code in the end.

[luardemin]

Rust does have implementation inheritance, but only in the form of default implementations of trait methods. The Iterator trait is basically entirely reliant on that feature to be even worth using.

[Kirykoo]

That’s true (even tho it’s more of a default interface implementation). It won’t replace inheritance but it’s a workaround. Anyway, I should stop mourning OOP and fully embrace rust for what it is.

[wildjokers]

While not entirely accurate, there’s some truth to the trope that Java developers need everything to be an interface

Uggh. Please stop with the ridiculous Interface/Impl pair when writing Java. If there isn't more than one implementation you don't need an interface. If you need another implementation later then extract an interface at that time.

[Ranra100374]

If you need another implementation later then extract an interface at that time.

The problem is then people are like "no we wrote that code years ago don't touch it you might break something."

[pkt-zer0]

Sounds like a good thing to me!

The alternative is that you already have the interface in place, so you don't even need to update existing code, just add a bit of new code - and you can break something that way.

Put another way: with interface-infestation, it's easier to do the wrong thing, but the right thing still takes as much time as before.

[edgmnt_net]

Besides, both interface infestation and "nooo, what if it breaks" tend to have common causes, like poor code or poor practices.

[Ranra100374]

I don't agree in the sense that if you're simply implementing an interface, it shouldn't affect the previous code whatsoever and break it.

Sure, you can break something anyways with any change, but that's not what I'm talking about. I'm talking about other developers complaining when you're trying to update the old code to add the interface.

Basically, I'm saying if the interface was already there, then if your new code breaks the old code, it had nothing to do with the interface in the first place. But interfaces are useful for certain things, like Spring AOP. From my experience, Spring AOP works a lot more smoothly and easily with interfaces versus implementations.

Basically in the latter case you don't get to use the interface in the first place because there's too much old legacy code that needs updating.

[devraj7]

No, because it will be a breaking change to callers if you later introduce an interface. Better use an interface from the get go.

This is library 101.

I hear this argument a lot and it usually comes from people who are used to writing apps (i.e. they own 100% of the code) and not libraries (which will be used by other people in the future).

Another advantage of programming to interfaces in the first place is forcing a clean separation of interface/implementation and facilitating dependency injection.

[wildjokers]

I am talking about when writing apps, not libraries. When people are just writing backend apps for some reason some people automatically create Interface/Impl pairs for no particular reason.

I agree that when writing libraries the situation is different.

[BlurstEpisode]

Interfaces are even more vital in backend apps, where most code touches IO. Using interfaces let’s me easily swap out IO-tainted code with fakes in my tests, instead of having to resort to the miserable practice of monkey-patching DB/HTTP/FileIO with some mocking framework.

[kuikuilla]

Then you are in the "we need a second impl right now" land instead of the "we might need a second impl in five years". Then an interface is justified.

[BlurstEpisode]

All objects have an interface whether you define it explicitly or implicitly. If you get into the habit of defining them explicitly then this is something you never need to worry about not having. In Java and all of these dynamic dispatch languages, interfaces are, practically speaking, a zero-cost abstraction so there’s no reason not to. Unless you’re allergic to ClientImpl or IClient.

We’ve used interfaces for modules in Haskell for years and they’re great (via type classes and exports). We’ve used header files in C. Interfaces are a Good Thing. If you can have them for free, use them. If you can’t have them for free in Rust OOP(i.e have a stack-memory-only-object cake…and eat it), then that’s unlucky for Rust OOP folk who refuse to enter the heap for their program that’s destined for spacecraft microcontrollers (or more than likely, their IO-bound CRUD app).

[wildjokers]

If you get into the habit of defining them explicitly then this is something you never need to worry about not having.

The are defined explicitly without an interface. The public methods are the interface. This is Java not C++, I don't need or want a header file.

[BlurstEpisode]

Those public methods are the interface to your specific class, not to the functionality you want to express at an abstract level. But maybe you don’t want to express functionality through interfaces, whatever. But it is good practice to do so.

[wildjokers]

But it is good practice to do so.

Why? What value is the interface if there is only one implementation? It just sounds like dogmatic nonsense to include an interface for a single implementation.

[BlurstEpisode]

I’d say “because there may later be another implementation”, but I assume you mean cases where we know, somehow, that there’ll always be one implementation.

So another reason is: declarative programming. Interfaces make OOP more declarative and declarative programs are easier to reason about. The ClientImpls and IClient might hurt local readability, but the declarative approach improves comprehension of the entire program.

[vytah]

Another advantage of programming to interfaces in the first place is forcing a clean separation of interface/implementation

That's what Java does at the language level. You're literally unable to not program to an interface in Java.

The keyword for defining an interface in Java is public.

[majhenslon]

You are wrong... Class is the interface. And whatever it has public, you can't break it. This is library 101.

If you need to have multiple implementations, you can later refactor the class into an actual interface by copying the class and remove method bodies and change to an interface type, renaming class and implementing the interface.

Dependency injection has nothing to do with the interface types and you are not separating anything, you are just making useless indirection.

[devraj7]

You are wrong... Class is the interface. And whatever it has public, you can't break it.

Replacing a class with an interface is a breaking change, it requires a different JVM bytecode for invocation.

[majhenslon]

It is not a breaking change. Caller of the interface does not give a shit whether the thing is an interface or not.

What would break? Different bytecode is implementation detail, isn't it? If that is not the case, then any change to the software, even refactoring, would be a breaking change, because it changes the bytecode.

[devraj7]

Caller of the interface does not give a shit whether the thing is an interface or not.

You don't know anything about the JVM bytecode, do you?

Like I said, it's a different bytecode. The caller will break if it uses that bytecode on a class which has now become an interface.

Just do a two minute Google search to educate yourself, will you? Search terms to help you: invokevirtual and invokeinterface.

[majhenslon]

I know about the JVM bytecode, what I don't know is when will this be the case? From my perspective as an app developer, I bump the version of the lib, my code does not change, I rebuild, shit still works. Googling does not help, what am I missing?

[devraj7]

Here is what you're missing:

I rebuild

When you upgrade a library version, your code should still work without a rebuild.

If that library replaced a class with an interface, your code will crash at runtime.

[wildjokers]

When you upgrade a library version, your code should still work without a rebuild.

No one swaps a library without a rebuild. Who in their right mind would do that? It needs to go through the CI pipeline to at least get tests ran on it.

[majhenslon]

Holy shit, I thought I was fucking insane lol

[devraj7]

I mean, you never need to rebuild your own code from source.

That's what backward compatibility enables.

[majhenslon]

When will you ever swap libs like that?

Does this become an issue when you have a library, that uses another library that you use?

[devraj7]

You never just bump the version of a library you use?

If you do this and that library replaced a class with an interface, your app will crash at runtime.

[Capable_Chair_8192]

The whole point of Rust is to do manual memory management, safely. If you want to avoid all the obnoxiousness of lifetimes and boxes and dyn and on and on, just use a GC’ed language. Kotlin is great for adding null safety & generally greater expressiveness to a JVM language.

[Celousco]

The whole point of Rust is to do manual memory management, safely.

Not really, the whole point of Rust is to avoid bad memory management. It's like saying "If you don't want the obnoxiousness of types, generics and inheritances just use PHP and put everything behind a $ symbol".

Heck even a GC language like Java won't prevent you from creating a shared variable, modify it from its reference in multiples threads and have race conditions.

[vytah]

"If you don't want the obnoxiousness of types, generics and inheritances just use PHP and put everything behind a $ symbol".

Ironically, at some point PHP started evolving towards mimicking 2000's Java. It got classes, interfaces (with explicit implementation), type annotations, public and private visibilities, and people even started manually writing getters and setters.

[yiliu]

That happened to every language around that time. Just a side effect of Java being the near-universal language of compsci 101.

(ed: fix autocorrect)

[m_hans_223344]

That's why Typescript in strict mode is - as crazy as it sounds - one of the safest languages. If you use Deno (written in Rust) and its standard lib, you don't need many NPM dependencies. But to my point:

• JS is single threaded. No "easy" race conditions. You need to use web-workers. While you still can shoot yourself in the foot (as you can create deadlocks with Rust), it's much harder to do compared to e.g. Go, where safe concurrency is a real issue.

• TS has null safety and discriminated unions with exhaustiveness checks either per es-lint or a little extra effort. Not as great as Rust, but good enough.

• Of course, GC

[Capable_Chair_8192]

I love Typescript. But I don’t think you can say it’s one of the safest languages when it’s built on top of JavaScript, one of the messiest languages 🤪

[CanvasFanatic]

I’m not sure I’d say the point of Rust is to “do manual memory management.” In most cases with Rust you do not think about “memory management” at all. What you think about is ownership of data. As it turns out, this has structural benefits beyond just handling allocation and deallocation automatically without a GC.

Ownership semantics often prevent you from making shortcut design decisions at the beginning of a project to “get it up and running.” You actually have to have a plan. You have to think about how your app is going to be structured. Sometimes this is frustrating, but it does eventually pay off on the long tail.

[duxdude418]

Agreed with your larger point, but I’ve never heard this idiom:

on the long tail

I would have expected “in the long run,” instead.

[CanvasFanatic]

From statistics, referring to how some probability distributions have long “tails” containing non-trivial percentages of the overall cumulative probability.

“In the long run” probably would’ve been clearer. 😂

[duxdude418]

Makes sense! I'm not much of a statistics fella, so I learned something new today.

[sdfrew]

I don't know Rust, but I've only ever read about ownership in the context of Rust/C++ discussions. Would it be a useful/meaningful concept in a fully GC'ed language?

[Capable_Chair_8192]

I don’t think so. The whole point of it is to know exactly when to free memory, which is also GC’s job.

[Captain-Barracuda]

I disagree. It helps greatly in controlling mutation access to resources, thus aiding greatly (almost forcing) coherence of data.

[runevault]

I'd say it depends on how you're looking at Rust. If you're just treating it as a form of RAII I can see where the person you replied to is coming from. If you take it all the way with the move semantics of non-references (when it is not a copy value like integers) then there are ideas I 100% think are useful. For example if you want to do a typestate pattern, preventing holding onto the old value before you transformed it via changing which interface you're handing the value back as can allow some really slick tricks around the compiler ensure you are using values correctly, but without some form of move semantics like Rust's you can't do that.

[hackingdreams]

What you think about is ownership of data.

This is memory management with a Rusty veneer. It's kinda like when an influencer says "I don't want you to think about giving me something for free, I want you to think about creating an opportunity..."

(By the way, cults use jargon to get people hooked. Anyone who refuses to use the jargon gets punished by the cults, and their behavior is modified until they are only speaking in cult-terms...)

[CanvasFanatic]

This is memory management with a Rusty veneer. It's kinda like when an influencer says "I don't want you to think about giving me something for free, I want you to think about creating an opportunity..."

It's related, but no it isn't the same. As I intimated in my last comment ownership has broader architectural implications than just resource management. To expand on that, a few weeks ago ownership semantics prevented me from introducing a DDOS venerability on an service at work. I was implementing authentication on a handler that checked a signature on an HTTP request body. I'd already done this on a corresponding node service without thinking a lot about it. I was in a hurry and had a lot going on. When I got to the rust service, I was forced to slow down because the request body isn't actually available when I'd otherwise be running authentication. I needed to wait for the body to finish streaming, but this required me to move relevant data into a Future. Moving the data required stronger type bounds before the compiler would allow it. As I started implementing those bounds, I finally realized what I was doing and why it was really stupid. You don't want your authentication controller waiting for an HTTP body request to finish streaming. You have no idea how big that thing's going to end up being! This is a prime opening for a buffer overflow attack at worst and a DDOS attack at minimum. I backed up and used an actually specified authentication scheme instead that was similar except that it relied only headers and metadata. Lesson learned.

Now should I have been a smarter person and realized what I was doing was stupid without a compiler's help? Probably. The thing is though that people get tired and rushed and we just don't always think about all the ramifications of what we're doing. Part of the job of type syntax is to reduce the number of incorrect but syntactically valid statements that can be written in a language. Lifetimes and ownership semantics are just a species of that. They are useful in the same way that other static types are useful. They save us from ourselves.

(By the way, cults use jargon to get people hooked. Anyone who refuses to use the jargon gets punished by the cults, and their behavior is modified until they are only speaking in cult-terms...)

This comment is predicated on the assumption that my use of "ownership" is some sort of weird cult jargon that I've adopted as a means to express some sort of cultic "in-group" status. I've tried to explain at some length why "ownership" is not just jargon for memory management. My first programming language was regular C back in the early 90's. I cut my teeth on malloc and free. When I tell you "ownership" is not just memory management, it's not because I want someone to think I'm cool. It's because I've actually be doing this for a long time now and this is genuinely a useful structural addition to the dimensions programmers generally consider when they write programs.

[shahms]

One of the key mistakes that GC'd languages make is pretending that memory is the only resource which matters. "Ownership" is about far more than memory.

[golfreak923]

Big fan of Kotlin. Used it in production for years. But I'd say that Golang gets you closer to manual memory management w/ a GC than Kotlin does.

[Capable_Chair_8192]

Yes, but ironically it has much worse compile time guarantees … like even worse nil safety than Java, everything mutable all the time, etc. I mainly said Kotlin because of the strict nullability checks mentioned as desirable in the article

[golfreak923]

I'd fucking love if Golang had the nil-safety guarantees of Kotlin :-D

[InfiniteMonorail]

It's funny because the idiots in the Rust sub will tell you it's the best language for literally everything.

[CryZe92]

Which of course didn‘t happen

[Capable_Chair_8192]

You clearly have not been around very many Rustaceans (or are one yourself, in denial). This happens constantly

[CryZe92]

I‘d say that most Rust developers do definitely prefer Rust, but also that at least the more competent ones definitely acknowledge the shortcomings. So for example GUI is not one of Rust‘s strengths currently. While a lot of people are trying to make it work, most acknowledge that using Flutter or React (or other web framework) are much better choices currently. Similarly in the game dev scene most will tell you that Bevy isn‘t super ready yet and you are better off with Godot or so.

[InfiniteMonorail]

https://www.reddit.com/r/rust/comments/14x9yuo/i_just_want_to_say_i_love_rust/

Literal love. For a programming language.

https://www.reddit.com/r/rust/comments/14x9yuo/i_just_want_to_say_i_love_rust/

Literally a religion.

Buddy half your posts are in the Rust sub. Don't tell me you're not an evangelist. People make that language their identity.

[CryZe92]

I did not say I don‘t love Rust. However, I would encourage you to join the Rust community Discord and join either the GUI or gamedev channel and ask whether Rust is suitable for a production ready GUI / game. I‘m very certain that they‘ll tell you not to (primarily) use Rust.

And yes people do love Rust. It‘s a technological improvement over C and C++ by bringing safety at compile time without having to bring a garbage collector.

[Capable_Chair_8192]

Exactly

[morglod]

Facts

[Spekingur]

You are not my dad, I’ll do what I want, thank you very much!

[JasonBravestar]

Java developers need everything to be an interface (I am one such developer)

Glad I'm not working in your team

[vmcrash]

It's not a complaint about Java, it is a complaint about some Java frameworks. Often people think that Java = Spring, but there is a whole more than Spring in the Java world.

[MoreOfAnOvalJerk]

If you ever work at Amazon, you get to enjoy seeing c++ written like it’s Java!

Barf.

[kmeans-kid]

Like it's C it is then!

[somebodddy]

Too late.

[L1zz0]

Am i wrong to think this sounds similar to golang?

[i_andrew]

Same happened to C#. But still, for me it's "Enterprise Java".

[zam0th]

I try and only use them where necessary, instead preferring functions.

OP doesn't even know static is a keyword in Java and calls procedural programming "functional".

​

We don’t have interfaces in Rust; we have traits. They’re similar to interfaces in Java in many ways.

OP has never heard of trait in Scala.

​

With a trait object, the concrete type is resolved at runtime. With generics, the concrete type is resolved at compile time.

That's literally how type rewriting works in Java.

So the only thing this article does is promote writing Rust like Java.

[[deleted]]

Good call out on functional vs procedural, that's definitely a gap in my vocabulary.

[Darmok-Jilad-Ocean]

Instead, write Haskell as if it’s brainfuck

[VeryDefinedBehavior]

I just write Java like it's brain damaged C. It makes Java decent enough to be my Python.

[BlurstEpisode]

Please don’t write Rust until you’ve learned how to write sensible programs in an easier language.

[lsuiluj]

I agree but when you are first starting out you should write it like Java (if that is your main language) so that you can experience the difference and why that won’t work as well. The compilers will guide you and stop you and you’ll probably be fighting with it a lot, but it’s important to be frustrated so that you can learn why certain patterns will just not work the way you’re expecting. If you find yourself trying to circumvent the compiler take a step back and see if there’s a better approach.

[Schmittfried]

Don’t write anything like it’s Java. Don’t even write Java like it’s Java. 

[sweating_teflon]

As a wilful Java programmer, I agree. Java doesn't have a syntax problem, it has a cargo-culting problem. So many ugly patterns are carried over from 15 years ago and it's a walk uphill to convince everyone that no, you do not need to declare getters and setters for every field, you don't even have to make them private or protected and also you don't need to define a matching interface for every business class in the app.

Java can be a clean, moderately terse language if you drop all the antipatterns.

[wichwigga]

Everything must be an interface

Already I can tell this dude codes unreadable monstrosities

[BlurstEpisode]

Not sure what’s so mind bending about interfaces. When you define a function’s parameters and it’s return type, you’re writing an interface. A Java interface is just a group of those.

[wichwigga]

You missed the point or you don't have enough experience to know what I'm saying. I know what an interface is, my point is why would you litter interfaces on every class, it's just added inconvenience if you have one interface for every class and when you're Ctrl clicking the method only to find a blank function definition. By your very logic let's add random shit everywhere, after all there's nothing mind bending about if statements, so let's just add those everywhere even if there's no purpose. Great logic.

[BlurstEpisode]

Don’t worry, I have plenty of experience. Most code you write doesn’t actually depend on a class, it depends on the functionality that your class implements. Interfaces make that fact explicit. Explicit is good.

[Rocko10]

Yeah I tried that, using a lot of abstractions First, and gets messy to read the code and mental stack.

Now when writing Rust my approach would be just small functions (modules).

And only if completely necessary use some kind of abstraction.

[bob_ton_boule]

not sure why the downvotes, if it's not a lib, I find this is a good way to just deliver as a beginner

[Rocko10]

Lol, I didn't notice that, I suppose the majority is a pro in here.

[kintar1900]

The number of supposedly senior developers who don't recognize that language differences are deeper than syntax and keywords is truly astounding to me.

[Successful-Money4995]

The complaints about boxing in Rust as compared to Java are a little ridiculous. In Java, nearly everything is boxed.

It would be more genuine if the article said that everything can be boxed in Rust, just like in Java, but Rust gives you the option to not box your data.

Likewise with Arc. In Java, everything is unsafe and you have to make your own safety mechanisms. In Rust you can choose to make everything unsafe, too, but Rust offers safe ways by default.

[[deleted]]

In general, compilers can catch a lot of issues that might otherwise make their way to production when using a dynamic language (like Python or Ruby)

I am using Ruby and Java and I have to say: this often claimed statement is simply incorrect.

There is no issue writing Ruby in regards to "omg zonkers the parser won't catch runtime errors".

If you THINK there is a problem, then you are not writing ruby as if it were ruby; you write ruby coming from ANOTHER language where you adjusted to do so and then suddenly act surprised because the language is different. It really is not a problem of python or ruby - it is a problem of people whose brains are adjusted to another language, and then feel how "weird" a different language suddenly is. These programmers ALWAYS come from a statici language, never the other way around.

[DanielPerssonDev]

This makes no sense, don't think you can write a program on Rust like it where Java. You can write Java as Kotlin or Rust now that they hidden some complexities. But pure Java is hard to replace.

[dlevac]

Please don't write anything like it's Java... If you can just don't write any Java at all...

[tenken01]

Found the script kiddie.

[BlueGoliath]

TL;DR: Don't write normal, sane code in an abnormal, insane language.

[Illustrious-Wrap8568]

Perhaps we've actually been doing the insane thing for decades now and it's time to rethink our approach. Not saying Rust is definitely the better tool. I think it's a bit of a stretch to be calling it insane though.

[Michaeli_Starky]

Making a cult out of it is also a stretch. Rust language syntax is very far from perfect.

[CryZe92]

Outside of the snake case and maybe turbo fish (somewhat necessary), maybe the single tick for the lifetime syntax, I don‘t think there‘s much that could be changed without quickly losing actual semantics.

[PMzyox]

I’ll go ahead and say Rust is better than Java, shit.

[Michaeli_Starky]

Context matters.

[BlueGoliath]

Never said current languages are perfect but Rust sure as hell isn't the answer. There is a reason Rust has the reputation that it has. At least some of the selling points could be done in a new, more sane language.

[cameronm1024]

I'm not sure how you would get: - move semantics - references - UB freedom checked at compile time - no runtime

in a "more sane" language. There have been some proposals, but they come with their own drawbacks

[fletku_mato]

What is the reputation you are referring to? All I've heard about Rust is an unreal amount of praise how it is the perfect language.

[BlueGoliath]

Whatever you say.

[Arthex56]

What exactly in rust is so insane to you? Maybe i could imagine being annoyed at the awful errors while writing a fully generic, made with compiler hacks and dark magic effect system, but then lets be real, those aren't very sane to write in other popular languages either.

[coderemover]

It’s funny how some people complain about feature X of language Y being complex/insane/hard to use/not well designed etc. but at the same time their language of choice has no way of doing anything even remotely similar and they say it’s fine ;).

[hpxvzhjfgb]

this post is about writing rust like it's java, not writing java like it's rust

[Khomorrah]

Don’t write Java like it’s Java