free counter

The case against an alternative solution to C

Like several others I’m writing an alternative solution to the C language (in the event that you read this website before then this must not be news!). My language (C3) is rather recent, there are certainly others: Zig, Odin, Jai and older languages like eC. Considering C++ alternatives you can find languages like D, Rust, Nim, Crystal, Beef, Carbon among others.

But can you really replace C? Consider some arguments against.

1. C language toolchain

The C language isn’t just the language itself but all of the developer tools developed for the language. Do you wish to do static analysis on your own source code? – There are a great number of people focusing on that for C. Tools for detecting memory leaks, data races along with other bugs? There’s lots of those, even though your language has better tooling out from the box.

In order to target some obscure platform, then likely it’s assuming you’re using C.

The status of C because the lingua franca of today’s computing helps it be worthwhile to create tools for this, so there are various tools being written.

If someone includes a toolchain setup working, why risk it switching language? A “better C” must bring plenty of added productivity to motivate the hanging out setting up a fresh toolchain. Whether it’s even possible.

2. The uncertainties of a fresh language

Before a language has matured, it’s more likely to have bugs and may change significantly to handle issues with language semantic. And may be the language even while advertised? Maybe it includes something similar to “great compile times” or “faster than C” only these goals grow to be hard to attain a the language adds the entire group of features.

And think about maintainers? Sure, an open source language could be forked, but I doubt many companies want in utilizing a language they further down the road may be forced to keep up.

Betting on a fresh language is really a big risk.

3. The language could not be sufficient

May be the language even addressing the true pain points of C? As it happens that folks don’t always acknowledge what the pain points with C is. Memory allocation, array and string handling tend to be tricky, but with the proper libraries and an audio memory strategy, it could be minimized. May be the language possibly addressing issues that advanced users don’t really be worried about if that’s the case then its actual value may be lower than expected.

And worse, imagine if the language omits crucial features which are within C? Features that C advanced programmers depend on? This risk is increased if the language designer hasn’t used C a good deal but originates from C++, Java etc.

4. No experienced developers

A fresh language will naturally have a much smaller pool of experienced developers. For just about any middle to large company that is clearly a huge problem. The more developers you can find available for an organization, the higher they enjoy it.

Also, as the company has experience recruiting for C developers, it generally does not learn how to recruit because of this new language.

5. The C ABI may be the standard for interoperability

If the language can’t easily call or be called – by C code, then anyone utilizing the language will need to want to do extra work to accomplish virtually whatever is interfacing with outside code. That is potentially an enormous disadvantage.

So those are a number of the downsides never to picking C, to be offset by the benefits of picking the choice. However, often language designers over-estimate what what size advantages their added “features” bring. Here are a few common “false advantages”

1. Better syntax

Having a “better syntax” than C is mainly subjective. Different syntax can be an enormous disadvantage: now you can’t copy code from C, you may have to rewrite each and every line even. No enterprise will adopt a language since it has slightly better syntax than C.

2. Safer than C

Any C alternative will undoubtedly be likely to be on par with C in performance. The thing is that C have practically no checks, so any safety checks placed into the competing language could have a runtime cost, which frequently is unacceptable. This results in a technique of only having checks in “safe” mode. Where in fact the “fast” mode is simply as “unsafe” as C.

There are several exceptions: “foreach” avoids manually adding boundary checks therefore will automatically be safer. Similarly slices helps on paper checks in comparison to “pointer + len” (or worse: null terminated arrays).

3. Programmer productivity

To begin with, virtually all languages ever can make vacuous claims of “higher programmer productivity”. The thing is that for a small business this usually doesn’t matter. Why? As the actual programming isn’t the primary time sink. In a small business, what does take time would be to actually find out what the duty really is. So something similar to a 10% or 20% “productivity boost” won’t even register. A 100% upsurge in productivity might show, but even that’s not guaranteed.

So if these don’t matter, what does? For a small business it’s whether regardless of the downsides the language might help underneath line: “Is this specific enough to outweigh the downsides?”

But if “better x” doesn’t help – what does? Well… “killer features”: having unique selling points that C can’t match.

Look at Java, when it had been released it offered the next features that a lot of of the competing languages couldn’t offer you:

  • OO done cleanly (OO was hot at that time)
  • Threading from the box (uncommon at that time)
  • “Write once run anywhere”
  • “Run your code in the browser”
  • Garbage collection built-in
  • Network programming
  • Good standard library
  • Absolve to use

That isn’t just one single but eight(!) killer features. Just how many of these unique selling points do the C alternatives have? Significantly less than Java did at the very least!

So my argument is a common way languages gets adoption when you are the only language to be able to use something: Dart for using Flutter, JS for scripting the browser, Java for applets, ObjC for Mac and iOS apps.

Even though those monopolies disappear as time passes, it offers the language become known and used.

Similarly you can find examples where frameworks have already been popular enough to improve languages, Ruby and Python are cases.

So considering our example languages, Jai’s strategy of bundling a casino game engine seems good: anyone deploying it will need to learn Jai, so if the engine is sufficient people will learn the language too.

But apart from Jai, is anyone C alternative really seeking to pursue having killer features? And when it generally does not have one, so how exactly does it prove the switch from C will probably be worth it? It can’t.

The “build it and they’ll come” idea is tempting to trust in, but there’s frankly little reason to drop C unless the choice has important unique features an/or products that C can’t desire to match.

While popularity and enthusiasm is effective, it cannot replace proven value. Ultimately, all that counts is whether utilizing a language can produce more tangible value to developers than C for at the very least a big subset of what C can be used for. While developers could be excited by new languages, that enthusiasm doesn’t translate to business value.

So regardless of how exciting that C alternative may look, it will probably fail.

Read More

Related Articles

Leave a Reply

Your email address will not be published.

Back to top button

Adblock Detected

Please consider supporting us by disabling your ad blocker