The biggest threat to Rust's sustainability

Re:The biggest threat to Rust's sustainability by littlestymaar on Friday March 19, 2021 @04:23PM (#26517826)

This article has been extensively discussed here and on reddit, the authors faced a problem, did not seek help, and solved on his own it in a pretty convoluted way involving compile-time metaprogramming with macros. As pointed elsewhere, his problem is usually addressed using the type system (enums or traits). You can write a non-standard over-engineered solution to a problem with any programming language, that doesn't mean the language is complex. Zig being especially designed around compile-time meta-programming, it's not a surprise that the resulting code looks much more straightforward.

And that being said, the author mainly complains about features that also exist in C (macros and ifdef, and Rust's version are easier than the C one), would you call C a too complex language because it has macros and ifdef? (I actually think that C is one of the most complex programming language ever written because you need to store too much invariants in your head otherwise it's UB, but ifdef and macros aren't at stake )

[ Parent | on HN ]

Re:The biggest threat to Rust's sustainability by carapace on Saturday March 20, 2021 @10:31AM (#26523469)

You (and dralley) are missing the point: the dude made a wrong turn with Rust and didn't with Zig. You can blame the user all day long but at the end of the day what leverage Rust devs have is not in the user's head, eh?

- - - -

> I actually think that C is one of the most complex programming language ever written because you need to store too much invariants in your head otherwise it's UB, but ifdef and macros aren't at stake

Like I said, without metrics we're just trading subjective anecdotes.

Metrics for complexity of machines is a subject I find fascinating, ever since I read Ashby's "Introduction to Cybernetics" wherein he asks the question "How can we measure the complexity of a machine?" in the context of a formal system for describing machines (Cybernetics.)

There is also the concept of "Kolmogorov complexity" https://en.wikipedia.org/wiki/Kolmogorov_complexity

We could compare the sizes of compilers for C and Rust.

We could teach each to different randomized groups of students and see how quickly people learn to write (safe!) code in each.

[ Parent | on HN ]

Re:The biggest threat to Rust's sustainability by littlestymaar on Saturday March 20, 2021 @05:32PM (#26526207)

> the dude made a wrong turn with Rust and didn't with Zig.

Yes, this one guy made a wrong turn once. If you want to conclude from one user making a mistake that a language is complex then you're just going to conclude that programming is complex … Everyday, with every language under the sun, people make mistakes, great discovery.

I'm not blaming “the user®” here, I'm blaming the blog post writer who makes a mistake and concludes that his tool is responsible for it and that he should tell the world how bad the tool is.

> Like I said, without metrics we're just trading subjective anecdotes.

Well that sentence is pretty ironic given the previous one, nevermind.

> We could compare the sizes of compilers for C and Rust.

I wonder what conclusion you'd draw from such a comparison. That assembly is the least complex language in existence, followed by Brainfuck and Chicken?

> We could teach each to different randomized groups of students and see how quickly people learn to write (safe!) code in each.

Oh I actually like this one. For Rust, you'd need to run a study to find out, but for C the answer is trivial: Never. Nobody on earth know how to write safe C. Not even DJB, not even Theo de Raadt, or Richard Hipp, or Brad Spengler. For almost 50 years, the brightest minds of computer science have tried to write safe C code, and consistently failed. Can we conclude that this language is a little bit too complex for humans, or should we wait a few decades more?

[ Parent | on HN ]