I'm always surprised as well when new languages targeting widespread use launch without an official one. Dotnet/C#, Go and other languages that come batteries included with the package manager built into some kind of compiler/SDK binary, make the out of the box experience so much smoother, and the community hasn't fragmented nearly as much as say Java, Python and JS have into competing third party package management and project build tools.
Everyone in the Go community more or less uses the same Go modules support built into the SDK binary, much like how almost the entire DotNet community uses the NuGet package manager support built into the dotnet SDK binary. There are no extra dependencies to grab your project dependencies and build it.
My experiences in those langauges is that there is so much less debate over tooling, and people just get work done. No one in DotNet is waging an equivelent holy war about Gradle vs Maven etc...
I'm all for choices, but the languages who have made package management a first class citizen in their SDKs tend to be the languages I've enjoyed working in the most. I think package management tooling is a critical piece of developer ergonomics.
People used to joke a lot about how JS has a new framework every week, but I feel that way about Python build tooling! I've now had to use uv, poetry, pipenv, hatch...
I find your choice of examples (dotnet and go) baffling to me. Both enjoyed a very long life (8-10 years) past “1.0” before getting a standard package manager. The other examples, Java, python and JS are significantly older than Go (and even dotnet). Python and JS also had a significantly different intended use (scripting) than where they ended. Expectations of a language and its ecosystem changed. The compiler, linker, build system, package manager, LSP, linter, formatter, debugger, and plenty more are expected of any new language now.
Well not Go's package manager, right? Go modules came out 2019, Swift 2015?
I wasn't arguing against Swift needing a default package manager, I agree with that. Just the examples you picked to compare with are odd in context. You could compare Swift to its contemporaries like Rust or Zig and come to the same conclusion.
Because a package index isn’t actually core to a programming language, and specifically with Swift, Apple tried to ship as many of the necessary types as possible in the standard library
I'm always surprised as well when new languages targeting widespread use launch without an official one. Dotnet/C#, Go and other languages that come batteries included with the package manager built into some kind of compiler/SDK binary, make the out of the box experience so much smoother, and the community hasn't fragmented nearly as much as say Java, Python and JS have into competing third party package management and project build tools.
Everyone in the Go community more or less uses the same Go modules support built into the SDK binary, much like how almost the entire DotNet community uses the NuGet package manager support built into the dotnet SDK binary. There are no extra dependencies to grab your project dependencies and build it.
My experiences in those langauges is that there is so much less debate over tooling, and people just get work done. No one in DotNet is waging an equivelent holy war about Gradle vs Maven etc...
I'm all for choices, but the languages who have made package management a first class citizen in their SDKs tend to be the languages I've enjoyed working in the most. I think package management tooling is a critical piece of developer ergonomics.
People used to joke a lot about how JS has a new framework every week, but I feel that way about Python build tooling! I've now had to use uv, poetry, pipenv, hatch...
I find your choice of examples (dotnet and go) baffling to me. Both enjoyed a very long life (8-10 years) past “1.0” before getting a standard package manager. The other examples, Java, python and JS are significantly older than Go (and even dotnet). Python and JS also had a significantly different intended use (scripting) than where they ended. Expectations of a language and its ecosystem changed. The compiler, linker, build system, package manager, LSP, linter, formatter, debugger, and plenty more are expected of any new language now.
All of them pre-exist Swift, so I think it's perfectly fair to compare. Swift wasn't made in a vacuum.
Well not Go's package manager, right? Go modules came out 2019, Swift 2015?
I wasn't arguing against Swift needing a default package manager, I agree with that. Just the examples you picked to compare with are odd in context. You could compare Swift to its contemporaries like Rust or Zig and come to the same conclusion.
I think you missed it: go and dot net launched without package managers. It was a long time before they had a standard package manager.
Because a package index isn’t actually core to a programming language, and specifically with Swift, Apple tried to ship as many of the necessary types as possible in the standard library