According to the project structure page[0], Apple, Inc. is the project lead and appoints the core team.

0: https://www.swift.org/community/#community-structure

Wouldn't it by nice to have a language where the project owners said "you know what, I think we're done, just bug fixes now".

Elixir announced something to that effect in 2019.

> As mentioned earlier, releases was the last planned feature for Elixir. We don’t have any major user-facing feature in the works nor planned. I know for certain some will consider this fact the most excing part of this announcement! [0]

[0] https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas...

Rich Hickey talked about this in his History of Clojure presentation and paper.

https://news.ycombinator.com/item?id=27782864

It's definitely an unusual approach for authors to consider software "done", and Clojure apparently gets close to it (?)

Not surprisingly, that kind of stance also generates controversy ... you can't win :)

Common Lisp is like this. There is a standard, but no changes have been done since then.

On the other hand, it also shows some of the disadvantages - for example, there is no multi-threading support of any kind in the Common Lisp standard, because this was not a common feature at the time the standard was created; neither is there Unicode support. Of course there are libraries that implement these things, even portably (and this being CL, the difference between library and core langauge is minimal), but it's still a point some hold against it.

Not a language in the way you mean, but TeX did this a while back.

That's Standard ML. Coming at you live straight outta '97

Mid-2000s versions of C and C++ come close, but I think the new features since then are largely worth having.

C++ was just tied in "C++0x" debacle for over a decade, only delivered when they cut tons of stuff.

Elixir feels largely this way to me.

Though I'm on the fence, that they end run around the pressure to evolve, by just inventing new DSLs via gobs of macro magic for some of the newer stuff. Whereas a language like Swift keeps leaning on the compiler to respond to evolving demands.

Yeah, for a dying language.

A language's surroundings can still be improved, the documentation can still be improved, new tools can still be made, new libraries can still be written, etc.

And at the end if the language is inadequate for something then simply use something else that fits better, there is no reason to force all languages be gigantic kitchensinks.

On the other hand, it is a lot of work to build your product in one language, which you then outgrow, which forces you to switch to another language.

I've seen this happen many times, particularly with projects that started out in Python. Eventually the codebase and teams get too big, and managing a large codebase in a language with Python's type system becomes very cumbersome. Type annotations were a reaction to that, and adding them to the language has probably enabled a lot of teams to continue using Python.

Off the top of my head, other examples of good changes include NIO and better concurrency primitives/lambda syntax in Java, generics in Go, and async/await in several other languages. All of those solved pain points for developers that might have otherwise been solved by switching languages.

Why does this matter? First of all, it's a lot of work to rewrite products in different languages. Also, while it sounds attractive to pick the right language for the task every time, in practice it is difficult to run a coherent engineering organization if every product or team uses a different language -- it's hard to build good shared libraries and app frameworks for every language in use, and if someone leaves the company it can be hard to transfer their projects to other engineers. Most of the time, as an engineering org matures it eventually settles on a few "blessed" languages, invests in good frameworks for them, and requires all the teams to use them. Out of necessity, those tend to be the "kitchen sink" variety.

This is about why you may want a kitchensink language, which can be fine depending on the case and a criterion for choosing it as "the right language" (or skipping a language) for your case but it isn't really about making all languages kitchensink languages. The comment above implied that languages which'd try to avoid becoming kitchensink languages would be dying languages - as if these are the only outcomes.

People miss that programing languages are no different from any kind of software products, and software products without new releases hardly survive.

COBOL awaits you!

Still being revised in standards committees: https://en.wikipedia.org/wiki/COBOL#COBOL_2014

feel free to use QBASIC

awk?

Apple has done some very cool things with Swift. The nice integration of pretrained (or train your own) deep learning models in Swift applications/apps, SwiftUI really does work as a multi-Apple-platform UI library. I wrote an app that was 98% identical across macOS/iOS/iPadOS.

I was deeply disappointed a few years ago when the TensorFlow in Swift project was scrapped.

Same, working with Python is such a poor UX by comparison.

That project had a ton of potential, but it seems like it lacked buy-in from the industry, and the team working on it seemed to lack leadership as little progress ever seemed to get made.