최근 수정 시각 : 2024-10-09 05:04:19

D언어

프로그래밍 사이트 선정 프로그래밍 언어 순위 목록
{{{#!wiki style="margin: 0 -10px -5px; word-break: keep-all"
{{{#!wiki style="display: inline-table; min-width: 25%; min-height: 2em;"
{{{#!folding [ IEEE Spectrum 2024 ]
{{{#!wiki style="margin: -5px 0"		<rowcolor=#fff> 스펙트럼 부문 상위 10개 프로그래밍 언어 직업 부문 상위 10개 프로그래밍 언어
1 Python 1 SQL
2 Java 2 Python
3 JavaScript 3 Java
4 C++ 4 TypeScript
5 TypeScript 5 SAS
6 SQL 6 JavaScript
7 C# 7 C#
8 Go 8 HTML
9 C 9 Shell
10 HTML 10 C++
}}}
}}}
}}}
[ Stack Overflow 2024 ]
||<tablewidth=100%><width=9999><-4><bgcolor=#FFA500><tablebgcolor=#fff,#222> 2024년 Stackoverflow 설문조사 기준 인기 상위 25개 프로그래밍 언어 ||
1 JavaScript 14 Rust
2 HTML, CSS 15 Kotlin
3 Python 16 Lua
4 SQL 17 Dart
5 TypeScript 18 어셈블리어
6 Bash 19 Ruby
7 Java 20 Swift
8 C# 21 R
9 C++ 22 Visual Basic
10 C 23 MATLAB
11 PHP 24 VBA
12 PowerShell 25 Groovy
13 Go
[ TIOBE 2024 ]
||<tablewidth=100%><width=9999><-4><bgcolor=deepskyblue><tablebgcolor=#fff,#222> 2024년 8월 기준 검색어 점유율 상위 20개 프로그래밍 언어 ||
1 Python 11 MATLAB
2 C++ 12 Delphi / Object Pascal
3 C 13 PHP
4 Java 14 Rust
5 C# 15 Ruby
6 JavaScript 16 Swift
7 SQL 17 Assembly language
8 Visual Basic 18 Kotlin
9 Go 19 R
10 Fortran 20 Scratch
{{{#!wiki style="margin: 0 -10px -5px; min-height: calc(1.5em + 5px);"
{{{#!folding [ 21위 ~ 50위 펼치기 · 접기 ]
{{{#!wiki style="margin: -5px -1px -11px"		 21 COBOL 36 Scala
22 Classic Visual Basic 37 Transact-SQL
23 LISP 38 PL/SQL
24 Prolog 39 ABAP
25 Perl 40 Solidity
26 (Visual) FoxPro 41 GAMS
27 SAS 42 PowerShell
28 Haskell 43 TypeScript
29 Dart 44 Logo
30 Ada 45 Wolfram
31 D 46 Awk
32 Julia 47 RPG
33 Objective-C 48 ML
34 VBScript 49 Bash
35 Lua 50 Elixir
}}}}}}}}} ||
[ PYPL 2024 ]
||<tablewidth=100%><width=9999><-4><bgcolor=green><tablebgcolor=#fff,#222> 2024년 8월 기준 검색어 점유율 상위 20개 프로그래밍 언어 ||
1 Python 11 Objective-C
2 Java 12 Go
3 JavaScript 13 Kotlin
4 C# 14 MATLAB
5 C/C++ 15 PowerShell
6 R 16 VBA
7 PHP 17 Dart
8 TypeScript 18 Ruby
9 Swift 19 Ada
10 Rust 20 Lua

}}} ||
프로그래밍 언어 목록 · 분류 · 문법 

#!syntax java
import std.stdio;

void main()
{
   writeln("Hello, world!");
}


파일:external/upload.wikimedia.org/D_programming_language_logo.png
공식 홈페이지

1. 개요2. 상세
2.1. 역사
2.1.1. D 1.02.1.2. D 2.0
2.2. 주요 기능 및 특징2.3. 컴파일러
2.3.1. DMD2.3.2. GDC2.3.3. LDC
2.4. DUB2.5. D언어를 지원하는 개발 도구2.6. 문제점: 쓰레기 수집2.7. 전망: 좁아지는 입지2.8. 다른 언어와의 비교: D vs Go vs Rust2.9. D맨
3. 관련 링크

1. 개요

2001년 12월에 처음 발표된 후, 2007년 1월에 정식 발표된 컴파일 언어이자 멀티 패러다임 프로그래밍 언어.
C++이 본래 C언어를 대체하기 위한 언어로 출발했듯이 D언어는 C++을 대체하기 위한 목적으로 출발한 언어이다.

2. 상세

2.1. 역사

2.1.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# 등 현대화된 메이저 언어들의 영향을 많이 받았다. 그러면서도 최근의 현대 언어들과 같이 인터프리터나 가상머신으로 실행되는 구조가 아니었으므로 퍼포먼스 지향적이어서 처음에는 많은 기대를 받았다.[1]

D는 표준 런타임 라이브러리로서 Phobos[2]가 존재했지만 D 커뮤니티는 Phobos 라이브러리의 느린 발전 속도에 만족하지 못했다. 언어와 개발 환경의 느린 발전 속도는 D언어가 원래 오픈소스가 아니고 Digital Mars에 카피라이트가 있고 상용 언어를 목표로 했기 때문이었다. D 사용자 커뮤니티는 Phobos와는 별도로 오픈소스로서 존재하는 런타임 라이브러리를 만들기로 했고 Tango 라이브러리가 발표되었다. Tango는 Phobos보다 다양한 기능을 제공했으며 커뮤니티가 참여해서 만들어졌기 때문에 발전 속도가 빨랐다. D언어에 관한 책은 거의 없지만 D programming with Tango라는 입문서가 출판될 정도였다.

그러나 이런 상황은 커뮤니티 자체를 분열시키는 결과를 낳았고 언어 자체의 발전속도를 저하시키고 인터넷상의 정보를 파편화시켜 D 언어를 지탱한 표준 런타임 라이브러리가 분열되고 말았다. 이 때문에 정보가 많지도 않은 상황에서 입문자들은 전혀 다른 스타일의 런타임 라이브러리에 혼란을 겪어야 했다. 비슷한 상황을 맞은 Python[3]을 보면 구글이 창시자를 영입하고 재단을 출범해 로드맵을 조정하는 것과 대조적이었다.

결국, 월터 브라이트는 D 1.0이 실패라고 판단하고 언어 자체를 재설계하기로 결정했다. D의 행보에 실망한 커뮤니티는 대부분 흩어지고, 초반에 받았던 세간의 관심으로부터도 멀어졌다.

2.1.2. 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언어는 바로 버려진 것은 아니고 꾸준히 버전업되면서 버그 수정(안정화 작업) 정도로만 유지되었다가[4] 2012년 12월 31일에 발표된 1.076 버전을 마지막으로 지원 중단되었다. 현재의 D언어인 2.0 버전은 오픈소스 프로젝트로서 GitHub에 전체 프로젝트가 공개되어 있으며 커뮤니티가 활발하게 기여를 하고 있다.

핵심 개발자인 안드레이 알렉산드레스쿠는 현재 페이스북에서 연구자로 소속되어 있으며 페이스북 내에서 D를 사용한 프로젝트를 진행하고 있다고 한다. 페이스북은 주로 HHVM[5]을 사용하고 있는데 구글 내에서 Python이 그랬던 것처럼 메이저 IT 회사 중 하나인 페이스북 내에서 어느정도의 입지를 가지게 되느냐에 따라 향후 D의 운명이 결정될 가능성이 크다.

그러나 알렉산드레스쿠는 D 언어 재단에 더 힘을 쏟기 위해 페이스북을 그만두었다. 본인도 많은 고민 끝에 내린 결정이라고...

2.2. 주요 기능 및 특징

D언어는 멀티 패러다임을 추구하며, 문제에 대한 가장 명확한 한 가지 해답을 추구하는 것이 아닌 다양한 해답을 추구한다. 재밌는 점은 함수형 프로그래밍과 객제 지향 프로그래밍 그리고 계약에 의한 프로그래밍이라는 개념을 동시에 괴리감 없이 잘 통합해낸 언어라는 것이다. 자세한 내용은 dlang.org - Overview의 Major Features of D를 참고할 것.
  • 명령형 프로그래밍: C언어와 거의 동일
  • 객체 지향 프로그래밍: 클래스, 연산자 오버로딩
  • 함수형 프로그래밍: 불변이 타입(immutable), 순수 함수(pure), 람다와 클로저
  • 배열 지향 프로그래밍: 정적배열, 동적배열, 연관배열, 인덱싱, 슬라이싱
  • 일반화 프로그래밍
  • 멀티태스킹
  • FFI - C, C++(일부), Objective-C
  • 신뢰성: 계약에 의한 프로그래밍, 유닛 테스트, Debug 속성 등등...
  • 자동 메모리 관리: 쓰레기 수집기(GC)가 내장되어 있어 RAII(Resource Acquisition Is Initialization) 패턴을 기반으로 메모리를 자동으로 관리해준다. 물론 C, C++처럼 저수준 메모리 관리를 원하는 프로그래머를 위해 core.memory 라이브러리를 가져와서 @nogc와 같은 키워드를 사용하면 GC를 사용하지 않을 수도 있다. 프로그래머가 C/C++처럼 직접 포인터 산술을 하거나 메모리를 제어할 수 있는 셈이다. 하지만, 이 기능 때문에 D언어를 발목 잡고 있다. 자세한 내용은 아래 문제점 항목에 후술.
  • SafeD: 메모리를 손상시키지 않고 안전하게, 신뢰하고 사용할 수 있도록 메모리를 직접적으로 만짐으로서 발생할 만한 행동들을 강제적으로 제한하는 일종의 규칙이다. 대표적으로 SafeD가 적용된 코드는 타입시스템을 cast 연산자로 깨거나, 포인터 값의 임의 변경 그리고 지역 변수 또는 함수의 매개 변수의 주소의 언급이 불가능하다. 메모리를 다룰 수 있는 허용 범위에 따라 @system, @trusted, @safe로 나뉜다. @safe의 경우는 다음과 같이 상당히 엄격하다.
    • 포인터가 아닌 타입을 포인터 타입으로 캐스팅 불가
    • 포인터 값의 임의변경 금지
    • 다른 타입의 오버래핑 참조나 포인터를 가진 unions타입의 접근 불가
    • @system 속성의 함수 사용 불가
    • Exception 클래스의 catching 불가[6]
    • 인라인 어셈블러 사용 불가(x86 asm block)
    • 스레드 로컬 객체 ↔ shared객체: 명시적 캐스팅 불가
    • 불변이 객체(immutable) ↔ 변이 객체(table): 명시적 캐스팅 불가
    • 지역 변수 또는 함수의 매개 변수의 주소의 언급 불가
    • __gshared 타입 접근 불가

2.3. 컴파일러


크게 구분하면 D언어 재단에서 유지 보수 중인 것과 커뮤니티(혹은 개인)에서 유지 보수 중인 것으로 나뉜다. D언어 재단에서 관리하는 레퍼런스 컴파일러로 DMD가 있으며 이외에 GDC, LDC 등이 있다.

각 컴파일러 별로 추구하는 목적과 특징까지 모두 다르기 때문에 D를 처음 접하는 사람이라면 선택의 어려움이 생긴다. 보통의 경우 DMD를 사용하는 게 가장 안정적이며, DMD에서 충족하지 못한 기술적인 요인이 생겼을 때 다른 컴파일러로의 이전을 고민해볼 수 있을 것이다.

2.3.1. DMD

Digital Mars D compiler의 약자이며 D언어 재단에서 공식적으로 유지보수&배포 중인 레퍼런스 컴파일러다. 기존에는 C++로 구현되었으나 2015년 11월 3일에 2.069.0 버전부터 프론트엔드를, 뒤이어 2018년 11월 11일에 백엔드를 D로 구현하는 데 성공했다. (소스코드 참조) D언어로 DMD를 작성했다는 뜻에서 DDMD라 부르기도 한다. GitHub 레포지토리
  • D언어 재단에서 제공하는 표준 레퍼런스 컴파일러
  • 빌드 속도는 GDC와 LDC보다 빠름
  • 빌드한 결과물의 퍼포먼스는 GDC나 LDC에 비해 떨어짐

2.3.2. GDC


이름에서 추측할 수 있듯이 GCC 기반의 D 컴파일러이다. 예전에는 DMD의 심각한 성능 문제나 디버깅의 어려움 때문에 커뮤니티에서는 'DMD 버리고 GDC를 써라' 라는 말이 돌기도 했었지만 꾸준한 DMD의 성능개선으로 모두 옛날 이야기가 됐다...였으나 2017년에 GCC가 D를 공식으로 포함했기 때문에 그냥 GCC를 쓸 수 있게 되었다!
  • GCC 프론트엔드
  • 버전 릴리즈는 가장 느림
  • 빌드 속도는 DMD와 비슷함

2.3.3. LDC


LLVM를 기반으로 둔 D 컴파일러이다.

DMD 컴파일러가 Android와 iOS환경에 대한 공식적인 지원이 없는데 비해 상대적으로 모바일 환경에 대한 지원이 활성화 되어 있다. 1.18버전부터 Android용 컴파일러 바이너리를, 1.20버전부터 iOS(tvOS·watchOS 포함)를 위한 codegen을 제공하기 시작했다.

그 외에도 D 커뮤니티 내 몇몇 능력자들의 포크(fork)나 사이드 프로젝트를 통한 기여가 많은 편이다. C++ 라이브러리를 바인딩 코드 없이 그대로 가져와 쓸 수 있는 LDC 컴파일러(Calypso)나 웹어셈블리어플리케이션 개발을 위한 라이브러리 등등.

2.4. 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 버전부터 포함되어 함께 배포되고 있다.

2.5. D언어를 지원하는 개발 도구

  • D언어를 지원하는 통합 개발 환경
    • Code::Blocks
    • Dexed
    • Dlang IDE
    • IntelliJ IDEA / CLion D Language 플러그인
    • Visual-D: 공식 홈페이지에서도 별도의 항목으로 분리될 정도로 가장 인지도가 높은 패키지. Visual Studio 2008부터 지원했지만 현재는 2013 이상을 권장하며, Express 에디션에서는 사용할 수 없으므로 D언어를 사용하려면 커뮤니티 이상의 에디션이 설치되어 있어야 한다.
    • Poseidon
    • Zeus
  • D언어를 지원하는 텍스트 에디터
    • Atom
    • CudaText
    • Dhee
    • Emacs
    • Geany
    • jEdit
    • KDE's KWrite
    • Kate
    • Notepad++
    • SciTE
    • Sublime Text 3
    • SynWrite
    • Textadept
    • TextMate
    • vim
    • Visual Studio Code
    • Zeus

2.6. 문제점: 쓰레기 수집

C++을 대체하기 위한 D언어가 쓰레기 수집기(GC)를 내장함으로서 발생하는 성능적인 비용 때문에 게임과 같이 빠른 연산이 필요한 곳, 특히 60FPS을 목표로 렌더링 해야 하는 고사양 게임 개발에 사용하기에는 부적합하다는 의견이 중론이다. 물론 @nogc로 쓰레기 수집기의 싸이클을 어느 정도는 회피할 수 있다고는 하지만 언어적 차원에서 지원되는 기능이라 GC를 사용하지 않았을 때의 제약점이 생긴다. 그래서 GC를 싫어하는 D 사용자들은 아에 D의 런타임(druntim)에 의존하지 않고 D 그 자체로 직접 메모리를 다뤄 C, C++처럼 쓰는 경우도 종종 보인다. C, C++ 스타일의 D언어

하지만 C, C++처럼 다루어야 한다는 제약 조건 자체가 D의 치명적인 약점인데, GC 기반의 고성능 언어가 기존에 이미 많이 있었고 (Java, C# 등) GC로 커버가 가능한 분야에서는 이미 성공적으로 C++를 대체하고 있었다. 그래서 C++에 남은 코드들은 GC로는 도저히 커버 불가능한 경우일 뿐이었는데, D가 GC를 요구하면서 이 사용자들에게 외면받았기 때문. GC로 커버 가능한 코드들은 이미 다른 언어로 옮겨갔으므로 그쪽에서도 사용자들을 끌어올 수 없었고, 이것은 D를 그대로 묻어버린 결정적인 실책이 된다.

그 후에 D는 실책을 깨닫고 *GC 없이 동작하는 모드*를 제공했으나, 문제는 이렇게 하면 표준 라이브러리인 druntim을 사용할 수 없고(...), 표준 라이브러리에 의존하는 모든 다른 라이브러리 또한 사용할 수 없는 상황이 되는데다(...) 결정적으로 이 모드에서는 메모리 안전성을 포기해야 했다. (leak! corruption! use-after-free!) 그러면 "C++와 별로 달라지는게 없게" 되어 이 모드도 묻혔다.

나중에 이 모드에서 작동 가능한 표준 라이브러리를 제공하기는 했으나 안전성까지 보완된 것은 아니라서, GC를 완전 배제하면서도 안전성을 제공하고 C++의 거의 모든 문제를 실제로 해결한 Rust가 뜨기 시작하자 최종적으로 묻히게 된다.

2.7. 전망: 좁아지는 입지

페이스북, 넷플릭스, 이베이 등에서 적용된 사례가 있으며, 실행 속도에 민감한 게임계에서도 레메디 엔터테인먼트가 퀀텀 브레이크의 일부 소스코드에 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#이 한창 푸시를 받던 당시 개차반이었던 Visual Studio의 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.8. 다른 언어와의 비교: D vs Go vs Rust

심심하면 한번씩 D vs Go vs Rust의 경쟁 구도를 통해 'D언어는 더 이상 비전이 없다'는 질타들이 올라오고 있으며, D언어의 주역들은 침착하게 답글을 달아준다. 안드레이 알렉산드레스쿠가 작성한 글[8]을 보면 알 수 있다. 그러나 이제 Go가 D언어와 비교될 수준은 한참 지났다고 봐야 한다. Go는 구글 제품은 물론 Docker, Kubernetes 등 주요 비즈니스 소프트웨어에 많이 사용되고 있으며, 개발자 채용 사이트들을 둘러보면 국내외를 포함해 Go 사용 경험이 있는 개발자를 뽑는 사례가 증가하고 있기 때문이다.

다만 로우레벨+실시간 영역에서 Go는 가비지 컬렉터의 존재로 인해 성능상 저하가 있으며, 이로 인해 Go ↔ D/Rust는 서로 다른 시장을 타겟팅하고 있다. 문제는 로우레벨 시장에서 Rust가 실질적인 대안으로 뜨고 있는 반면 D는 거의 존재감이 없다는 점.

2.9. D맨

파일:external/dlang.org/compiler-dmd.png

일명 D맨(d-men, d man)이라 불리는 D언어의 마스코트 쯤 되는 캐릭터이다. 알게 모르게 일본 쪽에서 2차 창작이 이루어지고 있었다...

D언어 공식 포럼에서도 이를 재밌게 보고 있다.[9] 간간히 직접 만든 아스키 아트가 올라올 정도다. Go의 햄스터(Gopher), Lisp의 코끼리와 함께 나란히 라인(Line)메신저의 스티커 아이템으로 데뷔했으니, 어쩌면 D 프로그래밍 언어 그 자체보다도 마스코트가 더 유명해졌을지도..?

3. 관련 링크


[1] 구글링해보면 D 1.0에 관한 다양한 포스팅이 존재한다.[2] D언어의 원래 이름이 Mars였기 때문에 화성의 위성 이름에서 따왔다.[3] Python 자체가 이런 부침을 겪지는 않았으나 Python 3의 릴리즈로 인해 비슷한 커뮤니티 파편화가 존재한다.[4] D 2.0 버전 개발에 집중하기 위해 deprecated로 전환된 상태였다.[5] PHP를 JIT 컴파일해서 실행하는 VM[6] D에서는 catching 가능한 클래스로 Error와 Exception 두가지가 있다. Error가 아니라 Exception의 발생은 이미 그 프로그램이 더 이상의 동작이 위험한 상황에 도달했음을 뜻하므로 안전하게 프로그램을 종료하도록 권장한다.[7] Vibe.d는 D언어로 Native하게 작성된 비동기 웹 프레임워크이다.[8] 원문: Which language has the brightest future in replacement of C between D Go and Rust? And Why?[9] http://forum.dlang.org/thread/[email protected]

분류