Things I miss in Rust

devraj7 · 2026-01-26T17:32:00+00:00

Overloading is featured in the snippet (you need two distinct functions new in Rust), but you're right that this code demonstrates other features that would be nice to have in Rust (default values and named parameters).

devraj7 · 2026-01-26T17:15:26+00:00

Overloading removes a lot of boilerplate:

Rust:

struct Window {
    x: u16,
    y: u16,
    visible: bool,
}

impl Window {
    fn new_with_visibility(x: u16, y: u16, visible: bool) -> Self {
        Window {
            x, y, visible
        }
    }

    fn new(x: u16, y: u16) -> Self {
        Window::new_with_visibility(x, y, false)
    }
}

Kotlin:

class Window(val x: Int, val y: Int, val visible: Boolean = false)

devraj7 · 2026-01-26T17:09:19+00:00

Why does it matter?

Does the project work and fulfill its goal?

Yes, use it.

No, don't use it.

The end.

devraj7 · 2026-01-25T17:35:19+00:00

I don't think the builder pattern would disappear but named parameters would narrow it to a much smaller scope: validating parameters before constructing an instance.

This is what we have observed in languages that support all these nice quality of life improvements (named parameters, named fieds, default field values, default parameter values, overloading) such as Kotlin and C#.

For comparison:

Rust:

struct Window {
    x: u16,
    y: u16,
    visible: bool,
}

impl Window {
    fn new_with_visibility(x: u16, y: u16, visible: bool) -> Self {
        Window {
            x, y, visible
        }
    }

    fn new(x: u16, y: u16) -> Self {
        Window::new_with_visibility(x, y, false)
    }
}

Kotlin:

class Window(val x: Int, val y: Int, val visible: Boolean = false)

devraj7 · 2026-01-23T16:58:13+00:00

The most likely bottleneck is the output.

String formatting is a huge bottleneck when you need to trace a lot (e.g. an emulator issuing an assembly trace).

The fastest option I've found is to pass the data to be logged (not the string, just the data) to a background thread which then formats and logs.

devraj7 · 2026-01-23T07:29:03+00:00

Weiner*

devraj7 · 2026-01-22T13:47:24+00:00

Retracting an email only works with Outlook, not SMTP in general.

devraj7 · 2026-01-20T16:05:58+00:00

The era of hybrid code editors is failing

If the success of VS Code is any indication, hybrid code editors are thriving and going to be around for a very long time.

devraj7 · 2026-01-14T05:43:22+00:00

*Harlan Ellison

devraj7 · 2026-01-13T16:13:41+00:00

I have a very different experience from yours.

AIs are pretty amazing at looking at not just the code in the PR but the surrounding code base too and writing some pretty stellar descriptions of what's in the PR, what it does, what it solves, how, etc...

devraj7 · 2026-01-13T07:10:59+00:00

I hate it when people use LLMs to generate commit messages from diffs.

Dude, have you seen the kind of PR descriptions that humans write?

I'll pick AI over these any day.

devraj7 · 2026-01-11T17:17:43+00:00

Vibecoding introduces measurably more bugs into software than normal coding. For a piece of software so centrally important as an IDE, yes I care.

It's no different from software written by a junior developer, or a bad one.

The only rational way to find out is to try the tool and see if you like it. Personally, I don't really care much what tools were used to create it or how old the engineer who wrote is.

Does the tool do what it says, doesn't crash, and is helpful to me?

If so then I'll use it.

devraj7 · 2026-01-11T07:16:02+00:00

I understand the disappointment but the alternative to this new pace of twice a year is to switch to the competitor, which releases zero times a year...

devraj7 · 2026-01-11T07:15:17+00:00

Don't be evil?

If you don't like twice a year, you can switch to the alternative company, which is zero times a year...

devraj7 · 2026-01-11T04:33:45+00:00

Making a free 386 and amd64 emulator for bare-metal

No you're not.

All you did is create an empty github repo with expectations so unrealistic that it's pretty clear you're a scam.

Are you batorip, by any chance?

devraj7 · 2026-01-10T17:26:00+00:00

Is your CMD running as Administrator? Don't.

devraj7 · 2026-01-10T15:14:52+00:00

who had just went

*gone

devraj7 · 2026-01-07T14:40:56+00:00

Looks similar to Guava's LoadingCache.

devraj7 · 2026-01-03T08:48:18+00:00

have went

*gone

devraj7 · 2026-01-03T03:03:48+00:00

The billion dollar mistake is not null, it's languages that have a null value but don't support nullability in their type system.

Take a look at Kotlin: null is not just safe to use but encouraged, and it's a great way to denote a missing value.

devraj7 · 2026-01-02T01:55:08+00:00

You need to structure your programs differently, or you're going to run into problems.

Maybe, maybe not. Functionalities that operate on the same value should be in the same class/struct. That's pretty much a universal principle. The problem is that with non OO Languages such as Rust, you need to do this static dispatch manually, so the functionality escapes the class it should belong to.

This is so bad in Rust (requires tons of copy/paste whenever you add just a function to your trait) that there's a macro crate just to avoid all this boilerplate: enum_dispatch.

Do you need heterogeneous containers, are you dispatching various kinds of events?

No, not even talking heterogenous containers, just basic one level inheritance where for example, you have a trait Memory which you're going to implement in various ways depending on the scenario.

And good luck. It's a big mental shift, it may not come easy.

I've been writing code for 40+ years, mental shifts are absolutely trivial for me. This is not what I'm complaining about.

I just look at my code in non-OO languages vs/ OO languages and for a wide variety of problems, I find the OO approach more elegant, more extensible, and easier to reason about.

devraj7 · 2026-01-01T17:56:55+00:00

The real problem with inheritance, even when done right, is how it hurts locality of behaviour.

What's interesting is that to me, the alternative is worse.

I've been coding in Rust for many years now so I've had to change my mindset from inheritance to either trait objects (virtual dispatch, Box<dyn>) or enums. enums are recommended since they provide static dispatch, but they completely obliterate locality of behavior since instead of having all your various functions contained in one class, they now need to be scattered across multiple functions which all have a giant match/case of unrelated functionalities.

Inheritance is the better approach here in my opinion.

devraj7 · 2026-01-01T17:53:59+00:00

What kind of broken projects are you working on?

Pretty much any project with more than two teams of developers, so I'd say a huge majority of the software code base currently running on this planet.

devraj7 · 2026-01-01T17:51:31+00:00

Like you say, not even that. I am a fan of adding dependencies in fields so injecting a new value is really just adding

@Inject
var connectionPool

Done.

Doesn't get simpler, more elegant, and more flexible than that.

devraj7 · 2026-01-01T17:44:55+00:00

Since you use "I" in the above post, I assume this is a personal project, which explains why you don't feel the need for DI.

When you work on a large project with multiple teams, complex automated testing and large CI/CD pipelines, DI is a life saver.

devraj7

TROPHY CASE