Hacker News Reader

Comment by adamgordonbell | Hacker News Reader

Author here. This was fun to write. I think there are counter-examples, but this was my main idea:

    When a new developer tooling innovation is discovered, newer programming languages get a chance to bake that innovation into their language tooling. Doing so gives them an incremental advantage, and these increments add up over time to a better developer experience.

    So newer languages have one clear, well thought out way to do something, and older languages will have either many contradictory ways, or no ways at all, to do the same thing. And this makes older languages feel old.

View on HN

I'm surprised you didn't talk about Go's novel dep management system. They have put as much thought into that design as the stdlib

https://verdverm.com/go-mods/

https://go.dev/ref/mod

I'm not an advanced user of either but both go.mod and cargo.toml seem like great examples of well thought out approaches to a problem, where they've learned from previous languages and came up with a pretty polished solution.

It's not the file format that's important.

For one, it's the algorithm used to select the right version of a transient dependency. Go uses MVS which is a polynomial time algo, rather than requiring SAT solver (NP-complete). Go does not allow dependency versions to be specified as ranges.

Second, it's all the other checks and infra behind the scenes. A serious amount of thought went into the design of a dependency system that is far more resistant to software supply chain attacks.

Great post. Now, why can't someone just come up with a great tooling system for a "dreaded" language, put it out there, and everyone start using that when they see it's better? Doesn't the answer just go back to the Green and Brown Language split? People who use these languages mostly work on legacy projects where they don't get to decide the tooling used. Because otherwise why would they use that language with all the trendy new options available?

I'm trying to think of examples of trying this for C or C++.

* Batteries-Included Standard Library - can't actually be a standard library, but could be the next best thing, a widely-used library; things like NSPR and APR for C, or Boost for C++

* Third-Party Package Repositories - Conan, which seems to be healthy, but hasn't taken over the world

* Documentation - Doxygen, which has been very successful

* Write Once, Run Most Places - little progress towards this for C, but the people in the C++ standards process do at least think about portability; i think there is an inherent tension between portability and being close to the metal which means it is always going to be a lower priority for C or C++

* Package Managers - see under 'Third-Party Package Repositories'; not clear to me to what extent this is a different thing

* Code Formatters - these have long existed, i suspect clang-format is most popular, but it is far from universal; what's missing is a universally-accepted strict formatting standard, as found in Go and Rust, and arguably now Python

So, it seems that these things do get retrofitted, and do get adopted, but not to the same extent as if they were there from the beginning of the language.

CMake, sanitizers and more static analysis tooling has seen good adoption. Yeah progress has been slower than new languages but improving.

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).

> Now, why can't someone just come up with a great tooling system for a "dreaded" language, put it out there, and everyone start using that when they see it's better?

I think the first two steps sometimes happen, but the last one is where things get stuck. Often times a better experience means incompatibility with the previous solutions, so adoption happens slowly if at all. Then eventually yet another incompatible solution comes out, and things fragment.

Thanks for reading.

Yeah true, legacy code must be a factor. If most people in C++ are working in legacy code bases that don't leverage many thrid-party packages then I guess there is little desire to standardize on a third-party package manager.

Another issue is more social. C++ has lots of package managers which is almost worse than declaring Conan the standard. Communities standards are hard to retro fit I guess?

(Not to pick on C++ by the way. Every popular language eventually sees itself competing with newer incumbents. It's like the innovators dilemma for PL. )

That's basically what the Laravel stack does for PHP. It's great, very ergonomic, I'd use it all the time if not for having to write PHP which I don't wish to do anymore.

It makes me think there isn't any reason old languages cannot adopt these.

Or even, come up with a new, batteries included version.

Eg. keep the Java syntax, but add one standard package manager (instead of ant, mvn, gradle), one standard test framework, standard formatter, etc. Call it 'Java++' or whatever.

You need to incentivize codebases to be moved to the new thing, or you have to rely on incremental adoption by new projects. It’s a tragedy of the commons — for any individual codebase it’s hardly worth the trouble (My codebase(s) already has a standard formatter / package manager / whatever; what do I get by changing?) but it’s worth it every other codebase was already moved.

Alternatively you build a thing that every other system could be auto-migrated to, which inevitably means supporting every possible feature of everything in play and slapping an ANSI standard label on it; and then watch as everyone extends the standard arbitrarily

> My codebase(s) already has a standard formatter / package manager / whatever; what do I get by changing?)

I guess you don't get much for yourself, but you get closer to some form of community standard. This ultimately helps your codebase "grow" when you need help from, or need to hire, other people. Other people that know those standards.

That’s fundamentally the problem; it’s only beneficial if the whole community moves in unison. If I switch from one standard with 10% ecosystem usage to another with 25%, I’ve accomplished nothing. You need something more like at least 60-70% standard usage to be a meaningful target.

Unless that 25% usage choice eventually grows to full usage… but I can’t predict the future — so I’m just betting on it. But that bet also does very little for me even on success (it’s definitely nicer to be normal, but it’s hardly critical), and I could just as well make the migration after it’s become a real standard with no risk.

So why am I migrating?

There are low hanging fruits which would have adoption problems but that can be navigated.

However, there are very painful things like modern compilers which are massive undertakings for an old languages. It cost Microsoft 3-4 years to rewrite the C# compiler to be modern. But the benefit is a language server which keeps pace with the compiler and refactorings on the same AST (aka more stable/reliable).

There are some absolutism in there which are not correct

> Because of this, Go developers lean on the standard library more than many other communities and generally hold it in high regard.

As a .NET developer I can just laugh here. Compared to JS and C/C++ this is accurate, but .NET, Java, PHP, Python this is the normal case. I would say the majority of platforms for application writing nowadays come like that. Which supports your argument, just that it is the norm already for a long time.

To your generalized argument: i do not follow that. Yes, modern languages have the benefit of knowledge, but the old stacks are massively catching up. Package manager and libraries is a solved problem (except for C++). The most interesting aspect this should focus about are modern compilers. The ones like C# or TypeScript which expose their services (AST, type checking, etc) as language servers. Here old platforms (PHP, C++, Java, ...) have massive pains because rewriting the compiler is the opposite of fun and new languages could start like that (e.g. TypeScript).

>> Because of this, Go developers lean on the standard library more than many other communities and generally hold it in high regard.

> [...] Compared to JS and C/C++ this is accurate, but .NET, Java, PHP, Python this is the normal case.

This is not my experience with Python, and even less for PHP. There are too many dark corners in the standard libraries of these languages to hold them in high respect. The standard library of PHP is an inconsistent mess, with many documentation holes.

For instance, there are several ways to send HTTP queries using the PHP STL. Apart from very basic needs, the usual way is through the libCURL integrated into the STL. Unfortunately this library is just a port from C, far from a native syntax and barely documented. For any advanced usage, the developer has to read the C documentation, or switch to a non-standard library.

Reply on news.ycombinator.com