Don't worry, none of my code uses that, designated initilizers, complex numbers, variable length arrays, typedef name overloading, unintilized constants, implicit void pointer casting, implicit function declarations, nested struct defintions, or any of the other exclusively-C features.
Pease consider the opposite; if a fork is needed at some point in the future, we need people who are familiar with the codebase. It would be, for example, much better for 3 of 4 contributors to be sane than only 2 of 3.
Sure, there's lots of solutions, but we have to talk about them. Even something as simple as "turning on red is often used as a crutch for signaling issues. We shouldnt be waiting at stop lights in the middle of nowhere when theres nobody nearby in the first place"
The key point is *include these people, their situation, their perspective, in the discussion"
I dislike these kinds of articles (as someone who bikes to work everyday) because of how they treat an urban perspective as if its the only perspective. Some highway stoplights are in the middle of nowhere, have no crosswalk, can go a full year without a single pedestrian, and often have mimal cars. People who sit at those lights every day get mad from articles (like this one) that are completely tonedeaf to their situation.
Yes, in a busy city it makes no sense to allow turn on red, and the article has some great info but it also makes no sense to wait 2 minutes on red when there isn't a car or human within a 5 mile radius.
If we want people to be onboard with change we've got to include them. We can solve both; like getting rual lights to use a flashing red to indicate "allows for turning on red" and THEN get city lights to ban turning right on solid red. Solving one problem expense of another is a quick way to create enemies.
That is an important difference. Still lots of people, myself included, classify "compiler printing an error (not a warning)" as failure, even if bizzarly the code still runs somehow.
I didn't say C++ was a superset of C, I said "if I take my c code and add a cpp extension it works". Believe me, I am painfully aware of the not-a-superset problem between C and C++. My point is Typescript doesn't even meet the very loose "its practically a superset" relationship that C++ has with C.
Type annotations. It can be as simple a adding any in front of parameters, but there are other edgecases too, and when you have a really big codebase it can be a pain to convert.
Chromium, Firefox, NodeJS, Deno, and Bun are all open source. I mean, sure the official name is ECMAScript not JavaScript, but unless you're talking about a technicality I'm not sure what your point is.
If I take my json and add a .yaml extension it works.
If I take my c code and add a .cpp it works.
If I take my js code and add a .ts
... it doesn't work
TS branches off of the JS syntax (which is great! way better than a syntax rewrite), but TS is not a superset; it does not meet the practical or technical definition of a language superset.
I'd say there's an initial learning curve of the basics that isn't bad. Kinda like learning programming for the first time; it's a different way of thinking and for something like Sudoku I'd say it's even pleasant.
But when you try to write a CLI videogame, or anything with an evolving internal state, then Prolog stops being the elegant logic system and instead becomes big bundle of edgecases where nothing makes sense practically or theoretically.
To get to your core point; I agree python without a virtual env, just raw python, is definintely not bulky. I'd argue its much more lightweight than cargo. My comment was because sounds like OP could be new-ish to programming, and, for a number of projects (ex; Android development), going from a big IDE to just a plaintext editor + command line commands can be a really painful jump. I remeber a Java course having a series of IDE tutorials and I could not for the life of me figure out the plaintext+commandline equivlent. The same can happen for certain python projects if a tutorial expects the editor to set the PYTHONPATH and the project has a venv, and the tutorial expects the editor's terminals start already-inside python virtual environment. That kind of stuff can make 'python without an IDE" confusing and daunting to someone merely following PyCharm tutorials.
I just wanted to assure OP they likely wouldn't have that kind of experince with Rust. AFAIK Rust tutorials rarely (if ever) assume an IDE.
Being not-bulky isn't a rust specific thing, a half-decent package manager meets the qualitification, but OP was asking about Rust and might not know.
I can generally convince people to use Telegram, but not signal. Telegram is better than SMS, GroupMe, WhatsApp, Discord, Facebook Messenger, SnapChat, etc so its what I use.
If anything, I've got hopes that Element/Matrix will get enough polish to become viable.
Is it just me or does it feel kinda unclean for it to just support 1 through 9?