Same age as Ruby, Java and JavaScript, but younger than Python, C, and C++. 😛
I'm guessing they meant "old" as in "no one uses it anymore, it's dead"
Meanwhile PHP quietly runs 80% of the internet by being used for WordPress.
Don’t tell my bosses that. Or the PHP community as a whole for that matter. Then I might have to get a real job.
I'm sorry. If you exclude the millions of sites using it, it is virtually unused.
The year they both came out (1995) I was coding in Visual Basic 3. Ack.
Modern php is not bad actually. Still kinda slow and dangerous, but A LOT better than it used to be :')
That said, i wouldnt build a web service with php still lol
Actual definitions (my opinion):
HTML is website
CSS is style
JS is everywhere
SQL is data
Python is simple
PHP is backend
Markdown is README
YAML is config
Python is NameError: name 'term_to_describe_python' is not defined
JavaScript is [object Object]
Ruby is TypeError: Int can't be coerced into String
C is segmentation fault
C++
Java is
Exception in thread "main" java.lang.NullPointerException: Cannot read the termToDescribeJava because is null at ThrowNullExcep.main(ThrowNullExcep.java:7)
Exec.main(ThrowNullExcep.java:7)
CSS j ust # sucks
Kotlin is type inference failed. The value of the type parameter K should be mentioned in input types
Go is unused variable
Rust is Compiling term v0.1.0 (/home/james/projects/Term)
C++ is std::__cxx11::list, std::allocator > >::erase(std::_List_const_iterator >) /usr/include/c++/12/bits/list.tcc:158
I once forgot to put curly braces around the thing I was adding into a hashmap. If I remember correctly it was like ~300 lines of error code, non of which said "Wrong shit inside the function call ma dude".
The only reason to use AI in programming is to simplify C++ error messages.
Rust is downloading 1546 dependencies
Crates aren't exactly runtime dependencies, so i think that's fine as long as the 1500+ dependencies actually help prevent reinventing the wheel 1500+ times
I'll happily download 63928 depends so long as it continues to work. And it does, unlike python projects that also download 2352 depends but in the process brick every other python program on your system
If you're not using a venv for python development, that's kind of on you
Venv is the way
Good for you. Not all of us have terabytes of free space on our computers.
If you're naming variables like that in Java you should definitely switch to C.
fixed ive using rust for a while
Mfw Rustaceans don't exist :(
Also, JavaScript...why are you the way you are? Does anyone have advice for learning it so it makes sense? I can't even get tutorial projects to run properly...
This meme is older than rust.
actually it says 8h meaning it's only 8 hours old
It will be 8 hours old forever.
Forever young...
use typescript and don't look too hard at the infrastructure
Lol any
Last company I worked at used Typescript, but used any for everything... I have no idea why. I never got an actual answer.
Because they didn’t want to train their JS developers and didn’t want to cause friction for new projects. They get to say they’re using TS, with basically none of the real advantages. (Apart from general rational error checking.)
I tried, but the infrastructure collapsed on me.
The mantra that got me through JavaScript was "almost nothing we do here is able to be synchronous".
Everything about the language makes more sense, with that context.
I like Douglas Crockford’s talks about the “good parts” of JavaScript. They’re old and probably a bit outdated, but he explain quite well the history and why JavaScript is the way like it is.
It clicked for me when I saw them the first time. Still hate JavaScript though.
What Crockford did was enable a lot of devs to realize there was a viable development platform built into the most prolific and open network client in the world. For that he should be commended but it should have never been taken as "this is a viable general purpose language".
He also showed that JavaScript has more resemblance to functional programming languages rather than object oriented ones. If you try to treat it as an object oriented language like Java (like the seem to imply), you will have a bad time.
This has changed with TypeScript though.
Can it even make sense tho? To me JS is an example of a not too good thing that people started too eagerly so now they're trying to make it make sense.
I have no idea.
Start simple.
And that probably requires not going with a tutorial. Because the JS ecosystem scorns at "simple". Just make some HTML scaffold and use MDN to understand the DOM.
Just accept it, all languages suck
"There are only two kinds of languages: the ones people complain about and the ones nobody uses."
That’s why Haskell is so loved. Nobody uses it.
I love how after a decade pandoc is still Haskell's "killer app". smh
I mean to be fair, that's a pretty useful tool.
Fortran would like a word.
Writing raw byte binaries ftw!
(Jokes aside, all programming languages have their good and bad things. Some just have more bad than good. And i say that as a C/C#/typescript/asm developer :p
Not Scala and Rust. They are my beloved, my sweethearts, my knights in shining armor.
Ok Rust does have some major issues, but not Scala...
Oof, slow compile times to target, of all things, the JVM? Implicit methods? Some(null)? Function call syntax where the difference between a tuple argument and a sequence of non-tuple arguments can be determined by whether or not there's a space before the parentheses?
There are definitely some major issues with Scala.
They also thought the best thing to take from Python is that version 3 should not be backwards compatible with version 2
I think that's good when the objective is to improve the language. One key thing that holds many languages back is that they're stuck with historical baggage, and it can be pretty difficult to replace/remove "outdated" stuff without breaking everything.
I do not want to be stuck using Python 2, or Scala 2 (although there exist people who use Scala 2 instead of Scala 3).
Where I’m working we’re heavily using Spark, which kind of blocks us from upgrading. There seem to be ways to get Scala 3 to work, but we also have old terribly written baggage code no one understands. Just upgrading between 2.12 to 2.13 was a journey.
I agree that the slow compile times are pretty bad (maybe even deal-breakingly for large projects). I think it's kind of necessary for a language with as powerful of a syntax as Scala though, it's pretty absurd how expressive you can get. Maybe if it didn't target the JVM, it'd be able to achieve way faster compile times – I don't really see a point of even targeting JVM other than for library access (not to say that that isn't a huge benefit), especially when it has relatively poor compatibility with other JVM languages and it's nearly impossible to use for Android (don't try this at home).
Even more so, I think that null handling isn't nice – I wish it were more similar to Kotlin's. One thing I'm really confused as to why Scala didn't go all-in on is Either/Result like in Rust. Types like that exist, but Scala seems to mostly just encourages you to use exceptions for error propogation/handling rather than returning a Monad.
A more minor grudge I have is just the high-level primitive types in general – it's pretty annoying not being able to specify unsigned integers or certain byte-width types by default, but if it really is an issue than it can be worked around. Also things like mutable pointers/references – I don't actually know if you can do those in Scala... I've had many situations where it'd be useful to have such a thing. But that's mostly because I was probably using Scala for things it's not as cut out to do.
With the tuple arguments point, I get it but I haven't found it much of an issue. I do wish it wasn't that way and it consistently distinguished between a tuple and an argument list though, either that or make functions take arguments without tuples like in other functional languages or CLI languages (but that'd probably screw a lot of stuff up and make compile times even LONGER). I saw someone on r/ProgrammingLanguages a while back express how their language used commas/delimiters without any brackets to express an argument list.
I think an actually "perfect" language to me would basically just be Rust but with a bunch of the features that Scala adds – of course the significant functional aspect that Scala has (and the clearly superior lambda syntax), but also the significantly more powerful traits and OOP/OOP-like polymorphism. Scala is the only language that I can say I don't feel anxious liberally using inheritance in, in fact I use inheritance in it constantly and I enjoy it. Scala's "enum"/variant inheritance pattern is like Rust enums, but on crack. Obviously, Rust would never get inheritance, but I've found myself in multiple situations where I'm thinking "damn, it's annoying that I have to treat and as almost completely serparate". It would especially be nice in certain situations with const generic traits that are basically variants of each other.
Plus, I've always personally liked function overloading and default arguments and variadics/variadic generics and stuff, but the Rust community generally seems to be against the former 2. I just really hate there being a hundred functions, all a sea of underscores and adjectives, that are basically the same thing but take different numbers of arguments or slightly different arguments.
The custom operators are a double-edged sword, I love them and always use them, but at the same time it can be unclear as to what they do without digging into documentation. I guess Haskell has a similar problem though, but I don't think Scala allows you to specify operator precedence like Haskell does and it just relies on the first character's precedence. I would still want them though.
How it goes now, though, is I use Scala 3 for project design/prototyping, scripting, and less performance-sensitive projects, and Rust for pretty much everything else (and anything involving graphics or web). Scala has good linear algebra tooling, but honestly I'll usually use C++ or Python for that most of the time because they have better tooling (and possibly better performance). I would say R too, but matplotlib has completely replaced it for literally everything regarding math for me.
Sounds like we're actually in agreement about most of this.
I'm okay with languages limiting their "expressive" power in order to provide stronger correctness guarantees or just limit how "weird" code looks; but this is largely because I've worked on many projects where someone had written a heap of difficult-to-understand code, and I doubt such limitations would be appealing if I were working strictly on my own.
I also don't really see the appeal of Java-style inheritance, but to be honest I didn't use Scala for long enough to know whether or not I agree that Scala does inheritance "right".
It does make sense that Rust provides mutability in some cases where Scala doesn't. Rust's superpower, enabled by the borrow checker, is effectively "safe mutability." I hope other, simpler languages build on this invention.
Yes, just flip binary directly to the cpu
not zig
ITT: Rust programmers rewriting the joke in Rust.
Are those adjectives randomly chosen?
Yeah, JavaScript powerful? How?
By running everthing in a single thread obviously. Won't get more powerful than that
good luck doing frontend development without it, but it can also do backend development
it can do everything
The thing it can do best is bewilder developers with it's strange choices
i wouldn't want to program in pure assembly either but asm is definitely powerful
I would argue that ASM isn't "powerful". It's direct. You can access advanced features of a CPUs architecture with the trade off limited portability. Sometimes it's necessary but power comes from being able to express complex control and data structures in a concise and readable amount of text.
The subjective topic of what "concise and readable" means is where the language wars come in.
but it can also do backend development
The same way a rusty spoon can dig a hole, sure.
That makes it versatile, not powerful.
When I hear powerful language, I think of languages that are good at intensive tasks like assembly, c, rust, Python (because of numpy, pandas, pyspark, cuda, etc.).
Python is powerful because it easily wraps C libraries that do real work! Just kidding mostly.
But yeah, js isn't a language I would describe as powerful. Ubiquitous? More capable than you would expect given it's history? Bloated?
Python is powerful because it easily wraps C libraries that do real work! Just kidding mostly.
Not kidding. There's no rule against that though. It's good at it's niche.
Does that not put JS (node) back on the table?
I'd say it's the low level language doing the heavy lifting, python or JS in this scenario are just front-ends.
Hell, I think FORTH has C bindings, that's not power, that's mental illness
Sure, but there are good and bad frontends. JavaScript has a tendency to silently fly off the handle in mysterious ways due to the crazy type system. Python will typically fail more predictably, and is famously easy to write. I know nothing about FORTH, honestly.
Dw, no one does.
I exercised JavaScript out of some of my apps, and I'm happier for it.
Did they get a good workout?
if its acceptable to force javascript onto the backend and everywhere else, then why not write the frontend in rust, or anything else than can compile to wasm ?
WASM has no native ability to access most web APIs, including the DOM. JavaScript is literally unavoidable on the front end.
javascript cannot be compiled natively for the backend or desktop either...
also libraries like wasm bindgen allow a developer to write almost no javascript. and i wouldnt could a few lines of bootstrapping.
im dont advocate for wasm when its not necessary. nor do i advocate for backend js when its not necessary.
Sorry, I'm not sure what your point is. I realize that you can almost completely avoid JavaScript, but the point I'm making is merely that there is a real technical limitation that limits the choices developers can make for front-end code, and although WASM is making great strides in breaking down that barrier (something I've been thrilled to see happen, but which is going much more slowly than I had hoped), the limitation is still there. Conversely, such a barrier has never existed on the backend, except in the sense that C limits what all other languages can do.
my point is that languages have their places.
javascript is great for the frontend. not just because it's the only choice, but it's also a lot easier to write code for ui than say, C or rust.
however i do not see a reason why it needs to run on servers or desktop apps, bar a few cases. i know node is popular, but i think fullstack devs just like to have everything in the same language, even if it makes it harder to use and slower to run.
likewise C, rust, go, whatever, are great for backends, embedded etc, but they shouldnt be ran on in the browser, unless there is a specific reason like heavy computation with little dom interaction.
just because a barrier does not exist doesnt mean that we should write programs in a language not designed for the domain.
I'm honestly not convinced JavaScript is good even for the front-end, because it's intentionally designed to swallow, ignore, and otherwise minimize errors; which is not helpful at all for development of any software. My point is that the only reason JavaScript is dominant in front-end development is that, prior to WASM, it was literally the only option; if that hadn't been the case, I doubt it would have become nearly so widely used.
i actually agree, but i think its more the issue that modern websites are designed like desktop apps. having a weakly typed and flexible langauage like js is fine when youre only adding a little interactivity to an otherwise mostly functional website.
IIRC JavaScript + TypeScript is the biggest demographic of engineers in the industry if you go by GitHub stats
I suppose you could call that power in a way
JavaScript is AN UNAVOIDABLE HARDSHIP
Pretty much so.
C++ is OVERWHELMINGLY SUPERIOR, if you ask any professional C++ developer.
I was a professional C++ developer for several years, and came to the conclusion that any professional C++ developers who don't acknowledge its flaws have a form of Stockholm Syndrome.
This is true of every language. If you can't think of things you don't like about the language you're working in (and/or its tooling) you just don't know the language very well or are in denial.
Ehhh, I mean this more strongly. I've never met people more in denial about language design problems than C++ adherents. (Though admittedly I haven't spent much time talking to Lisp fans about language design.)
It's made worse by the fact C++11 made a lot of solutions for the deep problems in the language. As the C++ tradition dictates, the problems themselves are carefully preserved for backward compatibility, the solutions are like a whole different language.
And Lisp is small - the first Google result provides a Lisp interpreter in 117 lines of Python code.
C++11 also introduced new problems, such as the strange interaction between brace-initialization and initializer-lists (though that was partially fixed several years later), and the fairly arcane rules around move semantics with minimal compiler support (for example, it would be great if the standard required compilers to emit an error if a moved-from object were accessed).
I know Lisp is minimal, I'm just saying that I expect there are Lisp fans who won't acknowledge (or would excuse) any shortcomings in the language, just as there are C++ fans who do the same for C++.
Can confirm. Chose to focus on C++ because it literally makes me superior to other people.
C++ is fine
Python is fine
C# is fine
PHP is fine
JavaScript is fine
C is fine
Java is fine
I could go on
PHP is fine
i will fine you
JavaScript is also not fine.
C++ apparently has a lot of footguns if you use too many parts of it. C and orthodox C++ are fine.
people say this but C is significantly more batshit than javascript
oh you used scanf? one of the basic functions of our language? sorry that's got a buffer overflow vulnerability so now your application is compromised
Yeah, but as far as I understand that's not a C vulnerability. It wasn't added. C just exposes how the underlying CPU works.
If you could avoid exposing dangerous memory quirks but still retain the same power... well, you'd have invented Rust. Rust is a better language than C, I agree with that.
Edit: Yep, just double checked. Buffers live in physical memory and have to be finite, so if you advance outside of them you'll go somewhere else. Scanf's not special, this is just another inherent pointer issue.
exposing the machinations of the underlying CPU with no regard for safety is like, the definition of a footgun
Okay, but how do you code on a CPU without directly interfacing the CPU at some point? Python and JavaScript both rely on things written in mid-level languages. There's a difference between a bad tool and one that just has limitations inherent to the technology.
Like, to echo the meme a bit, it's not a totally straight comparison. They have different roles.
a footgun isn't inherently bad, it just implies a significant amount of risk
yes, if you need the ability to code on a low level, maybe C is necessary, but the times where that is actually necessary is smol
also rust
Yes, also Rust. It wasn't an option until recently though.
The times when C or C++ is worth it definitely isn't always, but I'm not sure I'd class much of OS programming and all embedded and high-performance computing as small. If you have actual hard data about how big those applications are relative to others, I'd be interested.
Also, it's a nitpick, but I'd personally say a footgun has to be unforeseeable, like literal shoe guns being added to a video game where guns were previously always visible. Once you understand pointers C is reasonably consistent, just hard and human-error-prone. The quirks follow from the general concepts the language is built on.
There were memory-safe languages long before C was invented, though; C was widely considered "dangerous" even at the time.
True, but AFAIK they all sucked really bad. If you needed to make something that preformed back then you wrote in assembly.
FORTRAN might be a good counterexample. It's pretty fast, and I'm not actually sure if it's memory safe; it might be. But, it's definitely very painful to work with, having had the displeasure.
True, but AFAIK they all sucked really bad.
That's pure assumption and, as far as I can tell, not actually true. PASCAL was a strong contender. No language was competitive with handwritten assembly for several decades after C's invention, and there's no fundamental reason why PASCAL couldn't benefit from intense compiler optimizations just as C has.
Here are some papers from before C "won", a more recent article about how PASCAL "lost", and a forum thread about what using PASCAL was actually like. None of them indicate a strong performance advantage for C.
once you understand C++ the pitfalls of C++ are reasonably consistent
I'm not sure I'd class much of OS programming and all embedded and high-performance computing as small
there are like what, 3 operating systems these days?
assume those are all written entirely in c and combine them and compare that to all code ever written
once you understand C++ the pitfalls of C++ are reasonably consistent
All of C++? That's unreasonable, it's even in the name that it's very expansive. Yes, if you already know a thing, you won't be surprised by it, that's a tautology.
C is more than just pointers, obviously, but the vast majority of the difficulty there is pointers.
there are like what, 3 operating systems these days? assume those are all written entirely in c and combine them and compare that to all code ever written
Plus all previous operating systems, all supercomputer climate, physics and other science simulations, all the toaster and car and so on chips using bespoke operating systems because Linux won't fit, every computer solving practical engineering or logistics problems numerically, renderers...
Basically, if your computational resources don't vastly exceed the task to be done, C, Rust and friends are a good choice. If they do use whatever is easy to not fuck up, so maybe Python or Haskell.
All of C++? That's unreasonable, it's even in the name that it's very expansive.
similarly, "all of pointers" is unreasonable
"all of pointers" can have a lot of unexpected results
that's literally why java exists as a language, and is so popular
Plus all previous operating systems, all supercomputer climate, physics and other science simulations, all the toaster and car and so on chips using bespoke operating systems because Linux won't fit, every computer solving practical engineering or logistics problems numerically, renderers...
sure, and the quantity of code where true low-level access is actually required is still absolutely minuscule compared to that where it isn't
There was an adjective for C++. It's just the pointer was dropped.
JavaScript is powerful
Old joke (yes, you can tell):
"JavaScript: You shoot yourself in the foot. If using Netscape, your arm falls off. If using Internet Explorer, your head explodes."
C++ is all of those, provided you pick any 10% of it.
You're not supposed to cast every spell in the evil grimoire.
Well, except "robust", unless you have very strict code standards, review processes, and static analysis.
(And arguably it's never elegant, though that's almost purely a matter of taste.)
When the standard for "robust" is Java--
I see where you're coming from, but no matter how many null pointer exceptions there are in Java code, you're almost always protected from actually wrecking your system in an unrecoverable way; usually the program will just crash, and even provide a relatively helpful error message. The JVM is effectively a safety net, albeit an imperfect one. Whereas in C++, the closest thing you have to a safety net, i.e. something to guarantee that invalid memory usage crashes your program rather than corrupting its own or another process's memory, is segfaults, which are merely a nicety provided by common hardware, not required by the language or provided by the compiler. Even then, with modern compiler implementations, undefined behavior can cause an effectively unlimited amount of "bad stuff" even on hardware that supports segfaults.
Additionally, most languages with managed runtimes that existed when Java was introduced didn't actually have a static type system. In particular, Perl was very popular, and its type system is...uh...well, let's just say it gives JavaScript some serious competition.
That said, despite this grain of truth in the statement, I think the perception that Java is comparatively robust is primarily due to Java's intense marketing (particularly in its early years), which strongly pushed the idea that Java is an "enterprise" language, whatever that means.
C is powerful. Javascript is a husky midwestern gal at a Chinese buffet.
C++ is focused on getting a strong degree of root control over the hardware of lots of systems. Which is part of why it's difficult.
Only a part. A lot of the complexity is completely unnecessary.
Sorry, Undefined Behavior Everywhere was yelling way too loud to hear you clearly.
Were you talking about strong controlling anything with C++?
I mean, if you're talking about CVEs permitting attackers to get control of the hardware of lots of systems, then yes, I agree
C# is also here
I'm a [primarily] C# turned JavaScript dev. I miss C#.
The ecosystem is really it, C# as a language isn't the best, objectively Typescript is a much more developer friendly and globally type safe (at design time) language. It's far more versatile than C# in that regard, to the point where there is almost no comparison.
But holy hell the .Net ecosystem is light-years ahead, it's so incredibly consistent across major versions, is extremely high quality, has consistent and well considered design advancements, and is absolutely bloody fast. Tie that in with first party frameworks that cover most of all major needs, and it all works together so smoothly, at least for web dev.
The only reason I use C++ is because that's what all the main audio plugin tools use. It's warty and annoying, although I'm confused why Java would rank higher
So we just ignore JavaScript being on that list at sll?
I shit on JavaScript for years... but Deno (built around Rust) is honestly one of the most pleasant tools I've used for development, and you get all the completion in VS Code.
My main experience using C++ was because I got stuck modifying an app written with Qt Creator, an utterly insane cross-platform framework that used (still uses? I dunno, only people in Finland ever used it in the first place) C++ for the under-the-hood processing and Javascript for the UI. For good measure, the application developers had modified all the C++ stuff with macros to the point where it was barely even recognizable as C++. Fortunately, it mattered not at all because the app's customers were ISPs who just wanted a Skype clone so they could say they had one even though none of their customers ever used the damn thing.
Oh, trust me, Qt is still primarily C++. It's effectively a massive set of C++ libraries.
Couldn't we use pure C or Pure Data with hvcc for this?
Ruby is just happy to be included
Rust has safety and efficiency close to C
Perl is processing most of your healthcare records
What happens if I run paint splatters through OCR? Hmmmmm that random output looks like Perl. Holy shit it is Perl!
This actually happening is one reason I love the internet.
Perl? Nah, in this country its vb6, C#, java, gupta/centura and javascript :')
Source: been working for multiple healthcare market leaders in this country for 5 years now
What is C essential for anymore these days? Genuine question btw.
I thought C++ was essential for microprocessor control, but that it depends and sometimes I gather people use C instead, but not always.
Use the language that the company hires you to know:-).
I do embedded. Its all C. You can't replace it.
You can't replace it.
Zig?
Wait, that's like C with extra fewer steps
And I think they rewrote a bunch of C libraries in order to have a better cross-platform compiler for C and zig. Or something along those lines
Or Nim?
Inertia is a mofo. I did embedded programming for industrial automation almost thirty years ago, building upon and expanding an existing nightmare of C code... and I bet there's still some of mine running something out there to this day.
Most of the Linux kernel is written in C
Pretty much all of the command line coreutils programs I use daily are in C; cd, ls, pwd, touch, rm, etc. If I want to write some small utility I'll usually reach for a scripting language first like bash python ruby etc, but if it needs to be small and fast I'll use C instead.
Genuine question: if you're writing a new CLI utility, why not Rust? This is arguably where Rust has most excelled, most famously with ripgrep.
I don't have anything against Rust, I'm just not very familiar with it
any sort of FFI on a modern OS will need to be done through C
Used to be embedded systems mostly. Microwaves and the like. Although with the advance of the smart home I don't know I'd that's still true.
The majority of microwaves, fridges, etc. Still don't connect to WiFi. It's mostly the high end ones which do.
The thing with C is that it's almost always going to be the fastest high-ish level language and it has an extremely stable ABI. Self contained code written 30 years ago will likely compile with only minor (and sometimes no) tweaks today. You're lucky to go 3 years on C++ without something fairly big breaking due to changes in the underlying language and ABI.
That's the kind of insight I was hoping for, thanks for sharing!
C is also just a fun language to code in. You know, aside from pointers ofc:-). Though I have never done more than dabble around personally.
This is a really good post about why C is so difficult to seriously consider replacing, or even to avoid by using a different language for certain projects: https://faultlore.com/blah/c-isnt-a-language/
It isn't just a language, but it is a language - as it eventually gets around to saying, but it starts off by saying that it isn't, then later corrects itself to say that it is, etc. I feel like the focus of this ignores the historical context of what C was written to be for - at the time there was like Assembly, BASIC, Fortran (?), other long-dead languages like was it A and/or A* or whatever, there was a B language too! (developed by Bell Labs, if Google can be trusted these days), etc. - and C was developed to be better than those. So saying that like it lacks type conversions is very much missing the point - those were not invented yet. A lawn mower also lacks those, but it's okay bc it doesn't need them:-) I am probably nit-picking far too many points, I suppose to illustrate that the style of the article became a hindrance to me to read it b/c of those reasons. But thank you for sharing regardless.
I don't really like the title either, but the article does demonstrate how unfortunate it is that we're effectively locked in to using the ABI at some level of nearly every piece of software.
That said, there definitely were languages with better type systems prior to the invention of C. Pascal is a frequently-cited example.
Oh wow, good points!:-)
C++ catchin strays
C pew pew
There is another
That you might say is a little rusty
This meme only works if you don't include any example that is better than others in every regard.
I keep seeing people talk about Rust, and to be honest I never thought much about it because I've never had a reason to use it.
But when so many people in a programmer meme sub are saying "actually no joke Rust is amazing" that makes me pay attention.
︎ ︎ ︎ not alig-
︎ ︎ ︎ ned
Same age as Ruby, Java and JavaScript, but younger than Python, C, and C++. 😛
I'm guessing they meant "old" as in "no one uses it anymore, it's dead"
Meanwhile PHP quietly runs 80% of the internet by being used for WordPress.
Don’t tell my bosses that. Or the PHP community as a whole for that matter. Then I might have to get a real job.
I'm sorry. If you exclude the millions of sites using it, it is virtually unused.
The year they both came out (1995) I was coding in Visual Basic 3. Ack.
Modern php is not bad actually. Still kinda slow and dangerous, but A LOT better than it used to be :')
That said, i wouldnt build a web service with php still lol
Actual definitions (my opinion):
Python is
NameError: name 'term_to_describe_python' is not definedJavaScript is
[object Object]Ruby is
TypeError: Int can't be coerced into StringC is
segmentation faultC++
Java is
type inference failed. The value of the type parameter K should be mentioned in input typesunused variableCompiling term v0.1.0 (/home/james/projects/Term)C++ is std::__cxx11::list, std::allocator > >::erase(std::_List_const_iterator >) /usr/include/c++/12/bits/list.tcc:158
I once forgot to put curly braces around the thing I was adding into a hashmap. If I remember correctly it was like ~300 lines of error code, non of which said "Wrong shit inside the function call ma dude".
The only reason to use AI in programming is to simplify C++ error messages.
Rust is downloading 1546 dependencies
Crates aren't exactly runtime dependencies, so i think that's fine as long as the 1500+ dependencies actually help prevent reinventing the wheel 1500+ times
I'll happily download 63928 depends so long as it continues to work. And it does, unlike python projects that also download 2352 depends but in the process brick every other python program on your system
If you're not using a venv for python development, that's kind of on you
Venv is the way
Good for you. Not all of us have terabytes of free space on our computers.
If you're naming variables like that in Java you should definitely switch to C.
fixed ive using rust for a while
Mfw Rustaceans don't exist :(
Also, JavaScript...why are you the way you are? Does anyone have advice for learning it so it makes sense? I can't even get tutorial projects to run properly...
This meme is older than rust.
actually it says 8h meaning it's only 8 hours old
It will be 8 hours old forever.
Forever young...
use typescript and don't look too hard at the infrastructure
Lol any
Last company I worked at used Typescript, but used
anyfor everything... I have no idea why. I never got an actual answer.Because they didn’t want to train their JS developers and didn’t want to cause friction for new projects. They get to say they’re using TS, with basically none of the real advantages. (Apart from general rational error checking.)
I tried, but the infrastructure collapsed on me.
The mantra that got me through JavaScript was "almost nothing we do here is able to be synchronous".
Everything about the language makes more sense, with that context.
I like Douglas Crockford’s talks about the “good parts” of JavaScript. They’re old and probably a bit outdated, but he explain quite well the history and why JavaScript is the way like it is.
It clicked for me when I saw them the first time. Still hate JavaScript though.
What Crockford did was enable a lot of devs to realize there was a viable development platform built into the most prolific and open network client in the world. For that he should be commended but it should have never been taken as "this is a viable general purpose language".
He also showed that JavaScript has more resemblance to functional programming languages rather than object oriented ones. If you try to treat it as an object oriented language like Java (like the seem to imply), you will have a bad time.
This has changed with TypeScript though.
Can it even make sense tho? To me JS is an example of a not too good thing that people started too eagerly so now they're trying to make it make sense.
I have no idea.
Start simple.
And that probably requires not going with a tutorial. Because the JS ecosystem scorns at "simple". Just make some HTML scaffold and use MDN to understand the DOM.
Just accept it, all languages suck
"There are only two kinds of languages: the ones people complain about and the ones nobody uses."
That’s why Haskell is so loved. Nobody uses it.
I love how after a decade pandoc is still Haskell's "killer app". smh
I mean to be fair, that's a pretty useful tool.
Fortran would like a word.
Writing raw byte binaries ftw!
(Jokes aside, all programming languages have their good and bad things. Some just have more bad than good. And i say that as a C/C#/typescript/asm developer :p
Not Scala and Rust. They are my beloved, my sweethearts, my knights in shining armor.
Ok Rust does have some major issues, but not Scala...
Oof, slow compile times to target, of all things, the JVM? Implicit methods?
Some(null)? Function call syntax where the difference between a tuple argument and a sequence of non-tuple arguments can be determined by whether or not there's a space before the parentheses?There are definitely some major issues with Scala.
They also thought the best thing to take from Python is that version 3 should not be backwards compatible with version 2
I think that's good when the objective is to improve the language. One key thing that holds many languages back is that they're stuck with historical baggage, and it can be pretty difficult to replace/remove "outdated" stuff without breaking everything.
I do not want to be stuck using Python 2, or Scala 2 (although there exist people who use Scala 2 instead of Scala 3).
Where I’m working we’re heavily using Spark, which kind of blocks us from upgrading. There seem to be ways to get Scala 3 to work, but we also have old terribly written baggage code no one understands. Just upgrading between 2.12 to 2.13 was a journey.
I agree that the slow compile times are pretty bad (maybe even deal-breakingly for large projects). I think it's kind of necessary for a language with as powerful of a syntax as Scala though, it's pretty absurd how expressive you can get. Maybe if it didn't target the JVM, it'd be able to achieve way faster compile times – I don't really see a point of even targeting JVM other than for library access (not to say that that isn't a huge benefit), especially when it has relatively poor compatibility with other JVM languages and it's nearly impossible to use for Android (don't try this at home).
Even more so, I think that null handling isn't nice – I wish it were more similar to Kotlin's. One thing I'm really confused as to why Scala didn't go all-in on is Either/Result like in Rust. Types like that exist, but Scala seems to mostly just encourages you to use exceptions for error propogation/handling rather than returning a Monad.
A more minor grudge I have is just the high-level primitive types in general – it's pretty annoying not being able to specify unsigned integers or certain byte-width types by default, but if it really is an issue than it can be worked around. Also things like mutable pointers/references – I don't actually know if you can do those in Scala... I've had many situations where it'd be useful to have such a thing. But that's mostly because I was probably using Scala for things it's not as cut out to do.
With the tuple arguments point, I get it but I haven't found it much of an issue. I do wish it wasn't that way and it consistently distinguished between a tuple and an argument list though, either that or make functions take arguments without tuples like in other functional languages or CLI languages (but that'd probably screw a lot of stuff up and make compile times even LONGER). I saw someone on r/ProgrammingLanguages a while back express how their language used commas/delimiters without any brackets to express an argument list.
I think an actually "perfect" language to me would basically just be Rust but with a bunch of the features that Scala adds – of course the significant functional aspect that Scala has (and the clearly superior lambda syntax), but also the significantly more powerful traits and OOP/OOP-like polymorphism. Scala is the only language that I can say I don't feel anxious liberally using inheritance in, in fact I use inheritance in it constantly and I enjoy it. Scala's "enum"/variant inheritance pattern is like Rust enums, but on crack. Obviously, Rust would never get inheritance, but I've found myself in multiple situations where I'm thinking "damn, it's annoying that I have to treat and as almost completely serparate". It would especially be nice in certain situations with const generic traits that are basically variants of each other.
Plus, I've always personally liked function overloading and default arguments and variadics/variadic generics and stuff, but the Rust community generally seems to be against the former 2. I just really hate there being a hundred functions, all a sea of underscores and adjectives, that are basically the same thing but take different numbers of arguments or slightly different arguments.
The custom operators are a double-edged sword, I love them and always use them, but at the same time it can be unclear as to what they do without digging into documentation. I guess Haskell has a similar problem though, but I don't think Scala allows you to specify operator precedence like Haskell does and it just relies on the first character's precedence. I would still want them though.
How it goes now, though, is I use Scala 3 for project design/prototyping, scripting, and less performance-sensitive projects, and Rust for pretty much everything else (and anything involving graphics or web). Scala has good linear algebra tooling, but honestly I'll usually use C++ or Python for that most of the time because they have better tooling (and possibly better performance). I would say R too, but matplotlib has completely replaced it for literally everything regarding math for me.
Sounds like we're actually in agreement about most of this.
I'm okay with languages limiting their "expressive" power in order to provide stronger correctness guarantees or just limit how "weird" code looks; but this is largely because I've worked on many projects where someone had written a heap of difficult-to-understand code, and I doubt such limitations would be appealing if I were working strictly on my own.
I also don't really see the appeal of Java-style inheritance, but to be honest I didn't use Scala for long enough to know whether or not I agree that Scala does inheritance "right".
It does make sense that Rust provides mutability in some cases where Scala doesn't. Rust's superpower, enabled by the borrow checker, is effectively "safe mutability." I hope other, simpler languages build on this invention.
Yes, just flip binary directly to the cpu
not zig
ITT: Rust programmers rewriting the joke in Rust.
Are those adjectives randomly chosen?
Yeah, JavaScript powerful? How?
By running everthing in a single thread obviously. Won't get more powerful than that
good luck doing frontend development without it, but it can also do backend development
it can do everything
The thing it can do best is bewilder developers with it's strange choices
i wouldn't want to program in pure assembly either but asm is definitely powerful
I would argue that ASM isn't "powerful". It's direct. You can access advanced features of a CPUs architecture with the trade off limited portability. Sometimes it's necessary but power comes from being able to express complex control and data structures in a concise and readable amount of text.
The subjective topic of what "concise and readable" means is where the language wars come in.
The same way a rusty spoon can dig a hole, sure.
That makes it versatile, not powerful.
When I hear powerful language, I think of languages that are good at intensive tasks like assembly, c, rust, Python (because of numpy, pandas, pyspark, cuda, etc.).
Python is powerful because it easily wraps C libraries that do real work! Just kidding mostly.
But yeah, js isn't a language I would describe as powerful. Ubiquitous? More capable than you would expect given it's history? Bloated?
Not kidding. There's no rule against that though. It's good at it's niche.
Does that not put JS (node) back on the table?
I'd say it's the low level language doing the heavy lifting, python or JS in this scenario are just front-ends.
Hell, I think FORTH has C bindings, that's not power, that's mental illness
Sure, but there are good and bad frontends. JavaScript has a tendency to silently fly off the handle in mysterious ways due to the crazy type system. Python will typically fail more predictably, and is famously easy to write. I know nothing about FORTH, honestly.
Dw, no one does.
I exercised JavaScript out of some of my apps, and I'm happier for it.
Did they get a good workout?
if its acceptable to force javascript onto the backend and everywhere else, then why not write the frontend in rust, or anything else than can compile to wasm ?
WASM has no native ability to access most web APIs, including the DOM. JavaScript is literally unavoidable on the front end.
javascript cannot be compiled natively for the backend or desktop either...
also libraries like wasm bindgen allow a developer to write almost no javascript. and i wouldnt could a few lines of bootstrapping.
im dont advocate for wasm when its not necessary. nor do i advocate for backend js when its not necessary.
Sorry, I'm not sure what your point is. I realize that you can almost completely avoid JavaScript, but the point I'm making is merely that there is a real technical limitation that limits the choices developers can make for front-end code, and although WASM is making great strides in breaking down that barrier (something I've been thrilled to see happen, but which is going much more slowly than I had hoped), the limitation is still there. Conversely, such a barrier has never existed on the backend, except in the sense that C limits what all other languages can do.
my point is that languages have their places.
javascript is great for the frontend. not just because it's the only choice, but it's also a lot easier to write code for ui than say, C or rust.
however i do not see a reason why it needs to run on servers or desktop apps, bar a few cases. i know node is popular, but i think fullstack devs just like to have everything in the same language, even if it makes it harder to use and slower to run.
likewise C, rust, go, whatever, are great for backends, embedded etc, but they shouldnt be ran on in the browser, unless there is a specific reason like heavy computation with little dom interaction.
just because a barrier does not exist doesnt mean that we should write programs in a language not designed for the domain.
I'm honestly not convinced JavaScript is good even for the front-end, because it's intentionally designed to swallow, ignore, and otherwise minimize errors; which is not helpful at all for development of any software. My point is that the only reason JavaScript is dominant in front-end development is that, prior to WASM, it was literally the only option; if that hadn't been the case, I doubt it would have become nearly so widely used.
i actually agree, but i think its more the issue that modern websites are designed like desktop apps. having a weakly typed and flexible langauage like js is fine when youre only adding a little interactivity to an otherwise mostly functional website.
IIRC JavaScript + TypeScript is the biggest demographic of engineers in the industry if you go by GitHub stats
I suppose you could call that power in a way
JavaScript is AN UNAVOIDABLE HARDSHIP
Pretty much so.
C++ is OVERWHELMINGLY SUPERIOR, if you ask any professional C++ developer.
I was a professional C++ developer for several years, and came to the conclusion that any professional C++ developers who don't acknowledge its flaws have a form of Stockholm Syndrome.
This is true of every language. If you can't think of things you don't like about the language you're working in (and/or its tooling) you just don't know the language very well or are in denial.
Ehhh, I mean this more strongly. I've never met people more in denial about language design problems than C++ adherents. (Though admittedly I haven't spent much time talking to Lisp fans about language design.)
It's made worse by the fact C++11 made a lot of solutions for the deep problems in the language. As the C++ tradition dictates, the problems themselves are carefully preserved for backward compatibility, the solutions are like a whole different language.
And Lisp is small - the first Google result provides a Lisp interpreter in 117 lines of Python code.
C++11 also introduced new problems, such as the strange interaction between brace-initialization and initializer-lists (though that was partially fixed several years later), and the fairly arcane rules around move semantics with minimal compiler support (for example, it would be great if the standard required compilers to emit an error if a moved-from object were accessed).
I know Lisp is minimal, I'm just saying that I expect there are Lisp fans who won't acknowledge (or would excuse) any shortcomings in the language, just as there are C++ fans who do the same for C++.
Can confirm. Chose to focus on C++ because it literally makes me superior to other people.
I could go on
i will fine you
JavaScript is also not fine.
C++ apparently has a lot of footguns if you use too many parts of it. C and orthodox C++ are fine.
people say this but C is significantly more batshit than javascript
oh you used
scanf? one of the basic functions of our language? sorry that's got a buffer overflow vulnerability so now your application is compromisedYeah, but as far as I understand that's not a C vulnerability. It wasn't added. C just exposes how the underlying CPU works.
If you could avoid exposing dangerous memory quirks but still retain the same power... well, you'd have invented Rust. Rust is a better language than C, I agree with that.
Edit: Yep, just double checked. Buffers live in physical memory and have to be finite, so if you advance outside of them you'll go somewhere else. Scanf's not special, this is just another inherent pointer issue.
exposing the machinations of the underlying CPU with no regard for safety is like, the definition of a footgun
Okay, but how do you code on a CPU without directly interfacing the CPU at some point? Python and JavaScript both rely on things written in mid-level languages. There's a difference between a bad tool and one that just has limitations inherent to the technology.
Like, to echo the meme a bit, it's not a totally straight comparison. They have different roles.
a footgun isn't inherently bad, it just implies a significant amount of risk
yes, if you need the ability to code on a low level, maybe C is necessary, but the times where that is actually necessary is smol
also rust
Yes, also Rust. It wasn't an option until recently though.
The times when C or C++ is worth it definitely isn't always, but I'm not sure I'd class much of OS programming and all embedded and high-performance computing as small. If you have actual hard data about how big those applications are relative to others, I'd be interested.
Also, it's a nitpick, but I'd personally say a footgun has to be unforeseeable, like literal shoe guns being added to a video game where guns were previously always visible. Once you understand pointers C is reasonably consistent, just hard and human-error-prone. The quirks follow from the general concepts the language is built on.
There were memory-safe languages long before C was invented, though; C was widely considered "dangerous" even at the time.
True, but AFAIK they all sucked really bad. If you needed to make something that preformed back then you wrote in assembly.
FORTRAN might be a good counterexample. It's pretty fast, and I'm not actually sure if it's memory safe; it might be. But, it's definitely very painful to work with, having had the displeasure.
That's pure assumption and, as far as I can tell, not actually true. PASCAL was a strong contender. No language was competitive with handwritten assembly for several decades after C's invention, and there's no fundamental reason why PASCAL couldn't benefit from intense compiler optimizations just as C has.
Here are some papers from before C "won", a more recent article about how PASCAL "lost", and a forum thread about what using PASCAL was actually like. None of them indicate a strong performance advantage for C.
once you understand C++ the pitfalls of C++ are reasonably consistent
there are like what, 3 operating systems these days?
assume those are all written entirely in c and combine them and compare that to all code ever written
All of C++? That's unreasonable, it's even in the name that it's very expansive. Yes, if you already know a thing, you won't be surprised by it, that's a tautology.
C is more than just pointers, obviously, but the vast majority of the difficulty there is pointers.
Plus all previous operating systems, all supercomputer climate, physics and other science simulations, all the toaster and car and so on chips using bespoke operating systems because Linux won't fit, every computer solving practical engineering or logistics problems numerically, renderers...
Basically, if your computational resources don't vastly exceed the task to be done, C, Rust and friends are a good choice. If they do use whatever is easy to not fuck up, so maybe Python or Haskell.
similarly, "all of pointers" is unreasonable
"all of pointers" can have a lot of unexpected results
that's literally why java exists as a language, and is so popular
sure, and the quantity of code where true low-level access is actually required is still absolutely minuscule compared to that where it isn't
What’s the point of having a function in the standard library if the universal recommendation is to never use it?
Is that the recommendation? This is the first time I've actually seen it discussed.
I'm wondering at this point if a new, different stdlib would be better. Or just use Rust.
To be honest, my comment probably applies more to
gets, but the point is the same.A true programmer
Go on...
Don't give them ideas
There was an adjective for C++. It's just the pointer was dropped.
Old joke (yes, you can tell):
"JavaScript: You shoot yourself in the foot. If using Netscape, your arm falls off. If using Internet Explorer, your head explodes."
C++ is all of those, provided you pick any 10% of it.
You're not supposed to cast every spell in the evil grimoire.
Well, except "robust", unless you have very strict code standards, review processes, and static analysis.
(And arguably it's never elegant, though that's almost purely a matter of taste.)
When the standard for "robust" is Java--
I see where you're coming from, but no matter how many null pointer exceptions there are in Java code, you're almost always protected from actually wrecking your system in an unrecoverable way; usually the program will just crash, and even provide a relatively helpful error message. The JVM is effectively a safety net, albeit an imperfect one. Whereas in C++, the closest thing you have to a safety net, i.e. something to guarantee that invalid memory usage crashes your program rather than corrupting its own or another process's memory, is segfaults, which are merely a nicety provided by common hardware, not required by the language or provided by the compiler. Even then, with modern compiler implementations, undefined behavior can cause an effectively unlimited amount of "bad stuff" even on hardware that supports segfaults.
Additionally, most languages with managed runtimes that existed when Java was introduced didn't actually have a static type system. In particular, Perl was very popular, and its type system is...uh...well, let's just say it gives JavaScript some serious competition.
That said, despite this grain of truth in the statement, I think the perception that Java is comparatively robust is primarily due to Java's intense marketing (particularly in its early years), which strongly pushed the idea that Java is an "enterprise" language, whatever that means.
C is powerful. Javascript is a husky midwestern gal at a Chinese buffet.
C++ is a surprise CVE generator.
Anti Commercial-AI license
C++ is focused on getting a strong degree of root control over the hardware of lots of systems. Which is part of why it's difficult.
Only a part. A lot of the complexity is completely unnecessary.
Sorry, Undefined Behavior Everywhere was yelling way too loud to hear you clearly.
Were you talking about strong controlling anything with C++?
I mean, if you're talking about CVEs permitting attackers to get control of the hardware of lots of systems, then yes, I agree
C# is also here
I'm a [primarily] C# turned JavaScript dev. I miss C#.
The ecosystem is really it, C# as a language isn't the best, objectively Typescript is a much more developer friendly and globally type safe (at design time) language. It's far more versatile than C# in that regard, to the point where there is almost no comparison.
But holy hell the .Net ecosystem is light-years ahead, it's so incredibly consistent across major versions, is extremely high quality, has consistent and well considered design advancements, and is absolutely bloody fast. Tie that in with first party frameworks that cover most of all major needs, and it all works together so smoothly, at least for web dev.
Shhh don't tell people they'll ruin it.
what about Holy C? is it only usable to people that are actually god choosen programmers?
It's racist
Calling Terry racist is ableist. He was very much equal opportunity, applying the hard r to pale white CIA agents (imagined or otherwise).
You are right he was egalitarian in that.
I also have it on good authority that he had a black friend which gave him the N word pass.
nah, he bought the N word pass from SHV
https://www.youtube.com/watch?v=rPNrHN83Bdk
The only reason I use C++ is because that's what all the main audio plugin tools use. It's warty and annoying, although I'm confused why Java would rank higher
So we just ignore JavaScript being on that list at sll?
I shit on JavaScript for years... but Deno (built around Rust) is honestly one of the most pleasant tools I've used for development, and you get all the completion in VS Code.
My main experience using C++ was because I got stuck modifying an app written with Qt Creator, an utterly insane cross-platform framework that used (still uses? I dunno, only people in Finland ever used it in the first place) C++ for the under-the-hood processing and Javascript for the UI. For good measure, the application developers had modified all the C++ stuff with macros to the point where it was barely even recognizable as C++. Fortunately, it mattered not at all because the app's customers were ISPs who just wanted a Skype clone so they could say they had one even though none of their customers ever used the damn thing.
Oh, trust me, Qt is still primarily C++. It's effectively a massive set of C++ libraries.
Couldn't we use pure C or Pure Data with hvcc for this?
Ruby is just happy to be included
93% of Paint Splatters are Valid Perl Programs
What happens if I run paint splatters through OCR? Hmmmmm that random output looks like Perl. Holy shit it is Perl!
This actually happening is one reason I love the internet.
Perl? Nah, in this country its vb6, C#, java, gupta/centura and javascript :')
Source: been working for multiple healthcare market leaders in this country for 5 years now
What is C essential for anymore these days? Genuine question btw.
I thought C++ was essential for microprocessor control, but that it depends and sometimes I gather people use C instead, but not always.
Use the language that the company hires you to know:-).
I do embedded. Its all C. You can't replace it.
Zig?
Wait, that's like C with
extrafewer stepsAnd I think they rewrote a bunch of C libraries in order to have a better cross-platform compiler for C and zig. Or something along those lines
Or Nim?
Inertia is a mofo. I did embedded programming for industrial automation almost thirty years ago, building upon and expanding an existing nightmare of C code... and I bet there's still some of mine running something out there to this day.
Most of the Linux kernel is written in C
Pretty much all of the command line coreutils programs I use daily are in C; cd, ls, pwd, touch, rm, etc. If I want to write some small utility I'll usually reach for a scripting language first like bash python ruby etc, but if it needs to be small and fast I'll use C instead.
Genuine question: if you're writing a new CLI utility, why not Rust? This is arguably where Rust has most excelled, most famously with ripgrep.
I don't have anything against Rust, I'm just not very familiar with it
any sort of FFI on a modern OS will need to be done through C
Used to be embedded systems mostly. Microwaves and the like. Although with the advance of the smart home I don't know I'd that's still true.
The majority of microwaves, fridges, etc. Still don't connect to WiFi. It's mostly the high end ones which do.
The thing with C is that it's almost always going to be the fastest high-ish level language and it has an extremely stable ABI. Self contained code written 30 years ago will likely compile with only minor (and sometimes no) tweaks today. You're lucky to go 3 years on C++ without something fairly big breaking due to changes in the underlying language and ABI.
That's the kind of insight I was hoping for, thanks for sharing!
C is also just a fun language to code in. You know, aside from pointers ofc:-). Though I have never done more than dabble around personally.
This is a really good post about why C is so difficult to seriously consider replacing, or even to avoid by using a different language for certain projects: https://faultlore.com/blah/c-isnt-a-language/
It isn't just a language, but it is a language - as it eventually gets around to saying, but it starts off by saying that it isn't, then later corrects itself to say that it is, etc. I feel like the focus of this ignores the historical context of what C was written to be for - at the time there was like Assembly, BASIC, Fortran (?), other long-dead languages like was it A and/or A* or whatever, there was a B language too! (developed by Bell Labs, if Google can be trusted these days), etc. - and C was developed to be better than those. So saying that like it lacks type conversions is very much missing the point - those were not invented yet. A lawn mower also lacks those, but it's okay bc it doesn't need them:-) I am probably nit-picking far too many points, I suppose to illustrate that the style of the article became a hindrance to me to read it b/c of those reasons. But thank you for sharing regardless.
I don't really like the title either, but the article does demonstrate how unfortunate it is that we're effectively locked in to using the ABI at some level of nearly every piece of software.
That said, there definitely were languages with better type systems prior to the invention of C. Pascal is a frequently-cited example.
Oh wow, good points!:-)
C++ catchin strays
C pew pew
There is another That you might say is a little rusty
This meme only works if you don't include any example that is better than others in every regard.
I keep seeing people talk about Rust, and to be honest I never thought much about it because I've never had a reason to use it.
But when so many people in a programmer meme sub are saying "actually no joke Rust is amazing" that makes me pay attention.
So I looked into it and found this: https://github.blog/2023-08-30-why-rust-is-the-most-admired-language-among-developers/
Java is robust haha
I was caught by surprise and for some reason this joke clicked so much that I laughed for a while. Kudos
Stop comparing tools
such pointless
Tea? i saw it once in a wikipedia article.
C++ is... I got nothing.
C++ is inferior to Rust and should be used in no new projects unless it is absolutely necessary
I believe the trade-offs make Rust the best option to replace C++. Now, i'm not sure about Zig replacing C yet...