Is there any discussion on why D or even Ada was not considered? These languages have been around for long time. If they were willing to use llm to break the initial barrier to entry for a new language, then a case can be made for these languages as well.
They already made the mistake picking a niche language twice (first their own language, then Swift as a cross-platform language), why would you want them to make it a third time?
What kind of response is this? I was asking if there was any technical evaluation on other languages. And D and Ada are not niche. They have been battle tested in critical software.
Swift had/has some problems in the language itself. It's not because of the niche nature of Swift that was the problem iirc.
I don't think this is the right response because certainly a meaningful discussion could've definitely taken place and given how they were already open to other languages which was the reason why they picked Swift in the first place.
I remember Andreas video where he talked about how people used rust in his codebase and they were so happy but later it became very difficult whereas they found with swift that it became easier to manage. That was the reason why they picked swift that time.
Certainly their goal wasn't to pick a popular language (because if that's what you want use python or JS) but rather a language that was relevant to what they were building.
So if D and Ada were relevant or not, that's the main point of discussion imo.
I've dabbled a bit in Ada, but it wouldn't be my choice either. It's still susceptible to memory errors. It's better behaved than C, but you still have to be careful. And the tooling isn't great, and there isn't a lot in terms of libraries. I think Ladybird also has aspirations to build their own OS, so portability could also be an issue.
Not the case with spark. But I understand it requires writing lot of things from scratch for browsers. But I don’t think portability will be an issue with Ada, it is cross platform.
However, this is where d shines. D has a mature ecosystem. Offers first class cpp abi and provides memory safety guarantees, which the blog mentioned as a primary factor. And d is similar to cpp, low barrier for cpp devs to pick up.
There's no dynamic memory allocation with (100%) Spark. That's really limiting. You can to write "unsafe" code, but that has the same problems as Ada.
I thought SPARK got dynamic memory allocation when it adopted Rust-style ownership and borrowing in 2014.
That is true for parsers like libjs, but again crypto module or even networking, can still be written in spark, which is much more safety critical.
SPARK is not used for the whole system, but for the < 5% parts, which are safety/security-related in a good architecture.
Probably contributing reasons? I imagine over time they will have a lot more Rust contributors than D or Ada.
Unfortunately a really good question gets downvoted instead of causing a relevant discussion, as so often in recent HN. It would be really interesting to know, why Ada would not be considered for such a large project, especially now when the code is translated with LLMs, as you say. I was never really comfortable that they were going for the most recent C++ versions, since there are still too many differences and unimplemented parts which make cross-compiler compatibilty an issue. I hope that with Rust at least cross-compilation is possible, so that the resulting executable also runs on older systems, where the toolchain is not available.
Unfortunately some folks do get bit sensitive on rust, that can be off putting.
But what I wanted to know was about evaluation with other languages, because Andreas has written complex software.
His insight might become enriching as to shortcomings or other issues which developers not that high up in the chain, may not have encountered.
Ultimately, that will only help others to understand how to write better software or think about scalability.
I personally think that people might've framed it as use Ada/D over rust comment which might have the HN people who prefer rust to respond with downvotes.
I agree that, this might be wrong behaviour and I don't think its any fault of rust itself which itself could be a blanket statement imo. There's nuance in both sides of discussions.
Coming to the main point, I feel like the real reason could be that rust is this sort of equilibra that the world has reached for, especially security related projects. Whether good or bad, this means that using rust would definitely lead to more contributor resources and the zeal of rustaceans can definitely be used as well and also third party libraries developed in rust although that itself is becoming a problem nowadays from what I hear from people in here who use rust sometimes (ie. too many dependencies)
Rust does seem to be good enough for this use case. I think the question could be on what D/Ada (Might I also add Nim/V/Odin) will add further to the project but I honestly agree that a fruitful discussion b/w other languages would've been certainly beneficial to the project (imo) and at the very least would've been very interesting to read personally
> which might have the HN people who prefer rust to respond with downvotes.
This completely misses the purpose of the downvoting feature, which is not surprising, since upvoting seems no longer to indicate quality or truth of the comment neither.
> rust is this sort of equilibra that the world has reached for, especially security related projects
Which is amazing, since Rust only covers a fraction of safety/security concerns covered by Ada/SPARK. Of course this language has some legacy issues (e.g. the physical separation of interface and body in two separate files; we have better solutions today), but it is still in development and more robust than the C/C++ (and likely Rust) toolchain. And in the age of LLMs, robustness and features of a toolchain should matter more than the language syntax/semantics.
> Rust does seem to be good enough for this use case.
If you compare it to the very recend C++ implementations they are using, I tend to agree. But if you compare it to a much more mature technology like e.g. Ada, I have my doubts.
> If you compare it to the very recend C++ implementations they are using, I tend to agree. But if you compare it to a much more mature technology like e.g. Ada, I have my doubts.
I agree with you in the sense that it would've definitely been interesting to read what Andreas thinks of Ada/D and the discussion surrounding it and your overall comment too.
I do wish that anyone from ladybird team/maybe even Andreas if he's on HN (not sure) could respond to the original query if possible.
I remember ladybird had a discord server I once joined, perhaps someone from the community could ask Andreas about it there if possible since It would be genuinely fascinating to read.
Although a point I am worried about is if Ladybird changes the language again let's say after a discussion of using Ada/D. It might be awkward.
> I am worried about is if Ladybird changes the language again
In the time of good LLMs this is likely no longer a show-stopper (as e.g. the specific formating rules in C/C++ since there are good re-formating tools). The question is how long we will need programming languages at all. They were primarily invented because large assembler projects were too challenging for most people. But if all the complicated details can now be delegated to LLMs, strictly speaking, we no longer need programming languages either.
> This completely misses the purpose of the downvoting feature
"Downvote for disagree" has been canonicalized on HN since (nearly) the beginning, by pg himself, back when he used his real-name account to comment. :)
I agree that it has undesirable consequences, but it is fully established.
It's even worse than that. People are all too often willing to "flag for disagree". It's getting to be pretty common to see threads with comments that are [flagged][dead] which don't break the rules in any way, but merely express a view which is unpopular. Sometimes I even agree that it's a stupid position to take up, but that doesn't merit being flagged to death. I always vouch for those comments but it feels like an exercise in futility with so many people using the flag function as a "super fuck you" button.
Personally I would remove the downvote button entierly because apparently it is a lossy projection of an at least three-dimensional vector: agreement, quality, truth. Graying out text so it is no longer readable is a censoring measure not justified in most cases I encounter on HN in the eight years I'm here.