4 ms·

This doesn't imply the decision is any less jaw-dropping. Besides, polling enjoyment is not exactly what I would describe as a pragmatic approach.

LeFantome 2y ago
I think they had two overarching criteria: 1 - memory safe (ish) 2 - OOP Rust was off the table because of number 2. The list gets short after that.
- pjmlp 2y ago
  Rust has all the OOP features minus class inheritance, but folks like to repeat otherwise. All the COM programming patterns can be easily done in Rust. Here, ray tracing in one weekend, quite closely translated from the original C++ OOP design into Rust. https://github.com/pjmlp/RaytracingWeekend-Rust https://github.com/pjmlp/RaytracingWeekend-Rust
  - LeFantome 2y ago
    It has to work with the existing C++ code and class hierarchy. And OOP-like API is not good enough. It was not my assessment though. It was theirs.
    - pjmlp 2y ago
      Sure but that is already another criteria set, similar to how Carbon is also being developed, and not a plain "doesn't do OOP", because Java OOP is not the only flavour in town, which many folks conflate OOP with. Not only does it predate the language by a few decades, there is enough type systems variants to chose from.
    - nukem222 2y ago
      I mean that excludes swift too, it can't use the C++ ABI any more than other languages can. Excepting super-specialty languages
      - quux 2y ago
        I haven't worked with it myself but my understanding is that Swift's C++ interop has improved a lot recently and is continuing to be improved. Apple has a huge C++ codebase so they are incentivized to make Swift work well with it https://www.swift.org/documentation/cxx-interop/ https://www.swift.org/documentation/cxx-interop/
    - hypeatei 2y ago
      The C++ interop story for Swift isn't the most clear cut, though. You're forced to use Apple's fork of llvm (meaning no GNU or mainline clang support) and there are issues tracking the current blockers[0]. Along with other related issues under the "swift" tag[1]. I don't think this was necessarily a bad technical decision, but from a lock-in and practicality perspective it seems flawed. [0]: https://github.com/LadybirdBrowser/ladybird/issues/933 https://github.com/LadybirdBrowser/ladybird/issues/933 [1]: https://github.com/LadybirdBrowser/ladybird/issues?q=is%3Aissue%20state%3Aopen%20label%3Aswift https://github.com/LadybirdBrowser/ladybird/issues?q=is%3Ais...
- deleted 2y ago
  [deleted]
zem 2y ago
polling enjoyment is superbly pragmatic! this is a volunteer project that depends critically on the developers continuing to enjoy working on it. once you get past the first cut of "is this a reasonably mature language with a lot of community support behind it that compiles to fast native executables", enjoyment is one of the best ways you can choose between the various candidates. you can pretty much assume that rust/c++/swift/go/kotlin/etc all have the cross-platform support and libraries you will need.
- nukem222 2y ago
  Sure, if you're trying to have a good time it works great! No hate here.

LeFantome 2y ago

I think they had two overarching criteria: 1 - memory safe (ish) 2 - OOP Rust was off the table because of number 2. The list gets short after that.

pjmlp 2y ago
Rust has all the OOP features minus class inheritance, but folks like to repeat otherwise. All the COM programming patterns can be easily done in Rust. Here, ray tracing in one weekend, quite closely translated from the original C++ OOP design into Rust. https://github.com/pjmlp/RaytracingWeekend-Rust https://github.com/pjmlp/RaytracingWeekend-Rust
- LeFantome 2y ago
  It has to work with the existing C++ code and class hierarchy. And OOP-like API is not good enough. It was not my assessment though. It was theirs.
  - pjmlp 2y ago
    Sure but that is already another criteria set, similar to how Carbon is also being developed, and not a plain "doesn't do OOP", because Java OOP is not the only flavour in town, which many folks conflate OOP with. Not only does it predate the language by a few decades, there is enough type systems variants to chose from.
  - nukem222 2y ago
    I mean that excludes swift too, it can't use the C++ ABI any more than other languages can. Excepting super-specialty languages
    - quux 2y ago
      I haven't worked with it myself but my understanding is that Swift's C++ interop has improved a lot recently and is continuing to be improved. Apple has a huge C++ codebase so they are incentivized to make Swift work well with it https://www.swift.org/documentation/cxx-interop/ https://www.swift.org/documentation/cxx-interop/
  - hypeatei 2y ago
    The C++ interop story for Swift isn't the most clear cut, though. You're forced to use Apple's fork of llvm (meaning no GNU or mainline clang support) and there are issues tracking the current blockers[0]. Along with other related issues under the "swift" tag[1]. I don't think this was necessarily a bad technical decision, but from a lock-in and practicality perspective it seems flawed. [0]: https://github.com/LadybirdBrowser/ladybird/issues/933 https://github.com/LadybirdBrowser/ladybird/issues/933 [1]: https://github.com/LadybirdBrowser/ladybird/issues?q=is%3Aissue%20state%3Aopen%20label%3Aswift https://github.com/LadybirdBrowser/ladybird/issues?q=is%3Ais...
deleted 2y ago
[deleted]

zem 2y ago

polling enjoyment is superbly pragmatic! this is a volunteer project that depends critically on the developers continuing to enjoy working on it. once you get past the first cut of "is this a reasonably mature language with a lot of community support behind it that compiles to fast native executables", enjoyment is one of the best ways you can choose between the various candidates. you can pretty much assume that rust/c++/swift/go/kotlin/etc all have the cross-platform support and libraries you will need.

nukem222 2y ago
Sure, if you're trying to have a good time it works great! No hate here.