> Swift could have easily dethroned Python

No way something that compiles as slowly as Swift dethrones Python.

Edit: Plus Swift goes directly against the Zen of Python

> Explicit is better than implicit.

> Namespaces are one honking great idea -- let's do more of those!

coupled with shitty LSP support (even to this day) makes code even harder to understand than when you `import *` in Python.

Edit 2: To expand a little on how shitty the LSP support is for those who don't work with Swift: any trivial iOS or macOS project that builds fine in Xcode can have a bunch of SourceKit-LSP (the official Swift LSP) errors because it fails to resolve frameworks/libraries. The only sane way to work with Swift in VS Code or derivatives I've found is to turn off SourceKit diagnostics altogether and only keep swiftc diagnostics. And I have the swift-lsp plugin in Claude Code, there's a routine baseline of SourceKit errors ignored. So you have symbols without explicit namespaces, and the LSP simply can't resolve lots of them, so no lookup for you. Good luck.

▲

vovavili 8 hours ago | parent | next [-]

>No way something that compiles as slowly as Swift dethrones Python.

This must have pushed Chris Lattner towards making Mojo both interpreted and compiled at the same time.

	▲	7 hours ago \| parent [-]
		[deleted]

▲

bossyTeacher 8 hours ago | parent | prev | next [-]

> Explicit is better than implicit.

That's funny. To me magic is implicit by definition and Python strikes me as a very magical language compared to something like Java that is way more explicit.

	▲	robmccoll 8 hours ago \| parent \| next [-]
		Until you start using frameworks like Spring and then everything is so painfully magic that no one knows how the program actually runs.
	▲	wiseowise 7 hours ago \| parent \| prev [-]
		Magical language how? And you should see what reflection based Java monstrosities do in the background.

▲

commandersaki 8 hours ago | parent | prev [-]

Plus Swift goes directly against the Zen of Python

The Zen of Python is how we got crap like argparse where arguments are placed in the namespace instead of a dict.

▲

coldtea 6 hours ago | parent [-]

I wouldn't change that in any way. I'd might make it an Arguments class, but I wound't make what parser returns merely a dict.

▲

commandersaki 5 hours ago | parent [-]

Yeah, so what happens when you have an option with a '-' in it that isn't valid as a variable name (I know what happens). It's just stupid.

▲

coldtea 4 hours ago | parent [-]

The same thing you'd do yoursef if you wanted to assign it to a namesake local variable even if it was in a dict to begin with: you'd make the dash an underscore.

▲

commandersaki 3 hours ago | parent [-]

It would be extremely unlikely that you would replicate the name as a local variable if it was in a dict, but regardless a dict doesn't have that limitation. The namespace thing is atrocious and bad design -- no straightforward way to iterate over them, merging/updating them is awful, collides with keyword methods (keys, items, etc.), and so on; thankfully more modern argument parsing libraries didn't repeat this mistake. It's just a shame this ended up in the standard library, but then Python standard library has never really been any good, e.g. logging and urllib1234567.

	▲	coldtea an hour ago \| parent [-]
		>It would be extremely unlikely that you would replicate the name as a local variable if it was in a dict If you had some feature flag args, you'd keep accessing them via the dict? Highly unlikely...