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 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
@sir still not true tho
@deezthugs oh shut up, then, mister smarter-than-turing-award-winners
@sir not an argument :)
@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.
@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
@sir What makes it complicated for you?
@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 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?
cmpwn.com is a private Mastodon instance for friends of SirCmpwn.