"support and development just stops as all the ADD kids jump at the new toy"
We'll assume you means support and development of the language specification/Compilers/IDEs/etc.
Agreed that if there's not a solid backing either through a large community or major corporations, then yeh you'd be an idiot to invest production code in a a language that might not have longevity. This is not a risk unique to high level languages. This is a risk with any language that doesn't have a mature and committed community or corporation supporting it.
""five years down the road someone will fork the fork and you can throw all your code away"
I would be interested in examples of major languages that went this way, and why code had to be wholesale thrown away?
Let's assume by fork, you mean forking the language specification and/or compiler. Someone forking shouldn't cause you to need to throw away code. You would only have to throw your code away if the new fork became so popular that maintainers of the upstream decided to abandon their language and maintain the fork, AND you were of the opinion that the old upstream compiler/specification was not matured enough for you to stick with it.
Even if you switched to the forked compiler, I can only imagine a childish tantrum resulting in someone throwing away their code over some compiler errors that required minor syntax changes. You sound just like that type of person. If anything usually some clever regex will solve this problem. Although I agree, it's a good sign you were an idiot for choosing a language supported by those who do not value backward compatibility, and/or you invested production code into a language that was still in early development when backwards compatibility is usually not a primary goal.
These are attributes of niche languages. There are some low level languages that have been created as experiments, proof-of-concept, etc. that suffer from the same issues. C-- was a lowlevel languages created to try and implement common compiler algorithms for reuse, which is now dead. Ambitious little projects without enough of an audience to gain traction, and eventually the maintainer's time is directed elsewhere and it dies(the language, not the maintainer).
Those are attributes of niche languages, not of high level languages.
"That'll never happen with your C code."
You've not been around very long OR you've never tried to leverage some really old C code and had to fix hundred of compiler errors to get it up to speed. Now usually that's more of an issue with the code not being written to be very portable, but there's nothing inherent about C that makes it any more immune to the portability issues that high level languages suffer from when bad programmers get their fingers in there. Code that compiled fine 10 years ago often won't compile anymore if it's not been maintained, because the more common compiler options are vastly different. You've not been around the block if you've had to maintain someone's really old code and had your compile seg fault the first attempt to compile it.
In fact, I'd say writing portable code requires alot more skill in C because you're at such a low level and have to be much more knowledgeable of things that higher level languages hide from you. It probably makes you a better programmer for it, but that's about like saying beating yourself with a stick makes you tougher.
Anyway, there's lots of reasons people invent new languages. Some of them are doing it just for fun, and never intended them for production use. Proof of concepts, etc. Writing a compiler is a great learning experience.
There's nothing to be sickened by. It's not like there is some street peddler trying to get you to use some esoteric language. There might be a few misguided fools who are all excited about some language and pushing it for production use where it is inappropriate, but someone's misplaced zeal is usually no fault of the language or language designers.