You're entitled to your opinion, but most of it is 100% bullshit in my eyes.

I'll use Haskell as example. The ecosystem is a mess. `stack` is admirable effort to make development palatable, but it's ultimately a technical solution papering over a cultural issue: The community [including the language designers!] have 0 respect for backwards compatibility.

The node ecosystem is seems to be the worst at this. Not only is there no real respect for backwards compatibility, but it seems that the real purpose for a lot of the stuff is created is to 1) bolster the creator's resume and status or 2) to get funding from a VC. Certainly all ecosystems have that to some degree, but node just feels like the worst, by far.

I've written all the major languages with this problem professionally [except node]. It's not that I don't understand. It's that I did spend my time on understanding this and it was such a complete waste of time in retrospect. The solution isn't to spend more time learning the tooling. It's to only work in ecosystems that don't waste your time.

edit: Any ecosystem that has some notion of a "langauge version manager" is a big clue to me that I'm about to spend a lot of time learning a bunch of non-portable information.

Which ecosystems don’t waste your time, according to you?

Just curious.

Java is pretty good. Go. C because of the nature of how libraries are shipped. Just as an example:

"0 - libcurl 7.1, August 2000

1 - libcurl 7.5 December 2000

2 - libcurl 7.7 March 2001

3 - libcurl 7.12.0 June 2004

4 - libcurl 7.16.0 October 2006"

"During the first seven years of libcurl releases, there have only been four ABI breakages.

We are determined to bump the SONAME as rarely as possible. Ideally, we never do it again."

This is the attitude of what I want out of my dependencies.

Have you had an experience with Cargo, the Rust package manager? It is an absolute joy to work with, clean repeatable builds, and fast for what you are getting (speed of C++ with the correctness of Haskell).

Not really. I've played with Rust but haven't used it in anger. One thing I've noticed about my programming style is that I LOVE to learn about new languages and language features. Using a language like Go or Java forces to me concentrate on the problem at hand [which almost always something where GC is fine for what I'm working on]. That said, the Rust ecosystem seems pretty solid [except the edition stuff, that makes me very leery...]

Editions exist to guarantee forward compatibility, it's actually a really good solution to a hard problem.

It started at major version 7?

First release was major version 4, same as curl (using that name) itself.

https://curl.haxx.se/docs/history.html

I’ve been happy with the Elixir/Erlang world. Especially as a scripting/dynamic language it’s been remarkably stable from a "don’t waste my time" perspective. Core system features from years back work, and generally work with updated libraries.

Well despite a few major changes to Phoenix, but that was mostly changes to the naming patterns. It also switched to web pack which I consider a pain point of following JS development. With LiveView I only have a dozen JS deps and ~50 lines of JS so now I can get off the JS ratrace too! Well github complains about outdated npm deps. I should make a GH action for that or something.

Ruby is quite practical.

It has a decent standard library (so you don't waste tons of time evaluating/choosing libraries for basic things) and has a simple package management story with bundler, which separates what libraries you want (Gemfile) from what specific versions you happen to be using (Gemfile.lock).

This, a hundred times over.

The more experienced I get, the primary transformation I see in myself is being less dismissive of existing work that I wasn't involved in.

Were they insanely time crunched? Was this a prototype by a lawyer who painstakingly taught himself Excel and then taught himself Python again to port the Excel sheet he had into a service? Were the abstractions they chose based on whatever was the best practice at the time?

I've stopped scoffing at a simple app that I think I can "hack together in a weekend". No I can't. There are complexities and corners I don't see at the moment.

> I've stopped scoffing at a simple app that I think I can "hack together in a weekend"

How do you get your PM to stop planning that way, though?

Find a better PM.

The competent ones I’ve worked with invariably convince engineers their “weekend project” will take at least 2 months. They start by getting the engineer to spend an afternoon enumerating all the tasks they need to complete to implement and ship it.

Then the engineer takes 3 months, when they would have taken 6 without help from the PM. This is because the PM follows up, and helps them be ruthless with the requirements list.

I agree we should be more positive, but I think it's a mistake to think that if we understand enough, we stop calling things bullshit. I think that there are two common meanings of the term that are analytically useful.

One is Frankfurt's, as explained in his book On Bullshit [1]. His definition is "speech intended to persuade without regard for the truth". There's a lot of this in tech. Ego-driven posturing. Blind ideology. And a bunch more that comes from American business culture, where we have a special legal category for bullshit so obvious that it legally doesn't even count as false. [2]

The other is what Lean process experts call Muda [3]. It can be translated as: "futility; uselessness; wastefulness". But bullshit is often a perfectly good translation. As the original article points out, there can be an enormous amount of wasted effort coming up to speed, like "the footguns that will cost me a day to debug". Just yesterday I spent a day on what turned out to be a bug from 2015 that hundreds of people have voted on, but the tool maintainers have refused to solve because it doesn't fit with their initially chosen architecture. I am comfortable calling that bullshit.

I also think your "I don't have to spend time on it" bit is, well, let's gently call it "erroneous". Languages aren't like books, where a reader's choices are infinite. There are a finite number of languages popular enough for practical use, and every one of them was built with the express intention of having a lot of people use it. Every one of them has people who make their living from maintaining it, and many are purely corporate profit-driven considerations. When people set out to insert themselves into other people's lives, there's an inherent level of responsibility there. It shouldn't be handwaved away.

[1] https://press.princeton.edu/books/hardcover/9780691122946/on...

[2] https://en.wikipedia.org/wiki/Puffery

[3] https://en.wikipedia.org/wiki/Muda_(Japanese_term)

The ecosystem around a language is not different because each language needs a wildly different ecosystem. It’s mostly an accident of history where different tools and techniques are adopted by different communities over time.