Why we built Lightpanda in Zig(lightpanda.io)
lightpanda.io
Why we built Lightpanda in Zig
https://lightpanda.io/blog/posts/why-we-built-lightpanda-in-zig
195 comments
It's not quite a fully formed argument, but I'm coming to the view that Rust mostly requires less cognitive load than other languages. I'm coming at this from the perspective of "cognitive load" meaning, roughly "the measure of the number of things you need to keep in working memory". Rust is no doubt difficult to learn, there are many concepts and a lot of syntax, but when you grasp it cognitive load is actually lower. Rust encodes so much more about the program in text than peer languages so there are fewer things to keep in your head. One good example of this is pointer lifetimes in Zig and C which you have to keep in your head, whereas in Rust you don't.
My own appreciation for Rust is rooted in humility. I know I'm an overgrown monkey prone to all kinds of mistakes. I appreciate Rust for helping me avoid that side of me
My own appreciation for Rust is rooted in humility. I know I'm an overgrown monkey prone to all kinds of mistakes. I appreciate Rust for helping me avoid that side of me
The mentality around lifetimes is different in Zig if you are using it for the correct types of problems.
For example, a command line utility. In a CLI tool you typically don't free memory. You just allocate and exit and let the OS clean up memory.
Historically compilers were all like this, they didn't free memory, they just compiled a single file and then exited! This ended up being a problem when compilers moved more into a service model (constant compilation in the background, needing to do whole program optimization, loading into memory and being called on demand to compile snippets, etc), but for certain problem classes, not worrying about memory safety is just fine.
Zig makes it easy to create an allocator, use it, then just free up all the memory in that region.
Right tool for the job and all that.
For example, a command line utility. In a CLI tool you typically don't free memory. You just allocate and exit and let the OS clean up memory.
Historically compilers were all like this, they didn't free memory, they just compiled a single file and then exited! This ended up being a problem when compilers moved more into a service model (constant compilation in the background, needing to do whole program optimization, loading into memory and being called on demand to compile snippets, etc), but for certain problem classes, not worrying about memory safety is just fine.
Zig makes it easy to create an allocator, use it, then just free up all the memory in that region.
Right tool for the job and all that.
I've been having an absolutely great time with Rust's bumpalo crate, which works very similarly. The lifetime protection still works great, and it's actually a lot more permissive than normal Rust, since it's the same lifetime everywhere.
The sad exception is obviously that Rust's std collections are not built on top of it, and neither is almost anything else.
But nevertheless, I think this means it's not a Zig vs Rust thing, it's a Zig stdlib vs Rust stdlib thing, and Rust's stdlib can be replaced via #[no_std]. In the far future, it's likely someone will make a Zig-like stdlib for Rust too, with a &dyn Allocator inside collections.
The sad exception is obviously that Rust's std collections are not built on top of it, and neither is almost anything else.
But nevertheless, I think this means it's not a Zig vs Rust thing, it's a Zig stdlib vs Rust stdlib thing, and Rust's stdlib can be replaced via #[no_std]. In the far future, it's likely someone will make a Zig-like stdlib for Rust too, with a &dyn Allocator inside collections.
> In the far future, it's likely someone will make a Zig-like stdlib for Rust too, with a &dyn Allocator inside collections.
This exists in the nightly edition of Rust, but is unlikely to become a feature in its current form because the alternative of "Storages" seems to be a lot more flexible and to have broader applicability.
This exists in the nightly edition of Rust, but is unlikely to become a feature in its current form because the alternative of "Storages" seems to be a lot more flexible and to have broader applicability.
I'm not convinced that you can't borrow check in zig... (disclaimer, i'm working on compile time memory safety for zig)
I had no idea you were working on Zig dnautics.
If you were to add borrow checking to Zig, it would make it much easier to justify using it at my current workplace.
If you were to add borrow checking to Zig, it would make it much easier to justify using it at my current workplace.
clarifying: It's just an experiment for zig PL, not affiliated with zsf:
http://github.com/ityonemo/clr
was where i got last year. this december im doing a "prototype" which means its going to be done in zig and im going to clear sone difficult hurdles i couldn't do last year.... also accepting sponsors, details on page.
also disclaimer, im using heavy amounts of ai assistance (as implied in the preview video)
http://github.com/ityonemo/clr
was where i got last year. this december im doing a "prototype" which means its going to be done in zig and im going to clear sone difficult hurdles i couldn't do last year.... also accepting sponsors, details on page.
also disclaimer, im using heavy amounts of ai assistance (as implied in the preview video)
rad! sponsored
> Rust is no doubt difficult to learn, there are many concepts and a lot of syntax
People love to say this, but C++ is routinely taught as a first programming language to novice programmers (this used to be even more clearly the case before Java and Python largely took on that role) and Rust is undoubtedly simpler than C++.
People love to say this, but C++ is routinely taught as a first programming language to novice programmers (this used to be even more clearly the case before Java and Python largely took on that role) and Rust is undoubtedly simpler than C++.
C++ as First Language seems like an especially terrible idea to me. Maybe I should take a few months and go do one of those courses and see whether it's as bad as I expect.
The nice thing about Rust as First Language (which I'm not sure I'd endorse, but it can't be as bad as C++) is that because safe Rust ropes off so many footguns it's extremely unlikely that you'll be seriously injured by your lack of understanding as a beginner. You may not be able to do something because you didn't yet understand how - or you might do something in a terribly sub-optimal way, but you're not likely to accidentally write nonsense without realising and have that seem to work.
For example yesterday there was that piece where the author seems to have misunderstood how heap allocation works in Rust. But, in safe Rust that's actually harmless. If they write their mistake it won't compile, maybe they figure out why, maybe they give up and can't use heap allocation until they learn more.
I haven't thought too hard about Zig as first language, because to me the instability rules that out. Lecturers hate teaching moving targets.
The nice thing about Rust as First Language (which I'm not sure I'd endorse, but it can't be as bad as C++) is that because safe Rust ropes off so many footguns it's extremely unlikely that you'll be seriously injured by your lack of understanding as a beginner. You may not be able to do something because you didn't yet understand how - or you might do something in a terribly sub-optimal way, but you're not likely to accidentally write nonsense without realising and have that seem to work.
For example yesterday there was that piece where the author seems to have misunderstood how heap allocation works in Rust. But, in safe Rust that's actually harmless. If they write their mistake it won't compile, maybe they figure out why, maybe they give up and can't use heap allocation until they learn more.
I haven't thought too hard about Zig as first language, because to me the instability rules that out. Lecturers hate teaching moving targets.
As somebody that "learned" C++ (Borland C++... the aggressively blue memories...) first at a very young age, I heartily agree.
Rust just feels natural now. Possibly because I was exposed to this harsh universe of problems early. Most of the stupid traps that I fell into are clearly marked and easy to avoid.
It's just so easy to write C++ that seems like it works until it doesn't...
Rust just feels natural now. Possibly because I was exposed to this harsh universe of problems early. Most of the stupid traps that I fell into are clearly marked and easy to avoid.
It's just so easy to write C++ that seems like it works until it doesn't...
That's true, but as someone that doesn't do much rust, C++ is a language where there are fewer restrictions and you can use little parts of the language, whereas Rust is supposed to be a simpler language overall, but with more concepts to learn up-front to prevent things that happen where there are no rules....
You can use "little parts of the language" in Rust too; the cleanest and most foundational part of Rust is pure value-based programming with no mutability or referencing at all, much like in a functional language (but with affine types!). Everything else is built quite cleanly on top of that foundation, even interior mutability which is often considered incredibly obscure. (It's called "interior" because the outer cell's identity doesn't really mutate, even though its content obviously does.)
Precisely.
You can subset C++ and still knock out a program.
You cannot subset Rust and still create a program.
You can subset C++ and still knock out a program.
You cannot subset Rust and still create a program.
You can absolutely make a complete, featureful program in Rust without naming a single lifetime, or even without dealing with a single reference/borrow.
But Rust is a dramatically smaller language than C++. The various subsets of C++ people usually carve out tend to be focused on particular styles of programming, like “no exceptions” or “no RTTI”. Notably never things like “signed integer overflow is now defined”, or “std::launder() is now unnecessary”.
But Rust is a dramatically smaller language than C++. The various subsets of C++ people usually carve out tend to be focused on particular styles of programming, like “no exceptions” or “no RTTI”. Notably never things like “signed integer overflow is now defined”, or “std::launder() is now unnecessary”.
Discussions about Rust sometimes feel quite pointless because you can be several replies deep with someone before realising that actually they don't know much about the language and their strongly-held opinion is based on vibes.
Exactly. Claims like "even without dealing with a single reference/borrow."
When you have this stuff in "Hello World":
Egui Hello World:
When I can contrast this to say, ImGui C++:
This kind of blindness makes me wonder about what universe the people doing "Well Ackshually" about Rust live in.
Rust very much has an enormous learning curve and it cannot be subsetted to simplify it due to both the language and the extensive usage of libraries via Cargo.
It is what it is--and may or may not be a valid tradeoff. But failing to at least acknowledge that will simply make people wonder about the competence of the people asserting otherwise.
When you have this stuff in "Hello World":
Egui Hello World:
ui.add(egui::Slider::new(&mut age, 0..=120).text("age"));
fn render(frame: &mut Frame) {
fn run(mut terminal: DefaultTerminal) -> Result<()> {
loop {
terminal.draw(render)?;
if matches!(event::read()?, Event::Key(_)) {
break Ok(());
}
}
}
When I can contrast this to say, ImGui C++:
ImGui::Text("Hello, world %d", 123);
if (ImGui::Button("Save"))
MySaveFunction();
ImGui::InputText("string", buf, IM_ARRAYSIZE(buf));
ImGui::SliderFloat("float", &f, 0.0f, 1.0f);
This kind of blindness makes me wonder about what universe the people doing "Well Ackshually" about Rust live in.
Rust very much has an enormous learning curve and it cannot be subsetted to simplify it due to both the language and the extensive usage of libraries via Cargo.
It is what it is--and may or may not be a valid tradeoff. But failing to at least acknowledge that will simply make people wonder about the competence of the people asserting otherwise.
> Exactly. Claims like "even without dealing with a single reference/borrow."
> When you have this stuff in "Hello World"
Might be worth reading simonask's comment more closely. They said (emphasis added):
> You can absolutely make _a_ complete, featureful program in Rust without naming a single lifetime, or even without dealing with a single reference/borrow.
That some programs require references/borrows/etc. doesn't mean that all programs require them.
> When you have this stuff in "Hello World"
Might be worth reading simonask's comment more closely. They said (emphasis added):
> You can absolutely make _a_ complete, featureful program in Rust without naming a single lifetime, or even without dealing with a single reference/borrow.
That some programs require references/borrows/etc. doesn't mean that all programs require them.
I don't get your examples.
The rust code you pasted doesn't show any lifetime.
The `&f` in your imgui example is equivalent to the `&mut age`.
Are you just comparing the syntax? It just take a couple of hours to learn the syntax by following a tutorial and that `&mut` in rust is the same as `&` in C, not to mention that the compiler error tell you to add the `mut` if it is missing.
Also 0..=120 is much more clear than passing to arguments 0.0f, 1.0f. it makes it obvious what it is while looking at the imgui call it isn't.
The rust code you pasted doesn't show any lifetime.
The `&f` in your imgui example is equivalent to the `&mut age`.
Are you just comparing the syntax? It just take a couple of hours to learn the syntax by following a tutorial and that `&mut` in rust is the same as `&` in C, not to mention that the compiler error tell you to add the `mut` if it is missing.
Also 0..=120 is much more clear than passing to arguments 0.0f, 1.0f. it makes it obvious what it is while looking at the imgui call it isn't.
This seems like a very strange position, code written for Rust in 2015 still works, and in 2015 Rust just doesn't have const generics†, or async, or I/O safety, so... how is that not a subset of the language at it stands today ?
† As you're apparently a C++ programmer you would call these "Non-type template parameters"
† As you're apparently a C++ programmer you would call these "Non-type template parameters"
I gave up on a C++ after trying to learn on and off for years. LNK1009 still haunts me in my sleep. I am now an avid self-taught rust programmer and I feel like I have the power to create almost anything I can imagine using rust. This is great for hobby people
I don’t know anyone that learned C++ first. Maybe I’m younger in generations, but Java was the first thing everyone learned at my university.
I belonged to the generation that graduated into the rising dotcom boom. Around that time, lots of universities taught C++ as the first serious language. (Some still started with Pascal.)
The main thing a lot of had going for us was 5-10 years of experience with Basic, Pascal and other languages before anyone tried to teach us C++. Those who came in truly unprepared often struggled quite badly.
The main thing a lot of had going for us was 5-10 years of experience with Basic, Pascal and other languages before anyone tried to teach us C++. Those who came in truly unprepared often struggled quite badly.
I did. Though a few years earlier I had attended a class where Pascal was used (however, it was not the main topic, it was about robotics). C++ was what I learned first in a "real" computer science class. In later years, we did move to Java. And I initially hated Java :D but ended up making a career using it.
Java in the 2000's was a poor language, but after Java 8, it has become decent and I would say the latest version, Java 25, is a pretty good language.
This thread is about Zig though! I want to like Zig but it has many annoyances... just the other day I learned that you must not print to stdout in a unit test (or any code being unit tested!) as that simply hangs the test runner. No error, no warning, it just hangs. WTF who thinks that's ok?!
But I think Zig is really getting better with time, like Java did and perhaps as slowly. Some stdlib APIs used to suck terribly but they got greatly improved in Zig 0.15 (http, file IO and the whole Writergate thing), so I don't know, I guess Zig may become a really good language given some more time, perhaps a couple of years?!
This thread is about Zig though! I want to like Zig but it has many annoyances... just the other day I learned that you must not print to stdout in a unit test (or any code being unit tested!) as that simply hangs the test runner. No error, no warning, it just hangs. WTF who thinks that's ok?!
But I think Zig is really getting better with time, like Java did and perhaps as slowly. Some stdlib APIs used to suck terribly but they got greatly improved in Zig 0.15 (http, file IO and the whole Writergate thing), so I don't know, I guess Zig may become a really good language given some more time, perhaps a couple of years?!
I learned C++ first. Like many I wanted to make games so I started programming before high school. I think our first high school classes were also in C++ tbf.
Just after Pascal vs C craze in mid to late 90's for sure. That is quite a different C++ than the one of today however.
Oh, I do have a fully-formed argument for this that I should probably write out at some point :)
The gist of it is that Rust is (relatively) the French of programming languages. Monolingual English speakers (a stand-in here for the C/C++ school of things, along with same-family languages like Java or C#) complain a lot about all this funky syntax/semantics - from diacritics to extensive conjugations - that they've never had to know to communicate in English. They've been getting by their whole life without accents aigu or knowing what a subjunctive mood is, so clearly this is just overwrought and prissy ceremony cluttering up the language.
But for instance, the explicit and (mostly) consistent spelling and phonetics rules of French mean that figuring out how to pronounce an unfamiliar word in French is way easier than it is in English. Moods like the imperative and the subjunctive do exist in English, and it's easier to grasp proper English grammar when you know what they are. Of course, this isn't to say that there are no parts of French that an English speaker can take umbrage at - for example grammatical gender does reduce ambiguity of some complex sentences, but there's a strong argument that it's nowhere near worth the extra syntax/semantics it requires.
On top of all that, French is nowhere near as esoteric as many monolingual Anglophone learners make out; it has a lot in common with English and is easier to pick up than a more distant Romance language like Romanian, to talk of a language in a more distant family (like Greek or Polish). In fact, the overlap between French and English creates expectations of quick progress that can be frustrating when it sinks in that no, this is in fact a whole different language that has to be learned on its own terms versus just falling into place for you.
Hell, we can take this analogy as far as native French speakers being far more relaxed and casual in common use than the external reputation of Strictness™ in the language would have one believe.
The gist of it is that Rust is (relatively) the French of programming languages. Monolingual English speakers (a stand-in here for the C/C++ school of things, along with same-family languages like Java or C#) complain a lot about all this funky syntax/semantics - from diacritics to extensive conjugations - that they've never had to know to communicate in English. They've been getting by their whole life without accents aigu or knowing what a subjunctive mood is, so clearly this is just overwrought and prissy ceremony cluttering up the language.
But for instance, the explicit and (mostly) consistent spelling and phonetics rules of French mean that figuring out how to pronounce an unfamiliar word in French is way easier than it is in English. Moods like the imperative and the subjunctive do exist in English, and it's easier to grasp proper English grammar when you know what they are. Of course, this isn't to say that there are no parts of French that an English speaker can take umbrage at - for example grammatical gender does reduce ambiguity of some complex sentences, but there's a strong argument that it's nowhere near worth the extra syntax/semantics it requires.
On top of all that, French is nowhere near as esoteric as many monolingual Anglophone learners make out; it has a lot in common with English and is easier to pick up than a more distant Romance language like Romanian, to talk of a language in a more distant family (like Greek or Polish). In fact, the overlap between French and English creates expectations of quick progress that can be frustrating when it sinks in that no, this is in fact a whole different language that has to be learned on its own terms versus just falling into place for you.
Hell, we can take this analogy as far as native French speakers being far more relaxed and casual in common use than the external reputation of Strictness™ in the language would have one believe.
I suppose Rust users are indeed the Frenchmen of programmers, on more aspects than mentioned.
Oh yes, there is definitely a reputation of snobbery and rudeness. But I was trying to be somewhat fair/neutral :)
As a french person being close to many people who:
- don't have english or any european language as their first language
- have learned english successfully
- are now in a long, struggling process of learning french
I don't believe there is in day-to-day life much value in the advantages you mention for french.
- don't have english or any european language as their first language
- have learned english successfully
- are now in a long, struggling process of learning french
I don't believe there is in day-to-day life much value in the advantages you mention for french.
>My own appreciation for Rust is rooted in humility. I know I'm an overgrown monkey prone to all kinds of mistakes. I appreciate Rust for helping me avoid that side of me
I think we've heard these arguments ad nauseum at this point, but the longer I use Rust for ensuring long-term maintenance burden is low in large systems that I have to be absolutely, 10,000% correct with the way I manage memory the more it seems to reduce the effort required to make changes to these large systems.
In scenarios where multiple people aren't maintaining a highly robust system over a long period of time, e.g. a small video game, I think I'd absolutely prefer Zig or C++ where I might get faster iteration speed and an easier ability to hit an escape hatch without putting unsafe everywhere.
I think we've heard these arguments ad nauseum at this point, but the longer I use Rust for ensuring long-term maintenance burden is low in large systems that I have to be absolutely, 10,000% correct with the way I manage memory the more it seems to reduce the effort required to make changes to these large systems.
In scenarios where multiple people aren't maintaining a highly robust system over a long period of time, e.g. a small video game, I think I'd absolutely prefer Zig or C++ where I might get faster iteration speed and an easier ability to hit an escape hatch without putting unsafe everywhere.
> I'm coming to the view that Rust mostly requires less cognitive load than other languages.
This view is only remotely within the bounds of plausibility if you intended for "other languages" to refer exclusively to languages requiring manual memory management
This view is only remotely within the bounds of plausibility if you intended for "other languages" to refer exclusively to languages requiring manual memory management
Manual memory management is just one axis.
Some others are:
- `&mut T` which encodes that you have exclusive access to a value via a reference. I don't think there is any language with the same concept.
- `&T` which encodes the opposite of `&mut T` i.e. you know no one can change the value from underneath you.
- `self`/`value: T` for method receivers and argument which tells you ownership is relinquished (for non-Copy types). I think C++ can also model this with move semantics.
- `Send`/`Sync` bounds informing you how a value can and cannot be used across thread boundaries. I don't know of any language with an equivalent
- `Option<T>` and `Result<T, E>` encoding absence of values. Several other languages have equivalents, but, for example, Java's versions is less useful because they can still be `null`.
- Sum types in general. `Option<T>` and `Result<T, E>` are examples, but sum types are amazing for encoding 1-of-N possibilities. Not unique to Rust of course.
- Explicit integer promotion/demotion. Because Rust never does this implicitly you are forced to encode how it happens and think about how that can fail.
All of these are other ways Rust reduce cognitive load by encoding facts in the program text instead of relying on the programmer's working memory.
Some others are:
- `&mut T` which encodes that you have exclusive access to a value via a reference. I don't think there is any language with the same concept.
- `&T` which encodes the opposite of `&mut T` i.e. you know no one can change the value from underneath you.
- `self`/`value: T` for method receivers and argument which tells you ownership is relinquished (for non-Copy types). I think C++ can also model this with move semantics.
- `Send`/`Sync` bounds informing you how a value can and cannot be used across thread boundaries. I don't know of any language with an equivalent
- `Option<T>` and `Result<T, E>` encoding absence of values. Several other languages have equivalents, but, for example, Java's versions is less useful because they can still be `null`.
- Sum types in general. `Option<T>` and `Result<T, E>` are examples, but sum types are amazing for encoding 1-of-N possibilities. Not unique to Rust of course.
- Explicit integer promotion/demotion. Because Rust never does this implicitly you are forced to encode how it happens and think about how that can fail.
All of these are other ways Rust reduce cognitive load by encoding facts in the program text instead of relying on the programmer's working memory.
I don't think so?
In languages like Java their version of the Billion Dollar mistake doesn't have arbitrary Undefined Behaviour but it is going to blow up your program, so you're also going to need to track that or pay everywhere to keep checking your work - and since Rust doesn't have the mistake you don't need to do that.
Likewise C# apparently doesn't have arbitrary Undefined Behaviour for data races. But it does lose Sequential Consistency, so, humans can't successfully reason about non-trivial software when that happens, whereas safe Rust doesn't have data races so no problem.
Neither of these languages can model the no-defaults case, which is trivial in Rust and, ironically, plausible though not trivial in C++. So if you have no-defaults anywhere in your problem, Rust is fine with that, languages like Go and Java can't help you, "just imagine a default into existence and code around the problem" sounds like cognitive load to me.
Edited: Fix editorial mistake
In languages like Java their version of the Billion Dollar mistake doesn't have arbitrary Undefined Behaviour but it is going to blow up your program, so you're also going to need to track that or pay everywhere to keep checking your work - and since Rust doesn't have the mistake you don't need to do that.
Likewise C# apparently doesn't have arbitrary Undefined Behaviour for data races. But it does lose Sequential Consistency, so, humans can't successfully reason about non-trivial software when that happens, whereas safe Rust doesn't have data races so no problem.
Neither of these languages can model the no-defaults case, which is trivial in Rust and, ironically, plausible though not trivial in C++. So if you have no-defaults anywhere in your problem, Rust is fine with that, languages like Go and Java can't help you, "just imagine a default into existence and code around the problem" sounds like cognitive load to me.
Edited: Fix editorial mistake
This was linked below: https://github.com/DioxusLabs/blitz/pull/292/commits/e539f52... guess I'll call it Cheap Cloudflare Mistake.
The problem Cloudflare had, and from what it seems, still have is that they don't actually test software at small volumes before global deployment. I would guess that two outages in quick succession means the voices saying "You need to test everything properly" might win, but perhaps not.
The Billion Dollar mistake is about not even having the distinction shown in the commit you linked. In languages with this mistake a Goose and "Maybe a Goose or maybe nothing" are the same type.
The Billion Dollar mistake is about not even having the distinction shown in the commit you linked. In languages with this mistake a Goose and "Maybe a Goose or maybe nothing" are the same type.
This distinction still blows up your program and 1/3 of internet on top of that.
> I eventually came to the decision to stop developing in Rust, despite its popularity
It's also not popular for a language that old. It's roughly as popular as Ada was when it was the same age Rust is today (there may not have been as many projects written in Ada then, but there were certainly much bigger/more important projects being written in Ada then). It's not nearly as popular as C, or C++, or Java, or C#, or Go were at that age.
The relatively small number of developers who program in Rust, and the smaller still number of them who use it at work, are certainly very enthusuastic about it, but an enthusiastic "base" and popularity are very different things.
It's also not popular for a language that old. It's roughly as popular as Ada was when it was the same age Rust is today (there may not have been as many projects written in Ada then, but there were certainly much bigger/more important projects being written in Ada then). It's not nearly as popular as C, or C++, or Java, or C#, or Go were at that age.
The relatively small number of developers who program in Rust, and the smaller still number of them who use it at work, are certainly very enthusuastic about it, but an enthusiastic "base" and popularity are very different things.
It has routinely topped lists and surveys of most popular languages for years now.
The only lists it's topped are for likeability by users, where it was followed by Elixir and Clojure. If we go by the meaning of popularity that suggests how many people use these languages, let alone professionally, their ratings are quite low (e.g. https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...). Considering how old Rust is, the numbers are significantly lower than of any language that's become truly popular (as in widespread). An old language used by so few people can be many things, but "popular" isn't one of them.
You're citing language demand as a result of incumbent industry usage. That's an inherently weighted metric because existing products are not (contrary to what some Rust zealots might want) going to be rewritten in Rust for no reason.
i.e, it's not rocket science - languages with 10-20+ year history are embedded in the industry. News at 11. ;P
Popularity - as the term is actually used - is one where Rust is fine.
i.e, it's not rocket science - languages with 10-20+ year history are embedded in the industry. News at 11. ;P
Popularity - as the term is actually used - is one where Rust is fine.
I was comparing Rust to the popularity of other languages at the same age. Its adoption rate is not fine for a language that old if it aims to one day be as popular as C++ is today (or even as popular as Go is today).
The only modern language you listed is Go, which had Google backing it and is a simpler language overall. The rest achieved their popularity when the industry was smaller and there wasn't as much competition.
Those of us who were programming in the nineties and before remember there was a lot of competition [1]; not less than today. It's just that not much of it survived to this day in any popular form. Also, C++ didn't have any stronger backer than Rust, at least not at first. (BTW, Go's introduction was closer in time to Python's or Java's than it is to today; both Go and Rust are already fairly old languages)
[1]: In the application space, there were VB, Delphi, Smalltalk, and a host of other so-called "RAD languages". In the scripting space, Perl was dominant. In the low-level space, we had the entire Pascal family, with Ada and, to a lesser extent, Oberon.
[1]: In the application space, there were VB, Delphi, Smalltalk, and a host of other so-called "RAD languages". In the scripting space, Perl was dominant. In the low-level space, we had the entire Pascal family, with Ada and, to a lesser extent, Oberon.
Rust does not require GC-less memory management. It supports reference counting out of the box, and reference counting is a kind of GC. It's not inherently any harder to use than Swift (another memory-safe language) which plenty of average developers use to code for Apple platforms.
I think it is significantly harder to use than Swift, and inherently so.
I don’t think it’s a useful observation. Lots of people come to Rust from OOP languages and try to make everything `Arc<dyn Interface>`, and it immediately fails, to their great frustration.
Do not do this.
Do not do this.
Why would it fail?
It's fine as long as the graph of references is immutable, or is unidirectional/acyclic with unique ownership.
If you have backreferences or "parent pointers", you need `Arc<Mutex<...>>` or `Rc<RefCell<...>>`, and then you run into trouble as you encounter the same node multiple times while traversing the graph, because you cannot hold a mutex lock or mutably borrow `RefCell` twice in the same call stack.
The solution with much less resistance in Rust is to go for a data-oriented representation. If you really need an actual graph of objects, separate the node data from the topology metadata, and refer to the nodes using an ID or index. (As an extra bonus, this also gives you much better cache locality.)
If you have backreferences or "parent pointers", you need `Arc<Mutex<...>>` or `Rc<RefCell<...>>`, and then you run into trouble as you encounter the same node multiple times while traversing the graph, because you cannot hold a mutex lock or mutably borrow `RefCell` twice in the same call stack.
The solution with much less resistance in Rust is to go for a data-oriented representation. If you really need an actual graph of objects, separate the node data from the topology metadata, and refer to the nodes using an ID or index. (As an extra bonus, this also gives you much better cache locality.)
My experience has been the opposite. I came from Python and Typescript and the initial amount of reading and fighting with the compiler was very frustrating but I understood one thing that sets Rust apart - I write code with almost the same level of bugs as a seasoned Rust developer. That is a win for years to come as team grows and software gets old. I will bet on it again and again.
Now I mostly generate code with coding agents and almost everything I create is Rust based - web backend to desktop app. Let the LLM/agent fight with the compiler.
Now I mostly generate code with coding agents and almost everything I create is Rust based - web backend to desktop app. Let the LLM/agent fight with the compiler.
What are you developing in?
Depends on the problem at hand.
Zig where I used to use C/Rust (but admittedly I spent the least time here).
Go where I used to use Java.
Bun/Node for typescript/javascript, where each is appropriate, but I favor Bun for standalone application programming and local scripting.
Zig where I used to use C/Rust (but admittedly I spent the least time here).
Go where I used to use Java.
Bun/Node for typescript/javascript, where each is appropriate, but I favor Bun for standalone application programming and local scripting.
> Zig where I used to use C/Rust (but admittedly I spent the least time here).
I really don't understand how that fit with the “I want something that allows me to focus my mental facilities on the complexities of the actual problem domain”.
For low-level stuff, Rust allows to offload the cognitive load of maintaining the ownership requirements to the machine. On the opposite, Zig is exactly like C as it forces you to think about it all the time or you just shoot yourself in the foot at the first opportunity…
For stuff that can be done with managed languages, then absolutely, the GC allows to completely ignore that aspect, at the cost of some performance you don't always care about because how fast the modern hardware is.
I really don't understand how that fit with the “I want something that allows me to focus my mental facilities on the complexities of the actual problem domain”.
For low-level stuff, Rust allows to offload the cognitive load of maintaining the ownership requirements to the machine. On the opposite, Zig is exactly like C as it forces you to think about it all the time or you just shoot yourself in the foot at the first opportunity…
For stuff that can be done with managed languages, then absolutely, the GC allows to completely ignore that aspect, at the cost of some performance you don't always care about because how fast the modern hardware is.
I feel like vibe coding has completely changed this paradigm. Now all I care about is how fast and reliable the language is.
Probably throw in a dash of “is my model trained on this language sufficiently to perform this task well”.
So what do you use instead now?
> Zig particularly shines: comptime metaprogramming, explicit memory allocators, and best-in-class C interoperability. Not to mention the ongoing work on compilation times
The D programming language shines:
comptime: https://dlang.org/spec/function.html#interpretation
metaprogramming: https://dlang.org/spec/template.html#function-templates
explicit memory allocators: these are easily made, there's nothing special about them, I use them all the time
best-in-class C interoperability: Nothing beats D's ImportC, where you can import a .c file as if it were a module. You can even use ImportC to translate your C code to D! https://dlang.org/spec/importc.html
Performance: same as C and C++
The D programming language shines:
comptime: https://dlang.org/spec/function.html#interpretation
metaprogramming: https://dlang.org/spec/template.html#function-templates
explicit memory allocators: these are easily made, there's nothing special about them, I use them all the time
best-in-class C interoperability: Nothing beats D's ImportC, where you can import a .c file as if it were a module. You can even use ImportC to translate your C code to D! https://dlang.org/spec/importc.html
Performance: same as C and C++
I guess there are different levels of meta-programming. You can go really far in Rust/C++ too but I think Zig is really unique that you can write a function, which takes a type, it does some imperative mumbo-jumbo and spits out another type, doing exactly what you want, without having to think about restrictions, trait bounds, or whatever.
For example, here's comptime dependency-injection container, which notably, can be configured and extended, completely in comptime, and the final glue is something which in theory the compiler could optimize away too (no idea if it does). https://github.com/cztomsik/tokamak/blob/main/src/container....
And regarding what they discuss in article, I did something similar for N-API, note how much you can do in few hundred lines, and I'd say that you can use it for most of what people do with napi-rs except that napi-rs is huge (and also unsafe, because it allows indirect recursion, which allows breaking all the rustc promises) https://github.com/cztomsik/napigen/blob/main/src/napigen.zi...
For example, here's comptime dependency-injection container, which notably, can be configured and extended, completely in comptime, and the final glue is something which in theory the compiler could optimize away too (no idea if it does). https://github.com/cztomsik/tokamak/blob/main/src/container....
And regarding what they discuss in article, I did something similar for N-API, note how much you can do in few hundred lines, and I'd say that you can use it for most of what people do with napi-rs except that napi-rs is huge (and also unsafe, because it allows indirect recursion, which allows breaking all the rustc promises) https://github.com/cztomsik/napigen/blob/main/src/napigen.zi...
You should probably say you are the core contributor to D!
We are fortunate in having a number of highly competent core D contributors!
Why D sees low adoption?
I think in many ways D was just too ahead of it's time; Packaging the same feature set and abstraction level of C++ in much cleaner and saner package wasn't really seen at valuable at that time.
I think that if D were to be "re-release today" with a lighter syntax, and some coporate backing a-la GO/swift/typescript/carbon; It would find quite a bit of success.
Also wasn't the D compiler proprietary and a paid product for a long time after its initial release?
No judgement against trying to monetize valuable work, but in this day and nearly everyone expects free and OSS compilers/interpreters and core tooling.
No judgement against trying to monetize valuable work, but in this day and nearly everyone expects free and OSS compilers/interpreters and core tooling.
> Also wasn't the D compiler proprietary and a paid product for a long time after its initial release?
The backend for the DMD compiler was not fully open source for a number of years. That's because Symantec owned some of the code and they were not willing to let it be relicensed. They did allow that in 2017. It was never a paid product AFAIK.
Overall, that was beneficial to the D community. The GDC backend has always been open, and for some time has been part of GCC. The LDC backend was developed to use LLVM. It's possible that there would not have been motivation for those projects if DMD's backend had been open from the start. DMD compiles fast but the performance is not competitive with the other compilers if you're working on something that needs to push the CPU to its limits.
The backend for the DMD compiler was not fully open source for a number of years. That's because Symantec owned some of the code and they were not willing to let it be relicensed. They did allow that in 2017. It was never a paid product AFAIK.
Overall, that was beneficial to the D community. The GDC backend has always been open, and for some time has been part of GCC. The LDC backend was developed to use LLVM. It's possible that there would not have been motivation for those projects if DMD's backend had been open from the start. DMD compiles fast but the performance is not competitive with the other compilers if you're working on something that needs to push the CPU to its limits.
I'm only able to work on the DMD backend now and then, and so it has fallen behind compilers with a small army working solely on a backend.
Sadly, the number of people nerdly enough to want to work on a code generator is very, very small. Me, I find it quite enjoyable.
I cannot even think of anyone who wrote a full stack compiler these days.
Sadly, the number of people nerdly enough to want to work on a code generator is very, very small. Me, I find it quite enjoyable.
I cannot even think of anyone who wrote a full stack compiler these days.
> Why D sees low adoption?
Most components of the D standard library (Phobos) use garbage collection by default (when I last checked). This unfortunately removes it as a contender in the same space as Zig and Rust. And once you move to the GC space, there are a truckload of GC languages - it is the non-GC ones that are rare.
IMHO stdlib GC was one of the major barriers stopping D in the system programming space.
Most components of the D standard library (Phobos) use garbage collection by default (when I last checked). This unfortunately removes it as a contender in the same space as Zig and Rust. And once you move to the GC space, there are a truckload of GC languages - it is the non-GC ones that are rare.
IMHO stdlib GC was one of the major barriers stopping D in the system programming space.
We could do a better job at marketing
I really like D and want to use D instead of Zig if I can...
But it's difficult to do so! Nothing to do with marketing in my case, at least. The reasons are :
* `dub` is badly documented and does dumb things like including test code in the generated binary.
* `serve-d` is terrible. It can't handle even my little hello world programs - either crashes or consumes 100% CPU until I manually kill it.
* MacOS support sucks. All the time I have problems: the linker didn't work for years (fixed now). Immediate segmentation faults currently (fixed in nightly AFAIK). C code using the new flat128 doesn't compile (I think it was fixed already?). Just constant frustration.
* Too many features, many broken. It has an experimental borrow-checking feature, I tried to use it but it's largely undocumented. People in the Forum told me to that feature is completely unfinished. It has an allocators package as well, but no idea how I can make use of those like I would in Zig. Would love to see a well written post about that.
Using D in betterC mode is what I am most interested about exactly because it looks more like Zig and C than Java - and performs much better. But currently, that means forgetting about Phobos, the standard library, as that's written exclusively with GC and Exceptions in mind. Maybe that's ok as you can just use all C libraries you want, but would be nice to have some D conveniences to make that worthwhile.
Apart from that, I completely agree that D's comptime and metaprogramming is the best I've seen in any language (except for Lisp of course). All I need to keep using D is much better tooling and clarification about what parts of the language are "half-baked" (especially around DIP1000) and which parts are stable - perhaps "editions" will give us that, will check it out when it's ready. Oh and also top-notch MacOS support... I know that's a moving target but even Zig manages to handle that just fine, why not D?!
But it's difficult to do so! Nothing to do with marketing in my case, at least. The reasons are :
* `dub` is badly documented and does dumb things like including test code in the generated binary.
* `serve-d` is terrible. It can't handle even my little hello world programs - either crashes or consumes 100% CPU until I manually kill it.
* MacOS support sucks. All the time I have problems: the linker didn't work for years (fixed now). Immediate segmentation faults currently (fixed in nightly AFAIK). C code using the new flat128 doesn't compile (I think it was fixed already?). Just constant frustration.
* Too many features, many broken. It has an experimental borrow-checking feature, I tried to use it but it's largely undocumented. People in the Forum told me to that feature is completely unfinished. It has an allocators package as well, but no idea how I can make use of those like I would in Zig. Would love to see a well written post about that.
Using D in betterC mode is what I am most interested about exactly because it looks more like Zig and C than Java - and performs much better. But currently, that means forgetting about Phobos, the standard library, as that's written exclusively with GC and Exceptions in mind. Maybe that's ok as you can just use all C libraries you want, but would be nice to have some D conveniences to make that worthwhile.
Apart from that, I completely agree that D's comptime and metaprogramming is the best I've seen in any language (except for Lisp of course). All I need to keep using D is much better tooling and clarification about what parts of the language are "half-baked" (especially around DIP1000) and which parts are stable - perhaps "editions" will give us that, will check it out when it's ready. Oh and also top-notch MacOS support... I know that's a moving target but even Zig manages to handle that just fine, why not D?!
Don't use betterC as a global @nogc attribute. This flag does more than just remove the garbage collector and adds extra checks that can sometimes be overly restrictive. If writing GC-free code is important and compiler assistance is really needed, then add @nogc: at the top of every file. But even that is a bit extreme because the @nogc attribute is just a hint to the compiler, telling it to check that called functions also carry that hint. It is not essential for writing GC-free code.
My library for example is not using the GC, but I don't put @nogc on every function because it does not make sense. Here is the link to the library: https://github.com/Kapendev/joka
My library for example is not using the GC, but I don't put @nogc on every function because it does not make sense. Here is the link to the library: https://github.com/Kapendev/joka
The borrow checker is there as experimental, it is not an official part of the language. It is unfinished due to lack of interest in it by the D community.
I don't understand the special purpose behind Zig's allocators. It's just an interface. I make custom allocators in D all the time, it's trivial.
Dip1000 is also an experimental feature and is not part of the core language.
On a more pragmatic note, D has a notion of "sinks", aka output ranges. They provide a simple interface that accepts input, which is appended to the output range. Since the user of the sink has no idea what the sink is doing, just that it accepts input. This is a fun and very practical way to move the choice of how to allocate memory to the caller rather than the callee.
gdc and ldc offer top notch D support for the Mac.
I don't understand the special purpose behind Zig's allocators. It's just an interface. I make custom allocators in D all the time, it's trivial.
Dip1000 is also an experimental feature and is not part of the core language.
On a more pragmatic note, D has a notion of "sinks", aka output ranges. They provide a simple interface that accepts input, which is appended to the output range. Since the user of the sink has no idea what the sink is doing, just that it accepts input. This is a fun and very practical way to move the choice of how to allocate memory to the caller rather than the callee.
gdc and ldc offer top notch D support for the Mac.
> gdc and ldc offer top notch D support for the Mac.
Have you tried using D on Mac? That's almost impossible to do!! You get a segmentation fault immediately when using VS Code because it wants to download its own DCD and that's apparently compiled with DMD?? Everything that gets downloaded in binary doesn't work on MacOS. I only managed to get it working on emacs after building DCD locally with LDC AND making sure emacs does not try to use anything else. But even then, as I said, serve-d barely works (not sure if that's MacOS-specific). D has the worst MacOS experience of several dozen languages I've tried. Even FORTH just works, but D just does not.
Have you tried using D on Mac? That's almost impossible to do!! You get a segmentation fault immediately when using VS Code because it wants to download its own DCD and that's apparently compiled with DMD?? Everything that gets downloaded in binary doesn't work on MacOS. I only managed to get it working on emacs after building DCD locally with LDC AND making sure emacs does not try to use anything else. But even then, as I said, serve-d barely works (not sure if that's MacOS-specific). D has the worst MacOS experience of several dozen languages I've tried. Even FORTH just works, but D just does not.
BTW, if a language isn't trying out new ideas, it isn't progressing.
I think it would be helpful to make it clearer what's experimental and what's not. Is the `in` keyword experimental? How about `scope`?
There's just a minor note in the docs (https://dlang.org/spec/attribute.html#scope) saying "The -preview=dip1000 switch must also be enabled.". That's really not making it clear if that's an experimental feature, it sounds to me that using the preview flag just does additional checks, but that implies `scope` is NOT experimental?! Which is it?
I don't think D brought enough new to the table. I had already been coding in c++ for a while and was getting tired of all the little things wrong with c++. While D cleaned up a few things it was already too complex for my taste. And the whole GC thing followed by the D2 fiasco and I lost interest. When dipping my toes into Rust I also got the same vibe from it that I had from D. Too much complexity built in. I guess that made me a sucker for Zig because it is able to combine simplicity, cleverness, clarity and high performance.
Build the “killer app” that the audience wants and needs and where D is the best lang to do it and justify the investment in learning yet another lang. I have no idea of what that is and nobody knows, it’s the universal problem of any product/lang/tech. Right place at the right time I guess
A killer app can be built in any language.
Of course it can, but different killer apps for a different crowd. A missile tracking system wouldn't be the kind of application to do in PHP. Wrong app, wrong crowd.
I'm aware of D since it's inception more or less but don't know it very well. I would say D lacks a "bombastic" feature and maybe that's both the reason is not used more but also why is such a good language.
It's not "memory safe" like Rust, yes it's fast but so is C/C++, it doesn't have the "massive parallelism/ always-on" robustness like Erlang. It has a bit of everything which is good and bad.
Being a mid all-arounder is OK in my book, perhaps it's more a matter of some "post-AI" tech startup adopt it and get massive or famous, like Ruby because of the Web 2.0 era or Erlang with the Whatsapp thing.
Maybe D is good the way it is and will always be there.
I'm aware of D since it's inception more or less but don't know it very well. I would say D lacks a "bombastic" feature and maybe that's both the reason is not used more but also why is such a good language.
It's not "memory safe" like Rust, yes it's fast but so is C/C++, it doesn't have the "massive parallelism/ always-on" robustness like Erlang. It has a bit of everything which is good and bad.
Being a mid all-arounder is OK in my book, perhaps it's more a matter of some "post-AI" tech startup adopt it and get massive or famous, like Ruby because of the Web 2.0 era or Erlang with the Whatsapp thing.
Maybe D is good the way it is and will always be there.
D doesn't have a bombastic or killer feature. What it has is elegance. It simplifies things, and smooths out the ugly stuff. You don't have to worry if your char is signed or unsigned, or how many bits are in an int, or whether to use dot or arrow, or remember to make your destructor virtual, and on and on.
It's a more memory safe language than C/C++, no need to worry about forward references, strong encapsulation, simple modules, and so on.
And let's face it - the C preprocessor is an abomination in modern languages, why does it persist?
It's a more memory safe language than C/C++, no need to worry about forward references, strong encapsulation, simple modules, and so on.
And let's face it - the C preprocessor is an abomination in modern languages, why does it persist?
A missile tracking system is definitely a killer app.
In part, the compiler wasn't fully FOSS until 2017.
The gdc and ldc compilers were fully FOSS around 2007.
We were able to get dmd's backend license fixed in 2017.
We were able to get dmd's backend license fixed in 2017.
Ah, I stand corrected!
Good question, but I don't think this is the place for that conversation :)
And I say that as a Dlang fan :)
Why would a comment suggesting to use D not be the place to have a conversation for why D doesn't see adoption?
You and Walter could do that, but this post is about some cool devs and their cool Zig project.
The title is "Why we built Lightpanda in Zig", i.e. language selection criteria. Comparing it with D is on topic.
Absolutely. Rust is the only language that's allowed to derail HN programming threads.
too many features. tryhard vibe
We're implementing "editions" in order to remove some features that don't deliver enough value.
how is the community going these days ? stable ? growing ?
>Nothing beats D's ImportC
What does it offer over Zig's translate-c?
What does it offer over Zig's translate-c?
D does a pretty good job translating function-like macros, including creating lambdas out of macro expressions like:
ImportC can also import D modules, so C code can access the D code.
#define X 3+y
ImportC can also import D modules, so C code can access the D code.
This is actually a great summary of Zig. I am with the author: I am too old and stupid to use Rust properly. Whenever I watch someone like Gjengset write Rust, I realize I am doing it wrong.
I am too old and stupid to not use Rust. I’m kidding of course, but the mental load of doing the things we used do in C++ is really noticeable once it’s gone.
honestly manually tracing lifetimes of pointers is not as hard in zig as C and definitely easier than C++. it would be nice to know for sure but for small and medium sized programs it's not a that hard? and not even "cheating" using arenas
It was never hard for small things.
The hard part is when you have multiple people working on something, who all need to synchronize their mental model of all lifetimes in the project, or even in your own code when you come back to it in 3 months. Encoding this stuff in the type system is unbelievably useful.
Zig improves a lot of things, and seems like a pleasant language in general, but this isn't a problem that it does anything to solve.
The hard part is when you have multiple people working on something, who all need to synchronize their mental model of all lifetimes in the project, or even in your own code when you come back to it in 3 months. Encoding this stuff in the type system is unbelievably useful.
Zig improves a lot of things, and seems like a pleasant language in general, but this isn't a problem that it does anything to solve.
and for big teams you can run a checker: (wip) http://github.com/ityonemo/clr
I have seen this time and time again: first complain that C/C++ are too complex or lack feature X, new language is proposed, then sooner or later people find out that's it's not fast, expressive, flexible enough or imposes a nonstandard way of doing things (Rust), then back to C/C++ and few years after the cycle repeats.
Most of the article is about why they didn’t use C or C++.
Back in the day, before I had our robot overlords to write code for me, I would just use C++ as a fancy C with classes and a larger standard library. Or Boost as they have some fun and exciting things to play with.
Now, the robots do a good enough job at writing clean C++ without going too crazy that I just kind of let them do their thing and review the very readable code to keep them on the right path.
I can't even imagine the nightmare with something like a browser where you'd be pulling in C++ dependencies from all over the place and each having their own way of doing things. I mean, I get annoyed when C libs don't do the 'object to be operated on' as the first argument to functions so they can't be trivially wrapped in Python C-API extensions super easily using generators.
--edit--
Actually, this got me thinking, I was exploring using zig for a project (might still do, dunno) and came up with this meta-circular comptime peg grammar 'evaluator' to generate, at compile time, the parser for the peg grammar used to generate the parser for the runtime peg generator tool. Admittedly, I was pretty high when I cooked up this scheme with the robots but it seems to be viable...
Now, the robots do a good enough job at writing clean C++ without going too crazy that I just kind of let them do their thing and review the very readable code to keep them on the right path.
I can't even imagine the nightmare with something like a browser where you'd be pulling in C++ dependencies from all over the place and each having their own way of doing things. I mean, I get annoyed when C libs don't do the 'object to be operated on' as the first argument to functions so they can't be trivially wrapped in Python C-API extensions super easily using generators.
--edit--
Actually, this got me thinking, I was exploring using zig for a project (might still do, dunno) and came up with this meta-circular comptime peg grammar 'evaluator' to generate, at compile time, the parser for the peg grammar used to generate the parser for the runtime peg generator tool. Admittedly, I was pretty high when I cooked up this scheme with the robots but it seems to be viable...
Keep in mind you'll be using a different language in the future. All software is maintained for a given amount of time and then sunset. What matters is the lifecycle of the thing you're making now. Pick whatever is maintainable for that application and time frame.
Throwaway script? Use anything. A mobile app? Whatever gets it on the devices you're targeting today, that works for the life of the device/OS/etc. A backend API that will power a large platform? Something maintainable (by people other than yourself) for 3-5 years. Firmware for IoT that will remain in industrial systems for 20 years? Something that is well established and supported with a good number of other people who can fix it in the long haul.
Throwaway script? Use anything. A mobile app? Whatever gets it on the devices you're targeting today, that works for the life of the device/OS/etc. A backend API that will power a large platform? Something maintainable (by people other than yourself) for 3-5 years. Firmware for IoT that will remain in industrial systems for 20 years? Something that is well established and supported with a good number of other people who can fix it in the long haul.
Something interesting about your comment is that HN also has a post today (https://tigerbeetle.com/blog/2025-10-25-synadia-and-tigerbee...) about TigerBeetle's support for Zig and their reason for using Zig specifically talked about wanting something for a long time horizon:
> Investing in creating a database like TigerBeetle is a long term effort. Databases tend to have a long half life (e.g. Postgres is 30 years old). And so, while Zig being early in 2020 did give me pause, nevertheless Zig’s quality, philosophy and simplicity made sense for a multi-decade horizon.
> Investing in creating a database like TigerBeetle is a long term effort. Databases tend to have a long half life (e.g. Postgres is 30 years old). And so, while Zig being early in 2020 did give me pause, nevertheless Zig’s quality, philosophy and simplicity made sense for a multi-decade horizon.
If Zig's core developers decided tomorrow they wanted to do something else, would that result in the rest of the devs slowly leaving, and Zig being unmaintained after a couple years? Might be possible; but it would be impossible with C, C++, Java, etc. If you give me a choice between two products, one in Zig and one in Java, and I need to run it for two decades, I'm picking the Java one (and I dislike Java)
It’s a question of risk vs reward and it’s assessment
I like this take. While I've primarily lived in Python for much of my career (and I don't see that changing soon), I've tried to find reasons to use other languages in at least a hobby capacity so that I can (1) keep my learning muscles warmed up and (2) because they can often shape how I think about software in general.
Like the Alan Perlis (I think) quote goes: "A language that doesn't affect the way you think about programming is not worth knowing."
Like the Alan Perlis (I think) quote goes: "A language that doesn't affect the way you think about programming is not worth knowing."
Unfortunately you can get spoiled by a good language. After using Erlang it took me far too long to get comfortable programming without immutability.
I wrote an article (this morning actually!) on picking up Rust to combat AI brain atrophy. My background is JVM-based (Kotlin), and my main contenders were Go vs Rust vs Zig.
My reasoning for settling on Rust:
If I wanted something more general-purpose and ergonomic, I'd stick with something like Kotlin, which has wider ecosystem support. Go could fit here too, but I've heard from more experienced folks that Go's simplicity can get limiting as codebases grow (and requires 100s of developers to be disciplined). Not impossible, just not as conducive.
But since I specifically wanted a performant systems language, I figured I'd go to the other extreme. So my choice was Rust or Zig. I eventually chose Rust (as complicated as Rust can seem) the borrow checker is pretty elegant once it clicks and provides the necessary safety net for a language I intentionally am choosing for more control.
(here's my article on learning Rust if folks are interested: https://kau.sh/blog/learn-rust-ai-atrophy/) - different angle from the linked article.
My reasoning for settling on Rust:
If I wanted something more general-purpose and ergonomic, I'd stick with something like Kotlin, which has wider ecosystem support. Go could fit here too, but I've heard from more experienced folks that Go's simplicity can get limiting as codebases grow (and requires 100s of developers to be disciplined). Not impossible, just not as conducive.
But since I specifically wanted a performant systems language, I figured I'd go to the other extreme. So my choice was Rust or Zig. I eventually chose Rust (as complicated as Rust can seem) the borrow checker is pretty elegant once it clicks and provides the necessary safety net for a language I intentionally am choosing for more control.
(here's my article on learning Rust if folks are interested: https://kau.sh/blog/learn-rust-ai-atrophy/) - different angle from the linked article.
Gotta admit there is something funny about a browser company saying Rust is not well suited for browser development given why it was created in the first place
> LLMs deserve a 100x better browser.
Hold on, why can't humans have a 100x better browser?
Hold on, why can't humans have a 100x better browser?
Because you can't sell a better browser to LLM companies. That's their current business model.
Because a human browser has to implement CSS.
> Anyone who’s fought with CMake or dealt with header file dependencies knows this pain. For a small team trying to move quickly, we didn’t want to waste time debugging build configuration issues.
I find this take a bit hard to believe. There's no way that Zig is some kind of magic bullet that avoids build configuration challenges. Especially not considering you are building a browser on top of V8 in a different programming language.
CMake is quite crufty, but there's toolchains for every system under the Sun and this is what makes it actually less painful in a lot of cases. Glossing over your build files it does not look particularly scalable or portable. Nice that Zig allows you to write build config in Zig though.
I find this take a bit hard to believe. There's no way that Zig is some kind of magic bullet that avoids build configuration challenges. Especially not considering you are building a browser on top of V8 in a different programming language.
CMake is quite crufty, but there's toolchains for every system under the Sun and this is what makes it actually less painful in a lot of cases. Glossing over your build files it does not look particularly scalable or portable. Nice that Zig allows you to write build config in Zig though.
I think CMake is cool when it works, but debugging it when it doesn't is hell. I've often spent an inordinate amount of time trying to figure out why doesn't it pick up library paths.
And although I know Microsoft is uncool, I still want to shill vckpkg as it seems they finally managed to create a usable cross platform package manager for C++
And although I know Microsoft is uncool, I still want to shill vckpkg as it seems they finally managed to create a usable cross platform package manager for C++
I feel like I’m missing something. How do people justify the security implications of manual memory management when building a publicly accessible web service with Zig?
[deleted]
Just don't write bugs ;)
More seriously, a reasonably sane way to create a lot of web-heavy services (writing out something simple for brevity, not anything perfect) is with large regions partitioned into ropes (for use with, e.g., iovecs kernel APIs). You have a tiny bit of potentially memory-unsafe stuff in a simple backing data structure (or not -- at $WORK we're moving more things to static allocation models for a host of other benefits), and then everything else you do web-wise is with views into those ropes (enabling incremental processing and whatnot if you care). The rest is memory-safe by definition (only using slices and other such safe techniques), so if you have any memory bugs from there then they're the same logic bugs you can write in any language (a fairly classic example in a web context is serving another user's data, especially by not resetting view states, but that's also not what happens in a "normal" Zig program because the compiler will yell at you when you miss some fields).
You might notice that my answer seemingly wasn't Zig-specific. You can use that same architecture in C. Why is Zig safe? It's a lot of little things -- first-class errors, defer and errdefer statements, first-class tests and fuzzing, the existence of a built-in fat pointer type, etc. If you propose the same idea in C you'll likely screw up a detail somewhere (not checking an error, not using yet another fat pointer implementation for ergonomic reasons, whatever). In Zig you'll write safe code by default.
There are other architectures, other ways to ensure safety, and other things the compiler does to keep you on the straight and narrow. You could go fairly deep into the "why" and "how" of Zig being safe enough. I'll leave that chore for somebody else. The other half of your question though is "what do you gain?"
You gain lots of things, and they might not matter to you, but they probably exist.
One thing I encountered was needing a faster language and not being able to justify the huge ramp-up time to teach Rust to a bunch of Pythonistas (nor the ramp-up time on the company if we tried to hire explicitly for that work, even if we could have gotten the additional budget).
You also gain access to really world-class programmers. There are great programmers in every language, but in established languages they're a lot harder to find in any given job search (Not talking about any of you here on HN of course :) The point is that resumés have a sampling bias from the perspective of the receiving company favoring people who struggle to get jobs, and for a variety of reasons that gives you a much higher signal-to-noise ratio when hiring for less popular languages). This was true of Rust at one point too, but IMO it's a little harder to hire for now (yet still better than even more popular languages).
As a broader point, for somewhat nebulous reasons I don't fully understand yet, it's by far the easiest language I've personally found for writing high-performance software correctly. C/C++/Rust/etc were fine enough I guess (all of them more than fine in other problem domains -- I've used them professionally and don't have too many complaints that other practitioners would disagree with), but they were comparatively hard to use to write code that was anywhere near optimal for complicated problems.
More seriously, a reasonably sane way to create a lot of web-heavy services (writing out something simple for brevity, not anything perfect) is with large regions partitioned into ropes (for use with, e.g., iovecs kernel APIs). You have a tiny bit of potentially memory-unsafe stuff in a simple backing data structure (or not -- at $WORK we're moving more things to static allocation models for a host of other benefits), and then everything else you do web-wise is with views into those ropes (enabling incremental processing and whatnot if you care). The rest is memory-safe by definition (only using slices and other such safe techniques), so if you have any memory bugs from there then they're the same logic bugs you can write in any language (a fairly classic example in a web context is serving another user's data, especially by not resetting view states, but that's also not what happens in a "normal" Zig program because the compiler will yell at you when you miss some fields).
You might notice that my answer seemingly wasn't Zig-specific. You can use that same architecture in C. Why is Zig safe? It's a lot of little things -- first-class errors, defer and errdefer statements, first-class tests and fuzzing, the existence of a built-in fat pointer type, etc. If you propose the same idea in C you'll likely screw up a detail somewhere (not checking an error, not using yet another fat pointer implementation for ergonomic reasons, whatever). In Zig you'll write safe code by default.
There are other architectures, other ways to ensure safety, and other things the compiler does to keep you on the straight and narrow. You could go fairly deep into the "why" and "how" of Zig being safe enough. I'll leave that chore for somebody else. The other half of your question though is "what do you gain?"
You gain lots of things, and they might not matter to you, but they probably exist.
One thing I encountered was needing a faster language and not being able to justify the huge ramp-up time to teach Rust to a bunch of Pythonistas (nor the ramp-up time on the company if we tried to hire explicitly for that work, even if we could have gotten the additional budget).
You also gain access to really world-class programmers. There are great programmers in every language, but in established languages they're a lot harder to find in any given job search (Not talking about any of you here on HN of course :) The point is that resumés have a sampling bias from the perspective of the receiving company favoring people who struggle to get jobs, and for a variety of reasons that gives you a much higher signal-to-noise ratio when hiring for less popular languages). This was true of Rust at one point too, but IMO it's a little harder to hire for now (yet still better than even more popular languages).
As a broader point, for somewhat nebulous reasons I don't fully understand yet, it's by far the easiest language I've personally found for writing high-performance software correctly. C/C++/Rust/etc were fine enough I guess (all of them more than fine in other problem domains -- I've used them professionally and don't have too many complaints that other practitioners would disagree with), but they were comparatively hard to use to write code that was anywhere near optimal for complicated problems.
No, you don't.
Lets be honest Zig is a shiny new shit for people who doesn't want to learn and want everything to be familiar but new.
Criticism of it is not allowed and would be downvoted by bandwagon fanboys.
Lets be honest Zig is a shiny new shit for people who doesn't want to learn and want everything to be familiar but new.
Criticism of it is not allowed and would be downvoted by bandwagon fanboys.
I downvoted because I'm interested in charitable, non-disparaging conversation. I post this so the above commenter doesn't confuse a downvote (1 bit of information) as validation of their claim. I'm personally uninterested in spending much time looking at Zig right now, but I'm keeping an eye on it and generally interested in the progression of languages over time.
That might be true or not. But I’m sure you’re aware your post didn’t offer anything constructive and for that reason alone should be downvoted.
Familiar is different from the same, therefore is new. And zig has many new concepts and things different from C
Familiar is different from the same, therefore is new. And zig has many new concepts and things different from C
In practice aren't such services behind a reverse proxy/WAF? The other day I found an endpoint in the wild outputting a DB table. I tried fuzzing it to gather more evidence of a SQL injection vuln but my attempts were flagged by AWS WAF.
I mean you can opine about how Rust isn't suited for browser development, but as someone building a browser in Rust, I think it's just fine. If anything, Rust has been really shining in this project since Rust was designed to build a web browser.
https://github.com/dioxuslabs/blitz
Also I think it's a little ridiculous to build yet another new browser in a new language when so many amazing pieces are just sitting around ready for someone to use. Come contribute, we're already much further along :)
https://github.com/DioxusLabs/blitz/pull/292
https://github.com/dioxuslabs/blitz
Also I think it's a little ridiculous to build yet another new browser in a new language when so many amazing pieces are just sitting around ready for someone to use. Come contribute, we're already much further along :)
https://github.com/DioxusLabs/blitz/pull/292
agreed about rust literally being designed to build a browser, but when it was developed there were many amazing pieces sitting around in c++ :) let the zig folks have a go at building their own ecosystem.
That's why Rust was introduced into Firefox piece by piece. The goal wasn't to rewrite firefox in Rust - just to migrate the scary bits over to a memory safe lang. You can feel a lot of that in the servo codebase, weird pointer semantics as a result of needing to be API compatible with the C++ adapters.
If I were building a company around a new browser, I'd reach for the solid stuff that can be pulled in. Our whole blitz project is designed to be modular exactly for that use-case.
If I were building a company around a new browser, I'd reach for the solid stuff that can be pulled in. Our whole blitz project is designed to be modular exactly for that use-case.
> but when it was developed there were many amazing pieces sitting around in c++ :) let the zig folks have a go at building their own ecosystem.
Servo had Mozilla's backing in that endeavor though, and even then they didn't manage to ship a full browser in a decade, the problem is just that hard.
Servo had Mozilla's backing in that endeavor though, and even then they didn't manage to ship a full browser in a decade, the problem is just that hard.
> Servo had Mozilla's backing in that endeavor though, and even then they didn't manage to ship a full browser in a decade, the problem is just that hard.
Not that hard; Ladybird, with a fraction of the resources available to the servo team, is C++ (Moving to swift soon) and they got pretty damn far.
The lack of velocity in Rust is real; it's a trade-off between velocity and safety, and Ladybird has amply demonstrated just how rapid C++ velocity can be.
And this is coming from someone who doesn't even like C++.
Not that hard; Ladybird, with a fraction of the resources available to the servo team, is C++ (Moving to swift soon) and they got pretty damn far.
The lack of velocity in Rust is real; it's a trade-off between velocity and safety, and Ladybird has amply demonstrated just how rapid C++ velocity can be.
And this is coming from someone who doesn't even like C++.
> Not that hard; Ladybird, with a fraction of the resources available to the servo team, is C++ (Moving to swift soon) and they got pretty damn far.
You know the saying about the first 90% and then the second 90%? Making a web browser is the fractal version of that.
> The lack of velocity in Rust is real; it's a trade-off between velocity and safety,
No it's not, Rust has in fact much higher velocity than C++, even at Mozilla which was basically a C++ shop beforehand (and a pretty good one at that).
> and Ladybird has amply demonstrated just how rapid C++ velocity can be.
No, you seem to have a misunderstanding of what servo was. Mozilla didn't use Rust yo make a safer browser, they used Rust to make a faster browser by leveraging all the cores of modern CPUs. That was the primary motive for making Rust in the first place: making multithreading tractable for humans.
As a result, the servo project aimed for SotA performance and modules were rewritten multiple time as they improved the architecture for performance (see the different iterations of Stylo or Webrender, which ended up in Firefox proper when it converged).
That's why it was apparently slow, not because of safety but because it aimed to be the first fully parallel browser (which is something enabled by Rust's safety).
You can argue that Rust has lower velocity than garbage collected language because you need to think about ownership, but not that it has lower velocity than other low-level languages: they too need to think about ownership, they simply have no static check to catch errors at compile time: every error raised by the borrow checker would be as segfault. (And Rust keeps what makes C++ already much higher velocity than C, the ability to build powerful abstractions at no performance cost).
You know the saying about the first 90% and then the second 90%? Making a web browser is the fractal version of that.
> The lack of velocity in Rust is real; it's a trade-off between velocity and safety,
No it's not, Rust has in fact much higher velocity than C++, even at Mozilla which was basically a C++ shop beforehand (and a pretty good one at that).
> and Ladybird has amply demonstrated just how rapid C++ velocity can be.
No, you seem to have a misunderstanding of what servo was. Mozilla didn't use Rust yo make a safer browser, they used Rust to make a faster browser by leveraging all the cores of modern CPUs. That was the primary motive for making Rust in the first place: making multithreading tractable for humans.
As a result, the servo project aimed for SotA performance and modules were rewritten multiple time as they improved the architecture for performance (see the different iterations of Stylo or Webrender, which ended up in Firefox proper when it converged).
That's why it was apparently slow, not because of safety but because it aimed to be the first fully parallel browser (which is something enabled by Rust's safety).
You can argue that Rust has lower velocity than garbage collected language because you need to think about ownership, but not that it has lower velocity than other low-level languages: they too need to think about ownership, they simply have no static check to catch errors at compile time: every error raised by the borrow checker would be as segfault. (And Rust keeps what makes C++ already much higher velocity than C, the ability to build powerful abstractions at no performance cost).
I’m really excited for blitz, thanks for this amazing project. Do you intend to wipe a full fledged browser out of it?
The browser UI will likely be more of a cool demonstration of the project instead of the end goal. We want blitz to exist to help make it easier to build stuff like lightpanda. There's a whole world of interesting browser forks that could exist but don't, and being able to easily remix the browser opens the door to new stuff like AI automation, hybrid native gui frameworks, better accessibility tools, etc.
I was using C++ and C for decades, and I do a lot of embedded programming for fun. I switched completely to Rust about half a year ago. Friction went away very fast. Fun thing is that looking at my old C code now I see so many pitfalls I was oblivious about, just because I started to use Rust.
I mean, Rust does have a learning curve, but its complexity is overexaggerated imo. Yes, you have to learn something new, but how it is a problem?
I don't understand why pick language because it looks familiar and you don't have to change how you think. For me that is basically a problem with Zig - I can do everything Zig does in C++, having decades of libraries and infra while Rust actually contributes to the end product.
I mean, Rust does have a learning curve, but its complexity is overexaggerated imo. Yes, you have to learn something new, but how it is a problem?
I don't understand why pick language because it looks familiar and you don't have to change how you think. For me that is basically a problem with Zig - I can do everything Zig does in C++, having decades of libraries and infra while Rust actually contributes to the end product.
I just want Zig with classes, Zig++. :(
Isn't the whole point of zig that it eschews classes and object oriented programming?
You can bind functions to structs and first parameter is special cased when it's a pointer-to or a const version of the structs... What more do you want really besides inheritance (which is considered dangerous by many). In the era of LLMs do you really want that sort of "hidden action" that you force the LLM to inefficently reason through?
Or possibly Objective-Zig. :-)
I'm longing for Zig--. :(
And also for Hype-- about all these newfangled langs.
And also for Hype-- about all these newfangled langs.
What exactly do you need that Zig doesn't have? Inheritance?
Proper interfaces would be nice. I realize that eg tagged unions work for most cases but the syntactic sugar would reduce a bit of friction.
What form of interfaces would you want? Something trait-based? Rust's orphan rule has bitten me many times now, and it causes consolidation around certain libraries. Something like Go's interface, where the signature just needs to match? That would be nicer than the current situation with `anytype`, but I don't know if it's better enough to justify a full interface system. Curious to hear your thoughts.
Essentially enough syntactic sugar so you could write eg the Allocator interface without manually specifying the vtable and the opaque pointer.
But yeah, Go’s system is nice and simple. I am not sure, but I think the fact that Zig programs are a single compilation unit might have some bearing on the orphan rule. There is no concept of crates so “traits”/interfaces can be defined and implemented anywhere.
But yeah, Go’s system is nice and simple. I am not sure, but I think the fact that Zig programs are a single compilation unit might have some bearing on the orphan rule. There is no concept of crates so “traits”/interfaces can be defined and implemented anywhere.
That's a good point that it's all a single compilation unit which removes the orphan rule problem, but it still has the issue that there could be multiple different implementations of a trait, each from a different dependency.
Though, I am seeing your point on a simple interface system that would be enough to have something like the allocater interface, or the hash map interface.
Though, I am seeing your point on a simple interface system that would be enough to have something like the allocater interface, or the hash map interface.
Allocator can be implemented as one function pointer - recallocarray, see https://man.openbsd.org/calloc.3
Sounds fast. Does it respect `robots.txt`? My web services are not written in Rust, Zig, or Go. :)
has there ever been a project that became popular and/or successful because of its programming language? does it really matter to the end user what language it's in if it works well?
The language tends to affect everything, but to give a quick Developer example there’s Zed. Developers use it because it’s fast. Same with Sublime Text.
Your criticism makes more sense with products targeting non-technical users though. But IMO tech choices have cascading effects. I won’t buy a vehicle if the infotainment software sucks, and that’s the 2nd largest purchase I’ll ever make.
Your criticism makes more sense with products targeting non-technical users though. But IMO tech choices have cascading effects. I won’t buy a vehicle if the infotainment software sucks, and that’s the 2nd largest purchase I’ll ever make.
zed is a great example. most people use vscode, that is javascript. which ai code editors are built from scratch that aren't forked vscode?
[deleted]
Just Zed (if AI features are a requirement) as far as I know.
But to elaborate, they’ve found a niche simply by using Rust and rendering the GUI in a performant way on the GPU. I’m not saying performance is the only thing, but for a chunk of people it is something they care about.
But to elaborate, they’ve found a niche simply by using Rust and rendering the GUI in a performant way on the GPU. I’m not saying performance is the only thing, but for a chunk of people it is something they care about.
Good performance is a strong proxy for making other good software decisions. You generally don't get good performance if you haven't thought things through or planned for features in the long term.
I hate all infotainment systems, so I’m still on a car from 22 years ago — with no screen and ratting me out on how I drive to unknown entities.
If I had the optional GPS screen from 22yr ago, I think I would have ripped it out and replaced it a bunch of times or just bought a new car.
I’m curious to try the new iDrive 10. We will see…
If I had the optional GPS screen from 22yr ago, I think I would have ripped it out and replaced it a bunch of times or just bought a new car.
I’m curious to try the new iDrive 10. We will see…
There's a big part of me that agrees with your implied conclusion, that it shouldn't matter.
On the other hand, I've found that core decisions like language ecosystem choice can be a good leading indicator of other seemingly unrelated decisions.
When I see someone choose a tool that I think is extremely well suited for a purpose, it makes me curious to see what else we agree on.
The Oven team, the ones who created the Bun runtime, is a good example for me. I think Zig is probably the best compromise out there right now, for my sensibilities. The Oven folks, who chose to use Zig to implement Bun, _also_ made a lot of product decisions I really agree with.
On the other hand, I've found that core decisions like language ecosystem choice can be a good leading indicator of other seemingly unrelated decisions.
When I see someone choose a tool that I think is extremely well suited for a purpose, it makes me curious to see what else we agree on.
The Oven team, the ones who created the Bun runtime, is a good example for me. I think Zig is probably the best compromise out there right now, for my sensibilities. The Oven folks, who chose to use Zig to implement Bun, _also_ made a lot of product decisions I really agree with.
This is one of my assessments/red-flags when interviewing with a company. Their tech stack/choices is a reflection of their engineering culture. If they chose Zig or Rust, I'd want to hear why that was a better choice than using a gc'd language.
> If they chose Zig or Rust, I'd want to hear why that was a better choice than using a gc'd language.
Come on, they advertise with benchmarks hence it's quite obvious why they didn't chose a gc'd language.
Come on, they advertise with benchmarks hence it's quite obvious why they didn't chose a gc'd language.
Oh yes I know they do in this post, I meant more generally. Even myself I often wish I had a need to use a lower-level, cooler language, but the pragmatic side of me just can't justify it.
Yes. I don't think Linux would have succeeded if written in a language other than C. Today is a different story.
Yes it matters to me as an end user if my web browser is more or less likely to have vulnerabilities in it. Choice of programming language has an impact on that. It doesn't have to be Rust, I'd use a browser written in Pony.
If I were making something that had to be low-level and not have security bugs, my statement would be:
> I’m not smart enough to build a big multi-threaded project in a manual memory-managed language that doesn't have vulnerabilities. I want help from the language & compiler.
The size and longevity of the team matters a lot too. The larger it gets the more problematic it is to keep the bugs out.
Yes it matters to me as an end user if my web browser is more or less likely to have vulnerabilities in it. Choice of programming language has an impact on that. It doesn't have to be Rust, I'd use a browser written in Pony.
If I were making something that had to be low-level and not have security bugs, my statement would be:
> I’m not smart enough to build a big multi-threaded project in a manual memory-managed language that doesn't have vulnerabilities. I want help from the language & compiler.
The size and longevity of the team matters a lot too. The larger it gets the more problematic it is to keep the bugs out.
[deleted]
There have been some large scale companies that went under because of platforms chosen to develop their products in. First that comes to mind is MySpace with Dreamweaver.
This post is aimed at developers and hackernews is a technically focused forum. So I care as a developer.
If language doesn’t matter then why not go build something in fortran or brainfuck?
If language doesn’t matter then why not go build something in fortran or brainfuck?
I really don't understand the disdain for Fortran on HN. While it's not the most well-defined or portable programming language in the world, it does its job pretty well for those who need it, and has more actively maintained implementations than any language I can think of apart from C.
> If language doesn’t matter then why not go build something in fortran or brainfuck?
Because if you're getting lunch, and someone suggests Burgers, Sushi, or Casu martzu. Only two are actually reasonable.
Yes, yes, if I'm allergic to shellfish, I might want to make sure I have an EpiPen before getting sushi. But that doesn't mean it's a meaningful problem.
Because if you're getting lunch, and someone suggests Burgers, Sushi, or Casu martzu. Only two are actually reasonable.
Yes, yes, if I'm allergic to shellfish, I might want to make sure I have an EpiPen before getting sushi. But that doesn't mean it's a meaningful problem.
There are second order effects. You definitely attract different types of talent depending on the technology stack of choice. And building the right group of talent around an early stage product/company is an extremely impactful thing on the product. And blogs are an impactful talent marketing source.
This doesn't guarantee any sort of commercial success because there are so many follow on things that are important (product/market fit, sales, customer success, etc.) but it's pretty rough to succeed in the follow ons when the product itself is shit.
For first order effects, if a product's target market is developer oriented, then marketing to things developers care about such as a programming language will help initial adoption. It can also help the tool get talked about more organically via user blogs, social media, word of mouth, etc.
Basically, yeah, it matters, but as a cog in a big machine like all things.
This doesn't guarantee any sort of commercial success because there are so many follow on things that are important (product/market fit, sales, customer success, etc.) but it's pretty rough to succeed in the follow ons when the product itself is shit.
For first order effects, if a product's target market is developer oriented, then marketing to things developers care about such as a programming language will help initial adoption. It can also help the tool get talked about more organically via user blogs, social media, word of mouth, etc.
Basically, yeah, it matters, but as a cog in a big machine like all things.
What does it say about your latest project that it attracts the most toxic types from Germany to China^? Are you even aware? Do you consider this "building the right group of talent" for your project?
^https://xcancel.com/QULuseslignux/status/1918296149724692968
^https://xcancel.com/QULuseslignux/status/1918296149724692968
Most seem to agree that NeXTSTEP/macOS/iOS wouldn't have succeeded without Objective-C. So much of the functionality that made it stand out was predicated on Objective-C's somewhat unique programming model.
Of course, it's all just 1s and 0s at the end of the day. You can ultimately accomplish the same in any language. But the design of the language does shape the way developers end up thinking about the problems. If NeXT had used, say, C++ instead, it is unlikely that the people involved would have ever come to recognize the same possibilities.
Of course, it's all just 1s and 0s at the end of the day. You can ultimately accomplish the same in any language. But the design of the language does shape the way developers end up thinking about the problems. If NeXT had used, say, C++ instead, it is unlikely that the people involved would have ever come to recognize the same possibilities.
https://paulgraham.com/avg.html
Paul Graham is one of the founders of Y Combinator, the company that hosts Hacker News.
Paul Graham is one of the founders of Y Combinator, the company that hosts Hacker News.
I think I'll take the side of no (as long as it's fast/safe/good) and also I never find the reasoning in these language comparisons to be that compelling anyways. A "why we like $FOO" is better than "why $FOO works better/is better for us than $BAR", since the latter is almost always going to be incomplete.
[deleted]
Now that you mention it I think this is a new trend. I pretty sure I've seen more "written in Rust/Go/Zig" than any other language out there. I've never seen a post like "new cli, written in C++" for example. I don't know if it's just some kind of tribalism or a way to attract talent to your project.
I think end users don't give a shit about the tech stack of a software. Why would they?
I think end users don't give a shit about the tech stack of a software. Why would they?
The opposite is true: there are a lot of projects that failed because of the chosen language.
What are some famous examples?
Eclipse, Azureus, Minecraft, MySpace with ColdFusion, OpenOffice's Java parts...
> Minecraft
Typo?
Typo?
Why? It's horrendously slow thanks to the wrong language choice and also required a rewrite (bedrock).
[deleted]
Ruby on Rails.
Lightpanda doesn't appear to be interested in impersonating a more popular browser. How will such a strategy not end in failure?
I didn't read much past their headline and blurb, but I don't think they're aiming to compete with normal browsers. This seems like a Selenium situation but with AI integration on top.
What did I say that suggested they intend to compete with a normal browser?
Right now their browser is trivial to block, it provides no value that I can see. curl-impersonate is more useful than what they offer, at least it won't be stuck on captchas as often.
Right now their browser is trivial to block, it provides no value that I can see. curl-impersonate is more useful than what they offer, at least it won't be stuck on captchas as often.
I'd like to see a setup with Lightpanda feeding a local/private AI, with content rendered post-curation. You could filter out all the garbage at the intake, instead of doing all the plug-ins, extensions, add-ons, DNS and whackamole arms race.
AI researchers need to hurry up and invent the next big paradigm shift so AI on your phone is as good as SoTA bots, so we can stay ahead of the enshittification curve.
Awesome software - I've been meaning to build a crawler and this does the trick.
AI researchers need to hurry up and invent the next big paradigm shift so AI on your phone is as good as SoTA bots, so we can stay ahead of the enshittification curve.
Awesome software - I've been meaning to build a crawler and this does the trick.
Author and founder here. Thank you!
[deleted]
[deleted]
The biggest reason against Rust is 3 year old article from personal blog. Trying to reproduce benchmark result from it result in failure because Zig code fails to compile.
Meanwhile Rust compiles just fine. Even updating toolchain to newest causes no issues and benchmark still runs. All I had to do is remove pinning to old toolchain, and bump language version to latest. Also changing dependency version to latest worked without an issue.
You'd think that performing all advanced memory manipulations you would want all the safety you want, but hey. Zig is cool this days.
Go figure.
Meanwhile Rust compiles just fine. Even updating toolchain to newest causes no issues and benchmark still runs. All I had to do is remove pinning to old toolchain, and bump language version to latest. Also changing dependency version to latest worked without an issue.
You'd think that performing all advanced memory manipulations you would want all the safety you want, but hey. Zig is cool this days.
Go figure.
I've written a fair amount of code in Rust and D and a little less in Zig. In my opinion, Zig was not ready for prime time when I used it -- too many bugs -- and that may still be true. Rust is hard to learn and even after you do, it gets in the way a lot. D is very nice if you like C, but there are a lot of problems with the project and the tooling.
I'm about to say something that will likely surprise you; it surprised me: have you folks thought about Ada? I was around, working on (D)ARPA contracts at BBN, when Ada was designed. We didn't use it, so I had no opinion of it at the time. I thought it had dried up and blown away in the decades since, like PL1.
Well, it's now #17 on the Tiobe index and climbing. So I gave it a try for a small project. My reaction is very positive. The language is well-designed, obviously having learned a lot of lessons from the mistakes of C, among other things. The compiler, gnat, is built on gcc. Compilation times are very fast, execution times are fast, it works well with gdb, and it's well documented. It avoids many of the traps of C (no pointer arithmetic, no automatic type conversions) and it just feels carefully engineered. It's been used to build a lot of applications in areas like train control and aviation where you just can't screw up because people may die if you do.
Based on my experience with writing and debugging a little over a thousand lines of code (so not a lot), I'm very impressed -- it's surprisingly good. I'd suggest giving it consideration if/when the opportunity presents itself.
I'm about to say something that will likely surprise you; it surprised me: have you folks thought about Ada? I was around, working on (D)ARPA contracts at BBN, when Ada was designed. We didn't use it, so I had no opinion of it at the time. I thought it had dried up and blown away in the decades since, like PL1.
Well, it's now #17 on the Tiobe index and climbing. So I gave it a try for a small project. My reaction is very positive. The language is well-designed, obviously having learned a lot of lessons from the mistakes of C, among other things. The compiler, gnat, is built on gcc. Compilation times are very fast, execution times are fast, it works well with gdb, and it's well documented. It avoids many of the traps of C (no pointer arithmetic, no automatic type conversions) and it just feels carefully engineered. It's been used to build a lot of applications in areas like train control and aviation where you just can't screw up because people may die if you do.
Based on my experience with writing and debugging a little over a thousand lines of code (so not a lot), I'm very impressed -- it's surprisingly good. I'd suggest giving it consideration if/when the opportunity presents itself.
1. Developers balked at being required to take on the cognitive load required to allow GC-less memory management
2. Developers wore their ability to take on that cognitive load as a badge of honor, despite it not being in their best interest
I eventually came to the decision to stop developing in Rust, despite its popularity. It is really cool that its creators pulled it off. It was quite an achievement, given how different it was when it came out. I think that if I had to implement a critical library I would consider using Rust for it, but as a general programming language I want something that allows me to focus my mental facilities on the complexities of the actual problem domain, and I felt that it was too often too difficult to do that with Rust.