> Fortunately, a few weeks ago an issue I’ve been tracking for about 3 years was resolved. Zig now can export functions with variable arguments.
The key part. It wasn't possible to write Ruby extensions in Zig until a few weeks back. Now you can.
> I have a story of rewriting part of our production code as Rust extension, which turned out to be 3-4 times faster, but we ditched it anyway, because maintenance cost would be too high.
My solution to this problem is to stick with C. Your code won't get obsolete. Most people are still using C99, and not much has changed in 20 years, even in recent versions.
Those who think C is inherently good can’t be convinced otherwise. Any argument will be dismissed with “programmers need do be better”. Any assertion will be dismissed as subjective, lacking data. Any data backed study from Microsoft [1] or Google [2], [3] will be dismissed as Big Tech hiring mediocre programmers. There will be vague references to “just use the right sanitizers”.
Ultimately we need to recognise that for some people, language is a core part of their identity. At that point criticising “their” language hurts them. If we’re talking to someone who feels this way, it’s best to politely say “is that so?” and gently disengage.
I know it’s tempting to think that we could show them just one compelling data point that will change their minds. But that’s not any more possible than convincing someone to stop believing in religion by pointing out factual inconsistencies in scripture. If you tell a committed Christian that Jesus couldn’t have been born in 0AD because Herod died in 4BC and the census they were travelling for happened in 7AD … is that going to make them reconsider everything about their religion? No, they’ll dismiss this as a minor issue that can be worked around. Same with $language programmers.
> Those who think C is inherently good can’t be convinced otherwise
opposite is also true "those who think C is inherently not good [...]"
> Any data backed study from Microsoft [1] or Google [2], [3] will be dismissed as Big Tech hiring mediocre programmers.
They aren't being dismissed, but criticized when used to promote other languages.
Those studies are partial and about a different topic.
They are are about bugs in millions lines of code bloated products, written in C++. Not counting the actual implementation "bugs", like the browser X leaking details about users to make fingerprinting easier and then sell ads.
You know why those companies are worried about memory safety and nothing else?
Because it's the way people can circumvent the so called "features" and "protections" they implement.
Here we are talking about Ruby extensions in C, which is a completely different domain, involving completely different tradeoffs.
The author confess he's not a great Rust programmer yet, so probably using Rust over a language he knows better, just because Google said it, it's not the best of choices.
Just think about the fact that the Ruby interpreter itself is written in C.
Think about the fact that a bug in path traversal or input sanitization is at least an order of magnitude easier to exploit and usually more dangerous than a double free.
> If you tell a committed Christian that Jesus couldn’t have been born in 0AD because Herod died in 4BC and the census they were travelling for happened in 7AD
as a non believer, that is the least problematic issue about Christianity.
dates are conventions, we are not actually leaving in 2022, would you change your calendar because dating is completely made up?
also: Jesus does not exists nor can do anything for you, C does.
As a C programmer I am baffled by your attitude. Do you feel so threatened by people creating new programming languages? Personally I love that people are working on projects like Zig which try to be a better C. Rust is also an interesting project which has had a lot of positive effects on programming and programming language design, but it is not a perfect replacement for C and more of a better C++.
While some "innovation" actually make things worse I see a lot of interesting ideas coming from both Rust and Zig.
> The author confess he's not a great Rust programmer yet, so probably using Rust over a language he knows better, just because Google said it, it's not the best of choices.
> Do you feel so threatened by people creating new programming languages?
that's a lot of assumptions.
I never even said I write C code.
It feels to me that you are projecting your doubts on me to validate your choices.
I have absolutely no problem at all with programming languages, in fact I always try all the new ones I can, I can actually write code, with very different degrees of competence, in more than 30 of them, including Rust, my new language of choice to write NIF extensions for Erlang/Elixir. Thanks to rustler crate which is awesome.
> While some "innovation" actually make things worse I see a lot of interesting ideas coming from both Rust and Zig.
Never said the opposite though.
Just that a C Ruby extension is not the same thing of "writing a browser at Google in C++"
> He used Zig, not Rust.
I was referring to this sentence he wrote
Other options were not great as well. I can use Rust, but I have never been on good terms with Rust
> Just that a C Ruby extension is not the same thing of "writing a browser at Google in C++"
True. It's, if anything, worse: the users of the extension might not even know it's native, will definitely assume it's fully safe, and will absolutely feed it attacker-controlled data without a thought. And the extension author won't have the engineering review and tooling that a Google has in place either.
Ruby extensions in C (or any other language) are mostly - 100% of the time for non-trivial stuff - a thin layer wrapping a native library.
The attack surface is minimal and it's almost entirely in the realm of the library code, which usually the extension developer has no control over.
it is also much easier to sandbox a ruby process in a server than Chrome on the user's computer.
> the engineering review and tooling that a Google has in place either
hardly, I would argue that something that is hundreds of thousand times smaller in scope and number of lines of code is much easier to write, review, test and debug.
Chrome seats at 7 million LoC, the average Ruby extension is ~100 LoC.
The fact that writing a wrapper is trivial compared to writing a browser, also helps a lot.
Many people can write a bug free correct wrapper in any language using only their brain.
No one can write Google Chrome on their own, let alone a bug free correct implementation of it.
Premature optimization is the root of all evil.
“Omnia venenum sunt: nec sine veneno quicquam existit. Dosis sola facit, ut venenum non fit.”
Okay, next time I need to dive deep to get all the performance out of my machine I'll use the language you recommend which:
A) Has a clear specification (none of that "the implementation is the specification" shenanigans).
B) Is not manually memory managed (that's what we're trying to avoid by getting away from C).
C) Is not garbage collected (that's what we're trying to avoid by writing C).
D) Compiles to native code for if not all, at least most of the platforms that C supports.
...now I wonder which languages match that description, C++ with RAII and maybe SPARK?
I think few people think that C is "inherently good".
Many of us still like C because it is inherently simple. That doesn't mean that it's good. It just means that we value simple and will take some (a lot!) of bad to keep the simple.
When others try to pawn off complex languages like Rust as alternatives because they solve C problems, they are not really listening. From my perspective the pushback is really about 2 groups having diametrically opposite values.
1 values purity and perfection, 1 values simplicity. These two groups are never going to see eye to eye.
Modern C is full of various extensions. This makes it a fair bit more complicated than it appears. C is also missing key simplicity features - like modules and forward referencing.
Those kinds of features are wonderful and all and they don't add much complexity to having them in your language. The thing that makes languages more or less simple (and more or less complex) is the number and degree of abstractions they have. C has relatively few abstractions, which means you can spend more time thinking about what you're building. Most of the C replacements have more abstractions, which means you spend a lot of time thinking about the code itself (am I using the right abstraction here?) and less time thinking about the thing you're building.
That's one thing that has made Zig more attractive as an alternative for (a lot of) C developers, it stays close enough with only small abstractions.
I find the opposite is true. Having better abstractions makes the code easier to think about, and hence it's more productive. For example,
D:
foreach (i; 0 .. 10)
{ body }
C:
for (int i = 0; i < 10; ++i);
{ body }
Which one is more better? I can speak from experience that the former is much better, much easier to read, and has fewer bugs.
C doesn't allow forward referencing. What this means in practice as people lay out the code in a source file backwards, i.e. the leaf functions come first and the top level functions come last.
This is just not the ergonomic way to write code. The public functions should be first and the private leaf functions last. The code should read top to bottom.
The Therac-25 used a PDP-11 computer. So I assumed the software was written in C. It wasn't?
I would also assume that most embedded software (e.g. in cars, spaceships, weapons, etc.) is written in C. But I see now it's indeed hard to come up with definitive sources.
A few failures can be found here (and it's easy to google some more):
C was already dated when compared with languages like Modula-2 from 1978, modern system languages are kind of catching up with how the world used to look like outside Bell Labs walls.
I think it is people that left ruby coming back after seeing the alternatives. :-)
I view ruby ecosystem as totally different philosophy system anti-ethical to many others seen in the engineering realm.
This may be my personal poorly-educated view, but I cannot shake it. Most of the good engineering practices are based on the orthogonal cartesian view of the world, where ego of the creator wants to believe the that all the corner-cases will be ultimately handled. And we just need time to add this or that component. That leads to increasing complexity and it is a vicious circle because all the abstractions are leaky. While in the ruby community, I don't see above described philosophy to be as strong as it is in other language ecosystems.
This is a very interesting point of view. Can you describe it more in detail or share links to read about the topic "orthogonal cartesian view of the world vs others"?
I don't think I have any links. It is just something I am noticing after 13 some years in big tech.
And unfortunately, I don't think I can "describe it in detail" as that's what the ego wants. That's the whole point, the ego wants to hear the details and then argue with the details.
Details often times make a lot of sense, while the end result does not.
The U.S. Tax Code is 6,871 pages. When you include the federal tax regulations and the official tax guidance, the number of pages raises to approximately 75,000.
Every single word has to be there, because it is solving some corner case.
Imagine, a json parsing library 50k LOC in C++ that can be cross compiled on most of the platforms.
Every single LOC (line of code) needs to be there.
These are creations of the ego (and orthogonal cartesian view). That's the dominant ideology in our world, it works very very well.
PS: Everybody knows, you could just parse your little json with `strnstr()`, and somehow we believe that amending cmake anytime it breaks is more meaningful than having spaghetti code calling strnstr that just magically works.
> D also has a @nogc mode, but it feels like giving up on 60% of the language’s power.
Without the GC, D has exactly the same 'power' as Zig have..
I feel that the poster is a bit misleading: he chose Zig instead of D because Zig, being newer, is more fashionable, not because of an imaginary technical reason.
If there's a technical reason, it's not written in the article.
Even the first argument "no hidden control flow" is disingenuous :
either the object you are summing are complex and you have to call a custom function to define what "summing" means in that case (you need to provide the summing function), or those are a primitive type and you're just calling a function builtin the language itself. In every case, you are calling a function ...
> or those are a primitive type and you're just calling a function builtin the language itself
You’re thinking at a different level of abstraction to the Zig developers. Summing a primitive type is going to be turned into a couple of machine opcodes (but no branch instruction) and will usually be constant time, whereas an explicit function call will require pushing pc to the stack and jumping elsewhere, executing any number of instructions once there, taking an arbitrarily long time, making it more difficult to reason about.
A better way to think about it is: for a given line of code, how much context do you need in order to understand what function is actually going to be called? Yes, some compiler-rt or soft-fp function might get called but you know that's happening and what it does.
With most languages you need significantly more context than you do in Zig - in C you need to know what preprocessor shenanigans might be going on; in C++ pretty much anything could be happening (operator overloads, virtual functions, constructors, destructors, who knows what else). With Rust you need to know what traits are imported, and if proc macros are involved then anything goes.
FWIW regarding the package manager, based on the rest of the text my guess is that whoever wrote this intended to say that "Zig will ship with a package manager".
- A more stable API. (Zig's authors rightly expect it to change before 1.0.)
- A package manager (dub) and repository: https://code.dlang.org/ (Zig will get support for these but doesn't even have an HTTP client needed to back package fetching yet.)
- An HTTP server and client with SSL/TLS support. (Zig is too new to have these, although community libs are starting to spring up to fill the gaps.)
99% of the D ecosystem uses the GC. You probably can't use most of it if you put @nogc on main.
99% of the D ecosystem of docs and articles assumes using the GC. You're going to struggle learning how to build something without it. You are kind of on your own.
Also @nogc only was added in 2014, it's not that old.
So given that, I honestly doubt that @nogc is much more mature than Zig, and is probably more difficult to learn how to use in practice, given that it's not a normal thing to do.
2. pointers to the stack cannot escape the lifetime of the stack frame
3. cannot conflate pointers with non-pointers
4. cannot have uninitialized pointers
5. cannot do arithmetic on pointers (must use array slices, which come with array bounds checking)
6. cannot pass the same mutating pointer to a function more than once
There are many more of these. They may seem burdensome and restrictive, but actually are not. If you really want to do these things, there is a "system" annotation that can be used.
You're welcome. I really should write a supplemental page for the documentation that brings all these into one place. Then I can just link to it! Thanks for the inspiration.
>he chose Zig instead of D because Zig, being newer, is more fashionable
Maybe. But could as well be the GC stigma being too strong. It isn't without reason that there's a post on official blog named "don't fear the reaper."
Zig's power doesn't come from the language features it has but from those it doesn't. Its killer feature is that it's a small language that can be fully learned in a couple of days (if you're familiar with some low-level programming). Simplicity is the one feature you can never add to a language that doesn't already have it and, for many, it is one of the most valuable feature.
It's the community around D, the micro design decisions. If everything online presupposes you're using garbage collection most of the time, if everything in the language also makes that supposition sure possible to still go against the grain but it does feel like you're going against the grain.
Feel and community support is as important as anything else in a language decision.
For too long, I too have been bothered by amazing writers not having RSS. So, I ended up hacking my own reader, that can parse almost any page and turn it into a stream of logical items. It is interesting how many web resources lack efficient delivery mechanism.
> I can use Rust, but I have never been on good terms with Rust. I have a story of rewriting part of our production code as Rust extension, which turned out to be 3-4 times faster, but we ditched it anyway, because maintenance cost would be too high
That would be an interesting tale, especially in light of helix / ruru / magnus (why so many?) (and I don't know how they compare to pyo3 in terms of ease of use).
I would assume they don't "really write that much in Zig" either (and Rust would be much easier to maintain for Rubyists) so anything but a statically typed pseudo-ruby (something like cython) would fail the test.
You can't use Crystal to write ruby extensions, because it has a huge runtime and a big GC.
You can call Ruby script in Crystal though. [0]
And I think Zig would be easier to maintain compare to Rust because it is a simpler language. Sure there is a lot of breaking changes, but it's not much of trouble for a language that can be read in one afternoon (referring to the single page document).
> And I think Zig would be easier to maintain compare to Rust because it is a simpler language.
Which is not necessarily helpful when you're mostly not using it, and mostly as a way to build extensions for an other language: in that case what you want is a language which protects you from mistakes, and a glue layer which integrates safely (and hopefully idiomatically) between the two, aka pretty extensive safety abstractions, aka pretty much the opposite of zig.
> Which is not necessarily helpful when you're mostly not using it
When I return to a project written in a language that I don't use regularly, I basically have to re-learn the language (maybe there's something wrong with me, but I even forget the basics of a language that used to be my primary driver after I've not written in it for more than a year or two).
So if I need to re-learn a language to make some changes, I think I'd much rather re-learn a simpler language.
> I even forget the basics of a language that used to be my primary driver after I've not written in it for more than a year or two
Same for me. But "re-learning" takes half a day at most. I just need to get used to it again, remember the idioms, remember the quirks.
Of course this is more of an issue if you come back and half of the language changed in the meantime. (Something that's not so uncommon for pre-v1 stuff…)
Safety is overrated. If safety is the most important aspect of software then we should have been using Ada for everything by now.
The same with idiomatic, in order to write code in a language idiomatically, you have to spend a lot of time using it, and much more time for a huge language like Rust.
Usually people can't afford that, they want to rewrite the extension in a more performant language because they want the speed, not because they like the language they use to implement the extension (may be they do, but that's not the point). So simpler language like Zig is definitely better, the developers can just look at the one page document, implement the feature (with testing and all), then forget about it and come back to the language they are using daily.
> Safety is overrated. If safety is the most important aspect of software then we should have been using Ada for everything by now.
I would guess nobody would say something such stupid if they would be actually legally liable for the code they ship.
Where people actually can be sued for software bugs ADA is widely used, btw.
The good news is: The EU is working on removing the liability exclusion for software products finally. Let's see whether someone would say "safety is overrated" again after the EU authorities are done with changing the legislation and vendors will end up in front of a court for security breaches caused by the software they ship.
No, Crystal is a ruby-like statically typed language, but it's not designed for embedding / shared libraries, even less so with an other GC'd language: it has its own runtime and GC.
I would be shocked if they write more Zig than Rust. Likewise if they find more references and docs in Zig. A lot of zig code in the wild doesn’t even compile any more.
I wouldn't use either Zig or Rust in production just yet, but if you're someone willing to take that risk, then picking a language that is so easy to learn (learning Zig from scratch only takes a couple of days) is certainly an advantage especially if you're not using it much. There are definitely other factors against it, but I can easily see why this would be a very important one in its favour.
There is a massive difference in language stability, compiler stability and ecosystem maturity between Rust and zig. You can use Rust in production for multiple years and many companies do. The same can’t be said about zig.
Certainly, but on those metrics the two languages -- that are neither the only nor the frontrunner choices -- are closer to each other than either one is to the actually established, popular options that have a massive (positive) difference compared to both. So, if among the alternatives you are willing to consider either Rust or Zig to begin with, then popularity, maturity, clear prospects, and low long-term risk are clearly not your biggest factors and your choice will be based on other things that matter to you more.
These factors do matter a lot to me, which is why I, like the vast majority of low-level shops, wouldn't pick either one of these languages for production use at the moment (if top speed were a crucial factor for me in picking a car, I wouldn't care by how much the second-to-last car beat the last car in a race, as I'd pick one from the leading pack), but the poster clearly has other considerations that should be judged based on the poster's values, not mine.
> So, if among the alternatives you are willing to pick Rust or Zig to begin with, then popularity, maturity, clear prospects, and low long-term risk are clearly not your biggest factors and your choice will be based on other things that matter to you more.
Quite frankly I don't see a place where the choice _today_ is between Zig and Rust. Rust is an established language, Zig is not.
I replied to a comment that literally said "we don't really write that much in Rust so going back after a break is a PITA" and my comment should be read in that context. If you are not constantly going to keep your Zig code alive it's going to break just with the changes in compiler and language. Zig is a non stable language (and evidently does not try to be stable) and is notorious for miscompilations.
> but the poster clearly has other considerations that should be judged based on the poster's values, not mine
The person I replied to left two comments here. I would not interpret too much into that.
I’d be interested in it as well. I imagine the author talks about Rust being hard, cause extending Ruby with Rust doesn’t seem problematic. Here is an example of simd json extension written in Rust using Rutie: https://github.com/drogus/simd-json-ruby/blob/main/src/lib.r...
It has a bunch of macros that are rather straightforward to use
And Ruby code deployment story got another nightmare to tell! Not only now you require GCC and a bunch of -dev pages just to install the gems, now entirely different language toolset
How do y’all find out how to do things in Zig? The documentation as it currently exists is very brain dumpy (which makes sense, as the language is still young), so it’s hard for me to find exactly what I’m looking for.
Reading the manual, searching the stdlib for terms related to what I'm trying to do and reading tests, searching the issue tracker, and accidentally discovering things via LSP autocomplete. For higher level concepts that aren't implemented in language (like runtime polymorphism), I try to find examples of how it's done in the stdlib and copy that.
Someone please explain. There are a lot of people who hate on Zig in this thread and say "why not Rust". Then someone comes in and says "Hey, I like C" and gets summarily attacked for that opinion. But it's the same in Rust threads, too. Someone always comes in and says "Ugh, not another Rust thread". And it's been getting worse.
It's to the point where I usually don't even bother reading the comments on programming language specific submissions anymore. It's highly predictable and it's quite tiring to read.
Everyone who does that is saying "My language is better than yours", and in the same breath criticizing someone else for thinking that, in fact, their language is better. When we all know neither is. It's different tradeoffs, different concepts from different times perhaps, or just different goals.
So what if someone wants to use Zig for their native Ruby modules? So what if someone wants to write their Python extension in Rust? So what if someone doesn't mind D's GC?
Instead of immediately attacking them for their choice of language, or excusing it by saying "Those people can't be helped", maybe we can listen instead. Saying someone's a lost cause is never nice. And maybe you'll realize that you have a bias too. And that people might disagree with it.
We'll get nowhere if we just scoff at everybody. There are good projects made in all kinds of different programming languages, and nobody is lesser for choosing a different one than you'd want them to. Instead of a nice discussion about native ruby modules or addons and a healthy discussion about doing that in Zig, or Rust, or C, or Crystal, or whatever, it's just about the languages themselves again and how people are wrong for using them.
I think you know the answer. We can be a selfish and narcissistic creature and we often show our worst side on the internet since there are no repercussions. It's not as bad on HN but its definitely there.
My language brings all the devs to the yard
And they’re like, it’s better than yours
Damn right, it’s better than yours
I can teach you, but I have to charge
Hah, this sounds like it fits in the Nerdcore genre. Might need to go and listen to something by MC Frontalot because of nostalgia now. I've also heard some humorous tech songs by Dylan Beattie in the past (though his conference talks are even better).
Edit: As for the languages, it seems like there's still a lot of elitism, gatekeeping and bikeshedding going on, which was something that was spoken of in DevTernity 2022 as well (in addition to coupling in codebases and architecture being a big theme this year). Sure, sometimes one language might be superior to another, but for most purposes many of the popular (or even niche) languages can be good investments and just generally good enough.
> You do not question or criticise The Rusted Holy Grail and the Riscy Silver Bullet.
You forgot the Holy D Cup.
In other words don't be asshole to other people, unless you want them to stir drama. And if you are, make sure you have some decent ammo to back those claims.
When someone defends use of Electron they usually say it helps productivity so much, that the application would not be created if it would have to be done with a more conservative technology stack. I like to write my personal projects using C. I feel that I wouldn't have motivation to work on them if I would use Rust.
I do see many shortcomings of C, I see a lot of advantages of Rust. It is always a game of trade offs. Safety/correctness, speed of development, performance of applications. It all depends on many factors, familiarity being one of them.
Lately I am thinking if it is possible to write in a subset of Rust, that would essentially be C-with-Borrow-Checker. Not using most of stdlib and very limited set of libraries. I also look at all those Better-C languages and do hope for their maturity: Zig, Odin, Hare etc.
In my experience, the limitations imposed by the borrow checker actually make you express your ideas more clearly. In this way, you might be fighting the compiler, but when your code does compile, it usually does what you wanted it to (and is also designed in a much better way, since you're forced not to take the easy way to the finish line).
The whole kerfuffle around async and what had to be put into the compiler shows that Rust features don't compose well and don't allow the language to extend to unhandled cases cleanly (see: Pin).
#![nostd] still doesn't handle alternate memory allocators all that well.
My wishlist is C with just a bit of the Rust borrow checking and safety. I suspect that Zig or D will be able to get 80% of Rust's safety while only gaining 10% of Rust's complexity.
I disagree. We're finding that it's a great replacement for C++, C, C#, and Java. It even fits to replace or compliment scripting languages like JavaScript, Python, Ruby, etc.
> Rust macros are a disaster.
Better than C macros or no macros at all. Could it be better? Certainly.
However, I don't think that Zig comptime is capable of the very important things that Rust macros enable.
> The whole kerfuffle around async and what had to be put into the compiler shows that Rust features don't compose well and don't allow the language to extend to unhandled cases cleanly (see: Pin).
Actually, I consider Pin as a triumph of the Rust way. By adding a simple rule (do not move this) you get enable a bunch of useful properties. And it only affects things which need it. It requires some understanding of you're working with it in unsafe territory, but the API surface keeps things safe for the average user.
> #![nostd] still doesn't handle alternate memory allocators all that well.
I don't know enough about it to say otherwise.
> My wishlist is C with just a bit of the Rust borrow checking and safety. I suspect that Zig or D will be able to get 80% of Rust's safety while only gaining 10% of Rust's complexity.
All of your problems with Rust are being worked on. Most of the missing features and pain points I see bright up are really just cases where the language hasn't filled the whole multidimensional space where orthogonal features interact.
Based on pace of development, you might see Rust fill out before Zig or especially D fulfill your dreams. Especially if you want actual memory safety.
> We're finding that it's a great replacement for C++, C, […]
So far this makes a lot of sense.
> […] C#, and Java. It even fits to replace or compliment scripting languages like JavaScript, Python, Ruby, etc.
Well, I see you found a new hammer.
I for my part would say that Rust is overly complex for most things where C# or Java, and especially any Scripting language, would be a good fit.
But that's the cool thing about a hammer. You can use it use it for everything! Even eat soup with it. ;-)
> Based on pace of development, you might see Rust fill out before Zig or especially D fulfill your dreams. Especially if you want actual memory safety.
But you know that D has a GC by default? You can't be "more memory safe" than that.
> I for my part would say that Rust is overly complex for most things where C# or Java, and especially any Scripting language, would be a good fit.
Algebraic data types, which none of those languages have, are incredible for representing states in your program. They help reduce our eliminate the type of logic bugs that often show up in UIs and such.
The lack of null and using Options instead is one such example.
Rust has fantastic libraries like serde which make de/serialization fast without a need for reflection.
In short, the Rust ecosystem has a tendency to produce amazingly helpful abstractions.
> But you know that D has a GC by default? You can't be "more memory safe" than that.
First of all, D with GC is not a replacement for C. Anything with a GC is not going to fulfill a systems language role.
Secondly, you can be more memory safe than a GC. Most GCs do not protect against data races, but Rust does. I'm unsure exactly where D falls there.
> Algebraic data types, which none of those languages have, are incredible for representing states in your program. They help reduce our eliminate the type of logic bugs that often show up in UIs and such.
> The lack of null and using Options instead is one such example.
> Rust has fantastic libraries like serde which make de/serialization fast without a need for reflection.
Well, sure. But I'm completely unimpressed.
I'm a Scala developer. I have those features available mostly since "forever".
(Modern serialization based on compile time macros is "only" about a decade old, so quite "new" in Scala).
> In short, the Rust ecosystem has a tendency to produce amazingly helpful abstractions.
They do what they can and the results are OK-isch. But Rust is lacking features. Especially when it comes to abstractions.
Rust would need at least HKTs (higher kinded types) and "context abstractions" ("implicits") to come even close to what's possible in Scala. But Rust type system is still rudimentary in comparison.
Also the meta-programming story is very weak in Rust. I was shocked as I learned that Rust's macros are only on the level of Scheme. That's a shame for a new language, imho.
The only really interesting part about Rust for me is its raw performance. I have to admit that I'm really envious in that regard. (Scala has powerful features but you pay usually a high price for them as the compiler still isn't able to compile that stuff away. The annoying part is that nobody really cares much. They're more concerned with compile times; even Scala compiles at least an order of magnitude faster than Rust).
But actually it's not bad at all that Rust is a small and simple language. It's easy to pick up. (At least if you already know things like HOFs, ADTs, type-classes, Option / Either & Future monads, working with immutable data, and all that).
The other languages with comparable performance are mind twisting and full of bobby traps in comparison. C has no features at all and is outright crazy. C++ has features but that stuff is even more crazy. But Rust is nice and clean! (At least regarding semantics. The syntax is a different story. Rust is one of the ugliest languages. Everything seems patchy and irregular. But OK, that's "only syntax". One gets used to it quite quickly; and they wanted to attract C/C++ programmers, so I can understand why such an ugly syntax was chosen).
> Better than C macros or no macros at all. Could it be better? Certainly.
I don't agree. I'd rather have no macros because that would increase the pressure on the core language and compiler to evolve properly.
Any usage of macros that has to atomize down to the molecules of the syntax tree and then reassemble them from the ground up is screaming Language Failure Here. Those kinds of macros should only exist until the core language either vacuums up the construct and makes it standard or declares the construct verboten at which point they should be excised.
Instead, Rust's procedural macros are spreading like the plague throughout the ecosystem.
> All of your problems with Rust are being worked on.
Unfortunately they're not being completed--which is far more important.
> It is always a game of trade offs. Safety/correctness, speed of development, […]
Where's the trade-off? If the result is buggy crap and/or a security nightmare it makes no difference whether it was "fast to develop".
Saying something like that is like saying that you could build houses much faster if you just didn't have to follow any safety regulations. If you would try that in the real world you would end up in jail sooner or later. But in the virtual world of software people really seem to think that such an "argument" is valid.
I'm eagerly looking forward to the EU finally (and hopefully soon!) removing the liability exceptions that are still in place for software. It's in the working. Than software products would fall under the same liability laws than any other products, and vendors going to be finally full responsible for what they ship to customers. The whole "I don't care about safety and correctness because there are no consequences" madness would come to a very abrupt end in case vendors would be liable and could end up in court easy for shipping subpar products that were manufactured not adhering to state of the art practices.
> […] performance of applications.
Rust and C are the same in this regard. So no "trade-offs" here.
Different maturity. Rust got similar comments when the first people started using it. I think Zig also gets some criticism because it rejects the idea that memory safety is important and worth protecting against on the language level.
I reject zig because its maintainer has a maturity problem when dealing with critics. That's all I'll say about it. Bring on the downvotes, but I don't trust the security of the language whatsoever.
First off, you're judging group by the loudest/most obnoxious member. Plus this feeds into your existing biases. You didn't note same tone coming from members of D community.
Second. Regarding using C, how would you react if someone told you: "I prefer driving cars with seatbelts and airbags removed. I like the speed you get from the reduced mass."
Me, I'm not gonna try to convince you. I just don't want to drive with you.
Third people like their tribes. Insulting some language is bound to cause some members of said languages to retort. See discussion about D and Rust.
Sorry, but hard no. Not everything in life is relative.
There are objectively better programming languages than others. Like there are objectively better vehicles than others…
The blind Rust fanboyism reached crazy levels by now; and Zig isn't a bad language. (It's actually even quite nice for what it is). But there are very valid rational reasons to prefer one over the other.
Zig is a new language that repeats 50 year old mistakes. That's a very valid reason to criticize it. No memory safety is a big NO in the year 2022! Over 70% of all software malfunctions—and what's even more important, almost 100% of all severe security issues—are a direct result of missing memory safety. Even this one prominent stubborn and arrogant C dude realized that memory safety is an absolute requirement for a new language. That's saying a lot!
Still I recommend Zig to C die-hards. Because it's a slight improvement, and those folks will stick to C anyway otherwise.
But anybody who isn't married to C, and is still mentally flexible enough, should look for a better language instead.
As there are not much C contenders, especially safe and modern ones, the most valid choice right now in that field is Rust. Love it or hate it. It's like that. (And this does not change even in the light of the fact that Rust is currently overpraised by a large margin, and for a lot of "rewrite it in Rust" projects just using a GC language would be a more sane approach. Also there a niches where C can't be replaced by anything for the time being. But that are quite small niches, and they will likely become even smaller over time).
I’d bet that’s unlikely. A lot of if Rail’s power comes from the meta progamming (convention over configuration, was it?) which would be needlessly hard in extension land.
Extensions shine brightest on CPU bound workloads by doing away with a lot of the intermediate Object allocs/frees. The gains tend to not be worth the investment in IO bound settings.
This doesn’t mean Rails won’t benefit from extensions.
112 comments
[ 4.6 ms ] story [ 179 ms ] threadThe key part. It wasn't possible to write Ruby extensions in Zig until a few weeks back. Now you can.
> I have a story of rewriting part of our production code as Rust extension, which turned out to be 3-4 times faster, but we ditched it anyway, because maintenance cost would be too high.
My solution to this problem is to stick with C. Your code won't get obsolete. Most people are still using C99, and not much has changed in 20 years, even in recent versions.
Ultimately we need to recognise that for some people, language is a core part of their identity. At that point criticising “their” language hurts them. If we’re talking to someone who feels this way, it’s best to politely say “is that so?” and gently disengage.
I know it’s tempting to think that we could show them just one compelling data point that will change their minds. But that’s not any more possible than convincing someone to stop believing in religion by pointing out factual inconsistencies in scripture. If you tell a committed Christian that Jesus couldn’t have been born in 0AD because Herod died in 4BC and the census they were travelling for happened in 7AD … is that going to make them reconsider everything about their religion? No, they’ll dismiss this as a minor issue that can be worked around. Same with $language programmers.
1 - https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...
2 - https://www.chromium.org/Home/chromium-security/memory-safet...
3 - https://security.googleblog.com/2022/12/memory-safe-language...
opposite is also true "those who think C is inherently not good [...]"
> Any data backed study from Microsoft [1] or Google [2], [3] will be dismissed as Big Tech hiring mediocre programmers.
They aren't being dismissed, but criticized when used to promote other languages.
Those studies are partial and about a different topic.
They are are about bugs in millions lines of code bloated products, written in C++. Not counting the actual implementation "bugs", like the browser X leaking details about users to make fingerprinting easier and then sell ads.
You know why those companies are worried about memory safety and nothing else?
Because it's the way people can circumvent the so called "features" and "protections" they implement.
Here we are talking about Ruby extensions in C, which is a completely different domain, involving completely different tradeoffs.
The author confess he's not a great Rust programmer yet, so probably using Rust over a language he knows better, just because Google said it, it's not the best of choices.
Just think about the fact that the Ruby interpreter itself is written in C.
Think about the fact that a bug in path traversal or input sanitization is at least an order of magnitude easier to exploit and usually more dangerous than a double free.
> If you tell a committed Christian that Jesus couldn’t have been born in 0AD because Herod died in 4BC and the census they were travelling for happened in 7AD
as a non believer, that is the least problematic issue about Christianity.
dates are conventions, we are not actually leaving in 2022, would you change your calendar because dating is completely made up?
also: Jesus does not exists nor can do anything for you, C does.
While some "innovation" actually make things worse I see a lot of interesting ideas coming from both Rust and Zig.
> The author confess he's not a great Rust programmer yet, so probably using Rust over a language he knows better, just because Google said it, it's not the best of choices.
He used Zig, not Rust.
that's a lot of assumptions.
I never even said I write C code.
It feels to me that you are projecting your doubts on me to validate your choices.
I have absolutely no problem at all with programming languages, in fact I always try all the new ones I can, I can actually write code, with very different degrees of competence, in more than 30 of them, including Rust, my new language of choice to write NIF extensions for Erlang/Elixir. Thanks to rustler crate which is awesome.
> While some "innovation" actually make things worse I see a lot of interesting ideas coming from both Rust and Zig.
Never said the opposite though.
Just that a C Ruby extension is not the same thing of "writing a browser at Google in C++"
> He used Zig, not Rust.
I was referring to this sentence he wrote
Other options were not great as well. I can use Rust, but I have never been on good terms with Rust
True. It's, if anything, worse: the users of the extension might not even know it's native, will definitely assume it's fully safe, and will absolutely feed it attacker-controlled data without a thought. And the extension author won't have the engineering review and tooling that a Google has in place either.
Ruby extensions in C (or any other language) are mostly - 100% of the time for non-trivial stuff - a thin layer wrapping a native library.
The attack surface is minimal and it's almost entirely in the realm of the library code, which usually the extension developer has no control over.
it is also much easier to sandbox a ruby process in a server than Chrome on the user's computer.
> the engineering review and tooling that a Google has in place either
hardly, I would argue that something that is hundreds of thousand times smaller in scope and number of lines of code is much easier to write, review, test and debug.
Chrome seats at 7 million LoC, the average Ruby extension is ~100 LoC.
The fact that writing a wrapper is trivial compared to writing a browser, also helps a lot.
Many people can write a bug free correct wrapper in any language using only their brain.
No one can write Google Chrome on their own, let alone a bug free correct implementation of it.
Premature optimization is the root of all evil.
“Omnia venenum sunt: nec sine veneno quicquam existit. Dosis sola facit, ut venenum non fit.”
A) Has a clear specification (none of that "the implementation is the specification" shenanigans). B) Is not manually memory managed (that's what we're trying to avoid by getting away from C). C) Is not garbage collected (that's what we're trying to avoid by writing C). D) Compiles to native code for if not all, at least most of the platforms that C supports.
...now I wonder which languages match that description, C++ with RAII and maybe SPARK?
!C
> D) Compiles to native code for if not all, at least most of the platforms that C supports.
C
Good luck finding C & !C.
Many of us still like C because it is inherently simple. That doesn't mean that it's good. It just means that we value simple and will take some (a lot!) of bad to keep the simple.
When others try to pawn off complex languages like Rust as alternatives because they solve C problems, they are not really listening. From my perspective the pushback is really about 2 groups having diametrically opposite values.
1 values purity and perfection, 1 values simplicity. These two groups are never going to see eye to eye.
That's one thing that has made Zig more attractive as an alternative for (a lot of) C developers, it stays close enough with only small abstractions.
D: foreach (i; 0 .. 10) { body }
C: for (int i = 0; i < 10; ++i); { body }
Which one is more better? I can speak from experience that the former is much better, much easier to read, and has fewer bugs.
C doesn't allow forward referencing. What this means in practice as people lay out the code in a source file backwards, i.e. the leaf functions come first and the top level functions come last.
This is just not the ergonomic way to write code. The public functions should be first and the private leaf functions last. The code should read top to bottom.
It's the single language still in use with at least one or two orders of magnitude more quirks than features.
C is full of bobby traps. And nobody survived. Ever.
It's impossible to build reliable software in C. Even people tried for 50 years.
People died in RL not only once because of issues with the C language. I think no other language carries a real world death toll around.
C may seem "easy" because it lacks features one would need to know. But easy is not simple! Usually quite the contrary.
https://www.entropywins.wtf/blog/2017/01/02/simple-is-not-ea...
Can you link me info about those bugs? I'm familiar with the radiation software bugs, but they don't appear to have been written in C.
I would also assume that most embedded software (e.g. in cars, spaceships, weapons, etc.) is written in C. But I see now it's indeed hard to come up with definitive sources.
A few failures can be found here (and it's easy to google some more):
https://embeddedartistry.com/fieldatlas/historical-software-...
But sadly no reference to the used languages anywhere there.
So I forward the question as I'm now also unsure: Has anybody definitive sources that prove the absence of C code in the known fatal accidents?
I view ruby ecosystem as totally different philosophy system anti-ethical to many others seen in the engineering realm.
This may be my personal poorly-educated view, but I cannot shake it. Most of the good engineering practices are based on the orthogonal cartesian view of the world, where ego of the creator wants to believe the that all the corner-cases will be ultimately handled. And we just need time to add this or that component. That leads to increasing complexity and it is a vicious circle because all the abstractions are leaky. While in the ruby community, I don't see above described philosophy to be as strong as it is in other language ecosystems.
Thank you!
And unfortunately, I don't think I can "describe it in detail" as that's what the ego wants. That's the whole point, the ego wants to hear the details and then argue with the details.
Details often times make a lot of sense, while the end result does not.
The U.S. Tax Code is 6,871 pages. When you include the federal tax regulations and the official tax guidance, the number of pages raises to approximately 75,000.
Every single word has to be there, because it is solving some corner case.
Imagine, a json parsing library 50k LOC in C++ that can be cross compiled on most of the platforms.
Every single LOC (line of code) needs to be there.
These are creations of the ego (and orthogonal cartesian view). That's the dominant ideology in our world, it works very very well.
PS: Everybody knows, you could just parse your little json with `strnstr()`, and somehow we believe that amending cmake anytime it breaks is more meaningful than having spaghetti code calling strnstr that just magically works.
> D also has a @nogc mode, but it feels like giving up on 60% of the language’s power.
Without the GC, D has exactly the same 'power' as Zig have..
I feel that the poster is a bit misleading: he chose Zig instead of D because Zig, being newer, is more fashionable, not because of an imaginary technical reason.
If there's a technical reason, it's not written in the article.
It is, at least, more battle tested.
> Zig is a programming language, but it also ships with a package manager
Which is not true:
https://github.com/ziglang/zig/issues/943
> Zig has no macros and no metaprogramming
Literally from Zig's homepage (https://ziglang.org/):
"Comptime - a fresh approach to metaprogramming"
The rest of the arguments are very weak in my opinion.
You’re thinking at a different level of abstraction to the Zig developers. Summing a primitive type is going to be turned into a couple of machine opcodes (but no branch instruction) and will usually be constant time, whereas an explicit function call will require pushing pc to the stack and jumping elsewhere, executing any number of instructions once there, taking an arbitrarily long time, making it more difficult to reason about.
Because on your typical arm mcu, x/y is a function call to a definitively non-constant time function.
And lets not forget soft-fp. Every single floating point op is a function call...
With most languages you need significantly more context than you do in Zig - in C you need to know what preprocessor shenanigans might be going on; in C++ pretty much anything could be happening (operator overloads, virtual functions, constructors, destructors, who knows what else). With Rust you need to know what traits are imported, and if proc macros are involved then anything goes.
I created https://github.com/ziglang/www.ziglang.org/pull/228 let's see if it gets accepted :)
If you disable GC in D, and end up with something equivalent to Zig, then why not use Zig?
- Multiple production-ready compilers. (Zig does not claim to be production-ready yet.) https://wiki.dlang.org/Compilers
- A more stable API. (Zig's authors rightly expect it to change before 1.0.)
- A package manager (dub) and repository: https://code.dlang.org/ (Zig will get support for these but doesn't even have an HTTP client needed to back package fetching yet.)
- An HTTP server and client with SSL/TLS support. (Zig is too new to have these, although community libs are starting to spring up to fill the gaps.)
- Better documentation, including a very accessible tour at https://tour.dlang.org/ and books such as http://erdani.org/tdpl/.
Zig may get all of these in time but D had quite the head start. D is a good language and I wish it got more attention.
99% of the D ecosystem uses the GC. You probably can't use most of it if you put @nogc on main.
99% of the D ecosystem of docs and articles assumes using the GC. You're going to struggle learning how to build something without it. You are kind of on your own.
Also @nogc only was added in 2014, it's not that old.
So given that, I honestly doubt that @nogc is much more mature than Zig, and is probably more difficult to learn how to use in practice, given that it's not a normal thing to do.
D always looked nice conceptually. But the syntax!
Most likely I would use it actively if it wouldn't look like C.
The type annotations are "on the wrong side". Type inference is barely-there (`auto` is a joke). It's littered with superfluous braces and semicolons.
I would really love it if they would change the syntax, and the result would look more like the new syntax in Scala 3.
2. pointers to the stack cannot escape the lifetime of the stack frame
3. cannot conflate pointers with non-pointers
4. cannot have uninitialized pointers
5. cannot do arithmetic on pointers (must use array slices, which come with array bounds checking)
6. cannot pass the same mutating pointer to a function more than once
There are many more of these. They may seem burdensome and restrictive, but actually are not. If you really want to do these things, there is a "system" annotation that can be used.
Maybe. But could as well be the GC stigma being too strong. It isn't without reason that there's a post on official blog named "don't fear the reaper."
It's the community around D, the micro design decisions. If everything online presupposes you're using garbage collection most of the time, if everything in the language also makes that supposition sure possible to still go against the grain but it does feel like you're going against the grain.
Feel and community support is as important as anything else in a language decision.
For too long, I too have been bothered by amazing writers not having RSS. So, I ended up hacking my own reader, that can parse almost any page and turn it into a stream of logical items. It is interesting how many web resources lack efficient delivery mechanism.
That would be an interesting tale, especially in light of helix / ruru / magnus (why so many?) (and I don't know how they compare to pyo3 in terms of ease of use).
I can see it if they used "raw" rb_sys though, that seems... not much of an improvement over C unless the API is really small and you can quickly bail out to safe Rust: https://briankung.dev/2022/02/02/writing-a-rust-gem-from-scr...
And I think Zig would be easier to maintain compare to Rust because it is a simpler language. Sure there is a lot of breaking changes, but it's not much of trouble for a language that can be read in one afternoon (referring to the single page document).
[0]: https://github.com/Anyolite/anyolite
Which is not necessarily helpful when you're mostly not using it, and mostly as a way to build extensions for an other language: in that case what you want is a language which protects you from mistakes, and a glue layer which integrates safely (and hopefully idiomatically) between the two, aka pretty extensive safety abstractions, aka pretty much the opposite of zig.
When I return to a project written in a language that I don't use regularly, I basically have to re-learn the language (maybe there's something wrong with me, but I even forget the basics of a language that used to be my primary driver after I've not written in it for more than a year or two).
So if I need to re-learn a language to make some changes, I think I'd much rather re-learn a simpler language.
Same for me. But "re-learning" takes half a day at most. I just need to get used to it again, remember the idioms, remember the quirks.
Of course this is more of an issue if you come back and half of the language changed in the meantime. (Something that's not so uncommon for pre-v1 stuff…)
The same with idiomatic, in order to write code in a language idiomatically, you have to spend a lot of time using it, and much more time for a huge language like Rust.
Usually people can't afford that, they want to rewrite the extension in a more performant language because they want the speed, not because they like the language they use to implement the extension (may be they do, but that's not the point). So simpler language like Zig is definitely better, the developers can just look at the one page document, implement the feature (with testing and all), then forget about it and come back to the language they are using daily.
I would guess nobody would say something such stupid if they would be actually legally liable for the code they ship.
Where people actually can be sued for software bugs ADA is widely used, btw.
The good news is: The EU is working on removing the liability exclusion for software products finally. Let's see whether someone would say "safety is overrated" again after the EU authorities are done with changing the legislation and vendors will end up in front of a court for security breaches caused by the software they ship.
No, Crystal is a ruby-like statically typed language, but it's not designed for embedding / shared libraries, even less so with an other GC'd language: it has its own runtime and GC.
Ruby:Crystal is Python:Nim, not Python:Cython.
https://sorbet.org/blog/2021/07/30/open-sourcing-sorbet-comp...
These factors do matter a lot to me, which is why I, like the vast majority of low-level shops, wouldn't pick either one of these languages for production use at the moment (if top speed were a crucial factor for me in picking a car, I wouldn't care by how much the second-to-last car beat the last car in a race, as I'd pick one from the leading pack), but the poster clearly has other considerations that should be judged based on the poster's values, not mine.
Quite frankly I don't see a place where the choice _today_ is between Zig and Rust. Rust is an established language, Zig is not.
I replied to a comment that literally said "we don't really write that much in Rust so going back after a break is a PITA" and my comment should be read in that context. If you are not constantly going to keep your Zig code alive it's going to break just with the changes in compiler and language. Zig is a non stable language (and evidently does not try to be stable) and is notorious for miscompilations.
> but the poster clearly has other considerations that should be judged based on the poster's values, not mine
The person I replied to left two comments here. I would not interpret too much into that.
It has a bunch of macros that are rather straightforward to use
https://github.com/ziglang/zig/wiki/Community#discord-englis....
GitHub's code search beta is a good way to find out how other people are doing things with Zig, if you have access to it. For example:
https://cs.github.com/?scopeName=All+repos&scope=&q=http+pat...
Some less-known walkthroughs for those new to Zig but comfortable in other languages:
- A half-hour to learn Zig: https://gist.github.com/ityonemo/769532c2017ed9143f3571e5ac1...
- Zig Crash Course: https://ikrima.dev/dev-notes/zig/zig-crash-course/
You can also see how other people have solved problems you might have:
https://github.com/catdevnull/awesome-zig
Note that improvements from GitHub Code Search have been integrated into the main website, which means you can do something like this:
https://github.com/search?q=lang%3AZig%20%2F%22https%3F%3A%5...
I think you know the answer. We can be a selfish and narcissistic creature and we often show our worst side on the internet since there are no repercussions. It's not as bad on HN but its definitely there.
Hah, this sounds like it fits in the Nerdcore genre. Might need to go and listen to something by MC Frontalot because of nostalgia now. I've also heard some humorous tech songs by Dylan Beattie in the past (though his conference talks are even better).
Edit: As for the languages, it seems like there's still a lot of elitism, gatekeeping and bikeshedding going on, which was something that was spoken of in DevTernity 2022 as well (in addition to coupling in codebases and architecture being a big theme this year). Sure, sometimes one language might be superior to another, but for most purposes many of the popular (or even niche) languages can be good investments and just generally good enough.
> No more CPU time
> I run KILL DASH NINE
> And your process is mine
Reminds me of this.
Not really. Those are very rare and only happens when someone asking for alternative or make claims that something only Rust can do.
>And say "why not Rust".
The unwritten rule of HN:
You do not question or criticise The Rusted Holy Grail and the Riscy Silver Bullet.
You forgot the Holy D Cup.
In other words don't be asshole to other people, unless you want them to stir drama. And if you are, make sure you have some decent ammo to back those claims.
I do see many shortcomings of C, I see a lot of advantages of Rust. It is always a game of trade offs. Safety/correctness, speed of development, performance of applications. It all depends on many factors, familiarity being one of them.
Lately I am thinking if it is possible to write in a subset of Rust, that would essentially be C-with-Borrow-Checker. Not using most of stdlib and very limited set of libraries. I also look at all those Better-C languages and do hope for their maturity: Zig, Odin, Hare etc.
In my opinion:
- Rust is more productive than C
- Rust is easier than C, once you get past the initial bump
And it's not my opinion, it's just fact that Rust has practically the same performance as C.
I say this as someone who is currently actively maintaining embedded firmware with 10,000+ lines of C. It will be my last significant C project.
Rust macros are a disaster.
The whole kerfuffle around async and what had to be put into the compiler shows that Rust features don't compose well and don't allow the language to extend to unhandled cases cleanly (see: Pin).
#![nostd] still doesn't handle alternate memory allocators all that well.
My wishlist is C with just a bit of the Rust borrow checking and safety. I suspect that Zig or D will be able to get 80% of Rust's safety while only gaining 10% of Rust's complexity.
I disagree. We're finding that it's a great replacement for C++, C, C#, and Java. It even fits to replace or compliment scripting languages like JavaScript, Python, Ruby, etc.
> Rust macros are a disaster.
Better than C macros or no macros at all. Could it be better? Certainly.
However, I don't think that Zig comptime is capable of the very important things that Rust macros enable.
> The whole kerfuffle around async and what had to be put into the compiler shows that Rust features don't compose well and don't allow the language to extend to unhandled cases cleanly (see: Pin).
Actually, I consider Pin as a triumph of the Rust way. By adding a simple rule (do not move this) you get enable a bunch of useful properties. And it only affects things which need it. It requires some understanding of you're working with it in unsafe territory, but the API surface keeps things safe for the average user.
> #![nostd] still doesn't handle alternate memory allocators all that well.
I don't know enough about it to say otherwise.
> My wishlist is C with just a bit of the Rust borrow checking and safety. I suspect that Zig or D will be able to get 80% of Rust's safety while only gaining 10% of Rust's complexity.
All of your problems with Rust are being worked on. Most of the missing features and pain points I see bright up are really just cases where the language hasn't filled the whole multidimensional space where orthogonal features interact.
Based on pace of development, you might see Rust fill out before Zig or especially D fulfill your dreams. Especially if you want actual memory safety.
So far this makes a lot of sense.
> […] C#, and Java. It even fits to replace or compliment scripting languages like JavaScript, Python, Ruby, etc.
Well, I see you found a new hammer.
I for my part would say that Rust is overly complex for most things where C# or Java, and especially any Scripting language, would be a good fit.
But that's the cool thing about a hammer. You can use it use it for everything! Even eat soup with it. ;-)
> Based on pace of development, you might see Rust fill out before Zig or especially D fulfill your dreams. Especially if you want actual memory safety.
But you know that D has a GC by default? You can't be "more memory safe" than that.
So I really don't get the remark about D here.
Algebraic data types, which none of those languages have, are incredible for representing states in your program. They help reduce our eliminate the type of logic bugs that often show up in UIs and such.
The lack of null and using Options instead is one such example.
Rust has fantastic libraries like serde which make de/serialization fast without a need for reflection.
In short, the Rust ecosystem has a tendency to produce amazingly helpful abstractions.
> But you know that D has a GC by default? You can't be "more memory safe" than that.
First of all, D with GC is not a replacement for C. Anything with a GC is not going to fulfill a systems language role.
Secondly, you can be more memory safe than a GC. Most GCs do not protect against data races, but Rust does. I'm unsure exactly where D falls there.
> The lack of null and using Options instead is one such example.
> Rust has fantastic libraries like serde which make de/serialization fast without a need for reflection.
Well, sure. But I'm completely unimpressed.
I'm a Scala developer. I have those features available mostly since "forever".
(Modern serialization based on compile time macros is "only" about a decade old, so quite "new" in Scala).
> In short, the Rust ecosystem has a tendency to produce amazingly helpful abstractions.
They do what they can and the results are OK-isch. But Rust is lacking features. Especially when it comes to abstractions.
Rust would need at least HKTs (higher kinded types) and "context abstractions" ("implicits") to come even close to what's possible in Scala. But Rust type system is still rudimentary in comparison.
Also the meta-programming story is very weak in Rust. I was shocked as I learned that Rust's macros are only on the level of Scheme. That's a shame for a new language, imho.
The only really interesting part about Rust for me is its raw performance. I have to admit that I'm really envious in that regard. (Scala has powerful features but you pay usually a high price for them as the compiler still isn't able to compile that stuff away. The annoying part is that nobody really cares much. They're more concerned with compile times; even Scala compiles at least an order of magnitude faster than Rust).
But actually it's not bad at all that Rust is a small and simple language. It's easy to pick up. (At least if you already know things like HOFs, ADTs, type-classes, Option / Either & Future monads, working with immutable data, and all that).
The other languages with comparable performance are mind twisting and full of bobby traps in comparison. C has no features at all and is outright crazy. C++ has features but that stuff is even more crazy. But Rust is nice and clean! (At least regarding semantics. The syntax is a different story. Rust is one of the ugliest languages. Everything seems patchy and irregular. But OK, that's "only syntax". One gets used to it quite quickly; and they wanted to attract C/C++ programmers, so I can understand why such an ugly syntax was chosen).
I don't agree. I'd rather have no macros because that would increase the pressure on the core language and compiler to evolve properly.
Any usage of macros that has to atomize down to the molecules of the syntax tree and then reassemble them from the ground up is screaming Language Failure Here. Those kinds of macros should only exist until the core language either vacuums up the construct and makes it standard or declares the construct verboten at which point they should be excised.
Instead, Rust's procedural macros are spreading like the plague throughout the ecosystem.
> All of your problems with Rust are being worked on.
Unfortunately they're not being completed--which is far more important.
Where's the trade-off? If the result is buggy crap and/or a security nightmare it makes no difference whether it was "fast to develop".
Saying something like that is like saying that you could build houses much faster if you just didn't have to follow any safety regulations. If you would try that in the real world you would end up in jail sooner or later. But in the virtual world of software people really seem to think that such an "argument" is valid.
I'm eagerly looking forward to the EU finally (and hopefully soon!) removing the liability exceptions that are still in place for software. It's in the working. Than software products would fall under the same liability laws than any other products, and vendors going to be finally full responsible for what they ship to customers. The whole "I don't care about safety and correctness because there are no consequences" madness would come to a very abrupt end in case vendors would be liable and could end up in court easy for shipping subpar products that were manufactured not adhering to state of the art practices.
> […] performance of applications.
Rust and C are the same in this regard. So no "trade-offs" here.
Second. Regarding using C, how would you react if someone told you: "I prefer driving cars with seatbelts and airbags removed. I like the speed you get from the reduced mass." Me, I'm not gonna try to convince you. I just don't want to drive with you.
Third people like their tribes. Insulting some language is bound to cause some members of said languages to retort. See discussion about D and Rust.
There are objectively better programming languages than others. Like there are objectively better vehicles than others…
The blind Rust fanboyism reached crazy levels by now; and Zig isn't a bad language. (It's actually even quite nice for what it is). But there are very valid rational reasons to prefer one over the other.
Zig is a new language that repeats 50 year old mistakes. That's a very valid reason to criticize it. No memory safety is a big NO in the year 2022! Over 70% of all software malfunctions—and what's even more important, almost 100% of all severe security issues—are a direct result of missing memory safety. Even this one prominent stubborn and arrogant C dude realized that memory safety is an absolute requirement for a new language. That's saying a lot!
Still I recommend Zig to C die-hards. Because it's a slight improvement, and those folks will stick to C anyway otherwise.
But anybody who isn't married to C, and is still mentally flexible enough, should look for a better language instead.
As there are not much C contenders, especially safe and modern ones, the most valid choice right now in that field is Rust. Love it or hate it. It's like that. (And this does not change even in the light of the fact that Rust is currently overpraised by a large margin, and for a lot of "rewrite it in Rust" projects just using a GC language would be a more sane approach. Also there a niches where C can't be replaced by anything for the time being. But that are quite small niches, and they will likely become even smaller over time).
Extensions shine brightest on CPU bound workloads by doing away with a lot of the intermediate Object allocs/frees. The gains tend to not be worth the investment in IO bound settings.
This doesn’t mean Rails won’t benefit from extensions.