Not exactly what I would call C-like in that it does a whole lot more. It is C-like in the way many popular languages are, that the syntax resembles C but that superficial similarity isn't really worth noting. It may be good marketing to get people to look at a new language though.
> Language is type-safe and memory-safe.
> nullc library can execute code on a VM or translate it to x86 code for fast execution. It can also translate nullc files into C source files.
But sadly, although the project has been around for 11 years, development seems to have stalled since last year, at least going by GitHub activity.
Out here in the wild west of programming languages though, questions like "can I use this for anything real" aren't really material. Of course you can't, and the irregularity of the developer is just one reason out of many. Nonetheless, people find themselves drawn to these languages because they can actually offer something those top 50-100 languages can't -- fresh takes on programming language design and philosophy. True, we may never build anything more than a toy in these smaller niche languages, but still we can bring the insights gained back to our development practices in those top 50 languages.
This is just a terrible metric of software quality that became standard without anyone discussing why.
Today, a new language has a small window of a few years, after which it either achieves escape velocity, or re-enters the atmosphere and burns up. A new language which hasn't received major updates for two years, is effectively dead. It's a social phenomenon, not a technical one.
Why does it need to be discussed? Not actively maintained says it is either "done" or abandoned.
It is also a (weak) proxy for popularity, meaning if I do run into an issue an active repo means I am more likely to get help.
A quick glance at the git repo shows that it has builds set up on travis that are failing, and an unanswered question in the issue tracker. Neither of these inspire confidence that it will "work great"
I think Go took the right approach with calling those bugs to be avoided rather than features to be implemented.
Don't be clever. Be understandable to most readers.
If you make a function called add which actually subtracts, why is that any different to an operator overload?
Quickly onboarding novices is only helpful for throwaway work or teams with retention problems. Their work inherently needs more scrutiny until they become experts.
I say that as a member of a team whose median tenure (three years ten months) is short enough to concern me a little.
Based on my experience those projects are 99% of all projects in commercial organizations. So, emphatically no.
I accidentally replied to yours. I had intended to reply to preseinger.
The former is in general preferable to the latter, though, because it makes it a little more clear that arbitrary computation is occurring.
The whole attitude (and the Go programming language) is maybe downstream from the fact that perf/promo criteria punish people who maintain the software they write.
I'm not gatekeeping apples by saying a grape is not an apple, I'm debating how to classify these things.
Jokes aside, I might have a look at it over weekend, it would be nice to see some PR materials on their git repo. Why should one use it over C/Rust etc.