4 ms·
Copy-pasting a comment from "cup" on lobsters, because I think it's on-point: >1000 times yes. If Google wants their own libc that’s their business. But LLVM s
by Sir_Cmpwn 7y ago
Copy-pasting a comment from "cup" on lobsters, because I think it's on-point:
>1000 times yes. If Google wants their own libc that’s their business. But LLVM should not be part of their “manifest destiny”. The corporatization of OSS is a scary prospect, and should be called out loud and clear like this every time it’s attempted.
https://lobste.rs/s/dgmoyi/response_libc_llvm#c_hg8dvg https://lobste.rs/s/dgmoyi/response_libc_llvm#c_hg8dvg
- favorited 7y agoThere has been huge corporate involvement and investment in LLVM from its earliest days as anything beyond a research project. When Apple open-sourced Clang, or their C++ standard library implementation and contributed them to the LLVM project, was that something to be afraid of as well? It seems to have gone pretty well.
- svnpenn 7y agoFair point, but Google is not Apple. Google has a history of railroading standards to suit their needs, to the point where the standard becomes "what Google is doing". See the Chrome project.
- kevin_thibedeau 7y agoUh... Firewire.
- flukus 7y agoApple ignores standards in the first place and opts for a completely closed and proprietary ecosystem wherever possible (see vulkan support and many others). They're both out to screw you but at least google does a bit of romancing first.
- Conan_Kudo 7y agoThere are plenty of examples on Apple's side, too. To name a few: Floppy disks. CDROM. USB. Firewire. WebKit.
- omeid2 7y agoUnfortunately, the good deeds does not protect from bad consequences. Google has shown little regard to standards and community, specially as of recent, based on their handling of the musl libc in fuchsia, libc++ in Android, Go the language and it's community, and the elephant in the room: Google Chrome. Google has a bad culture of forking things and breaking things for good business reasons which does not align with the community and people outside Google. The concerns around Google fucking things up with their influence is not unreasonable.
- hermitdev 7y agoI'm only a casual observer of LLVM, and have really only used tools such as clang-format. That said, I haven't observed Apple applying a heavy hand in regards to LLVM/Clang development. As a C++ developer, clang has been a god send, amd not just for Clang users. For a long while, they had the best error messages around. Actually truly pointing you to precisely where the error is and giving meaningful errors. For a long fucking time, C++ compilers gave really verbose, shitty error messages that took a whole other level of understanding to decipher, which really hindered novices from progressing. Clang put pressure on GCC and Visual Studio to up their game and produce useful errors during compilation. It was bad enough at one point, I used to present interview candidates with example code that failed to compile and the compiler output and ask the candidatea to fix the code (it was always a trivial mistake in the code involving templates, bit it'd generate a few screen fulls of errors). It wasnt my sole judge of whether I'd recommend them or not, but it was a good indicator of how well they understood the C++ environment and how to decipher compiler errors (sample program was less than 20 lines, but generated at least 3 screen full of errors due to template spewage).
- chandlerc1024 7y agoJust so we're completely clear, Google has been an incredibly long-term contributor to basically all parts of LLVM. So have sooooo many other companies. This is a really cool project IMO, but it doesn't represent a significant change in who or how much anyone is contributing to LLVM... It's a drop in the bucket. And for the record, LLVM is doing fine with all these corporate contributors. I'm not trying to say that this can't be a concern for OSS communities and projects, but LLVM seems to have a quite successful and sustainable model here.
- danieldk 7y agoThe problem is that neither the original thread, nor the threads here (which seem to be quite heavy on Google commenters) answers the question 'why?'. I think this wouldn't have caused nearly as much commotion as it does now, if the original post explained the technical reasons for starting a new libc. What problems do existing implementations have? How could a new libc address these issues? Instead, this has an air of (regardless whether this is true): we are going to write a new libc for completely opaque company-driven reasons, and either you accept it or you we will make it happen anyway.