C3 언어 개발자가 C를 대체하는 새 언어를 만드는 것에 반대 논거를 정리한 글입니다. 풍부한 C 툴체인 생태계, 신생 언어의 불확실성, 숙련 개발자 부족, C ABI 상호운용성 문제 등이 C 대체 언어의 현실적인 장벽입니다. 또한 '더 나은 문법'이나 '더 안전함' 같은 장점이 실제로는 과장되기 쉽다고 지적합니다.
번역된 본문
여러 사람들처럼 저도 C 언어의 대안 언어를 개발하고 있습니다 (이 블로그를 이전에 읽어보셨다면 새로운 소식은 아닐 것입니다!). 제 언어(C3)는 최근에 나왔고, Zig, Odin, Jai 같은 언어와 eC 같은 오래된 언어들도 있습니다. C++ 대안으로는 D, Rust, Nim, Crystal, Beef, Carbon 등이 있습니다. 하지만 정말 C를 대체하는 것이 가능할까요? 반대 논거들을 살펴봅시다.
C 언어 툴체인
C 언어는 언어 자체만이 아니라 그 언어를 위해 개발된 모든 개발 도구들을 포함합니다. 소스 코드에 정적 분석을 하고 싶은가요? C를 위한 많은 사람들이 그 작업을 하고 있습니다. 메모리 누수, 데이터 레이스 등 다른 버그를 탐지하는 도구들? 언어가 기본적으로 더 나은 도구를 제공하더라도 C용 도구가 훨씬 많습니다. 잘 알려지지 않은 플랫폼을 타깃으로 하고 싶다면, 아마도 C를 사용한다고 가정할 것입니다. 오늘날 컴퓨팅의 공용어(lingua franca)로서의 C의 지위 때문에 C를 위한 도구를 만드는 것이 가치 있고, 따라서 많은 도구들이 만들어지고 있습니다. 이미 툴체인이 잘 갖춰져 작동하고 있다면, 왜 언어를 바꾸는 위험을 감수할까요? '더 나은 C'는 새 툴체인을 설정하는 시간을 들일 동기를 줄 만큼 많은 생산성 향상을 가져와야 합니다. 그것이 가능하다면 말이죠.
새 언어의 불확실성
언어가 성숙해지기 전에는 버그가 있을 가능성이 높고, 언어 의미론의 문제를 해결하면서 크게 변경될 수도 있습니다. 그리고 그 언어가 정말 광고하는 대로일까요? '훌륭한 컴파일 시간'이나 'C보다 빠름' 같은 것을 제공할 수도 있지만, 언어가 모든 기능을 갖추게 되면 이런 목표는 달성하기 어렵다는 것이 밝혀지기 마련입니다. 그렇다면 유지보수자는 어떤가요? 물론 오픈소스 언어는 포크될 수 있지만, 나중에 직접 유지보수해야 할지도 모르는 언어를 사용하는 데 관심을 가진 회사는 많지 않을 것입니다. 새 언어에 베팅하는 것은 큰 위험입니다.
언어가 충분히 좋지 않을 수 있음
그 언어가 정말 C의 진짜 고질적 문제를 해결하고 있을까요? 사람들이 C의 문제점이 무엇인지에 대해 항상 동의하지는 않습니다. 메모리 할당, 배열과 문자열 처리는 종종 까다롭지만, 올바른 라이브러리와 합리적인 메모리 전략을 사용하면 최소화할 수 있습니다. 언어가 고급 사용자들이 실제로 걱정하지 않는 문제를 다루고 있다면, 그 실제 가치는 기대보다 훨씬 낮을 수 있습니다. 더 심각하게는, 언어가 C에 있는 중요한 기능을 생략한다면 어떻게 될까요? C 고급 프로그래머들이 의존하는 기능들 말입니다. 이 위험은 언어 설계자가 C를 많이 사용해보지 않고 C++, Java 등에서 넘어온 경우 커집니다.
숙련 개발자 부족
새 언어는 당연히 훨씬 적은 수의 숙련 개발자 풀을 가집니다. 중견~대기업에게 이것은 큰 문제입니다. 회사에 사용 가능한 개발자가 많을수록 회사는 좋아합니다. 또한 회사는 C 개발자 채용 경험은 있지만, 이 새 언어의 개발자를 채용하는 방법은 모릅니다.
C ABI가 상호운용성의 표준
언어가 C 코드를 쉽게 호출하거나 호출받을 수 없다면, 그 언어를 사용하는 사람은 외부 코드와 인터페이스하는 거의 모든 작업에 추가 작업을 해야 합니다. 이것은 잠재적으로 매우 큰 불리함입니다.
'더 나은 X'는 중요하지 않다
위 내용은 C 대신 다른 언어를 선택하지 않을 이유들이며, 대안 언어의 장점으로 상쇄되어야 합니다. 하지만 언어 설계자들은 자신이 추가한 '기능'의 장점이 얼마나 큰지 과대평가하는 경우가 많습니다. 흔한 '가짜 장점'들을 소개합니다.
더 나은 문법
C보다 '더 나은 문법'을 가지는 것은 대부분 주관적입니다. 다른 문법은 오히려 큰 불리함이기도 합니다. 이제 C 코드를 복사할 수 없고, 모든 줄을 다시 작성해야 할 수도 있습니다. 문법이 C보다 약간 낫다는 이유로 언어를 채택할 회사는 없습니다.
C보다 안전함
어떤 C 대안 언어든 성능 면에서 C와 대등할 것으로 기대됩니다. 문제는 C가 사실상 검사를 하지 않는다는 것이고, 경쟁 언어에 넣는 안전 검사는 런타임 비용을 발생시켜 종종 용납될 수 없다는 점입니다.
Like several others I am writing an alternative to the C language (if you read this blog before then this shouldn't be news!). My language (C3) is fairly recent, there are others: Zig, Odin, Jai and older languages like eC. Looking at C++ alternatives there are languages like D, Rust, Nim, Crystal, Beef, Carbon and others. But is it possible to replace C? Let's consider some arguments against. 1. C language toolchain The C language is not just the language itself but all the developer tools developed for the language. Do you want to do static analysis on your source code? - There are a lot of people working on that for C. Tools for detecting memory leaks, data races and other bugs? There's a lot of those, even if your language has better tooling out of the box. If you want to target some obscure platform, then likely it's assuming you're using C. The status of C as the lingua franca of today's computing makes it worthwhile to write tools for it, so there are many tools being written. If someone has a toolchain set up working, why risk it switching language? A "better C" must bring a lot of added productivity to motivate the spending time setting up a new toolchain. If it's even possible. 2. The uncertainties of a new language Before a language has matured, it's likely to have bugs and might change significantly to address problems with language semantic. And is the language even as advertised? Maybe it offers something like "great compile times" or "faster than C" – only these goals turn out to be hard to reach a the language adds the full set of features. And what about maintainers? Sure, an open source language can be forked, but I doubt many companies are interested in using a language that they further down the line might be forced to maintain. Betting on a new language is a big risk. 3. The language might just not be good enough Is the language even addressing the real pain points of C? It turns out that people don't always agree on what the pain points with C is. Memory allocation, array and string handling are often tricky, but with the right libraries and a sound memory strategy, it can be minimized. Is the language possibly addressing problems that advanced users don't really worry about – if so then its actual value might be much lower than expected. And worse, what if the language omits crucial features that are present in C? Features that C advanced programmers rely on? This risk is increased if the language designer hasn't used C a great deal but comes from C++, Java etc. 4. No experienced developers A new language will naturally have a much smaller pool of experienced developers. For any middle to large company that's a huge problem. The more developers there are available for a company, the better they like it. Also, while the company has experience recruiting for C developers, it doesn't know how to recruit for this new language. 5. The C ABI is the standard for interoperability If the language can't easily call – or be called - by C code, then anyone using the language will have to have to do extra work to do pretty much anything that is interfacing with outside code. This is potentially a huge disadvantage. "Better X" doesn't matter So those are some of the downsides to not picking C, to be offset by the advantages of picking the alternative. However, often language designers over-estimate what how big advantages their added "features" bring. Here are some common "false advantages" 1. Better syntax Having a "better syntax" than C is mostly subjective. Different syntax is also a huge disadvantage: now you can't copy code from C, you might have to rewrite every single line even. No company will adopt a language because it has slightly better syntax than C. 2. Safer than C Any C alternative will be expected to be on par with C in performance. The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable. This leads to a strategy of only having checks in "safe" mode. Where the "fast" mode is just as "unsafe" as C. There are some exceptions: "foreach" avoids manually adding boundary checks and so will automatically be safer. Similarly slices helps in writing checks compared to "pointer + len" (or worse: null terminated arrays). 3. Programmer productivity First of all, pretty much all languages ever will make vacuous claims of "higher programmer productivity". The problem is that for a business this usually doesn't matter. Why? Because the actual programming is not the main time sink. In a business, what takes time is to actually figure out what the task really is. So something like a 10% or 20% "productivity boost" won't even register. A 100% increase in productivity might show, but even that isn't guaranteed. What matters? So if these don't matter, what does? For a business it's whether despite the downsides the language can help the bottom line: "Is this valuable 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 was released it offered the following features that most of the competing languages couldn't give you: OO done cleanly (OO was hot at the time) Threading out of the box (uncommon at the time) "Write once run anywhere" "Run your code in the browser" Garbage collection built in Network programming Good standard library Free to use That's not just one but eight(!) killer features. How many of those unique selling points do the C alternatives have? Less than Java did at least! The next killing feature So my argument is that a common way languages gets adoption by being the only language in order to use something: Dart for using Flutter, JS for scripting the browser, Java for applets, ObjC for Mac and iOS apps. Even if those monopolies disappear over time, it gives the language become known and used. Similarly there are examples where frameworks have been popular enough to boost languages, Ruby and Python are good examples. So looking at our example languages, Jai's strategy of bundling a game engine seems good: anyone using it will have to learn Jai, so if the engine is good enough people will learn the language too. But aside from Jai, is anyone C alternative really looking to pursue having killer features? And if it doesn't have one, how does it prove the switch from C is worth it? It can't. Conclusion The "build it and they will come" idea is tempting to believe in, but there is frankly little reason to drop C unless the alternative has important unique features an/or products that C can't hope to match. While popularity and enthusiasm is helpful, it cannot replace proven value. In the end, all that matters is whether using a language can produce more tangible value to developers than C for at least a large subset of what C is used for. While developers may be excited by new languages, that enthusiasm doesn't translate to business value. So no matter how exciting that C alternative may look, it probably will fail.