As the old saying goes, "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies."
Rust is a crutch which is enabling the proliferation of awful software from the latter camp under the guise of a moral imperative for "more secure" software
@sir .-. I think Firefox only has its CSS engine written in Rust. And i don't get why you say Firefox is "awful" xD
@jorge_jbs I might clarify by saying that any software which implements a web browser is awful by definition
@sir that's not the language's fault xD
I get you don't like Rust, but I don't think you should use such strong language if you don't argue it.
@jorge_jbs actually a lot of it is the language's fault. Rust is designed to be useful in contexts where the problem being solved is so complicated that it's a stupid idea to solve it at all (e.g. web). It encourages this web-tier crap to proliferate
@sir Rust is designed to have safe memory management even with concurrency. That context is very big. Could you use C in those situations? Probably, but I guess it is easier and faster to do it in Rust. And those situations that are very very complicated and writing in C would be difficult are not "bad software". I can think game engines for example.
@jorge_jbs concurrency is generally undesirable
@jorge_jbs also, game engines are universally terrible. And I don't say that out of ignorance, I've worked with m any
@sir Concurrency is generally undesirable because it is hard to get right (sometimes concurrency is bad even if it is easy to implement, I'm not talking about that). Rust makes it easier (though not easy), making the software that really needs concurrency less buggy while being more efficient.
@sir And I'm not talking about the quality of game engines, I'm saying they are an example of necessary complex software. In fact, if they are terrible, maybe giving tools to make them more efficient while remaining equally (or more) correct makes them less terrible. Rust is just one of those tools.
@jorge_jbs very little software actually needs concurrency. And I don't believe in black boxes - the complexity exists and someday you're going to be neck deep in it when it breaks. If you only understand the layer at which you're working, you're going to make bad programs.
@jorge_jbs in fact, I struggle to think of any software which I would use threads for.
@sir Maybe because you don't typically write the kind of software that needs them, that doesn't mean they are universally useless.
@jorge_jbs that's not what I said. Name software which needs threads
@sir Software that does something fast and wants to do it faster. Parallelization is one tecnic to make software faster.
@jorge_jbs I'm all for parallelization - in separate processes. This is easy in most languages. Threads need not apply
@sir When did I say black boxes?
>Could you use C in those situations?
I think you're missing @sir 's point.
The point that in such situations, you shouldn't use C. Or Rust. Or any language at all. You should refuse to solve the problem, and demand that whoever created the situation gets rid of it and decides he doesn't want the problem solved anymore.
@Wolf480pl @sir I'm not. As I say at the end, sometimes complicated software *is necessary*. You want to make an efficient game with complex graphics and you say "well, the software is too complicated, maybe the game is a bad idea". That sounds very dumb.
I'm saying a game as an example, but I don't really know much about game development and this could be transferred to other cases.
cmpwn.com is a private Mastodon instance for friends of SirCmpwn.