They were also plain C functions in my case, but it doesn’t take too much discipline to only call it through the struct. Also, you can put the struct in a different crate which includes the C bindings to ensure that you can’t call the C bindings without the struct.

Just use the Mutex from the parking_lot crate.

The only time I’ve ever needed a Mutex<()> so far with Rust is when I had to interop with a C library which itself was not thread safe (unprotected use of global variables), so I needed to lock the placeholder mutex each time I called one of the C functions.

Actually I think in this case you’re still better off using a Mutex with “data” inside. I’ve done this before. The idea is that you make a unit struct MyCFuncs or whatever and then you only call the C functions from methods of that unit struct. Then you can only access those methods once you lock the Mutex and get the instance of the unit struct. It feel elegant to me.

I’m curious just because I never use ropes or knots - what kind of work or activity do you do where you use that regularly?

That’s hardly low tech, especially not the newer ones.

So is it an emulator? Or does “translation layer” mean something else?

At least use TOML if you like ini, there is no ini spec but TOML can look quite similar.

No thanks, I’ll be staying with datastruct.nextState() rather than const nextState = prevState.nextState()

You can easily do the first option in Rust, you just use the mut keyword. That’s it, nothing more than that. And you’ll find that you quite rarely have to do that, and when you do it, it’s actually quite a useful signal to be aware of, since mutability sometimes means a bit more surprising data changes.

I wouldn’t even call that a functional feature, that’s just the language being based on expressions and bool having a then method. It’s more object-oriented in that sense if anything tbh

I really think you should give Rust a chance. It is not a functional language, like Haskell. Haskell is a hardcore purely functional language. Rust is not a purely functional language - instead it just borrows a few features and ideas from functional langauges. It also borrows ideas from object-oriented languages and it is inspired by C++ in some aspects (or has at least learned from C++, I guess you could say).

Could you maybe elaborate what it is about the functional ideas in Rust you don’t like? I really only see them as benefits - Rust is like the best of both worlds. The good stuff from functional and the good stuff from object-oriented.

The problem with classes is inheritance. Inheritance is just a bad idea and a bad way to structure stuff if you ask me.

Rust fixes this neatly with traits that basically provide the same benefits as classes without any of the downsides.

Sorry but immutable by default just makes sense. When you start coding Rust you’ll see how rarely you actually need to use the mut keyword. It’s quite rare actually.

I was kinda baffled by this too. I like the general idea that they present (you need to pay your own long-tenured engineers higher than market rate cause they actually know more about your own system), but this idea of a formula? What, are you gonna start counting git commits? A formula sounds like a super weird way to solve that problem.

Just look at the engineers that add value in your company and pay them a fair market rate. When someone leaves, find out what salary they get in the new job and ensure all your remaining engineers get at least that amount and adjust as you go along. Something like that perhaps.

The expect lint is really great, been looking forward to that for a while.

Still waiting for more flexible const generics 🤞

Personally I’m a developer, so I care a lot about integrating parts of my development stack. A lot of those things don’t “just work” on Windows, or even Mac, so I’m happy to stick with Linux instead.

I’m also a developer, but I’m also a user, depending on what I’m doing. And this is a very poor excuse for Linux having bad UX.

Linux shouldn’t only be for developers, it should be for everyone.

Then again, how many examples are there for things that should “just work” and do on Linux but don’t on Windows?

Maybe some but much, much fewer. It shouldn’t be surprising - Microsoft has hundreds if not thousands of people hired specifically for creating working UX and design. Linux just can’t compete with that since it’s mostly developers working on it and, again, developers unfortunately make for awful UX designers.

I don’t think external monitors or a responsive UI is a matter of “perspective”. These are things that should just work, always, for everyone.

What are the examples you are thinking of btw?

I’ve previously posted a few examples:

Two 4k external monitors through a docking station - Why is this seemingly effortless for Windows but basically impossible for Linux?

Is there a way to keep Linux responsive when at ~100% CPU usage?

I also regularly have my window manager crash when inserting my laptop into my docking station. Happens maybe 20% of the time. Sometimes even when it works the display scaling makes things blurry until I reset the scaling from 150% back to 100% and back again, then it’s fine. Add to this a few annoyances with UI, but these are more forgivable.

There’s all kinds of these small problems that compound to just make for a much worse experience. It doesn’t just work but it needs to if it really wants to provide a viable alternative to normal people.

Keep in mind, I am not a “normal person” - I am a professional software engineer and I still find all this stuff super annoying.

Yes but it has subpar user experience. But there is no reason you can’t have both, that’s what I’m saying.

No it’s not. Good user experience should also allow for extensive customization. There is nothing mutually exclusive about these things.

What do you mean?