The problem is that a static easily tooled language is not going to be as good as the dynamic un-toolable one without massive tooling support specifically for t

The problem is that a static easily tooled language is not going to be as good as the dynamic un-toolable one without massive tooling support specifically for that language's features. Creating those tools is not the job of a lone developer. The cost is immense. The language first has to achieve popularity to receive the tooling, or be heavily backed by a large tooling capable company (eg, Google, Jetbrains, Microsoft). So far, the only recent languages to receive the kind of required static tooling are from those 3 companies. Also note that the language did not come first in those cases - the requirement for the language came first, and a language was made to fit what was needed. However even more importantly - if you're going to create a language, it needs to be the ultimate language in your own eyes. You can't leave off novel features that you have experience in because it doesn't have mass appeal or has tooling issues. You need to create the best language you possibly can if you want to compete with others trying to create the best language. Hamstringing your enjoyment of the language by going in a direction you don't like because it has more apparently mass market appeal isn't any more likely to be successful, and it certainly isn't going to be enjoyable enough for you to slog through the tiny complexities. While there is a tiny chance that your language becomes the next big thing, it probably won't. That means you need to make the language you want to make and hope it succeeds, not make the language that 'will succeed' but you don't want to make.