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 Can you give examples of such "awful 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 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 @jorge_jbs This is a trap :)

Of course no problem "needs" threads in the sense of you can not write algorithm without threads to solve the problem (giving aside special things like hard realtime etc.).

The point is, there are many problems where using concurrency leads to a better structured, understandable, cleaner (!) code.

The main problem with concurrency AFAIK is that most of the programmers are not used to write separated modules which do not share state (!). So most of the problems are "how to make shared state safe". And the obvious, clean (!) solution is to NOT use shared state in the first place :)

I think Erlang is a good example of language where concurrency do not lead to ugly, complicated code but the right opposite.

>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.

@jorge_jbs @sir
"well, the software is too complicated, maybe the game is a bad idea" doesn't sound all that dumb to me.

@jorge_jbs @sir

Sometimes the only way to win is not to play.

@Wolf480pl @jorge_jbs for the record, Rust is dogshit for game development. Game programmers are barely even programmers in the first place, most of them just want to make their game and code is a confusing and annoying means to their end. Does that kind of person really want to be fighting Rust?

@sir I'd like to say the same thing for business software. Barely programmers. Despite my code being heavily commented the handover conclusion was that it wasn't to be used after I left and instead some slow, unmaintainable VB6 code it was substituting was to be used instead.

@Wolf480pl @jorge_jbs

@Wolf480pl @sir Engineers should let artists do their best work. It is really dumb to make software like blender and game engines less capable just because that would make them more complex. There are other nice things other than usability, like aesthetics.

@jorge_jbs @sir

It's been shown that limitations increase creativity.

@jorge_jbs @Wolf480pl it would be possible to make a piece of software like blender good. I don't know enough about the blender internals to wager if they've accomplished that

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!