as long as everyone is clear that lisp has the best syntax idc about the rest.
if you don’t like Lisp, you can use Forth
(((Truth)))
Homoiconicity is the shit.
C++ is pretty sweet.
It definitely has its issues - don’t get me wrong, but it’s pretty sweet.
Correction: modern C++ is pretty sweet.
Chances are if you’re working on C++ in a professional setting it’s not modern C++ :(
As a Rustacean, I’d rather use C than C++ for a small project.
Why C ‘hackers’? Why not just regular C users?
Was thinking of putting “UNIX Hackers” but I thought that might have been too obscure. Referencing people like Linus Torvalds’, Theo de Raadt’s, and cat-v’s opinions on C++.
To my knowledge, it’s a name that came out of the free software / GNU movement. So, “hackers” as in clever problem solvers, not those that break into insecure systems.
Which should be known as a “cracker”, but yeah mainstream media fucked the word “hacker” to mean something it doesn’t.
Meh? I write pretty much exclusively in C and honestly I still like C++ better, and wouldn’t mind switching to Rust either
I started with c++ so does c really has advantages over c++ ?
And yeah same, Rust seems to be pretty cool too, at some point I’m gonna try it…
I started in C and switch to C++. It’s easy to think that the latter sort of picked up where the former left off, and that since the advent of C++11, it’s unfathomably further ahead. But C continues to develop and occasionally gets some new feature of its own. One example I can think of is the
restrict
key word that allows for certain optimizations. Afaik it’s not included in the C++ standard to date, though most compilers support it some non-standard way because of its usefulness. (With Rust, the language design itself obviates the need for such a key word, which is pretty cool.)Another feature added to C was the ability to initialize a
struct
with something likeFooBar fb = {.foo=1, .bar=2};
. I’ve seen modern C code that gives you something close to key word args like in Python using structs. As of C++20, they sort of added this but with the restriction that the named fields have to come in the same order as they were originally defined in the struct, which is a bit annoying.Over all though, C++ is way ahead of C in almost every respect.
If you want to see something really trippy, though, have a look at all the crazy stuff that’s happened to FORTRAN. Yes, it’s still around and had a major revision in 2018.
I just like that it’s relatively procedural. Assembly too. Classes etc are just not something I’ve needed… Yet.
C++ is way ahead of C in the same way that a metastasized cancer is way ahead of a benign tumor
I started with C++ too, and then ended up finding a job writing firmware pretty much all in C. There really hasn’t been anything we’ve run into that’s made us consider switching to C++; being able to (and needing to) have complete control over your memory means you can do some pretty fancy stuff with the tiny amounts of memory on our ASICs.
We’ve been eyeballing switching to rust a little bit, but really only for other applications; the root of our main code base is over 25 years old at this point and a rewrite would take a Herculean effort.
Yeah, learning Rust has given me greater appreciation for C/C++. Like, the selling feature of all three is that they don’t use a runtime, which means you’re not locked into that ecosystem. You can create libraries with them, that can be used from virtually any other language.
It’s also easy to say that the performance of Java, Python et al is fine, but having a larger application start up in 1 rather than 20 seconds is still always appreciated.
Like, the selling feature of all three is that they don’t use a runtime
Microsoft:
C and C++ are way worse than mid. Had rust been invented at the same time, C and C++ would’ve disappeared in obscurity and only been taught at university to explain pointers.
They are nearly on the same level of bilge as COBOL.
ATS blasting in here to give you linear types, dependent types, & refinement types with the literal performance of C—& safety beyond all 3.