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

Good software engineers write simple software with simple tools, and it works. Bad software engineers write complicated software with complicated tools and it only works insofar as you run it on CPUs designed in the last 6 months on one of 2-3 operating systems on 1-2 architectures and provided you don't look at it too funny

@sir whether we want it or not, majority of software is written by "bad engineers", and people depend on it. It's better if the tools used to make it work with less hiccups, even if it constrains the environments where it can work.

@ignaloidas I think bad engineers can be made into good engineers

@sir I disagree. Not everyone who develops software is a professional engineer, and most of the time have no incentive(or even unable) to become a "good engineer". Take for example data science. They do use programming, they create utilities for self and others, but they do not gain anything from becoming a "good engineer". For them using tools that decrease the amount of thinking they have to do for a piece of code, while also adding security guarantees, is an obvious choice.

@ignaloidas Given a simple and well defined environment, bad engineers can write good code. Case in point: Golang. And I pray to any god who will listen that academics will not be building the operating systems of the future.

@sir Golang isn't that different from Rust though. They both provide a safe environment, but with different tools. Rust gives more varied tools for lower level programming, while Golang gives you simple general tools for general programming. In turn it is easier to write good general code in Golang, and good low level code in Rust.

@ignaloidas Golang and Rust are similar insofar as they're both programming languages. In every other respect they are starkly different and I find your statement disingenuous and outlandish

@sir I don't see a huge difference between them in sense we are talking. They are both memory safe languages. They both are statically typed. The only real difference I can see between them are the tools provided. Go has very barebone tools suited for general development. Rust has a lot more tools that are more suited for lower level programming and abstraction. Between the languages themselves I don't see much difference, I only see the difference in tools provided with them.

@ignaloidas they are fundamentally different in goals, design, implementation, and usage, in almost every respect. Yes, if you bucket them into broad, opaque categorizations like "statically typed", they have a similar shape. An orange has a similar shape to a basketball, too.

@sir @ignaloidas For example, Go programmers have a nil, which Tony Hoare called a billion dollar mistake[0], and Rust avoided that mistake, right? It looks like there's a billion dollar difference between the two! At least!

@sir @ignaloidas Unexperienced developer can do very harmful mistakes in Go just by overlooking some corner cases. The compiler does not help even when it could.

E.g. non-exhausting case switch or unintentionally shared state between goroutines. These bugs can live unnoticed for a long time and be very harmful.

@mprymek @ignaloidas certainly. But even good developers write bad code in Rust, because idiomatic Rust code is bad code.

@sir @ignaloidas I don't know Rust well but this statement sound like wishful thinking / ideological view more than a reasonable argument to me, I'm sorry.

@mprymek @ignaloidas I've enumerated my problems with Rust countless times, I encourage you to seek out these explanations instead of expecting me to prepare an essay for each person in my notifications

@sir @ignaloidas Do you have any carefully written text on any blog or anything? I have just read few toots here which I sometimes do not understand well.

@mprymek @ignaloidas I do, and searching "drew devault rust" brings it up as the result on DDG

@mprymek @ignaloidas admittedly, some of the argument comes from my larger perspective on software development, which isn't as easily googled, but scanning the titles should set you on the right path:

@sir @mprymek @ignaloidas That pretty much doesnt make any sense because it mostly doesnt add any overhead.

@ignaloidas @sir it'd be fine if people cleaned up after them before others depended on the code

@sir What are your specific complaints about Rust? The borrow checker specifically or something else?

I like both Rust and Go, that’s why I’m curious.

@sir is that really an old saying or something you just made up? Also it is not accurate. There are 1000 ways to make software.

@deezthugs quote from Tony Hoare's 1980 Turing Award lecture, which I would assume is a damn sight better credentials than either your or I have both

@deezthugs oh shut up, then, mister smarter-than-turing-award-winners

@sir :-( I have been a proponent of your work. I’m a paid up yearly supporter of Sourcehut and have recommended it to friends and other projects. I’m also a fan of Rust. I’ve tried to ignore these sorts of comments but i can not longer do so. You’ve lost a supporter.

@wezm if you're unable to separate the tool from the person then it's your loss. Note that I have done nothing to inhibit the utility of sourcehut for rust users.

@wezm I have a unconventional view on software design, and you'd be hard pressed to find anyone who agrees with me on everything. But these philosophies are the source of innovation and have led to the production of software that you seem to enjoy. If you were to bubble yourself in from ideas that contradict your ideology, then what're are you giving up?

It's no skin off my back if you chose to end your subscription. Just my 2c on your way out.

@wezm @sir if this sort of thing bothers you so much that you'll end a subscription over it then maybe you need to spend more time up front researching before subscribing?

Drew's views on Rust haven't exactly been a secret, you know...

@sir What a good saying. Clearly, every non-trivial C program is of the second nature, because C has indecipherable semantics. But what is it about Rust?

@sir If you are out for simple design why dont you write your software in Ziglang?

@nifker I don't agree that zig is simple, or encourages the use of simple design practices

@nifker I think comptime is a bad idea, among other things

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