해시넷
D 언어
D 언어는 2001년 12월에 처음 발표된 후, 2007년 1월에 정식 발표된 컴파일 언어이자 멀티 패러다임 프로그래밍 언어이다. C++이 본래 C 언어를 대체하기 위한 언어로 출발했듯이 D 언어는 C++을 대체하기 위한 목적으로 출발한 언어이다.
개요
D는 디지털 마스의 월터 브라이트가 개발한 객체 지향 명령형 프로그래밍 언어이다. 2001년 공개되었다. C++의 리엔지니어링으로 기원하였으나 D는 해당 언어와는 별개의 언어이다. 일부 핵심 C++ 기능들을 다시 설계하였으며 자바, 파이썬, 루비, C#, 에펠과 같은 다른 언어들의 특징들을 공유하기도 한다. 이 언어의 설계 목적은 현대의 동적 언어의 표현 능력을 가지고 컴파일 언어의 성능과 안전의 병합을 시도하는 것이다. 관용적인 D 코드는 동등한 C++ 코드보다 크기가 짧더라도 C++만큼 속도가 빠른 것이 보통이다. 이 언어는 전반적으로 메모리 안전에 속하지 않으나 메모리 안전을 검사하도록 설계된 선택적 속성을 포함한다.[1]
역사
- D 1.0
최초의 네이티브 C++ 컴파일러였던 Zortech C++(Symantec C++이 되었다가 현재는 DMC++이 됨)의 메인 개발자였던 월터 브라이트는 C++의 복잡도를 줄이고 현대적인 언어 개념들을 포함한 언어를 만들기로 했고 1999년부터 작업을 시작해 2001년 12월 8일에 첫 번째 버전를 발표한다. 처음에는 Mars 언어라고 이름붙였지만 그의 동료 중 한명이 계속 D라고 부르면서 D로 이름을 바꾸게 되었다는 사연이 있다. 버전업이 매우 느렸기 때문에 D 1.0 버전이 발표된 건 2007년 1월 2일이 되어서였다. 범용 시스템 프로그래밍 언어인 C++을 대체하는 것을 목적으로 만들어졌으므로 C++과 같이 기계어 컴파일이 되는 언어였으며 Python, Java, C# 등 현대화된 메이저 언어들의 영향을 많이 받았다. 그러면서도 최근의 현대 언어들과 같이 인터프리터나 가상머신으로 실행되는 구조가 아니었으므로 퍼포먼스 지향적이어서 처음에는 많은 기대를 받았다. D는 표준 런타임 라이브러리로서 Phobos가 존재했지만 D 커뮤니티는 Phobos 라이브러리의 느린 발전 속도에 만족하지 못했다. 언어와 개발 환경의 느린 발전 속도는 D언어가 원래 오픈소스가 아니고 Digital Mars에 카피라이트가 있고 상용 언어를 목표로 했기 때문이었다. D 사용자 커뮤니티는 Phobos와는 별도로 오픈소스로서 존재하는 런타임 라이브러리를 만들기로 했고 Tango 라이브러리가 발표되었다. Tango는 Phobos보다 다양한 기능을 제공했으며 커뮤니티가 참여해서 만들어졌기 때문에 발전 속도가 빨랐다. D언어에 관한 책은 거의 없지만 D programming with Tango라는 입문서가 출판될 정도였다. 그러나 이런 상황은 커뮤니티 자체를 분열시키는 결과를 낳았고 언어 자체의 발전속도를 저하시키고 인터넷상의 정보를 파편화시켜 D 언어를 지탱한 표준 런타임 라이브러리가 분열되고 말았다. 이 때문에 정보가 많지도 않은 상황에서 입문자들은 전혀 다른 스타일의 런타임 라이브러리에 혼란을 겪어야 했다. 비슷한 상황을 맞은 Python을 보면 구글이 창시자를 영입하고 재단을 출범해 로드맵을 조정하는 것과 대조적이었다. 결국, 월터 브라이트는 D 1.0이 실패라고 판단하고 언어 자체를 재설계하기로 결정했다. D의 행보에 실망한 커뮤니티는 대부분 흩어지고, 초반에 받았던 세간의 관심으로부터도 멀어졌다.
- D 2.0
D 2.0 버전을 줄여서 D2로 알려진 것이 바로 현재의 D언어를 가리킨다. C++ 구루 중 한명이며 Modern C++ Design이라는 책에서 템플릿 메타프로그래밍에 기반한 정책기반 설계라는 개념을 정립한 것으로 널리 알려진 안드레이 알렉산드레스쿠(Andrei Alexandrescu)가 D2 프로젝트에 공동설계자로서 합류하게 된다. 그가 합류하면서 D는 메타프로그래밍 언어로서의 성향이 매우 강해졌으며 관련된 언어 상 기능들이 다수 추가되었다. 2007년 6월 17일에 정식 발표되면서 D2를 D2라고 불리지 않으며 그냥 D라고 부른다. 1.0 버전으로 발표된지 5개월밖에 안 된 기존의 D언어는 바로 버려진 것은 아니고 꾸준히 버전업되면서 버그 수정(안정화 작업) 정도로만 유지되었다가 2012년 12월 31일에 발표된 1.076 버전을 마지막으로 지원 중단되었다. 현재의 D언어인 2.0 버전은 오픈소스 프로젝트로서 GitHub에 전체 프로젝트가 공개되어 있으며 커뮤니티가 활발하게 기여를 하고 있다. 핵심 개발자인 안드레이 알렉산드레스쿠는 현재 페이스북에서 연구자로 소속되어 있으며 페이스북 내에서 D를 사용한 프로젝트를 진행하고 있다고 한다. 페이스북은 주로 HHVM을 사용하고 있는데 구글 내에서 Python이 그랬던 것처럼 메이저 IT 회사 중 하나인 페이스북 내에서 어느정도의 입지를 가지게 되느냐에 따라 향후 D의 운명이 결정될 가능성이 크다. 그러나 알렉산드레스쿠는 D 언어 재단에 더 힘을 쏟기 위해 페이스북을 그만두었다. 본인도 많은 고민 끝에 내린 결정이라고 한다.[2]
특징
고수준 모델링 지원을 위한 기반을 제공한다. 실행 전 컴파일을 미리 해둬야하는 언어이며, 높은 성능을 보여준다. 정적 타입(static typing) 특성을 갖는다. 모든 타입은 컴파일 시점 전에 결정된다. 예를 들어, 값을 반환하는 함수 등에서 어떤 타입을 반환하는지 명확히 알 수 있다. 운영체제와 하드웨어가 제공하는 API를 직접 제어할 수 있다. 컴파일에 드는 소요시간이 짧다. 메모리 안전을 보장하는 제한된 D 언어 환경을 제공합니다.(Safe D) 프로그램 유지 및 보수에 편리하며, 이해하는데 어려움이 없는 코드를 작성할 수 있다. 갑자기 어려워지는 부분 없이, 일정한 코딩 난이도 상승 속에서 배워 갈 수 있는 언어이다.(C나 Java와 비슷한 문법 구조) C 응용 프로그램/라이브러리와의 호환성을 갖는다. C++ 응용 프로그램/라이브러리와의 제한적 호환성을 갖는다. 다양한 프로그래밍 패러다임을 포함하고 있다.(명령형, 구조형, 객체지향, 제너릭, 함수형 프로그래밍, 어셈블리) 언어에 내장된 오류 탐지 기능이 있다.(Contracts, 유닛 테스트)[3]
종류
- DMD
Digital Mars D compiler의 약자이며 D언어 재단에서 공식적으로 유지보수&배포 중인 레퍼런스 컴파일러이다. 기존에는 C++로 구현되었으나 2015년 11월 3일에 2.069.0 버전부터 프론트엔드를, 뒤이어 2018년 11월 11일에 백엔드를 D로 구현하는 데 성공했다. (소스코드 참조) D언어로 DMD를 작성했다는 뜻에서 DDMD라 부르기도 한다. D언어 재단에서 제공하는 표준 레퍼런스 컴파일러다. 빌드 속도는 GDC와 LDC보다 빠르다. 빌드한 결과물의 퍼포먼스는 GDC나 LDC에 비해 떨어진다. 윈도우, 리눅스, 맥 모두 지원하며, 윈도우에서 설치하는게 제일 쉽다.
- GDC
이름에서 추측할 수 있듯이 GCC 기반의 D 컴파일러이다. 예전에는 DMD의 심각한 성능 문제나 디버깅의 어려움 때문에 커뮤니티에서는 DMD 버리고 GDC를 쓰라는 말이 나오기도 했었지만 꾸준한 DMD의 성능개선으로 모두 옛날 이야기가 됐다. 하지만 2017년을 기준으로 GCC가 D를 공식으로 포함했기 때문에 그대로 GCC를 쓸 수 있게 되었다. 버전 릴리즈는 가장 느리다. 빌드 속도는 DMD와 비슷하다.
- LDC
LLVM를 기반으로 둔 D 컴파일러이다. DMD 컴파일러가 Android와 iOS환경에 대한 공식적인 지원이 없는데 비해 상대적으로 모바일 환경에 대한 지원이 활성화 되어 있다. 1.18버전부터 Android용 컴파일러 바이너리를, 1.20버전부터 iOS(tvOS·watchOS 포함)를 위한 codegen을 제공하기 시작했다. 그 외에도 D 커뮤니티 내 몇몇 능력자들의 포크(fork)나 사이드 프로젝트를 통한 기여가 많은 편이다. C++ 라이브러리를 바인딩 코드 없이 그대로 가져와 쓸 수 있는 LDC 컴파일러(Calypso)나 웹어셈블리어플리케이션 개발을 위한 라이브러리 등이 존재한다.
- DUB
DUB은 D언어를 위한 빌드 프로그램이다. 단순히 프로젝트 빌드 뿐만 아니라 code.dlang.org에 게시된 제3자 라이브러리를 가져와 쓸 수 있도록 패키지 매니저의 역할(Python의 Pypi, Lua의 LuaRocks 같은 셈이다.)도 하며 DMD, GDC, LDC로의 선택이나 플래그도 dub.json 또는 dub.sdl 파일(프로젝트 설정파일)을 통해 쉽게 작성할 수 있다. 원래 DUB은 D언어 재단에서 공식적으로 개발하는 소프트웨어가 아니다. DUB역시 Vibe.d[7] 프로젝트의 커뮤니티로부터 공존해오고 있는 프로젝트이지만 사실상 D언어로 스크립트 수준의 작은 프로그램이 아니라 외부 라이브러리, 이를테면 바인딩이나 3th Party library를 쓸 일이 생긴다면 DUB은 필수이다. D 유저들 사이에서는 암묵적인 표준 소프트웨어나 다름없는 셈. 이미 D언어 재단에서도 공식적으로(official) 밀어주는 모습을 보여준다. 얼마 전까지만 해도 DUB은 Vibe커뮤니티 사이에서 따로 배포되어 왔었으나 Rust 컴파일러 패키지에 Cargo가 기본적으로 포함되어 있는 것을 D 유저들이 의식하고 DMD 컴파일러 패키지에도 DUB을 포함하자는 의견이 있었다. 현재 2.72.x버전 부터 포함되어 함께 배포되고 있다.
활용
- 헬로 월드 프로그램
import std.stdio;
int main(string args[])
{
- writeln("안녕. D Programming Language!");
- return 0;
}
- 예제2
다음 예제는 콘솔에 명령행 인자를 출력한다.
[1]import std.stdio: writefln;
void main(string[] args)
{
- foreach (i, arg; args)
- writefln("args[%d] ＝ '%s'", i, arg);
}
문제점
C++을 대체하기 위한 D언어가 쓰레기 수집기(GC)를 내장함으로서 발생하는 성능적인 비용 때문에 게임과 같이 빠른 연산이 필요한 곳, 특히 60FPS을 목표로 렌더링 해야 하는 고사양 게임 개발에 사용하기에는 부적합하다는 의견이 중론이다. 물론 @nogc로 쓰레기 수집기의 싸이클을 어느 정도는 회피할 수 있다고는 하지만 언어적 차원에서 지원되는 기능이라 GC를 사용하지 않았을 때의 제약점이 생긴다. 그래서 GC를 싫어하는 D 사용자들은 아에 D의 런타임(druntim)에 의존하지 않고 D 그 자체로 직접 메모리를 다뤄 C, C++처럼 쓰는 경우도 종종 보인다. 하지만 C, C++처럼 다루어야 한다는 제약 조건 자체가 D의 치명적인 약점인데, GC 기반의 고성능 언어가 기존에 이미 많이 있었고 (Java, C# 등) GC로 커버가 가능한 분야에서는 이미 성공적으로 C++를 대체하고 있었다. 그래서 C++에 남은 코드들은 GC로는 도저히 커버 불가능한 경우일 뿐이었는데, D가 GC를 요구하면서 이 사용자들에게 외면받았기 때문이다. GC로 커버 가능한 코드들은 이미 다른 언어로 옮겨갔으므로 그쪽에서도 사용자들을 끌어올 수 없었고, 이것은 D를 그대로 묻어버린 결정적인 실책이 된다. 그 후에 D는 실책을 깨닫고 *GC 없이 동작하는 모드*를 제공했으나, 문제는 이렇게 하면 표준 라이브러리인 druntim을 사용할 수 없고 표준 라이브러리에 의존하는 모든 다른 라이브러리 또한 사용할 수 없는 상황이 되는데다 결정적으로 이 모드에서는 메모리 안전성을 포기해야 했다. 그럴 경우 C++와 별로 달라지는게 없다는 평가가 이루어지기에 이 모드도 실패도 끝났다. 나중에 이 모드에서 작동 가능한 표준 라이브러리를 제공하기는 했으나 안전성까지 보완된 것은 아니라서, GC를 완전 배제하면서도 안전성을 제공하고 C++의 거의 모든 문제를 실제로 해결한 Rust가 뜨기 시작하자 최종적으로 사용되지 않게 된다.[2]
C/C++와 비교
- - C/C++ 로부터 유지되는 기능들
일반적인 외형은 C 나 C++ 과 비슷하다. 이것은 D언어를 학습, 포팅하는것을 쉽게만든다. C/C++ 로 부터 D언어로의 전환은 편안하게 느껴질것이다. 프로그래머는 이를 위해서 모든것을 새로운 방식으로 배울 필요는 없다. D언어를 사용한다는것은 프로그래머가 자바나 스몰토크의 vm(virtual machine) 처럼 특정 런타임 vm 에 제한적이게 된다는 의미가 아니다. D 언에에는 vm이 없다.링크가능한 오브젝트 파일을 직접 컴파일러가 생성한다. C언어에서처럼 D언어도 운영체계에 연결한다. 일반적으로 make 같이 친숙한 툴들이 D언어 개발에도 적합할 것이다.
- 일반적인 외양, 느낌은 C/C++것을 유지하였다. C/C++의 그것과 표현양식, 외양이 거의 동일하다.
- D 프로그램은 C 스타일(함수와 데이터), C++ 객체지향스타일, C++ 템플릿 메타프로그래밍, 혹은 3가지의 조합으로도 사용할수있다.
- 바이트코드로 컴파일되고 해석되어지는것을 배제한것은 아니지만, compile/link/debug 개발모델이 유지되었다,
- 예외처리
- 많은 경험에 의해서 예외처리가 C 에서 전통적으로 error 코드와 errno 전역변수들로 에러를 처리하는것보다 우월한 방법이 될것이다.
- RTTI(Runtime Type Identification)
- 이것은 일부 C++에 구현되었다. D언어에서는 완전하게 지원하며, 향상된 가비지 컬렉션, 디버거 지원, 보다 자동화된 persistence 등등을 지원하고있다.
- D 언어는 C언어의 함수 호출 규약과 호환성을 유지한다. 이것은 D 프로그램이 운영체계의 API에 직접 접근할수있게 해준다. 기존 API에 대한 프로그래머의 지식과 경험, 패러다임은 최소한의 노력으로 D 언어에 적용가능하다.
- 연산자 오버로딩
D 프로그램은 연산자 오버로딩이 가능하고, 이로 인해서 기본 데이터 타잎을 사용자 정의 타잎으로 확장가능하다.
- 템플릿 메타프로그래밍
- 템플릿은 제네릭 프로그래밍을 구현하기위한 한 방법이다. 다른 방법중에는 매크로를 사용하거나, variant 데이터 타잎 사용등이 있다. 매크로의 사용은 고려대상이 아니다. Variants의 사용은 수월하기는 하지만, 비효울적이고 형식 체크에 부족하다. C++템플릿의 어려움은, 그 복잡성에 있다. 그것은 언어의 문법과 잘 어울리지 않는다. D언어에서는 conversions 과
overloading을 위한 모든 다양한 규칙들이 갖추어져있다. D언어는 템플릿을 하는데있어서 훨씬 간단한 방법을 제공한다.
- RAII (Resource Acquisition Is Initialization)
- RAII 기법은 신뢰성있는 소프트웨어를 개발하기 위한 필수요소이다.
- Down and dirty programming
- D언어는 다른 언어로 컴파일된 외부 모듈의 도움 없이도, down-and-dirty programming
(저수준의 어려운 프로그래밍을 말하는것같다.)을 할수있다. 때때로, 시스템 작업을 위해서 포인터를 써야만 하거나, 어셈블리를 이용할 필요가 있다. D언어의 목적은 down and dirty programming 을 못하게 하는것이 아니라, 일상적인 코딩 업무를 해결하는데 있어서 그 필요성을 최소화 시키는데 있다.
- C/C++ 로부터 제거된 기능들
- C 소스와의 호환성
- C언어 확장으로 소스코드의 호환성을 유지하려는 것은 이미 진행되어져 왔다 (C++ 과 ObjectiveC). 이영역에서의 향후 작업들은 수많은 기존 코드들로 인해 제한받게 될것이고,
괄목할만한 개선이 이루어지기는 어려울 것이다.
- C++과의 링크 호환성
- C++ runtime object model 은 너무 복잡하다. 만약 호환성을 유지하려한다면, 그것은 본질적으로 D 컴파일러를 완전한 C++ compiler 로도 만들어야한다는것을 의미한다.
- C 전처리기.
- 매크로 처리는 실제 존재하지 않는 기능을 추가함으로서 (symbolic 디버거로 볼수없는), 언어를 확장시키는데 쉬운 방법중의 하나이다. 조건적인 컴파일, 층층이 쌓인 #include 문장 , 매크로들, token 연결, 등등은 본질적으로 하나가 아닌, 두개가 함께 병합되어 그것들을 명확히 구분할수 없는 언어를 형성한다. 더 안좋은것은(혹은 아마 가장 훌륭한것은 ) C 전처리기가 매우 원시적인 매크로 언어란것이다. 한걸음 뒤로 물러나, 전처리기가 무엇을 위해서 사용되는지 살펴보고, 또 그것의 능력을 직접 언어안에서 지원하게끔 설계를 해야하는 시점이다.
- 다중 상속.
- 복잡하며 논쟁의 여지가 있는 기능이다. 효율적인 방법으로 구현하기 매우 어렵고, 그것을 구현하면서 컴파일러는 많은 오류 발생의 여지가 있다. 거의 모든 다중상속의 효용성은 단일 상속과 인터페이스, 통합(aggregation) 조합으로도 대체 가능하며, 더이상 다중상속 구현의
어려움을 정당화시키지는 못한다.
- 네임 스페이스.
- 독립적으로 개발어진 코드들을 모두 함께 연결하는데 있어서 문제점은 이름들간의 충돌이다. Modules 사용하는 것이 훨씬 간단하며 더욱 잘 동작한다.
- Tag name space.
- 이 C언어의 잘못된 기능은, 분리되었지만 병행되어 같이 참조되는 심벌 테이블에 구조체들의 Tag 이름들이 존재하는 것에 기인한다. C++는 기존 C 코드와 호환성을 유지하면서, tag name space 를 일반 name space 와 병합하려 했다. 그결과로 불필요한 혼돈이 야기 되었다.
- 먼저 선언하기(Forward declarations)
- C 컴파일러는 현재상태 이전 내용에 대해서만 의미 파악을 할수있다. C++은 이것을 조금 확장해서, 클래스 멤버들은 이전에 참조된 클래스 멤버들에 의존할수 있다. D언어는 논리적인 결론에 도달했는데, 전방 선언은 더이상 module 단위에서 불필요 하다는것이다. 함수들은 C 프로그램에서 전방 선언을 피하기 위해 흔히 사용되는, 뒤바뀐 함수들의 순서가 아닌 자연스러운 순서로 정의되어질 수 있다.
- Include 파일들
- 각각의 컴파일 단위마다 무지막지한 양의 헤더파일을 재해석해야함으로서 컴파일이 느려지는 주원인이다. 파일들을 include하는것은 심벌 테이블을 importing 할때 처리되어야 한다.
- Trigraphs and digraphs. Unicode가 미래다.
- 비 가상 멤버 함수들.
- C++ 에서는 클래스 설계자는 어떤 함수가 가상인지 비가상인지를 먼저 결정한다. 함수가 오버라이드 될때, 베이스 클래스 멤버함수를 가상함수로 변경하는것을 잊어버리는것은 흔하고(그리고 매우 찾기 힘든) 코딩 오류이다. 모든 멤버 함수를 가상함수로 만들고 만약 아무런 오버라이드가 없다면 그함수를 비가상함수로 전환시키는것을 컴파일러가 결정하게 하는것이 더 신뢰성있다.
- 임의 크기의 Bit fields.
- Bit fields 는 복잡하고 비효율적이며 거의 사용안되는 기능이다.
- 16비트 컴퓨터 지원.
- near/far 포인터, 훌륭한 16비트 코드를 생성하기 위해 필요한 장치에 대한 고려는 없다. D언어의 설계에서는 최소한 32비트 실수 메모리 공간을 가정한다. D언어는 향후 64비트 구조에 원활하게 적응할 것이다.
- 상호 의존적인 컴파일러 단계들.
- C++에서는 성공적인 소스 파싱은 심볼 테이블을 가지는것 그리고 전처리기의 다양한 명령에 의존한다. 이것은 C++소스를 먼저 파싱하는것을 불가능하게 만들고, 코드분석기와 문법 통제된 편집기가 제대로 동작하는것을 극도로 어렵게 만든다.
- 컴파일러 복잡성
- 컴파일러 구현을의 복잡성을 감소시키는것은, 다수의 올바른 컴파일러 구현을 가능하게 한다.
- 저 정밀도 부동 소수점
- 만약 누군가 현대의 부동 소수점을 구현한 하드웨어를 사용중이라면, 그것은 현재 하드웨어간 통용되는 가장 낮은 정밀도의 부동 소수점을 사용중인 프로그래머에게도 가능해야한다. 특별히, D 언어의 구현은 IEEE 754 계산과 만약 확장된 정밀도가 가능하다면 그것을 지원해야 한다.
- < 과 > 부호를 이용한 템플릿 오버로딩
- C++에서의 이 선택은 수년간의 버그들, 비탄 그리고 프로그래머들, 컴파일러 구현자들, C++소스 파싱 벤더들의 혼란의 원인이 되어왔다. 이것은 완전한 C++ 컴파일러가 수행하는것과 거의 같은 일을 하지 않는다면, C++코드를 제대로 파싱하는것을 불가능하게 만든다. D 언어는 깔끔하고 명백한 문법으로서 !( 와 ) 를 사용한다.[4]
전망
페이스북, 넷플릭스, 이베이 등에서 적용된 사례가 있으며, 실행 속도에 민감한 게임계에서도 레메디 엔터테인먼트가 퀀텀 브레이크의 일부 소스코드에 D를 사용하는 등 실제 비즈니스에 이용된 사례가 조금씩 늘어나는 추세지만, C++에 비해 D의 입지가 작은 것은 여전하다. 2017년 6월 21일에 GCC 컴파일러가 D를 공식으로 지원하기 시작해서 여건이 그나마 나아질 것 기대되고 있으나 Rust 언어가 각광받고 있는 상황을 봐서는 전망이 좋다고 보기 어렵다. C++의 대안을 자처하고 나왔기 때문에 항상 C++ 세계의 흐름에 영향을 받을 수밖에 없는 언어이다. D가 처음 나왔을 때는 C++이 겨우 표준안을 마련하고 현대화를 시작한 무렵이었으므로 C++의 복잡도를 크게 경감시킨 D가 설 자리가 충분히 존재했다. 그러나 커뮤니티가 분열하고 언어가 재설계되는 동안 C++은 C++11로서 그 결과를 내놓으며 현대화에 박차를 가했다. .NET 프레임워크를 출시하고 오랫동안 C#을 밀던 마이크로소프트도 다시 돌아와 네이티브 환경에 힘을 쏟기 시작했고 Visual C++ 2010, 2012에서 C++11의 많은 기능을 수용했다. C#이 한창 푸시를 받던 당시 대우가 안 좋았던 비주얼 스튜디오의 C++ 인텔리센스 기능도 2013 버전에 와서는 드라마틱하게 향상되었다. 레거시 코드의 컴파일을 보장해야 하고 헤더 include 구조를 유지해야 하는 C/C++에 비해, 한 번역 단위 내에 명세와 구현이 같이 존재하고 사용하기 쉬우면서도, C와 같은 저수준 개발이 가능하며 컴파일 속도가 빠른 네이티브 언어로서의 D의 유니크한 입지는 아직 유효하다. 그러나 네이티브 개발자 세계에서 예나 지금이나 주력은 C++이고 벌써 C++14, C++17, C++20을 논하며 현대화되는 현 시점에서 D의 입지는 거의 사라져 버린 것이 현실이다. 그리고 결정적으로, C++의 문제점 때문에 C++를 버리고 "더 나은 대안"을 찾는 사람들에게는 D는 syntax 정도만 갈아엎은 어정쩡한 솔루션인데 비해, Rust는 syntax는 물론이고 모든 문제를 갈아엎으면서 Ada에 비교되는 안전함을 제공하는 혁신을 보여줬기 때문에 더더욱 비교가 되고 있다. ABA Games의 서클장 쵸 켄타가 이 언어를 이용한 벡터 그래픽을 구현해 탄막 슈팅 게임을 제조하였으나, 현재는 XNA로 바꾸었다.[2]
각주
- ↑ 1.0 1.1 D (프로그래밍 언어) 위키백과 - https://ko.wikipedia.org/wiki/D_(%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D_%EC%96%B8%EC%96%B4)
- ↑ 2.0 2.1 2.2 D언어 나무위키 - https://namu.wiki/w/D%EC%96%B8%EC%96%B4
- ↑ 〈D 프로그래밍 언어의 세계에 오신 걸 환영합니다.〉, 《D Programming Language》
- ↑ 쭌안아빠, 〈D 언어 overview〉, 《블로거》, 2008-10-31
참고자료
- D (프로그래밍 언어) 위키백과 - https://ko.wikipedia.org/wiki/D_(%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D_%EC%96%B8%EC%96%B4)
- D언어 나무위키 - https://namu.wiki/w/D%EC%96%B8%EC%96%B4
- 〈D 프로그래밍 언어의 세계에 오신 걸 환영합니다.〉, 《D Programming Language》
- 〈D Programming Language〉, 《Wikipedia》
같이 보기
