It’s a test for the compiler which ensures that these legal yet extremely weird expressions continue to compile as the compiler is updated. So there is a purpose to the madness but it does still look pretty funny.

There’s a crate for it too: anymap2

Not exactly the same thing but this is still pretty funny. This is code that is technically 100% legal Rust but you should definitely never write such code 😅.

Frankly, all of your points sound quite ignorant. Syntax is literally just a matter of getting used to it. Comparing HashMap ergonomics doesn’t make sense, you should rather compare to struct construction. There are many good reasons for different string types and number types. There are good reasons not to bake in async. Rust documentation is in the code for a very good reason and it’s actually really nice to read docs like that (obviously read it on docs.rs, not in the code itself).

I could go on but there are answers to all of your specific qualms if you just bothered to look for yourself.

While there certainly is some blame on the programmers (to the extent that it is useful to even assign blame), I would say it is hardly fair to blame programmers for most mistakes.

Bugs are a fact of life - the presence of bugs can hardly be blamed on a specific programmer. Rather, it is a result of the resources assigned to a project and its quality assurance. Yes, at the end of the day it comes down to the lines of code written, but everything and anyone involved in the process up to that point (like designers, project managers, people managers and of course executives at the top) are to blame as well. Especially the decision-makers who deprioritized security or quality assurance are to blame, much more so than the programmer who wrote the line.

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.

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.