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).
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.
Rust has all of those except in place binary patching and fast compile times.
Personally I don't find it necessary, but the proposal for REPL has been accepted: https://github.com/ziglang/zig/issues/596
REPLs do exist for C and C++.
Zig security story is hardly much better than using something like Free Pascal, with even less libraries.
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.
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.
D themselves did that, that's what I was referring to: https://dlang.org/spec/betterc.html
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.
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.
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?
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.
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++.
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.
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
x = m * y
x = m.vector_mult(y)
x = m * y
x = m.vector_mult(y)
If you have fast iterative build times, lots of assertions, and good debugger there is no reason to waste time writing it in another language first.
Almost every system uses basic vectors and matrices/quats, most gameplay code also uses them etc.
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.
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 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.
So like a single player video game, it might be an easier overall choice, in a hypothetical world where ecosystems are similarly fleshed out.
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.
- Guy Steele, Java spec co-author
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.
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 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.
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.
You claimed that you don't have to teach Manual Memory management in Rust so why not do the same for C++?
"Rust makes all of this go away. They don't have to manage their memory manually"
Both C++ and Rust has manual memory management but rarely needed. Both supports RAII where everything managed automatically.
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 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.
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.
It builds intuition.
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.
Sourcetrail does amazing job at explaining larger code bases. Check it out.
So you are saying they should (as totally newbies) ask to go through a company's code before accepting a job?
https://jobs.smartrecruiters.com/FireEyeInc1/743999738511776...
They can also look at the creation date of company and make a educated guess.
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"
To me it's the difference between programming and computer science.