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.

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.

Make them optional lmao. I dont have a 4k screen, havent ever had one, and wont buy one for a very long time. Why am i storing these assets i will never use?

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.

Saying "non negotiable" doesnt actually hold up in small claims, nor against basic resistance in most cases.

Look up your local laws, in some places carpets must be replaced at the expense of the landlord every X years, or if there is any kind of damage (caused by regular wear and tear) that could be a trip hazard. Pictures from move-in, carpets not being replaced when you moved in, etc. all help your case.

Last place i lived, I spent 30 minutes arguing on the phone with my previous landlord over flooring and got my 700 dollars back. Turns out most of the time they only vaguely know the laws they're quoting, so if you come with confidence, prep, and a willingness to take it to small claims, they'll fold to save themselves the effort.

“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".

Rule number 2: stop dismissing performance questions just because of something some guy said decades ago. Performance matters, learning about performance matters, and answers like yours dont help anyone.

Did they ask if they should optimize, or did they ask which one generates more performant assembly? Which one of those questions did you answer?

Maybe they already measured and already knows this is a bottleneck. Maybe they are curious if match statements are a slow abstraction (e.g. in python, it's essentially a chain of if/else. In rust it's often compiled to an indexable table). Maybe the given example code is only partially representative of the actual code this is being applied to.

It's so irritating to look up performance-related questions when this answer is at the top (and middle, and bottom) of every thread. I swear half the reason every piece of modern software runs like shit is because nobody bothered to learn how to optimize and now everyone just parrots that phrase instead of saying "i dont know".

There's tons of little "premature" optimizations that you can do that arent evil. Choosing the right data structure (how random is the access? Are you using keys? Does it need to be sorted?). Estimating time complexity and load size (e.g. "i'm parsing [11 million | 2] files, i should probably [keep time complexity in mind | ignore time complexity completely]"). Structuring loops in a way that's easy for compilers to auto-vectorize - usually it's not any harder to read what the loop is doing, so why not do it right away?

Yes i'm bitter =(

If they had made the deck more powerful, the old ones would suddenly have been obsolete.

I'm pretty sure it has more to do with current chip technology not actually changing that much in the, what, 2 years since the deck first released?

Also obsolete is a pretty strong word for what - if it had stronger internals - would likely end up being more expensive than current models.

code that's been written today has been made obsolete by a language feature in the latest nightly build

I mean couldnt you say that about any language? There's lots of old C code that's obsoleted by features in C11. There's lots of stuff written in python today that's obsoleted by stuff in the 3.13 alpha. It's just kinda how things go.

Doesnt the edition system prevent this from being too big of an issue anyway?

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

Hopefully this month i can finally finish up nand2tetris. I did more or less all of it in rust to learn the language, and i feel like I'm now about as comfortable in it as i am in python. Learning how to build a computer from logic gates was sick, but debugging the compiler has been really draining. The way compilers work is neat, but all sorts of little problems keep coming up that force me to restructure large pieces of it over and over and i've lost almost all my momentum.

I'm not sure what I'll move on to next, maybe something more front-facing like a gui library, or maybe I'll finally look into anything that might actually provide me skills that will get me a job lol.

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.

Nah, i dont think that's true at all. Priority number 1 is learn the language that deals in what you're most interested in. Priority 2 is learning the language whose ecosystem you can tolerate.

Why? Because you learn most when you enjoy what you're doing.

I'm interested in performance and systems programming so i tried to start with c++. C++'s ecosystem and tooling are complete garbage and i spent more time fighting it than learning to program. I learned python for a specific project, but eventually started learning rust because i was frustrated with python's lack of low level functionality (and speed).

Rust has a lot of modern features that c++ doesnt (and that arent buried behind 20 years of "do this, no wait that's bad, actually do this instead"). The tooling is excellent for beginners, and there's lots of core and standard library features that simplify some of the stupid things about low level programming. And you dont have to start with all the low level fiddly bits, you can start with variables, conditionals, and functions just like you would in python or whatever.

As for book recommendations:

NOT the official rust book. Imo it assumes you already know at least one other programming language. It doesnt always go into enough detail about advanced concepts, but other times goes into WAY too much detail for true programming beginners.

The two that i liked the most were:

Programming Rust by Blandy, Orendorff, and Tindall

Rust in Action by Tim McNamara

I've also heard good things about Command-Line Rust by Ken Youens-Clark, but i havent read it myself.

Also, dont be afraid to read language-agnostic books that cover general computer science concepts like Dive Into Algorithms, Understanding The Machine or Data Structures The Fun Way after you've gotten your feet wet.

15532 on-type format (, by adding closing ) automatically

Thank fucking god lmao. The PR specifically mentions the Some( case too, which is exactly where i encounter this the most.

Overall very nice changes

For sure, but as long as clickbait works they'll keep doing 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".

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 =(

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"

Pyo3 doesnt generate type hints at all iirc. There's some more info here

The gist, as i recall, is that you're supposed to maintain a .pyi file in the rust project folder that gets automatically added in by maturin when building. I'm no regex wizard, but i was able to whip together a small script that generates simple function and class stubs that also have the rust docstring. Iirc they're planning on adding some official support for generating type hints, but i have no idea how far along it is or where it is on the priority list

Here's the script. It's nothing fancy, and iirc it only works for top level functions/classes. That means you still have to take care of attributes and methods which is a little annoying, but for simple stuff it should save a bit of time.