To be honest, I didn't pay much attention to it for a while -- it felt like it might have simply been that day's "flavor of the day", destined to sink once then next flavor became popular.
Now, there's a real problem to be solved. But I thought a simpler approach would be needed (e.g., Zig or something like it). I guess that may still happen, but seems more and more like Rust is here to stay.
I suspect that Zig will still end up eclipsing Rust - not because it's a "more powerful" language, but because it's much easier to learn. Lower barriers of entry seem to matter more than mere "power" - see Common Lisp's multi-decade feature lead being ignored, and Python leapfrogging other more capable languages (Common Lisp) or equally capable ones that came first (Ruby) due to ease-of-use.
Zig is too uninteresting to eclipse anything. It's the same problem as D's -betterC option. It's not better-enough to motivate switching away from C in places where C is still used, and it's far too stripped down & basic to attract the majority that's gone to C++, Rust, Go, ObjC, or Swift (or even "full" D). It doesn't offer much to justify switching costs. If C++11 had never happened then maybe Zig would attract the C++ crowd, but today?
Zig also seems far too opinionated & even self-contradictory. Like no hidden control flow means that you can't have operator overloading because apparently the + operator is invisible to people or something. And if it could be overridden it could call a function (gasp!) or throw an exception (double gasp!), followed immediately by a big section about how the + operator internally is hidden control flow and can throw an exception (overflow checking).
It then also constantly claims itself as being small & simple, but it has compile-time reflection & evaluation for templated functions - which is widely considered the main complexity of C++. I think Zig is better overall having this feature, I love constexpr & friends in C++, but compile-time code generation & evaluation over generic types is also not "simple" nor "small".
As someone who knows C and not Zig, Zig is very interesting. It has incremental compilation, in-place binary patching, the ability to use code before declaration in a file, compile-time code execution, and extremely low compile times. Rust itself doesn't have most of those.
Also, as Python illustrated, a language doesn't have to be interesting to be popular.
As Python also illustrated, a language can be opinionated and popular. I'm growing more and more convinced that useful languages have to be opinionated - opinions have to be somewhere, and if they're not in the language (where the entire community is forced to use them), then they'll have to be in individual code-bases, where you'll get a bunch of fragmentation (which I think was one of the things that killed Lisp).
Now, Zig is very imperfect - no hidden control flow/operator overloading, no REPL, and a weak type system, most notably - but it's better than C in almost every way, easier to learn than Rust, and way more conceptually scalable than FORTH (which has a more "beautiful" design).
> Also, as Python illustrated, a language doesn't have to be interesting to be popular.
Python was very interesting, or rather, Python is the thing in its interesting group that survived. Highly flexible scripting language with a "batteries included" library set is a very compelling sales pitch, even today. It was Perl but readable, and in this case simply being "readable" was interesting enough to cause it to win out (and also Perl's internal drama)
> As Python also illustrated, a language can be opinionated and popular.
Python's "style guide" is opinionated, but Python the language itself isn't that opinionated. Missing ++ & -- are about the only contentious "opinionated" aspects to it. You can fiddle with basically everything else however you want, though, and the language made adjustments to make that even more possible (eg, replacing the print keyword with the overridable print() function).
Critically Python's standard library didn't really get any special treatment from the language. When a language lets the standard library or builtins do things that you can't, that's when it gets really questionable.
"Perl but readable" and "batteries included" are true but leave out some equally important things: The explicit reference / dereference business in Perl makes handling nested data structures pretty annoying and strongly guides programmers to avoid those, which has a lot of compounding effects to structure of prgorams. Also Python embraced multiplatform early on, and had eg excellent Windows support, whereas Perl was always Unix first. Also the culture is important. Python was always beginner-friendly whereas Perl people were less likely to suffer fools gladly.
> It has incremental compilation, in-place binary patching, the ability to use code before declaration in a file, compile-time code execution, and extremely low compile times. Rust itself doesn't have most of those.
Rust has all of those except in place binary patching and fast compile times.
Rust's "compile-time code execution" is a horrendously complex joke, and it's compile times are so atrociously long that the lack of those two things you mentioned is even worse than in a language like C (with somewhat-sane compilation speed).
> Incremental compilation, edit-and-continue are available in Visual C and C++.
In a particular toolchain not available cross-platform - not comparable to Zig having it available in the reference implementation, which is open-source and cross-platform.
> REPLs do exist for C and C++.
Hacky, nonstandard ones with limitations and altered semantics that aren't included in any of the major IDE's. Not remotely comparable to what's provided with SLIME.
> It's the same problem as D's -betterC option. It's not better-enough to motivate switching away from C in places where C is still used, and it's far too stripped down & basic to attract the majority that's gone to C++, Rust, Go, ObjC, or Swift (or even "full" D).
I've been interested in D since the early days (back when it had two competing standard libraries) - I think you're kind of misrepresenting why D never caught on - it wasn't that people weren't interested in a better C++ - it's that D was unsuitable for a lot of scenarios C++ was used because they decided to include GC in the language and it needed to have a runtime that supports it. This put D more in the C# alternative camp than C++ alternative, it was harder to port (I don't know if D still has a working iOS or Android ports, it didn't have them a few years ago when I last checked). And as a C# alternative it's strait out worse across the board (C# has quite string native interop so D doesn't really win much, tooling ecosystem and support is levels above).
If someone came up with something ala D (strong C/C++ interop, fast compile times, good metaprogramming, modules, package manager) without the GC and LLVM based (so it's super portable out of the box) I'm sure it would gain traction. The problem is that's a huge undertaking and I don't see who would be motivated to fund such a thing.
Rust exists because it solves a real problem and places like this BT stack seem like perfect use case due to security aspects - but the security aspect also adds a lot of complexity and there are domains that really don't care about it - they just want sane modules, modern package management and fast compile times.
Go has it's own niche in the application/network programming.
Seems like modern system languages get purpose built and general purpose ones are higher up the stack.
> If someone came up with something ala D (strong C/C++ interop, fast compile times, good metaprogramming, modules, package manager) without the GC and LLVM based (so it's super portable out of the box) I'm sure it would gain traction.
This happened recently (in D timeframe) and is still a hack that basically creates a different language that's a subset of D - which is the dirtiest way to fix an initial design mistake. If D came out as betterc from the go I guarantee you the adoption would have been much better - this way you're stuck with legacy decisions of a language that was never really that popular to begin with (unlike C - C++ story).
Also back when it launched LLVM wasn't really a thing (GCC was probably the closest thing to having a portable backend but it wasn't nearly as clear cut especially with the licensing and all that anti-extensibility attitude), and D having it's own custom backend was also an issue.
I applaud the effort but at this point I think it will never get mainstream popularity like Rust. I'm sure it's useful to people but it had it's time in the spotlight, I don't see how they get the momentum shift.
> It's not better-enough to motivate switching away from C in places where C is still used
I suspect zig will eventually fill this niche. Proper arrays and strings and better compile time execution support while still being a small, simple, explicit language are quite significant improvements on C.
But why wouldn't I use Rust in those scenarios, which gives me even more safety & compile-time bug checking? Zig isn't actually a small or simple language, after all, that's just marketing bullshit. Manual, mostly unassisted memory management isn't simple, and compile time evaluation & reflection isn't small. It keeps making claims about being simpler because it doesn't have macros or metaprogramming, but that's incredibly deceptive at best since it does have compile-time code generation (aka, metaprogramming). It's how Zig's printf function works! https://ziglang.org/documentation/0.7.1/#Case-Study-printf-i...
And as a bonus Rust includes a package manager today, instead of a coming eventually promise. So I'm not seeing why I'd ever go with Zig over Rust if I was migrating off of C today?
> Zig isn't actually a small or simple language, after all, that's just marketing bullshit. Manual, mostly unassisted memory management isn't simple, and compile time evaluation & reflection isn't small. It keeps making claims about being simpler because it doesn't have macros or metaprogramming, but that's incredibly deceptive at best since it does have compile-time code generation (aka, metaprogramming).
As VP of marketing bullshit I recommend you double check your source of information as we never claimed that Zig has no metaprogramming, in fact comptime is mentioned on the front page of the official Zig website and the codesample on the right of it shows comptime metaprogramming too.
That said, is you need something stable today, then Rust is undoubtedly the better choice.
It think zig makes quite a bit of sense for micro-controllers where you need really precise control of things, avoid lots of bugs simply by having all memory statically allocated, and you need to do a lot of unsafe bit twiddling anyway to interact with hardware.
Zig won't dis-allow any correct programs, zig would compile faster, and zig does appear to be simpler even though in principle you could come across specific zig programs that aren't simple due to doing crazy metaprogramming.
If I imagine a world where Zig is 1.0, and has the same tooling/ecosystem as Rust, and I want to make a single player game from scratch, I would probably pick Zig over Rust, and Zig over C or C++.
I think Zig is really interesting and has a lot of great ideas, some of which I hope Rust takes inspiration from. They've also done some difficult engineering work to make parts of the development experience feel amazing, like bundling clang and libc implementations for a variety of platforms so that cross-compiling works out-of-the-box. The Zig cross-compiling story is the best I've ever seen of any language, bar none.
That being said, I do think Rust's memory safety story is a game-changer for systems programming. We seem to be in a programming language boom, with lots of new and interesting languages being developed. I hope some of them iterate on the concepts that Rust has developed so we can do even better in the future! I don't think anyone involved in Rust would claim that it's the best we can do, or it solves every problem perfectly.
Why would you need operator overloading in a low-level language? It's not like you are gonna write Jupyter notebooks with it. Zig is not meant to replace MATLAB, Python or Julia. I would use it instead to build the backbone of such a data science platform.
> Why would you need operator overloading in a low-level language?
Have you ever heard of matrices and vectors? You need them in a lot of DSP (digital signal processing) applications, like audio and video filters, or in 3D graphics. Being able to write
because the * operator is side-effect free by convention, while a method like vector_mult() might or might not be mutating (i.e., it could work like the *= assignment operator).
I use operator overloading in C++ all the time, you seem to be looking at it from a data science perspective, but other fields use math also, such as gamedev.
I would have imagined that in game dev you prototype first with a high level language and then you would write the math code. How much of game dev is actually math code, aside from critical components like rendering, physics, etc.?
I share your view partially. As you said, code generation is difficult and it can get messy pretty fast, but this is the beauty of Zig, you have these features tightly packed, there is a capped number of ways for doing things. In Zig you learn how to use the wand properly, instead of being distracted by trying different sizes and colors of wands. While many languages focus on the breadth of ways of doing things, Zig is all about the depth of a small set.
Sounds a lot like Go. For me, that was a huge problem with Go.
I can only speak for Go, not Zig at all, but not giving me the "wand colors" meant that when i still needed colors to solve my problems, i had to invent them myself. .. okay this analogy breaks down there, but yea. The need for basic things like iterators, enums, and sometimes even generics didn't go away in Go. They didn't stop being extremely useful patterns or abstractions. They're just missing.
So what do you do with something that is still useful, possibly needed, but missing? You reinvent it. Very basic behavior like Iterators, Maps, etc become separated by piles of functions spread out all over the page. Yea, it's all simple - no complex features, but also no way to express that logic tightly, quick to reason about. Go wears down your scroll wheel in my experience (~5 years).
Would i have the same complaints about Zig? Your comment leaves me feeling like i would.
> So what do you do with something that is still useful, possibly needed, but missing? You reinvent it.
Yup, see for example java.lang.Comparable which is basically just the standard library going "yeah the language screwed up, here's your operator overloading"
Back then the main draw of Python was supposed to be the "one way of doing things" - Python originally started as a teaching language.
And look at Python today - there's what, five different "standard" ways of packaging libraries? (And why is "packaging libraries" even a thing?) Instead of "batteries included" we get at least four different ways of doing every common task: the stdlib Python 2 way, the stdlib Python 3 way, the "standard" community third-party synchronous library and the "standard" community async one.
This is just how it always is. Every language starts with the goal of being small, easy to understand and beautifully composeable.
The cruft builds over time because people eventually want it and because none of it ever really goes away due to backwards compatibility.
I think it's best to make peace with this fact, learn to live with the cruft and accept existing languages rather than switching your entire stack every three years trying to chase an unobtainable dragon.
I think Zig could end up being much more popular for domains where Rust's safety and correctness features are less important. Something like a bluetooth stack is exactly where Rust is ideal though imho. Some for crypto libs.
I believe the number of domains which benefit from Rust’s safety features combined with its runtime performance are vast. IoT, hardware drivers, autonomous systems, embedded systems, (cars, drones) infrastructure, etc.
I would choose Rust in these scenarios if I have choice.
I understand that the language has a steeper learning curve but it’s an upfront cost compared to C (or Zig?) where you have to put even more effort later on chasing the same bugs which Rust could’ve protected you from.
I don’t know Zig well enough so I’m not arguing against it. It’s just what I think about being safe vs being easier to learn.
But I see your point. At the end of the day, the growth of the language happens almost organically and might not follow the logic I put forward.
I think of Zig as a quarter step between C and Rust. You don't get memory safety, but you DO get better handling of undefined behavior, and option types, and better protection from array bounds overruns.
So like a single player video game, it might be an easier overall choice, in a hypothetical world where ecosystems are similarly fleshed out.
Common Lisp had itself and its community to blame. Their dependency managers were decades behind other scripting languages. Poor defaults for build tooling. Even now building a statically-linked binary is an exercise in frustration.
Despite being an ANSI specified language, the most popular libraries focuses only on SBCL. CL is like Lua where most interpreters never achieve 100% compatibility with each other. The lack of Emacs/Vim alternatives demands beginners to adhere to their dogma. Adhering to their cargo cult might be reasonable if they are the dominant language and culture. But they are not. Software engineering classes in university teaches how to make Java AbstractSingletonProxyFactoryBeans first and caml/lisp much later. Common lisp had it coming when they had their lunch eaten by Clojure. They were an old irrelevant relic that sat on their ivory tower and refused to improve or confront the status quo beyond empty words.
And it is not like the Common Lisp community lacks resources. They claim their language is used at Google via ITA software and in GOFAI through Grammarly. Even the bleeding edge of computing through Regetti. Then where are all the maintained, up to date tooling and libraries? Do a quick search and almost everything is unmaintained or half dead, with the usual generic excuse being "we are ANSI specified, libraries twenty years ago will work perfectly fine".
HN is an echo chamber for the greatness of Lisp where every commenter would worship at its church before going back to coding JS/Python/Java on Monday.
Rust isn't that hard to learn. I teach it to college sophomores who only know Java, and within 2-3 months I have them writing parsers and interpreters in Rust. In fact these students are requesting our courses to be taught in Rust, and have never heard of Zig.
I think that while the language is a little complicated, this is tempered by how nice the tooling is. I consider the borrow checker to be my TA, as it actually helps the student write code that is structured better. When they go on to write C and C++ in later courses, their code is actually more memory safe due to having their habits having been shaped by Rust.
It's fairly mixed. Compiler warnings and errors are great. IDE integration is improving. CPU profiling with perf/hotspot is fine, albeit memory-hungry. Debugging and memory profiling is still bad compared to java.
That's nice, at UPB in Bucharest we use for the OS course C and for the distributed systems one Go/Java, though the DS one involves heavy theory/math and less coding but implementations in Go/Java are a big bonus. I don't know where do you teach, but our students would probably be confused by Rust and their time will be spent elsewhere instead of being focused on the actual course content.
Possibly but Python is a completely different level of programming too.
I do wonder if Rust is easier or harder than other comparable languages like C / C++ when the person has no prior knowledge of programming.
I would say just the ease of having a hello world and the ease of the Rust book would make it easier to get to grips with. No dealing with complex build systems and compiler flags at the start
> I do wonder if Rust is easier or harder than other comparable languages like C / C++ when the person has no prior knowledge of programming.
I can answer this because I previously taught the course in C and C++. The students supposedly have some knowledge of Java but they seem to always have forgotten all of it when they reach me.
Students learning C use all of the footguns you can imagine. The biggest problem for them is writing code that segfaults, and their code always segfaults. It's not so much a problem that it does, but that there is 0 useful feedback as to why the segfault occurred and where they could potentially look to fix the problem. The bigger issue for them is memory management. They frequently walk into the use after free, double free, and memory leak walls. They also have significant trouble with N-dimensional pointer arrays. They have trouble allocating the appropriate memory for these arrays and can't seem to visualize the layout of memory.
C++ is a little better because they have experience with Java, but they are frequently mystified by constructors/destructors and how to manage memory manually (they only have experience with a GC), and template programming is always an issue. But they still run into the same issue with segfaults.
Rust makes all of this go away. They don't have to manage their memory manually, and they don't encounter a single segfault. Ever. We are able to just sweep all of those problems under the rug, and move on to actual content. With C/C++ we focused a lot on the language with the hope we could use it as a tool eventually, with Rust we use the language as a tool and focus on the wider world of applications for which that tool is useful.
You are doing it wrong If you are manually managing memory on Modern C++.
C++ has RAII built in even before Rust came to the scene.
I've never had a situation where I had to manage memory manually during my professional career in C++
If your students face seg faults, please show them Valgrind. Valgrind is better than GDB when it comes to seg faults. It can show you where exactly error occurred.
Edit: Oh I got downvoted for saying truth. I now know what they are really up to.
You still need to teach what the delete keyword is and how memory management works in C++. There's tons of code out there not written with smart pointers.
And yes we use valgrind, but it's important not to overload students who are new to programming. Students tend to reach for withdrawal forms when you tell them "I see you are overwhelmed by this new tool you're learning. To solve this problem here's a new tool to learn". The near-universal sentiment I've gotten from students going from C/C++ to Rust is "Wow, this is so much nicer". YMMV.
Depending on what kind of work you do, you may not have a choice as to whether you get to you smart pointers or not. Our students go into work with decades-old codebases littered with new and delete. They need to know what they do.
> You claimed that you don't have to teach Manual Memory management in Rust so why not do the same for C++?
Because there are no old rust codebases where manual memory management is an issue.
I haven't seen a 'new' or 'delete' in C++ in 15 years. (And I have worked on teams writing custom malloc implementations and lots of other low-level things.)
I guess there are lots of demented and broken codebases out there, but starting students with the broken dysfunctional case as the default seems wrong. They can learn bad habits on their own later.
I have worked with decades old codebases. I use up-to-date compiler where you get to use smart pointers and all the Modern C++ features. It's your fault if you not teach them how to upgrade the compiler. There is zero risk when compiling C++98 with C++11.
It's also student fault if he selects a company with C++98 codebase. The student shall do due diligence.
It's my advice for you to teach the Modern C++ before driving into legacy C++ sort of like how you teach History. You start what's current then drive deep under.
Ok. I'll take your advice and give it the consideration which it's due. Thanks for taking the time out of your day to create a throwaway account just to tell me how to do my job. Cheers.
Unfortunately, the C ++ Committee knows that universities do a terrible job teaching C ++, except the one Bjarne teaches. If you ask Bjarne, he will tell you the same things I said.
A lot of universities stuck in C++98. It will takes them 1000 years to adopt C++20 tho.
One of mistakes many universities do is teaching either C or Java before C++.
I find C++ as a minimal OOP language to get head start.
C++ -> Java
-> C
But if student is a complete noob to programming, I'd suggest to learn Javascript before going to C++
Again, this is to keep the intuition otherwise they will forget what they learnt.
I wish if many universities listened to Kate Gregory talk.
When you teach Java before C++,
Students try to write C++ in Java Style (Eg with new and delete). I answer plenty questions of students on Reddit's cpp sub who are trying to write C++ in Java style. I might make a talk on this in CPPCon.
When you teach C before C++,
Students try to write C with Classes.
But, as once Steve Jobs said,
"I used to think that technology could help education. I’ve probably spearheaded giving away more computer equipment to schools than anybody else on the planet. But I’ve had to come to the inevitable conclusion that the problem is not one that technology can hope to solve. What’s wrong with education cannot be fixed with technology. No amount of technology will make a dent."
You can laugh at me, that's okay. But truth is truth!
By the way, This is my 50th throwaway account. I use them because I'm getting down voted to death when speaking in defense of C++.
I was blessed that my own university during the early 90's, already teached C++ after Pascal to first year students, C was never taught explicily and naturally Java was like 6 years away to be a reality.
The same univerity does teach modern C++ nowadays.
Have you coded on larger code bases not written by you? Usually most of the time you read code instead of writing it. Sure you can add new code that adds smart pointers, but you still have to understand the exant code, at least to some degree.
I've done plenty contractual work on larger code bases that has C++98 to some extent. I will tell you what you will never truly understand the whole code base.
Sourcetrail does amazing job at explaining larger code bases. Check it out.
My experience with C++ is that every time I look at it every few years, C++ developers tell me that I'm stupid for wanting to do memory management the way it was done a few years ago and nobody has ever done that.
No. A lot of job posts out there that highlights the language version. For example, I saw a lot of job posts for C++11, C++17 so on. Heck even, some jobs directly mentions Modern C++.
> I've never had a situation where I had to manage memory manually during my professional career in C++
I don't know what kind of career you had but it's nothing like any C++ career I've ever heard of. Do you never allocate integers or other basic types on the heap? Do you never deal with C-strings? Do you never interact with C libraries? Do you never call posix functions?
A C++ career is full of memory management. You got downvoted because it appears you're speaking from a lack of experience. Even if what you're saying is the truth, I would say you fell into a lucky niche that is unusual compared to the average C++ programmer.
"C++ is a little better because they have experience with Java, but they are frequently mystified by constructors/destructors and how to manage memory manually"
The Rust book as currently written assumes that the user has some programming experience. That's mainly b/c there hasn't been much of any experimentation in teaching Rust as a first time programming language. Although obviously it's been done for C++ and even C, so it ought to be quite doable, if perhaps with a bit of a "learn programming the hard way" style.
Python is way too ad-hoc to be a good teaching language in a professional context. It's designed to teach kids and first-time coders, as an alternative to BASIC.
I think that wholly depends on the context. Python is a great teaching language IMHO if the goal is to teach how to get things done. It's not a good language if you're teaching how things do work under the hood.
To me it's the difference between programming and computer science.
I don't think so, too many heavy hitters are adopting rust, and rust has the advantage in adoption across the board. To beat rust you have to be at least 2-10X as desirable as rust.
And it doesn't have memory safety. Zig is really fun and it is excellent for small wasm modules, but until it gets memory safety it will never be a Rust alternative.
Thanks for the links. I donate a pittance to Zig, I really want to see where CTFE goes. If nothing else, Zig pushes the state of the art and every time a new system does, it sets the lower bound (hopefully) for the future.
Safety is a matter of degree, not an absolute. Unsafe Rust isn't safe. Not to mention, safe Zig isn't unsafe. And, if you want a lot of memory safety -- more than Rust in some ways -- you can use something like Javascript.
C++ doesn't have "memory safety" and it is a Rust alternative. Stop being pretentious, not every language has to have Rust's borrow checker or whatever its called.
C backwards compatibility doesn't help, but it definilty does have the opt-in tooling to make it way safer than using C, although it isn't Ada safe IDE improvements for live static analysis do help.
But C++ does have opt-in memory safety via smart pointers and RAII. It's not preventing all the bug types hat rust will, but it is. There is also tons of code written without it, but you get the idea.
Zig misses a lot of futures that modern C++ has without offering anything in return. Yeah, it's easy to learn compared to C++ and Rust, but what the point of learning it if doesn't offer anything new?
I agree, but nothing short of borrow checker is considered memory safety to Rust advocates and they probably think that we segfault at least 10 times an hour with use-after-free's, double-free's and buffer overflows.
I don't think Zig is meant to replace C++. It's a cool language on its own.
By the way, you've been shadowbanned if you haven't noticed it yet.
To be honest, I didn't pay much attention to it for a while -- it felt like it might have simply been that day's "flavor of the day", destined to sink once then next flavor became popular.
Now, there's a real problem to be solved. But I thought a simpler approach would be needed (e.g., Zig or something like it). I guess that may still happen, but seems more and more like Rust is here to stay.