Getting pretty sick of Rust's BS
Why does everyone want to be clever? I'm not gonna blame you if you want to specify your program in a DSL, but if you do, for the love of god just implement an ad-hoc parser instead of embedding the syntax in the language with macros. Knowing C and C++, I have a fairly good chance of being able to understand any given program. Knowing Rust, it's entirely dependent on how whimsical the developer felt that day. And it's not just humans that are thrown off by macros; IDEs get totally wrecked by them. I've seen instances of rust-analyze use over 2 GB of RAM trying to figure out what on earth the code means and then give up, leaving VS Code as nothing but a much more resource-intensive Notepad++.
And Christ, it's like everything has fifteen levels of abstraction. I'm digging through module after module trying to find the bit that actually does the thing. It's FizzBuzz Enterprise Edition all over again, only I'm pretty sure this isn't a joke, and at least IDEs are able to parse FBEE.
And Christ, it's like everything has fifteen levels of abstraction. I'm digging through module after module trying to find the bit that actually does the thing. It's FizzBuzz Enterprise Edition all over again, only I'm pretty sure this isn't a joke, and at least IDEs are able to parse FBEE.
| I'm not gonna blame you if you want to specify your program in a DSL, but if you do, for the love of god just implement an ad-hoc parser instead of embedding the syntax in the language with macros. |
Environments that make the best use of macros are either dynamically-typed or type-less (at least partially), and have simple syntax. Forth implementations, assemblers, and Lisp environments are all typical examples. This is because macros are easier to write, offer more flexibility, and are easier to understand when they can fully exploit polymorphism.
Rust has a static type system and C-like syntax and no REPL. So it's unsurprising that the results are a disaster.
Last edited on
I think you hit the nail on the head. Rust's syntax is already fairly complex. If you add on top that any time you're looking at code you need to scroll up to see if there's a
macro!( 100 lines up, it becomes a mess.
Yet the fanbois insist Rust will become THE defacto programming language, replacing everything else. Why? Because....
Yet COBOL is still being used and maintained. Fortran is still being used. The list of programming languages still in use is rather extensive.
Rust IMO is a niche language that tried to "improve" on what the creators saw as the deficiencies of C/C++. Tried and failed. C/C++ has grown in complexity over the years, but without sacrificing the ability to create code of simplicity. For the most part. C++ has deprecated and removed a few core parts. std::auto_ptr, for example. std::random_shuffle for another.
Yet COBOL is still being used and maintained. Fortran is still being used. The list of programming languages still in use is rather extensive.
Rust IMO is a niche language that tried to "improve" on what the creators saw as the deficiencies of C/C++. Tried and failed. C/C++ has grown in complexity over the years, but without sacrificing the ability to create code of simplicity. For the most part. C++ has deprecated and removed a few core parts. std::auto_ptr, for example. std::random_shuffle for another.
I don't know rust but how much of this is programmer vs language? You can make an unholy mess in c++, of course, with macros or without them. This isn't a flaw in the language; the only way to prevent that is to limit it so much you can't do anything (aka java).
Macros of this sort are a special case. A tool that lets you program the compiler to parse arbitrary code (or almost) makes it too easy to do things you really shouldn't be doing. Imagine being able to insert Java code in the middle of a .cpp. Yeah, it may be convenient, but are you really gaining anything compared to putting it in a .java and parsing it in a separate build step? Is it worth making autocomplete useless on that file?
I don't know. Ive see that done in C & C++ before, to translate various languages into native. Ive done it, with matlab, but it was a long, long time ago (and not with macros, but still, some funky syntax shuffling).
I can see doing it here and there, but it has a goldilocks problem. Code that is too small, you just rewrite, the parser/macros are too awful. Code that is too big, you compile a library you can tap in the original language, if possible: its too big to be sure you didn't muck it up. In the middle, where it makes sense, all I can think of is the original language can't be exported to c++ lib or worse, may not even have a working modern compiler available, or costs big money, etc... its an option, but an ugly one.
I can see doing it here and there, but it has a goldilocks problem. Code that is too small, you just rewrite, the parser/macros are too awful. Code that is too big, you compile a library you can tap in the original language, if possible: its too big to be sure you didn't muck it up. In the middle, where it makes sense, all I can think of is the original language can't be exported to c++ lib or worse, may not even have a working modern compiler available, or costs big money, etc... its an option, but an ugly one.
Last edited on
rust - a flaky coat caused by corrosion
I have only a very superficial nodding acquaintance with Rust, but IMO it shows all the detriments first shown by Algol68 - committee designed and too clever for its own good. Algol68 never took off (succeeded by Pascal). Although some now apply that label to current C++ as well...
I have only a very superficial nodding acquaintance with Rust, but IMO it shows all the detriments first shown by Algol68 - committee designed and too clever for its own good. Algol68 never took off (succeeded by Pascal). Although some now apply that label to current C++ as well...
Topic archived. No new replies allowed.