Generics and cross-crate inlining enable zero-(runtime)cost abstractions, meaning there’s usually no perf downside to using 3rd party code instead of your own.
Strict type system, standardized error checking, thread safety in interfaces, and built in tooling for API documentation makes using libraries relatively easy.
The ecosystem is pretty large now, and has a culture of respecting semver, and focus on safety and reliability.
Cargo makes adding dependencies easy (the most common complaint is that it’s too easy, and people use too many dependencies).
With a typical workflow of “just compile this source code”, this is an impossible task, because performance of algorithm implementations depends on the actual data they process (think how SQL plans queries based on table stats). Profile-guided optimization already improves performance significantly despite merely informing some heuristics. A truly optimal compiler would need to design algorithms for specific data sets (basically what people do when they profile the code).
However, there are some takes beyond the “Algol68 on PDP11” design of most languages. There’s Intel’s SPMD C compiler that extends the language to make auto-vectorization a first-class feature.
There is Halide lang specifically for image processing, which separates the goal from the algorithms used to archive it.
The problem is that a typical built-in standard library can't change or remove any APIs, even the ones that turned out to be mistakes or became obsolete, without breaking users. Eventually all the fancy standard parts of it get easier, faster, cleaner 3rd party replacements, and everyone is saddled with a dilemma of using the meh stdlib or a 3rd party dependency anyway.
OTOH functionality shipped as external libraries can be versioned, upgraded, and replaced by users individually, on their own schedule. The obsolete cruft can be pulled in by old projects that still need it, without burdening new projects with the same old APIs (but they still can interoperate, because multiple versions of the same library can coexist!)
For very long-lived languages (which Rust has ambition to be) a one-size-fits-all built-in big standard library is a big risk. The bigger it is, the less obvious and less timeless the APIs are. A basic Vec is easy to get right on the first try, but networking is a moving target, fashions for file formats come and go, threads/green threads/callbacks/promises/await come and go, parsers can be designed in many differently-bad ways, and OSes change — we don't have non-binary files any more, but ossified languages do! WASM/WASI has upturned even Rust's barebones standard library, and Fuchsia would even more.
This risk of maintaining mistakes forever eventually makes maintainers of the standard library overly cautious, and design very defensive opaque non-committal APIs.
IMHO languages should not have any single built-in unversioned library at all. Pull in what you use, in a version that makes sense this year, without the baggage that every API has to remain unchanged forever, and still be sensible and efficient half a century later, even on an OS that doesn't exist yet on hardware that hasn't been invented yet.
Rust has a nice solution of having a &str slice (equivalent of C++ std::string_view) as the lowest common denominator and a deref operator that can easily coerce various string types to the slice.
This allows Rust to have all kinds of string flavors (fixed-len or NUL-terminated or growable, on stack or heap or in ROM, with SSO, with CoW, interned or refcounted, atomically or not, and so on), but they all coerce to the basic &str, so they have the same basic methods, and are compatible with most functions that just want a string without caring how it's allocated.
You can use your own weird string type if you want, but usually you're not forced to convert or copy it to use it with standard library functions or 3rd party dependencies.
Yeah - although the cost of this is that it makes rust harder to learn. (Try answering the common beginner question: “How is &String different from &str?”)
In rust Strings are usually passed in to functions as a &str, and returned from functions as String. It makes sense once you’re used to it, but I think philosophically Rust is much closer to C++ than C. Rust is missing the elegant minimalism of C or Zig.
It just illustrates the point. There is no elegance in simplicity. Zig is not memory safe and its functions „assume” utf8 with UB when they encounter invalid bytes.
C also has &str and &String, but they're "char* that crashes if you free() it" and "char* that leaks if you don't free() it".
Ownership is hard to learn, and it is a barrier to learning Rust. However, don't confuse it with C++. Rust has two+ string types on purpose, not because of carrying 1970's legacy.
> Try answering the common beginner question: “How is &String different from &str?”
This has nothing to do with strings though - how is &Vec<T> different from &[T] or &Box<[T]>? You need to understand ownership, references, and unsized types.
Sort of. It certainly affects strings, and you can't really use strings without understanding the difference.
My point is that its yet another thing in the big bucket of junk you need to learn in order to use rust effectively. Rust is the only language I know of that has separate types for owned strings and a borrowed strings. Its a powerful concept - and its fast and efficient for the computer. But its not "free". The cost is that it makes it harder to learn rust.
While we're on the topic - it also really doesn't help that the names of these types in the standard library are super idiosyncratic. String is to Vec<u8> as &str is to &[u8]. You just have to memorise that. How about Path and PathBuf? One of them is like String, and one is like &str. I swear I have to look it up every single time.
I think the investment is worthwhile - I adore rust. But as I said, rust feels more like a better C++ than a better C. All the pain is front loaded, with the assumption that you'll eventually write enough software in rust to make the investment worthwhile.
Simpler languages like Python or Go get out of your way immediately and let you be productive. I prefer rust, but there's definitely something to be said for that attitude.
I think I would sum this up with saying that strings are not simple, and there is a delicate balance between making simple things simple and complex things possible without shooting yourself in the foot - both as a user, and as a library designer.
Since Rust prefers to have verbosity and correctness over ease, it makes sense to have multiple types to reflect the different requirements of the underlying data.
I sympathize with some of the std library verbosity when it comes to strings (and paths) but I don't think it's really a big criticism of why Rust's learning curve is steep. You have the same issues in C++, and doubly so in C because it doesn't help you at all and when you screw up the program crashes. When you use strings in an unmanaged language and need to manipulate them, you do need to understand the underlying consequences of how those strings are defined and stored. Comparing to managed languages like Python and Go is a bit unfair, because they're working in a different domain.
Python is a great example of what happens when you try and hide complexity too far from the programmer - the python3 ecosystem fracture took millions of dollars and over a decade to settle - because of the inherent complexity in string representations.
> Rust is the only language I know of that has separate types for owned strings and a borrowed strings.
C++ and Objective-C (kinda) have different types for owned and referenced strings. C++ in particular has the same requirements as Rust, where referenced strings need to be able to refer to literals and it's not acceptable to make the default allocate.
Agree that the naming is pretty bad, but ultimately there are like… three or four of these owned/deref pairs you actually have to remember in day to day usage? I do wish they had gone with a consistent naming scheme, but in the grand scheme of things this is one of the more minor things that Rust got wrong.
Yup, I can’t imagine switching to a language that doesn’t have something like that, since in C# you have a similar feature in the form of Span<T> and ReadOnlySpan<T>, to which all manners of sources can be coerced: heap-allocated arrays, stack-allocated buffers, inline arrays, strings, native memory, etc.
At this point it has nothing to do with user experience, security or whatever convenient excuses they had. Apple is just flexing how much control they have over everything on their platform.
When did the fee ever have anything to do with those things? Not sure which argument logic trap that is but I’m sure somebody can correct me :) It is their platform, they can charge what they want. Epic is going to charge as much as they possibly can on their platform. If you make a platform that people want to use, charge as much as you like.
I can’t read the site due to a massive “We value your privacy” pop up informing me about the 1532 data-harvesting “partners” they sell information to, and there’s only “Allow All” button accessible (which is illegal by GDPR).
They really value my privacy, for its resale value.
There is a huge difference between the common stereotype of ADHD (just rowdy children who can't sit still), and actual symptoms and diagnostic criteria. The difference is almost as comically warped as an image of a "hacker" in media vs actual hackers.
ADHD includes many other things like weak short-term memory, defunct perception of time, hard to control hyperfocus, overwhelming inner monologue, and executive dysfunction that makes some tasks physically impossible to start even when the person wants to do them. And it comes with a bunch of other comorbidities. Doctors diagnosing ADHD also have obligation to exclude other causes of the symptoms, like bipolar.
The stimulant medication does not actually cause stimulation in people with ADHD. When people have a deficit/insensitivity to the neurotransmitters, the meds merely bring them up from a dysfunctional level where the brain lacked ability to function properly to the normal-ish level.
I really like that you list a whole lot of things that ADHD includes that most people are unaware of, but I wanted to call attention to the two that probably had the largest negative impact on my own life
Rejection Sensitivity and Emotional Disregulation
I have always been paralyzed by being afraid of failure (rejection), and that has kept me from pursuing a lot of things in the past
And I've always been prone to anger outbursts, even over seemingly trivial silly things. It has damaged so many of my relationships and overall left me pretty lonely throughout my life. And when the dust settles I'm sitting there thinking "Why was I so angry about that thing. I don't even care that much about it"
My ADHD diagnosis and medication, starting in my early 30s, has almost entirely turned my life around
Thank you both for adding these comments. I'm older than you, mid-40s now, and I'm _just_ starting to get treatment for ADHD after a lot of unnecessary struggles.
I'm sure that people like the root of this thread mean well, but at the same time that attitude is exactly what kept me from receiving treatment or care when I was younger.
I’m predominantly inattentive type but focus isn’t actually my most severe symptom. That would be executive dysfunction.
I lucked into SWE being a hyperfocus of sorts, so luckily work isn’t awful if I’m not on meds, but holy cow is anything else just complete drudgery. Feels like everything is behind a wall of “startup energy” that is so hard to get through, especially without external accountability.
Rejection sensitivity is also part of it for me. I felt like I could never think fast or organized enough in the moment when talking (I would lose my train of thought in the middle of sentences), so I would get anxious coming in and try and plan, but there’s only so much you can plan for, and it just is a bad cycle to get in. Therapy and internalizing things don’t actually have that high stakes is helpful but only mostly a fix.
I wonder if the symptoms you described can be also explained by being on autism spectrum. And then there's generalized anxiety disorder - a common comorbidity with ADHD, which could also cause worrying about failure.
I fairly certain I have either ADHD, autism, or probably both, and have existing diagnosis pointing to being "neuroatypical". But coming up with exact diagnosis seems to be pretty difficult, because many other diagnosis can explain specific symptoms.
It's possible, sure. There's a blurry line between ADHD and autism, and ADHD is often comorbid when diagnosed with autism.
I would say, though, that ADHD medication can help with rejection sensitivity disorder and help regulate some emotional stress on top of the more well-known ADHD symptoms. Practically speaking, it doesn't matter where it comes from if it can be treated.
For ADHD in particular I think you have to zero in on executive function. It does bring along a lot of friends, but poor executive function is absolutely the keystone of any ADHD diagnosis
If you don't struggle with that, then you can probably safely eliminate it as a suspect... Or at least put it much lower on the list
How long have you been on medication? I think I should start medication again (diagnosed 7 years ago in early adulthood) but am scared of the side effects of long term medication use.
TLDR: I’ve been on Adderall over ten years and no known long term problems attributable to my meds. You should share your concerns with a/multiple doctor(s).
I’m not the parent but since no one answered: I was diagnosed in early childhood but only started meds around 21 years old (the first time I took Adderall was the first time I wrote an outline for a paper) and I’ve been on it nearly continuously for 13 years now, almost at the maximum dose. So far, no side effects at all of long-term use other than a learned behavior of building anxiety and stress every month around the time of getting my perception due to the war on drug style of regulation. I have only rarely had short term side effects when only taking extended release Adderall.
On your concern generally, I’m not a doctor but I’m not sure long-term effects should be a big concern without some known contraindication. To my recollection, none but my current doctor have given much discussion to long term effects of Adderall, if at all. My current doctor (who I believe had finished residency shortly before I started seeing him) was concerned about long term (heart) effects and I asked him for some links to info/studies. He sent me a webmd link to an article discussing a paper examining cardiac events in Canadian patients over 65 recently starting Adderall, which found no increased risk of cardiac events vs those not starting/taking Adderall. I don’t think there were conflicts of interest declared but it seemed like some authors had some association with the Shire pharmaceutical company. For context I’m mid 30’s, American, and have been taking Adderall as a long-term patient so I was confused about why he would send that but he didn’t expand on it when pressed. Research I did on my own only led me to studies showing that people with ADHD are twice as likely to of die in an accident as non-adhd counterparts, which I had never heard from any doctor and I believe is the leading cause of death in my age group.
As another note, my uncle was prescribed Concerta for an off-label use and quickly started having suicidal thoughts and stopped using it. Work with a physician who feels like a good match with you so you can be candid with them.
Not really, because broken proxies include anti-virus software that sits at the endpoint, as well as corporate TLS-MITMing boxes.
Browsers have spent years trying to find a way to deploy pipelining, but nothing really worked. You can't even allowlist based on known-good User-Agent or Via headers, because the broken proxies are often transparent. It's also very hard to detect pipelining errors, because you don't just get responses out of order, you may get response bodies mangled or interleaved.
The idea is truly dead. With H2 being widely supported now, and having superior pipelining in every way, there's no incentive to retry the pain of deossifying H1.
Generics and cross-crate inlining enable zero-(runtime)cost abstractions, meaning there’s usually no perf downside to using 3rd party code instead of your own.
Strict type system, standardized error checking, thread safety in interfaces, and built in tooling for API documentation makes using libraries relatively easy.
The ecosystem is pretty large now, and has a culture of respecting semver, and focus on safety and reliability.
Cargo makes adding dependencies easy (the most common complaint is that it’s too easy, and people use too many dependencies).