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
Generators probably. It’s the one thing i genuinely miss about python when i work in rust.
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?
Seems you missed the last line
compiles to fast code
Obligatory shoutout to Qownnotes for being excellent, fully open source, and with owncloud integration.
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
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”.
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.
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.
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
It’s most useful when you’re using some data you already have as the dictionary key. A usecase i had for this was a binary file parser with 10 types of event markers. It was originally coded with if/elif, but performance was a pretty big consideration. Using the event markers as keys to a dictionary dispatch improved performance by about 15% and made the code significantly more readable.
I can vouch, i got one of their previous bundles that includes some of these items. Their tutorials are great, much better than random youtube videos if you’re serious about getting started. I only went through one of the courses so far, but when i get back to game dev it’s one of the first resources on my list
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.
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 =(
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.