Hacker News new | past | comments | ask | show | jobs | submit login

I’ve worked in C++ and picked my own tools. The tooling experience in Go is much more polished for a few reasons.

First, as the author states, it’s hard to get consensus on a tool if it wasn’t baked in from the beginning. I don’t think there will ever be a dependency manager or especially an option-free formatter for C++ with the same adoption as gofmt or go modules.

Second, it helps a lot to have the compiler/runtime authors think about the tooling. Go runtime developers think about pprof. GCC developers don’t think about the UX of valgrind. C++ standard authors don’t write PR’s for code formatting tools when they change the language spec.




> I don’t think there will ever be a dependency manager

I know a C++ guy who insists that C++ already has a dependency manager — he says it’s called Docker. Not sure I agree, but that’s the kind of attitude that seems to grow when a void exists; people get by with “good enough hack for my use case in a pinch”, and then over time that turns into “this is the way it’s done”.


C’s problem is that my “way it is done” is different from yours.

Your friend uses Docker. My friend uses Apt (and hopes the libraries he wants are in there). Someone else compiles by hand and uses pkgconfig. Or CMake files. Or VC++ referenced projects. Or XCode projects. Or autotools. Or hand written make files. Or ninja. And so on.

Universal tooling only has value when it’s universal. Adding yet another contender to the mess doesn’t really help unless it becomes a standard.


Docker is orthogonal to the other tools you mentioned. You use apt or pkgconfig or autotools or hand rolled configuration inside of Docker (ignoring cross-platform issues for brevity).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: