3 ms·

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 ha

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.

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.