Honestly, it’s because a bunch of programs i used disappointed me (performance, functionality, [being a web app at all], etc.) and i figured it couldnt be that hard to do it better. In some cases i was right, in most i was wrong. As it turns out though, I really like programming so i guess i’m stuck here

I’m not sure I understand your point about fall through having to be explicit

As far as i understand it, every switch statement requires a break otherwise it’s a compiler error - which makes sense from the “fallthrough is a footgun” C perspective. But fallthrough isnt the implicit behavior in C# like it is in C - the absence of a break wouldnt fall through, even if it wasnt a compiler error. Fallthrough only happens when you explicitly use goto.

But break is what you want 99% of the time, and fallthrough is explicit. So why does break also need to be explicit? Why isnt it just the default behavior when there’s nothing at the end of the case?

It’s like saying “my hammer that’s on fire isnt safe, so you’re required to wear oven mitts when hammering” instead of just… producing a hammer that’s not on fire.

From what i saw on the internet, the justification (from MS) was literally “c programmers will be confused if they dont have to put breaks at the end”.

the ergonomics expected of modern languages.

As someone learning c# right now, can we get some of those “modern ergonomics” for switch statements 💀

I cant believe it works the way it does. “Fallthrough logic is a dumb footgun, so those have to be explicit rather than the default. But C programmers might get confused somehow, so break has to be explicit too”

I miss fallthrough logic in languages that dont have it, and the “goto case” feature is really sick but like… Cmon, there’s clearly a correct way here and it isnt “there is no default behavior”

I feel like it’s like pointers.

“Variable” refers to the label, i.e. a box that can contain anything (like *ptr is a pointer to [something we dont know anything about])

Immutable describes the contents, i.e. the stuff in the box cant change. (like int* ptr describes that the pointer points to an int)

Rust makes it very obvious that there’s a difference between constants and immutable variables, mainly because constants must be compile time constants.

What do you call it when a variable cant change after its definition, but isnt guaranteed to be the same on each function call? (E.g. x is an array that’s passed in, and we’re just checking if element y exists)

It’s not a constant, the contents of that label are “changing”, but the label’s contents cant be modified inside the scope of that function. So it’s a variable, but immutable.

That depends on your definition of correct lmao. Rust explicitly counts utf-8 scalar values, because that’s the length of the raw bytes contained in the string. There are many times where that value is more useful than the grapheme count.

I think it was this issue. Looks like maybe it got fixed some time this year? Iunno, i’ll look into it at some point

Is pycharm’s semantic highlighting still kinda ass? That’s the biggest thing that stopped me from using it over vsc. As of like may this year i remember there still being active issue tracking for it.

You could say that about anything. Of course you have to learn something the first time and it’s “unintuitive” then. Intuition is literally an expectation based on prior experience.

Intuitive patterns exist in programming languages. For example, most conditionals are denoted with “if”, “else”, and “while”. You would find it intuitive if a new programming language adhered to that. You’d find it unintuitive if the conditionals were denoted with “dnwwkcoeo”, “wowpekg cneo”, and “coebemal”.

“Unintuitive” often suggests that there’s something wrong with the language in a global sense

I mean only if you consider “Intuition” to be some monolithic, static thing that’s also identical for everyone. Everyone has their own intuition, and their intuition changes over time. Intuition is akin to an opinion - it’s built up based on your own past experiences.

just because it doesn’t look like the last one you used — as if the choice to use (or not use) curly braces is natural and anything else is willfully perverse on the part of the language designer.

I don’t think it’s that deep. All people mean when they say it is that “[thing] defied my expectation/prior experience”. It’s like saying “sea food tastes bad”. There’s an implicit “to me” at the end, it’s obvious i’m not saying “sea food factually tastes bad, and anyone who says they like it is wrong or lying”.

For downsides, i’d like to add that the lack of function overloading and default parameters can be really obnoxious and lead to [stupid ugly garbage].

A funny one i found in the standard library is in time::Duration. Duration::as_nanos() returns a u128, Duration::from_nanos() only accepts a u64. That means you need to explicitly downcast and possibly lose data to make a Duration after any transformations you did.

They cant change from_nanos() to accept u128 instead because that’s breaking since type casting upwards has to be explicit too (for some reason). The only solution then is to make a from_nanos_u128() which is both ugly, and leaves the 64 bit variant hanging there like a vestigial limb.

Please don’t say the new language you’re being asked to learn is “unintuitive”. That’s just a rude word for “not yet familiar to me”…The idea that some features are “unintuitive” rather than merely temporarily unfamiliar is just getting in your way.

Well i mean… that’s kinda what “unintuitive” means. Intuitive, i.e. natural/obvious/without effort. Having to gain familiarity sorta literally means it’s not that, thus unintuitive.

I dont disagree with your sentiment, but these people are using the correct term. For example, python len(object) instead of obj.len() trips me up to this day because 99% of the time i think [thing] -> [action], and most language constructs encourage that. If I still regularly type an object name, and then have to scroll the cursor back over and type “len(”, i cant possibly be using my intuition. It’s not the language’s “fault” - because it’s not really “wrong” - but it is unintuitive.

People in different socioeconomic situations/locations experience new technology at different points in time. Just because the internet existed doesnt mean they (or anyone in their immediate vicinity) had internet, state of the art computers, etc.

it makes what looks like formatting an arbitrary complex operation and that it doesn’t improve readability that much.

What’s silly to me about that reasoning is that all workarounds are equally less convenient, have less readability, and the effect is identical to just letting me put whatever between the brackets. I genuinely dont understand the downside i guess.

Calling .join on a vector can have side effects too, except the “we’re concatting strings” is at the end rather than the beginning (and could obfuscate the fact that the end result is a string). It has just as much room for abuse as a long format!(). Even with just format!(), anything you could do inbetween the brackets, you can do outside the brackets in the arguments anyway. At least when it’s between the brackets, i know exactly where it’s going and when without having to juggle the string pieces and assemble them in my head.

in this case it’s about 80% function calls. They’re convenience functions for assembly instructions, so they’re of the form:

load(Reg::D, "A"),
load_const(5),

which is more useful than variables would be. I guess i could use .join or a crate like concat_string? Either way i sorely miss arbitrary expression format strings from python =(