Unfortunately the generational GC modifies bits all over the heap, so you have to use some tricks to really leverage copy on write (as the commenter alludes to).
Typescript has almost identical semantics to Javascript but adds typing syntax to improve developer experience and make it easier to manage a large-scale JS codebase.
Zig is a fundamentally different language than C that has a lot of new features. Two great examples are comptime and allocators which have complements in C, but are really very different from what C provides.
If you're suggesting that zig is aiming to provide a C alternative with better ergonomics, then I agree; but zig and C have a lot more differences than Typescript and Javascript.
Zig has more things for C interop than you're suggesting though, namely the extern keyword, calling convention, etc. Like ts/js, zig/c seems first class designed be used together in one codebase, compared to eg Rust where is obviously possible but more deliberately discouraged (since it breaks the safety guarantees, which Zig never claimed to begin with)
There is an option to circumvent the prerequisites as a non-major:
You may also get permission from an advisor if you performed very high on the CS Assessment on Canvas.
I took the course over the summer as a music major and subsequently took several other CS courses as a music major after having a discussion with an advisor in the CS department. I ended up finishing a CS degree a year after my music degree. CMU was really great about providing opportunities for students to explore courses outside of their majors, especially over the summer.
This varies by school. Some will allow you to skip prereqs with instructor or advisor permission, some make that almost impossible. Some may allow you to audit the course but not take it for credit.
Honestly for the larger CS classes I took, there were enough people in the class that I doubt anyone would have noticed a person slipping in to a back row seat and just quietly watching. More than once I sat in on classes that I thought I might want to take, to get a better sense of the content and the professor's teaching style.
"Principles of Imperative Programming" is a misnomer.
The course is really about developing techniques for reasoning about low-level software. You build up abstractions in C by leveraging contracts and writing proofs of correctness based on those contracts.
This was the first computer science course that I took at CMU and it was absolutely mind blowing for me. I had previously taken AP CS and had played around with making games in flash and writing little programs for my graphing calculator. But this course taught me how to reason about my programs (and why that might be valuable, to begin with).
> You build up abstractions in C by leveraging contracts and writing proofs of correctness based on those contracts. […] this course taught me how to reason about my programs
That seems like an essential part of what programming should be about? And imperative programming has it’s own considerations on how to go about it. I don’t see how it is a misnomer.
That's a big "if". The author themselves mentions modular implicits and points out that they haven't been updated in something like five years. I don't think modular implicits are going to happen in Ocaml in our lifetimes.
Doesn't the normal approach in C++ run into similar issues? The workarounds in C++ are more ergonomic than in Rust, but can still require a lot of refactoring.
One of the performance bottlenecks that I ran into while reimplementing clox in C++ was using `new` and `delete` instead of `realloc` for arrays and hash tables.
By the time that I figured out it was an issue, I was already using `operator new` to track heap allocations for the garbage collector.
I'm not sure that it's that cut and dry. Rust provides good tools for building high level abstractions and the developer tooling is comparable to something like typescript. Depending on the team, rust can be a perfectly reasonable choice for a CRUD application.
I have a lot of experience writing microservices and batch jobs using C++. At first this seems outrageous, but with a reasonable set of high level utility libraries, C++ can be very expressive. And then you have the option to drop down to whichever level of abstraction is necessary to address performance or concurrency issues.
Beyond platform requirements (e.g. HTML, CSS and JS on the web or python for ML) I think language choice has more to do with business needs than high level problem domain. When you're building an MVP or have an urgent business need where you need to prioritize short term progress over long term flexibility, high level languages with GC are great. If you have an experienced team and you want to build something that will offer flexibility in the long term, Rust is a fine choice.
I agree Rust is a great language (and has many great things besides its safety protections) but I do think that putting it everywhere when it isn’t necessary is dangerous.
If one doesn’t exist already, someone should make a rust-like language with garbage collection.
EDIT: Thanks to reading other comments, I remembered Elixir, which offers a lot of the concurrency safety of rust without the memory risks.
Kotlin is probably also a good choice (but it ties you do the JVM, which does come with some operational headaches of it's own). Swift would be a fantastic language for this kind of work, but unfortunately it's library ecosystem isn't on nearly the same level as Rust's for backend web.
Rust is an interesting mix. OCaml gets pretty close and type inference offers better ergonomics. The fearless concurrency story is still much better in Rust than OCaml.
If you want high level abstractions, well, automatic memory management enables a bunch of abstractions that the Rust developers gave up on long ago. There are languages with many more capabilities than the ones Rust gives you.
If you have a high level problem, you don't want to spend your focus on low level issues.
> automatic memory management enables a bunch of abstractions that the Rust developers gave up on long ago.
These claims should really come with sourcing. Rust devs have been raising the potential for abstraction in Rust since the initial 1.0 release, most recently with GAT's. What's always been quite hard is zero overhead abstraction, which GC languages simply have no equivalent for.
Sourcing for my "water is wet" claim? Just try writing a language parser in Rust and Haskell and you'll see the difference. Or, to be more on topic, write some database to HTML on Rust and note how you have to keep track of your templates' lifetimes.
The Rust developers are a bunch of very smart people working hard on creating a great language, but they can't do impossible things.
Batch jobs seem like a good candidate for C++ because of how much faster a single instance will be. Multiplied across the size of the total job, that can represent enormous savings. On the other hand, using Rust for a web server with low QPS and atop a relatively novel web stack seems unnecessarily risky. The article does comment on Actix being a pain point.
My current job doesn't use Rust at all, but we're experimenting with converting some CLI tools. There should be relatively little library dependence for the things we're targeting.
Fatigue is a common side effect of Zyrtec (and other antihistamines). From purely anecdotal evidence, I think most people have to experiment with allergy medication to find one that works best for them. I know that I'm dysfunctional when taking Zyrtec but Claritin doesn't bother me at all.
I definitely had to experiment as well - I bounced around between Claritin and Allegra for a couple of years. I did try Zyrtec and experienced significant fatigue with it, which led me to stop using it pretty quickly.
Earlier this year I discovered Xyzal (expensive, but does have generic versions, too), which appears to be a close relative to Zyrtec. Interestingly though, they recommend taking it at bedtime rather that in the morning, the idea being you'll get a better night's sleep from not being congested AND you'll sleep through the worst part of the fatigue from it. This has worked out well for me - my allergies have bothered me less this year than they have in the last ten years or so, and I sleep better at night (I've had problems with insomnia off and on for ~20 years).
RE: the OP, I'm in my mid 40s and have always had some issues with following through and not procrastinating, and my sister was recently diagnosed with ADHD, so it's probably something I should at least discuss with my doctor at my next physical.
