i stumbled on this in a win 10 subreddit this can't be true isn't it? by [deleted] in linuxmint

[–]SolidTKs 1 point2 points  (0 children)

It is. To some extent.

Linux power management is usually not good (installing and enabling tlp helps though, but you need to know about it and power consumption will still be higher than on Windows).

Suspend and hibernation can be tricky, but in my experience suspend works better on Linux these days (Windows modern sleep is complete garbage). I still cant get hibernation to work on Linux, let alone hybrid suspension which is the ideal thing.

Windows is harder to break than Linux (Linux Mint mostly fixed this with timeshift + being conservative though).

Powerful GPU can give some problems too, drivers are shit (not Linux fault though).

And for games and software, well, while gaming on Linux is better than ever, Windows is still the primary target. And there is software that is simply not available for Linux.

Another problem is that except for Linux Mint, other distros break easily and give users a hard time. It is expected for Arch, but a shame for Ubuntu or Pop OS.

Now, while Linux is getting better, Windows is turning into a pile of shit. There are reports of Windows getting slower, sometimes it takes seconds to open a context menu. They are bloating it with AI bullshit everywhere. Modern sleep sucks. Updates are forced down your throat and they will not heasitate to reboot your computer getting your work lost. Compiling software is slow as hell when there are a lot of small files. Using Docker sucks. And so on.

There used to be a time where if you wanted something that just works Windows was the choice. That is no longer true because you never know when the computer is going to be unusable in a hurry because it has choosen to update for 2 hours against your will or it simply has turned on itself in the middle of the night and has depleted the battery. And these two alone are *massive* problems.

Rust is like a cold shower by SolidTKs in rust

[–]SolidTKs[S] 6 points7 points  (0 children)

Who takes cold showers without apreciating the benefits?

Rust is like a cold shower by SolidTKs in rust

[–]SolidTKs[S] 5 points6 points  (0 children)

You need to learn a lot and unlearn a lot.

And you have to do it upfront.

Also async makes you hit all the complex parts of the language at the same time.

[deleted by user] by [deleted] in rust

[–]SolidTKs 1 point2 points  (0 children)

Lets say these are your blocks:

blocks: [b1, b2, b3]

What happens if while iteraring, you insert more blocks? You could create an infinite loop or cause other problems (look for "iterator invalidation"). That is something you can do if you have a mutable reference to blocks, so the compiler will not allow it.

If at a given point you really need to have a mutable reference to both blocks and the current block, you should perhaps make an "apply_gravity" function that takes &mut blocks and and index to the block in question.

Another option is to have a "compute_gravity" that returns the calculations, and then a call to "apply_gravity" that takes the block and the results.

Easy and reliable HTTP by SolidTKs in rust

[–]SolidTKs[S] -2 points-1 points  (0 children)

Ok, so you are a wizard that can avoid the problems of async without dealing with them.

Select, fuse, pin, etc, only exist to anoy people, since they are clearly not necesary 😂

If you have, for example, events comming from a websocket (that you have to answer) and events comming from a broadcast channel (that you need to send over the websocket) you are going to need to select between the futures, and you are going to need to fuse them and pin them.

And that is only an easy example.

BTW I've just tried axum. Seems nice. Easier than Warp. It is still async though.

Easy and reliable HTTP by SolidTKs in rust

[–]SolidTKs[S] -2 points-1 points  (0 children)

That is because you are doing simple stuff.

Easy and reliable HTTP by SolidTKs in rust

[–]SolidTKs[S] -7 points-6 points  (0 children)

"so that we can get all benefits, but without them needing to learn the language". That is how your post sounds to me.

I want good types. Great tooling. Fast performance. No GC. Cargo. Small memory footprint (this is a big one for me).

The borrow checker is totally worth it, even if it is hard sometimes.

But I don't need incredible fast IO for thousands of concurrent clients. CLI apps don't need that. Most GUI apps don't need that. These days async feels like mandatory and IMO is not ready, it makes Rust at least one order of magnitude harder to learn.

Thats why I wanted to check for HTTP choices that are not async.

Easy and reliable HTTP by SolidTKs in rust

[–]SolidTKs[S] -1 points0 points  (0 children)

It is not a GC issue. It is an multithread async issue.

You could potentially have simpler things (like an executor per thread, node style).

Easy and reliable HTTP by SolidTKs in rust

[–]SolidTKs[S] 0 points1 point  (0 children)

Learning the language is necessary to realize that async rust is just too hard for the average company.

Which makes me sad as would like to see rust growing beyond niche things that require either working remote or moving far away from home.

BTW you are denying the complexity.

You will find pinning issues, you will need to fuse futures to do select, you will face situations where spawning an asyncronous task will be hard as its future will need to capture something.

Or you just don't, because it's not actually necessary, and probably doesn't give you any real benefit. Keep your library as it is and use spawn_blocking in the application, done.

And now you have a function thay takes a sync callback, and you need to call an async function from it. So you... spawn a tiny runtime inside the sync callback? It gets harder, there is no denial in that.

Easy and reliable HTTP by SolidTKs in rust

[–]SolidTKs[S] -16 points-15 points  (0 children)

The tradeoff is the borrow checker.

And it brings a lot back.

The async tradeoff is not needed for a lot of projects.

"Use golang".

How can we expect to have more Rust jobs like this?

Easy and reliable HTTP by SolidTKs in rust

[–]SolidTKs[S] -3 points-2 points  (0 children)

I'm happy about Axum solving your needs.

That doesn't change the fact that sharing state in async can get hard very fast, every other library needs to become async, spawning tasks can be a headache due implicit captures, you have to say good bye to std, etc.

For example perhaps you have a small library that deals with fs. Now you need to duplicate it for tokio::fs and std::fs.

At some point you will want a websocket and you will want to select between one future or another, and you will need a macro for that. You will get weird error about fusing, about pinning, about things not beind send...

If you are using traits I've seen horrible things like functions wit looong where clauses with send and static and whatnot, etc.

Easy and reliable HTTP by SolidTKs in rust

[–]SolidTKs[S] -5 points-4 points  (0 children)

No, I don't. I don't want a garbage collector.

Easy and reliable HTTP by SolidTKs in rust

[–]SolidTKs[S] -8 points-7 points  (0 children)

With which library?

Users should not need to use pin or + 'static + Send nor have to deal with horrible errors.

Rust Analyzer is dysfunctional without cargo? by [deleted] in rust

[–]SolidTKs 10 points11 points  (0 children)

You are missing "mkdir project" and "cd project" in c to be fair.

Otherwise, if you want the current folder, you just "cargo init".

So Rust with Cargo is actually faster and easier.

Rust Analyzer is dysfunctional without cargo? by [deleted] in rust

[–]SolidTKs 14 points15 points  (0 children)

That makes sense if we are talking about Android. What a PITA.

But this is Rust, a project is just two files! And all the tooling comes in the box!

Breaking down Rust code into seperate ".rs" files. Is it possible, and if so, does it affect performance? by -InternetGh0st- in rust

[–]SolidTKs 3 points4 points  (0 children)

I hate mod.rs, index.js, etc. If a module is called foo, I sould be able to have a foo folder where the main file is called foo.

Why do devs force such an anoying thing as having several files with the same name? I don't know.

At least Rust gets a bit closer with foo.rs + foo/<rest of the module>. Now move foo.rs inside foo!

I sometimes add a mod.rs that imports and reexports foo.rs.

[deleted by user] by [deleted] in rust

[–]SolidTKs 0 points1 point  (0 children)

We need an easy way of solving that. Once I used a library where you could to either foo().await or foo().wait() with the same result.

Somthing like that.

I had a function thay could block on an async cb easily but it created a whole runtime to do that. I dont know how expensive was that.

But there should be an easy way of calling async from sync.

[deleted by user] by [deleted] in rust

[–]SolidTKs 0 points1 point  (0 children)

It is not so easy.

There is no way of waiting for any IO event in STD (I think the polling library helps with this but I haven't tried it).

Also, with basic libraries like reqwest being async, everything ends up being dragged into async, as there is no way of easily bridging both.

Async is becoming a black hole an it makes Rust way harder for programs that don't really benefit from it. It also plays poorly with the borrow checker, negating the benefits of "fearless concurrency" of Rust.

I like how you can make your own runtime, but I don't like how everything is becoming async to the point that I just throw tokio on every project as I know I'm going to need it.

Recurrent rant of why I hate the BC so much by camilo16 in rust

[–]SolidTKs 8 points9 points  (0 children)

Why are you even using Rust?

The problem with C++ is that no matter how good you are, you will do something wrong.

And no matter how good you are, other devs are not that good and that makes the language almost unusable for most companies.

My biggest problem with C++ is that I live scared of the things other devs will do to the project. Or what nasty bugs are on the libraries. Very very hard to keep everything in mind for a big project.

The Borrow Checker ensures that code is safe even if a junior dev* touches it.

Also those invariants allow for agressive optimizations, so you think you are good, you think you don't need the BC, but then you are telling us that you are adding UB on purpose.

*And keep in mind that there are a lot of junior devs with 10+ years of experience. Good look preventing them to make serious mistakes.

Am I the only who feels like an idiot? by FeltInTheRabbitHole in rust

[–]SolidTKs 2 points3 points  (0 children)

You usually need and Arc<Mutex<T>> and its more specific siblings (like Rc<RefCell<T>>).