There are not enough good symbols trivially typed on a keyboard to sacrifice half of them to dead keys. Either the dead key or the programming symbol can be mapped to a key combination.

If that's the rationale for choosing which symbols should be allowed, then let's ban {} as they require AltGr+Shift in many layouts. And let's avoid <> (used as parentheses, e.g. for templates or XML tags, not as less-than/greater-than) because in ISO keyboards they loose all their symmetry. And what about shells, with /, one of the most used characters, relegated above 7 in many layouts?

Jokes apart, I like the choice of ^ or any other characters distinct from * for pointer dereference. To be more precise, I despise the use of the same symbol with different meaning. In C the same * is used for multiplication, pointer dereference and takes part in commments, too. You need full context to parse some cases, or you have to play with spaces:

  (a)*(b) // multiplication or casted deref?
  x/ *y // multiplication
  x/*y  // comment start

  m&&n  // logical and
  m& &n // masked address

Chances are 677,634 of those will be broken next week though :-P

The problem with package managers is that they encourage piling on dependencies and creating deep (and thus fragile and often hard to reason about) dependency trees.

I loathe having to install anything more complicated than simple scripts[0] based on Python because unless the developer constantly chases after all their dependencies to keep them in working order, i'll be the one who will have to do that when something inevitably breaks (assuming it wasn't already broken the time i decided to try it - which is sadly something i encountered more than a few times). And once the developer moves on, the bitrot spreads alarmingly fast.

[0] and even that isn't reliable if the scripts rely on more than whatever comes preinstalled with Python

The short version is: projects should vendor their deps and manually resolve package versions. I don't think he states his argument very clearly. But I do think he's basically correct.

Vendor your damn deps!

Quality over quantity, please

Look at Rust and NPM... Insane amounts of dependencies for almost every library.

C and C++ famously don't have package managers, well, at least not blessed ones (although you could argue Linux/Unix is a C package manager).

The idea is to be more informed about the dependencies you're bringing in, to encourage libraries to be more standalone things, and just not to automate dependency hell.

On the plus side, the Odin compiler makes it very, very easy to compile your program with dependencies.

Hell, even in my Ruby journey I've realised that 99% of what's on Rubygems is absolute trash. I basically use Rails, Faraday, RubyLLM, and not much else.

I think he would say either copy the code you want into your own project, or clone down the repo and control the code yourself.

He hae interviews on Primeagens channel and Developer Voices where he talks about it.

Is it in vendor package yet? No? Then Odin vendor package will be a bottleneck for development.

That being said it's way to early to say it "never became an issue". Odin is still small and not well established. If/when it starts to grow in popularity someone is going to develop a solution eventually. It's impossible for the language to offer EVERYTHING people could need, and developers love package managers.