Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@retoor It's pattern matching. `if let Some(foo) = maybe_foo {}` matches maybe_foo against Some(foo). E.g. if it's the Some variant it binds the contents to foo
-
@retoor It's not truthy because you're extracing values
You can also match against `Some(Some(foo))` or
`MyCoolEnum::VariantA(...)` or even `MyStruct { a: 20, .. }`. The latter only matches when the field is 20 -
@retoor That only works for null (and empty strings I guess)
Here's a cool way to do fizzbuzz using pattern matching
https://play.rust-lang.org//...
Can't do that without pattern matching :P -
@12bitfloat no, why would you :p But did you make that for me? 😍 Aww. I'm really annoyed by not the "%s" in that code tho.
-
@retoor What am I looking at 💀 Most readable C code lol
How does that even work? I thought the format string has to be a literal? 🤔 -
@retoor I did make it for you :P
-
@retoor Huh, it actually works https://godbolt.org/
You learn something new every day :D
Unused params in vararg functions should be fine I think -
@retoor Last I tried rustc it didn't likit when I `};`'d all over her face and tits, which ruined the mood for me.
Anyway, it's C++ but worse. Perhaps there's an octopusdog inside all of us. -
@retoor rust, specifically, suffers from it's syntax primarily.
I say 'specifically' because any compiler that gives you a high number of features/guarantees is inevitably going to result in the language itself requiring the programmer learn many more concepts to utilize it effectively, to say nothing of the striking increases in compilation time.
But this is true for *many* languages other than C++ and rust, it's a problem inherent to high-level programming in and of itself, in that you're stacking complexity, which leads to the 'befuddling' quality of code -- ie, there's too much shit to keep in your head to fully understand how anything at all works without mind-altering, preferably injectable drugs.
rust syntax, had it learned lessons from the innumerable syntactical idiocies of C++, would be a lot better off. However, the language leans on and propagates said intellectual failures of humanity, resulting in its decisive failure to fulfil the promise of replacing C and C++. -
@Liebranca tf are you talking about. Rust did learn from c++, thats why it doesnt look outdated with 5 different ways of doing the same thing
-
@retoor They are all different for different usecases. Remember, Rust is a systems lang!
str -> std::string_view
String -> std::string with utf8 guarentee
OsStr/OsString -> no utf8 guarentee because filenames/envvars might not be utf8
CStr/CString -> no interior null bytes and are null terminated for C interop -
@retoor Makes sense. The other types are only useful in certain areas (e.g. dealing with the os, like paths)
-
@12bitfloat Pardon, you did not learn how to read.
"[rust syntax], had it learned lessons from the innumerable syntactical idiocies of C++, would be a lot better off."
7mar. -
@Liebranca Please enlighten me what syntax Rust has taken from C++ instead of learning from it
Because the answer is literally nothing. Rust doesn't look like C++ at all nor does it have the syntactical issues that C++ has. For starters, Rust's syntax is context free -
-
@Liebranca I think you're just a retarded hater with no actual arguments, which isn't surprising considering you likely have never written 10 lines of rust code
Of course you don't like it. You have zero clue how it works or what it does -
@12bitfloat Well, you have no eyes, on top of no cock.
-
@Liebranca Also, bro, 75% of your github projects are C++ and Perl. Fucking perl of all things. And this man is criticising syntax
...yeah okay. Guess we just have *very* different preferences ;P -
@12bitfloat I don't recall defending perl or C++.
-
@Liebranca Which is good because they have horrible syntax, none of which landed in Rust
Gimme an example of bad rust syntax and what your critique of it is -
@12bitfloat
macro_rules! forward {
( $( $fn:ident( $($param:ident: $ty:ty),* ) $( -> $ret:ty)? ),+ $(,)? ) => {
impl Build {
$( fn $fn(&self, $($param: $ty),* ) $( -> $ret)? {
self.config.$fn( $($param),* )
} )+
}
}
}
src: https://github.com/rust-lang/rust/...
Critique: It's shit.
Another question? -
@Liebranca Declarative macros is such a copout answer. Nobody writes them on a daily basis and they barely even qualify as "Rust syntax" (more like a preprocessor)
Even then, tell me how to improve it. How would a Liebranca approved declarative macro system look like, that has the same power as Rust's current syntax?
Let me have a guess, it'll look pretty much the same because that's just how declarative macros work -
@Liebranca Oh yeah and how is that in any way related to C++?
It's a feature C++ doesn't even have, and the only thing you could criticise. Hundreds of thousands of lines of Rust code: ifs, whiles, structs, traits and you couldn't find one example there to criticise....
Wonder why -
@retoor You can't really use utf8 for paths because on windows paths might be in some weird codepage or utf16 and on linux paths can contain any byte except nul
For most stuff storing paths as utf8 is fine, but Rust is meant for robust systems development. They don't want to lie to you and give you a wrong abstraction, so they force you to deal with it
Imagine writing the `ls` util in rust and somebody creates a file with a non-utf8 path. Now you can't list files in the terminal anymore because it crashes.... fun times :P -
@retoor String is guarenteed utf8 because it makes everything easier. You can't use utf8 for paths
It's really that easy. Other languages will silently fail if you have weird paths. Rust is made for robust programs, not silly scripts -
@retoor Different strokes for different folks :P
Rust is a serious lang for serious programs. Safety isn't optional, it's required
But I can see you're getting frustrated. That's pretty normal when learning rust. I was cursing rust in the first few weeks too -
@retoor To expand on why it's good to have different types: Rust has this idea of safety by design (or construction? don't remember)
If you hold a type T, it IS a valid T. It can never be in a bad state. Like in C when you declare a variable without initialising it, it has undefined contents. In Rust that's impossible. Same with references: If you hold a &T then you are guarenteed to hold a reference to a valid and existing T
This is very powerful because it makes certain properties be enforced at compile time. You can't accidentally have a string that isn't utf8 which will then fail in weird ways at runtime. Or a path which accidentally contains weird symbols you weren't expecting
It makes your code more robust by pushing these errors from runtime to compile time. Rust forces the programmer to deal with these intricacies instead of pretending they don't exist -
@retoor Python is designed to be easy and fast to program, not to be rigorous and robust. Which is fine! I like python but Rust just has a different mindset
Python strings are btw a little more complex than just utf8 (if I remember correctly)
But okay, now you code a script in python and somebody with a really weird setup wants to use it. And they can't because their paths contain non-utf8 sequences. Python will just crash or silently do the wrong thing
That's fine for the 95% case but Rust is designed for the 99.9999% case -
@12bitfloat Macros being ugly by nature conceded, yet the fact remains plain to see: the ones I write in flat assembler are infinitely more readable, all while allegedly under the influence of crack cocaine, see the top of this very rant for an example.
Thusly, the linked code perfectly illustrates how high-level languages inevitably fall into a jungled mess of complexity, which tends to permeate their syntax, and that is the point I made.
What the relationship is should then be clear: rust does not alleviate nor improve on this issue, of which C++ is the prime example, and only adds further complexities of its own, which exacerbates the problem -- hence the statement that it did not learn lessons, or more snarkily, "its C++ but worse".
As for how to improve: read the argument. Complexity is inevitable at the high-level and that leaves only one answer, but can *we* afford to use assembly? Generally speaking: no, not in a professional capacity.
Continued in the next comment. -
The core of the problem is that a compromise has to be struck between these two extremes:
- Base language offering no higher abstraction, allowing for the simplest possible syntax.
- Higher abstraction being builtin, which often times necessitates that syntax be more complex.
This is an ongoing question. What I'd propose is that abstraction should be obtained by writing more user-level code rather than by modifying the base language, but that implies a major shift in how compilers are built, due to certain metaprogramming problems (in my eyes) requiring that the syntax itself be extendable or modifiable to a certain degree, which means that [the compiler itself must, in a way, be **extendable** through said code].
In essence, the ideal scenario would be that a base language is both simple and flexible enough so as to allow for building the extreme opposite when it is required.
See fasmg for something that approximates this concept. Its an assembler engine though, so not quite.
Consider,
```
namespace A;
macro m00 a,b;
··display a,b;
end macro;
macro m01 a;
··m00 a,$0A;
end macro;
m01 $24;
end namespace;
```
OUT: $0A24 ("$\n").
Ah, but you just HAD to fuck me in the ass, didncha fasm2? Initializing anal bleeding:
```
namespace B;
A.m01 $24;
end namespace;
```
OUT: illegal instruction 'm00'.
Explanation: macros carry no context, and so 'm00' is unreachable from 'B' namespace.
Could I maybe write a code-capture macro to generate a wrapper that resets the namespace? Yes, and in fact, I did; brilliant exercise in mystical mindfuckery.
But why try so hard? Just pass the fucking ref, like a MAN.
EXPLICIT CTX, BITCH.
```
define @CAS $non; current addressing space
define %ICE @CAS;
macro self:PA&; recursive macro, uuuh spooky-spooky
··match ice , %ICE;
····; self->proc(args)
····match =-=> proc (args) , PA;
······path.proc ice,args; pass ref and args
····; ^self->proc()
····else match =-=> proc () , PA;
······path.proc ice; pass ref only
····; ^sneaky sneaky. set current context when self ctx;
····else match cas , @CAS;
······%ICE equ cas.PA;
····end match;
··end match;
end macro;
```
ALL TOGETHER NOW
```
namespace A;
macro m00 ice,a,b;
··display a,b;
end macro;
macro m01 ice,a;
··self->m00(a,$0A); could also be 'ice.m00 ice,a,$0A' lmao
end macro;
end namespace;
namespace B;
self A; set ice
self->m01($24);
restore %ICE; back to previous
end namespace;
```
OUT: $0A24 ("$\n").
A-há, now **I** got you from behind motherfucker!
Final note: this is 100% perl DNA seeping through the cracks of my sanity and into a fresh fasm2 framework. Why? Dingle-dongle-jungle-berries, that's why. Also crack.
Have a nice wallop.
rant
recursive virtual constexpr sodomy