Producing code that does what's intended. The metric is fuzzy and based on the usage of the software, not the scale of lines of code. The extent of the importance of the code itself is that I'm practice software tends not to be "one and done", so you need to be able to go back and modify it to fix bugs, add features, etc., and it turns out that's usually hard when the code is sloppy. Those needs still should stem from the sandal actual user experience though, or else we've lost the plot by treating the mechanism as the goal itself
Would my user rather have a program that works 100% in 2 weeks, or a program that works 80% in one day?
When the user needs a change made, would they prefer I spend another two weeks extending my perfect program, or throw a few LLMs at their sloppy code and have it done in a day?
That would depend on who your users are and what they're using their program for. My point is that the context of who is using the program, how they're using it, and what they're using it for are what actually matters, because most of the time, software that no one uses is by definition useless. There are circumstances where that might not apply, like code used as part of education or training (whether in a formal course or a project someone writes specifically because they're trying to learn something from the process) or when the purpose is aesthetic or humorous, but I'd argue that whatever process makes sense for them doesn't necessarily bear any resemblance given how different the goals are.
You're really asking if a user would want a program that fails a fifth of the times?
In some cases it might be better to have some crap right away and more cheaply, but even you would probably not like a 20% failure rate in most of the software you use.
The trait/type system can get pretty complex. Advanced Rust doesn't inherit like typical OOP, you build on generics with trait constraints, and that is a much more complex and unusual thing to model in the mind. Granted you get used to it.
OOP inheritance is an anti-pattern and hype train of the 90's/00's, especially multiple inheritance. Especially the codebases where they create extremely verbose factories and abstract classes for every damn thing ... Java, C++, and the Hack (PHP-kind) shop are frequently guilty of this.
Duck typing and selective traits/protocols are the way to go™. Go, Rust, Erlang+Elixir... they're sane.
What I don't like about Rust is the inability to override blanket trait implementations, and the inability to provide multiple, very narrow, semi-blanket implementations.
Finally: People who can't/don't want to learn multiple programming language platform paradigms probably should turn in their professional software engineer cards. ;)
Sure, if you define "automatic memory management" in a bespoke way.
> Could you be more specific?
The lifetime system, one of the most complex and challenging parts of the Rust programming model, exists only so that Rust can combine manual memory management with memory safety. Relax the requirement to manage memory manually and you can safely delete lifetimes and end up with a much simpler language.
Quetta is unusable for me from how much they redesign the UI for no real reason. What I wanted was just an up-to-date version of Kiwi Browser which this project seems to aim for.
reply