14 ms·

What a monster. But let’s be real. Language preference is a real thing. Some developers don’t want to learn C++ properly and would rather use their own favouri

What a monster. But let’s be real. Language preference is a real thing. Some developers don’t want to learn C++ properly and would rather use their own favourite language when developing. Likewise, some people don’t want to learn rust and would rather stick to C++ or Go or whatever. Of course some devs prefer C++ and some prefer rust. How is that surprising? For a community systems project like FreeBSD, rust would be a great option for developers who prefer it. But it would fragment the ecosystem more for everyone else. Whether or not that’s worth it for the project is always going to be a hard choice.

lifthrasiir 2y ago
Yeah, that's why I can't really blame phk for objecting against Rust per se. But FreeBSD apparently had Perl in the base system for a long time, so presumably there always were needs for more (or different) languages to serve different needs. This time FreeBSD would also care about its dependence on broader ecosystems that wouldn't be usable within the base system though.
- bluGill 2y ago
  Freebsd got rid of perl because the cost was more than the gain. Sure you can write some things in perl better than sh, but now everyone needs to know both because somethings can't be perl.
  - lifthrasiir 2y ago
    Of course, but it does show that Perl did have enough value to be included---only for a while though. An alternative with a similar gain but lower cost could have been explored.
    - tialaramex 2y ago
      The argument against Perl is probably the most compelling of the arguments against Rust. In practice Perl programmers wanted various extra components. They didn't want to use out-of-the-box Perl, they wanted this popular CPAN library, and that one, and actually, also this other one. FreeBSD found that often "We have Perl" wasn't enough and yet "Lets add six more Perl libraries" is a tall order for them. Unlike the Linux kernel programmers, FreeBSD's programmers are mostly writing userspace code, there is after all a lot more userspace. But in userspace, Rust programmers will reach for popular crates. Clap for example, to consistently parse arguments, or Regex to have excellent regular expressions. And so we're back to the same problem as Perl. Like I said, this is the most compelling argument against Rust in base FreeBSD. However, it does make me wonder what the situation is for the C++ in Base today. Are FreeBSD base programmers part of the (large) C++ contigent who want to land everything in the stdlib because that way they can smuggle in larger dependencies ie it's just the same as allowing an extra dozen popular Rust crates or Perl libraries, but without any FreeBSD process ? C++ appears likely to get the entire BLAS, a graph library, another whole suite of container types, several distinct lockfree reclamation mechanisms (including RCU and Hazard Pointers), a full blown Dimensioned Units type system and more, are these all vocabulary? Maybe such an argument can be made for the BLAS, and mp-units, but I'm sceptical. RCU is not vocabulary, neither in practice is this graph library. These will not enable practical interoperability.
      - lifthrasiir 2y ago
        Indeed, the bar is understandably high but C++ being above the bar is questionable. Maybe the reasoning was backward: any mainstream C compiler needs C++ so C++ had to be in the base system.
      - josephg 2y ago
        We need a better answer for this. Application programmers don't want to be stuck in the dark ages where packages in Cargo / pip / etc aren't available - or where all the packages you depend on have to be copied by hand into the system package managers (pkg/apt/rpm/etc). C and C++ deal with this by having dependency management be utterly horrible for application developers. You have to either vendor dependencies, or figure out how to find compatible versions of the packages you depend on on every system you want to support. (Ok, there's libsdl on ubuntu. On debian - oh, its a super old version. On redhat its split into multiple rpms. On macos? On freebsd? On windows? What about arch? Nix? Ok, next up - libpng. Oh no...) Of course perl devs want to use packages in CPAN. And of course rust devs want to use packages from Cargo. They're really good! And there's hundreds of tiny libraries which are way better than anything I'd write myself - from SIMD accelerated UTF8 validation, to serialization, arg parsing, network libraries, FFI for other languages, and so on. This stuff shouldn't be manually, partially mirrored in freebsd ports, apt and all the other places. Thats a ridiculous solution to a very real problem.
pdimitar 2y ago
> Some developers don’t want to learn C++ properly I do get your point but now you are kind of losing nuance. As engineers we also have to be able to answer the questions: "Is it really worth continuing to sink time and energy into technology X? Would it really give me increased productivity? Would it reduce runtime bugs? Would the return of investment be a favorable coefficient?" So yes, people actually stop and think about these things. What monsters indeed. The fallacy of "you have to know it perfectly to reject it" is tiring. If you want a technology to keep being used then maybe make it worth people's time. And I don't think language preference plays any measurable role in this; sure it exists but every serious engineer I've known just scoffs at syntax, myself included (whether I am a serious engineer or not, I make no claims). Syntax is something people constantly overplay as a factor and in reality I'd think at least 80% of all programmers get used to it in the first 2 - 8 weeks and then forget about it. To sum up, "learning C++ properly" is not a worthy endeavor and has not been in a long time. Of course people who only know that will reach for any other venues to attack the "youngsters" or whatever other ad hominem they prefer this week. That's known and well-understood, and hence their stance is obviously biased and as such is not a good starting discussion point.
- josephg 2y ago
  I agree re: syntax, but there’s sooo much more to be said about the differences between C++ and rust than syntax. There’s OO. The borrow checker vs smart pointers. Templates vs traits. Async. Philosophy around safety. And on and on. > To sum up, "learning C++ properly" is not a worthy endeavor and has not been in a long time. Even as someone who adores rust, this is where you lose me. The problem is that smart engineers disagree about whether rust and/or c++ is worth learning & using in 2024. I don’t think there’s any getting around that. You simply won’t convince a lot of C++ devs to like rust any more than you’ll convince many rust devs to learn & enjoy C++. The remaining question is what do you want to do about that? Would rust be good for the FreeBSD kernel? Are there enough rust devs around in the FreeBSD community to justify making rust a first class citizen in the base system?
  - pdimitar 2y ago
    [flagged]
ruthmarx 2y ago
> Language preference is a real thing. It is, much the same as most people don't all learn the same way. Even more, most language wars are people arguing their preferences, not objective pros and cons. Rust is different though, as it has real, objective advantages that merit consideration IMO.
- josephg 2y ago
  So? So does C++: - It has multiple working compiler implementations - It has a mountain of existing working software & libraries that may never be ported to rust, like most AAA video games, Chrome, Firefox, Windows, CUDA, etc. - C++ has better interop with pure C code. - C++ usually produces smaller binaries than rust. - Complex data structures (like b-trees) are easier to write in C++. (Rust supports pointers in unsafe blocks - but the syntax around pointers is, for some reason, horrible.) I adore rust, and I'd pick it over C++ every day of the week. But C++ is a powerful, fast, mature programming language with a rich ecosystem of compilers and tools. Rust is not a drop-in replacement for C++ in every case.
  - ruthmarx 2y ago
    > So? So does C++: These advantages are not really advantages in the same way the advantages Rust offers are advantages. In fact, most of the advantages you've listed here could apply to numerous languages not especially suited to modern development. As in, they're not real advantages and pale in comparison.

lifthrasiir 2y ago

Yeah, that's why I can't really blame phk for objecting against Rust per se. But FreeBSD apparently had Perl in the base system for a long time, so presumably there always were needs for more (or different) languages to serve different needs. This time FreeBSD would also care about its dependence on broader ecosystems that wouldn't be usable within the base system though.

bluGill 2y ago
Freebsd got rid of perl because the cost was more than the gain. Sure you can write some things in perl better than sh, but now everyone needs to know both because somethings can't be perl.
- lifthrasiir 2y ago
  Of course, but it does show that Perl did have enough value to be included---only for a while though. An alternative with a similar gain but lower cost could have been explored.
  - tialaramex 2y ago
    The argument against Perl is probably the most compelling of the arguments against Rust. In practice Perl programmers wanted various extra components. They didn't want to use out-of-the-box Perl, they wanted this popular CPAN library, and that one, and actually, also this other one. FreeBSD found that often "We have Perl" wasn't enough and yet "Lets add six more Perl libraries" is a tall order for them. Unlike the Linux kernel programmers, FreeBSD's programmers are mostly writing userspace code, there is after all a lot more userspace. But in userspace, Rust programmers will reach for popular crates. Clap for example, to consistently parse arguments, or Regex to have excellent regular expressions. And so we're back to the same problem as Perl. Like I said, this is the most compelling argument against Rust in base FreeBSD. However, it does make me wonder what the situation is for the C++ in Base today. Are FreeBSD base programmers part of the (large) C++ contigent who want to land everything in the stdlib because that way they can smuggle in larger dependencies ie it's just the same as allowing an extra dozen popular Rust crates or Perl libraries, but without any FreeBSD process ? C++ appears likely to get the entire BLAS, a graph library, another whole suite of container types, several distinct lockfree reclamation mechanisms (including RCU and Hazard Pointers), a full blown Dimensioned Units type system and more, are these all vocabulary? Maybe such an argument can be made for the BLAS, and mp-units, but I'm sceptical. RCU is not vocabulary, neither in practice is this graph library. These will not enable practical interoperability.
    - lifthrasiir 2y ago
      Indeed, the bar is understandably high but C++ being above the bar is questionable. Maybe the reasoning was backward: any mainstream C compiler needs C++ so C++ had to be in the base system.
    - josephg 2y ago
      We need a better answer for this. Application programmers don't want to be stuck in the dark ages where packages in Cargo / pip / etc aren't available - or where all the packages you depend on have to be copied by hand into the system package managers (pkg/apt/rpm/etc). C and C++ deal with this by having dependency management be utterly horrible for application developers. You have to either vendor dependencies, or figure out how to find compatible versions of the packages you depend on on every system you want to support. (Ok, there's libsdl on ubuntu. On debian - oh, its a super old version. On redhat its split into multiple rpms. On macos? On freebsd? On windows? What about arch? Nix? Ok, next up - libpng. Oh no...) Of course perl devs want to use packages in CPAN. And of course rust devs want to use packages from Cargo. They're really good! And there's hundreds of tiny libraries which are way better than anything I'd write myself - from SIMD accelerated UTF8 validation, to serialization, arg parsing, network libraries, FFI for other languages, and so on. This stuff shouldn't be manually, partially mirrored in freebsd ports, apt and all the other places. Thats a ridiculous solution to a very real problem.

pdimitar 2y ago

> Some developers don’t want to learn C++ properly I do get your point but now you are kind of losing nuance. As engineers we also have to be able to answer the questions: "Is it really worth continuing to sink time and energy into technology X? Would it really give me increased productivity? Would it reduce runtime bugs? Would the return of investment be a favorable coefficient?" So yes, people actually stop and think about these things. What monsters indeed. The fallacy of "you have to know it perfectly to reject it" is tiring. If you want a technology to keep being used then maybe make it worth people's time. And I don't think language preference plays any measurable role in this; sure it exists but every serious engineer I've known just scoffs at syntax, myself included (whether I am a serious engineer or not, I make no claims). Syntax is something people constantly overplay as a factor and in reality I'd think at least 80% of all programmers get used to it in the first 2 - 8 weeks and then forget about it. To sum up, "learning C++ properly" is not a worthy endeavor and has not been in a long time. Of course people who only know that will reach for any other venues to attack the "youngsters" or whatever other ad hominem they prefer this week. That's known and well-understood, and hence their stance is obviously biased and as such is not a good starting discussion point.

josephg 2y ago
I agree re: syntax, but there’s sooo much more to be said about the differences between C++ and rust than syntax. There’s OO. The borrow checker vs smart pointers. Templates vs traits. Async. Philosophy around safety. And on and on. > To sum up, "learning C++ properly" is not a worthy endeavor and has not been in a long time. Even as someone who adores rust, this is where you lose me. The problem is that smart engineers disagree about whether rust and/or c++ is worth learning & using in 2024. I don’t think there’s any getting around that. You simply won’t convince a lot of C++ devs to like rust any more than you’ll convince many rust devs to learn & enjoy C++. The remaining question is what do you want to do about that? Would rust be good for the FreeBSD kernel? Are there enough rust devs around in the FreeBSD community to justify making rust a first class citizen in the base system?
- pdimitar 2y ago
  [flagged]

ruthmarx 2y ago

> Language preference is a real thing. It is, much the same as most people don't all learn the same way. Even more, most language wars are people arguing their preferences, not objective pros and cons. Rust is different though, as it has real, objective advantages that merit consideration IMO.

josephg 2y ago
So? So does C++: - It has multiple working compiler implementations - It has a mountain of existing working software & libraries that may never be ported to rust, like most AAA video games, Chrome, Firefox, Windows, CUDA, etc. - C++ has better interop with pure C code. - C++ usually produces smaller binaries than rust. - Complex data structures (like b-trees) are easier to write in C++. (Rust supports pointers in unsafe blocks - but the syntax around pointers is, for some reason, horrible.) I adore rust, and I'd pick it over C++ every day of the week. But C++ is a powerful, fast, mature programming language with a rich ecosystem of compilers and tools. Rust is not a drop-in replacement for C++ in every case.
- ruthmarx 2y ago
  > So? So does C++: These advantages are not really advantages in the same way the advantages Rust offers are advantages. In fact, most of the advantages you've listed here could apply to numerous languages not especially suited to modern development. As in, they're not real advantages and pale in comparison.