There are other languages which compile to C. There are languages with good C interop – some of these are just as small. There are languages with good safety mechanisms, some of which don't even use a garbage collector. Not sure why none of the existing languages would fit the bill.
You do not need to always do novel work, and not every piece of code has to be in support of some specific engineering goal with external justification. I don't consider gardening a waste of energy, even if I can get groceries at the store more efficiently. I don't consider painting a waste of time, even if my paintings are bad compared to others.
Let people retread well-known paths.
But it's definitely a wasted effort if the goal is to write a light weight chat client...
Implementing something, disliking the tools we use and deciding to implement our own... I think we've all been there.
But a language takes years of work by dedicated people to reach any level of maturity.
That’s vacuously true, because there are always more goals besides just writing a light-weight chat client.
I find most of what I do is balance different goals, objectives, and concerns against each other. Even if you only have external business objectives, you at least consider both the short-term and long-term.
Consider that there are multiple languages that have evolved in this space recently, all of which take slightly different approaches and make different tradeoffs. I personally know of at least: Nim, Rust, Terra, Zig. There are probably others.
(Edit: This isn't quite right: these don't all compile to C. But they're all low-level and make tradeoffs which are similar to C.)
You can say, "well all of these already exist so why not join up with an existing effort instead of creating a new one?" Except that languages make tradeoffs that fundamentally impact other objectives. For example, Rust has already made tradeoffs which make it seem unlikely that it will ever get Terra-style metaprogramming (at least to the full extent to which Terra supports it). And that might be fine for many of the things you'd want to do with Rust. But I at least have things I'd like to do that benefit strongly from Terra-style metaprogramming, and I might like to have something that combines the advantages of both. Right now that thing doesn't exist, and it's not obvious if you could ever get there in a reasonable way from either Rust or Terra by taking one or the other and trying to build to the other side. Thus, I don't find the approach of starting over from scratch unreasonable at all.
https://internals.rust-lang.org/t/rust-2019-towards-richer-l...
In short, the biggest difference is that Terra makes it very easy to interact with the compiler at every level: I can insert new keywords, and incrementally type check pieces of code to see (a) if they compile and (b) what types they produce. This makes it surprisingly easy to build really powerful tools like Regent [1]. While if you read through the rest of the thread, it does sound like it's possible to do this in Rust, it will be very painful, at least today. In particular, it would require either (a) calling out to rustc as an external program, which would probably be very slow, (b) rebuilding the parts of rustc in the DSL compiler, which realistically isn't going to happen, (c) directly hacking on rustc, which is a lot of work and would result in a hard fork to the language, or (d) radically simplifying the DSL compared to what Rust provides, which I think would be counterproductive. So, without a lot more work I think this is a no-go for the moment. But I'm eager to see if the Rust team can come up with something better, since I like Rust in many other ways and it would be great to see Rust grow a capability like this.
Using a new language makes a single project into two projects, at least one of which is huge.
Among the many benefits of an existing language with a mature ecosystem:
- fewer bugs
- more than one person can contribute without learning a new language
- extensive tooling
- long term language support
How many useful projects never have more than one developer?
What is more likely to boost productivity: good tooling (including incremental compilation) or custom-tailored syntax?
Syntax is important, but obsession about syntax (to the point of rejecting hundreds of existing languages) is bikeshedding.
Basically none of the existing languages have the features that I need:
1) Compilation speed. V compiles 15 million lines of code per second. Only Go and Delphi are relatively fast.
2) Simplicity & maintainability. Only Go is simple. I made V even simpler and stricter.
3) No runtime/GC. I want the language to be close to metal so that it can be used to develop small and fast native apps, games, drivers, etc. Go's out.
4) Safety. Go has nil (runtime errors), no option types (verbose error checks and unhandled errors), data races, global variables.
5) Easy interop with C. Cgo ads a lot of overhead.
There are other languages that are slightly further from this niche which might serve. Go is not very powerful, lacks generics, is garbage collected. Rust . . . I don't know. Turned off by the fact it's so hard to write a linked list in it (I know that's very superficial but it is what it is). It also doesn't compile very fast from what I read.
I think this is a great space for new ideas. The successor to C is still quite unsettled, I think, and there's space for motivated people to have an impact..