4 ms·

The language looks ok. If they are going for world domination a more likely path seems to be evolving C very slowly. That is they should start from C and then e

by jon6 15y ago

The language looks ok. If they are going for world domination a more likely path seems to be evolving C very slowly. That is they should start from C and then every few years add a few new features and take out some old crummy features until they finally reach Rust. Lots of people probably don't like rewriting code bases wholesale and new languages take a while to become trusted.

aaronblohowiak 15y ago
> and take out some old crummy features Backwards-compatibility is held extremely dear to the C community, with those few breaking changes being simple (usually) to work around. If you want to break compatibility, you have a better chance calling it a new language.
- jon6 15y ago
  Thats true, but new modes can be added with switches similar to how gcc has -std=c89, -std=c99 and whatnot. Newer modes could disable old features and people could upgrade at will.
  - rcfox 15y ago
    Except that there's no business case for rewriting old code that still works and is still supported by the compiler. And then suddenly, the compiler team has to support multiple, very different versions in the same release.
  - roel_v 15y ago
    With 10 years between each such 'mode', and the differences still being relatively minute, it would take centuries to morph C into something else. Which is a good thing, don't get me wrong. It just shows that the proposed approach isn't feasible.
enneff 15y ago
How can you build trust in a language that changes all the time?
- riffraff 15y ago
  as a point of thought: you could have a language where you introduce small changes incrementally, and a tool like go's gofix that is builtin and goes over an existing code base updating stuff that is obsolete. The current approaches of "leave the things substantiatlly unchanged" and "release a bunch of changes all together" have not exactly been proven "the best".

by jon6 15y ago

aaronblohowiak 15y ago

> and take out some old crummy features Backwards-compatibility is held extremely dear to the C community, with those few breaking changes being simple (usually) to work around. If you want to break compatibility, you have a better chance calling it a new language.

jon6 15y ago
Thats true, but new modes can be added with switches similar to how gcc has -std=c89, -std=c99 and whatnot. Newer modes could disable old features and people could upgrade at will.
- rcfox 15y ago
  Except that there's no business case for rewriting old code that still works and is still supported by the compiler. And then suddenly, the compiler team has to support multiple, very different versions in the same release.
- roel_v 15y ago
  With 10 years between each such 'mode', and the differences still being relatively minute, it would take centuries to morph C into something else. Which is a good thing, don't get me wrong. It just shows that the proposed approach isn't feasible.

enneff 15y ago

How can you build trust in a language that changes all the time?

riffraff 15y ago
as a point of thought: you could have a language where you introduce small changes incrementally, and a tool like go's gofix that is builtin and goes over an existing code base updating stuff that is obsolete. The current approaches of "leave the things substantiatlly unchanged" and "release a bunch of changes all together" have not exactly been proven "the best".