I emphatically disagree about the waste of energy.
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.
> But it's definitely a wasted effort if the goal is to write a light weight chat client...
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.
There isn't enough detail on this page to really know what's unique about this language. However, I'd say in general that I don't think this area is "solved" at all, and there are a lot of open problems (or at least, problems in integrating different approaches together).
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.
Rust's procedural macros let you write Rust code that generates Rust code. In combination with tools like quote, it's just a much clunkier version of the same thing that Terra offers!
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.
“Waste of energy” is generous. It seems like a genuinely bad idea unless the problem space is poorly addressed (messaging is certainly very well-trodden territory) or the app is just a hobby.
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
Having your own language can increase productivity. The compiler took 2 weeks according to OP. Also the fast compile times definitely help. This is also a project only OP is working on so number of contributors doesn't matter, and even then it's stupidly simple to learn any C-like language if you know one already. If this works for OP then it's definitely not a waste of time really.
It is an extra ordinary feat that the OP took only couple of weeks to create a working programming language. I always thought it takes years to create a new language. It will be interesting hear from OP, how he could create a new language in couple of weeks
A programming language is a translation scheme. If you know your scheme upfront, it's trivial to translate. C-like languages are easier to translate to binaries because well, C is glorified assembly. The analysis parts may take longer, but when you start writing a language you don't need to do much analysis, especially when writing a C-like language. Parsing can be automated, and given a clean grammar like Go's it's trivial to parse
It's not about syntax. I knew that "why another language" would be a very common question, so I'll add an answer to the landing page of V's website :)
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.
I would argue that this is a niche that is underserved at the moment. There are very few powerful, fast-compiling, as-fast-as-C languages. Right now I'm aware of Nim and Zig in this space, along with Jonathan Blow's unreleased programming language Jai. I have used Nim, very briefly, for a toy project. I can say that it's really interesting and has a lot of great ideas, but it feels a little rickety. Like it's a slightly too-thin layer over C. Zig I haven't looked in to much yet. Jai isn't out yet.
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..
