Haxe 검토: Haxe 4 기능 및 강점

이전 Haxe 리뷰는 곧 출시될 Haxe 4를 살펴보는 것으로 끝이 났습니다. Haxe 4의 공식 릴리스(그리고 얼마 지나지 않아 두 가지 버그 패치 릴리스 버전 4.0.1 및 4.0.2)와 함께 새로운 Haxe 리뷰가 필요합니다. . 이 급성장하는 프로그래밍 언어에 가장 최근에 추가된 것은 무엇입니까? Haxe 프로그래밍 언어 커뮤니티는 어디로 가고 있습니까? Haxe 게임 엔진이 여전히 주류입니까?

Haxe 검토: Haxe 4의 새로운 기능

마지막 주요 릴리스 이후 3년 이상의 개발을 통해 Haxe 프로그래밍 언어 버전 4는 매크로 성능, 개발자 경험 및 구문을 개선합니다. 개선 사항 중 세 가지는 여전히 실험적인 것으로 간주되지만 강조할 가치가 있는 새로운 JVM 바이트코드 대상, 인라인 마크업 지원 및 null 안전 검사입니다.

Haxe 4의 실험적 JVM 바이트코드 컴파일 대상

Haxe 4의 새로운 JVM 바이트코드 타겟은 주요 컴파일 단계를 생략함으로써 Haxe를 통한 Java 개발을 상당히 더 효율적으로 만듭니다. Java 자체 컴파일러( javac )가 Haxe 변환기의 Java 소스 코드 출력을 컴파일하도록 하는 두 번째 단계가 없습니다.

Haxe 4로 컴파일하는 이 방법은 또한 Java 개발자 키트(JDK)에 대한 종속성을 완전히 제거하고 향후 구현될 대화형 디버깅의 문을 엽니다.

hxjava 의 메인스트림 버전이 Haxe 4와 호환될 때까지 기본 설정에는 Haxe와 Haxelib를 설치한 다음 haxelib install hxjava 4.0.0-alpha 를 실행하는 것이 포함됩니다. 이렇게 하면 개발 흐름이 간단해집니다.

 # transpile directly to JVM bytecode with Haxe (-D jvm would also work): haxe --main HelloWorld --java jar_output --define jvm # run JVM bytecode with Java: java -jar jar_output/HelloWorld.jar

직접 JVM 컴파일이 Haxe 4에서 여전히 실험적 상태임을 감안할 때 몇 가지 주의 사항이 있습니다.

• Android와 관련된 몇 가지 문제가 있습니다.
• 런타임 성능은 간접적인 방법보다 결국 더 빠를지라도 그다지 좋지 않습니다.

그럼에도 불구하고 이는 Java 기반 기술을 활용하는 모든 사람에게 올바른 방향으로 나아가는 주목할만한 단계입니다.

Haxe 4의 실험적 인라인 마크업 지원

JSX, 누구? Haxe 4는 인라인 마크업을 활성화하여 개발자가 예를 들어 Haxe 소스 코드 내에서 직접 HTML을 작성할 수 있도록 합니다.

 var dom = jsx( <div> <h1>Hello!</h1> <p>This is a paragraph.</p> </div> );

여기에서 jsx() 는 정적 매크로 함수가 될 수 있기 때문에 개발자가 구현하고자 하는 XML 사양을 준수하는지 여부에 대해 프로젝트에서 컴파일 타임 검사를 수행할 수 있습니다. XML 지원 자체가 Haxe API에 내장되어 있기 때문에 검사는 Xml.parse() 를 활용할 수 있지만 기본 "XML-ish" 구문 분석 가능성을 위해서는 필요하지 않습니다.

 static macro function jsx(expr) { return switch expr.expr { case EMeta({name: ":markup"}, {expr: EConst(CString(s))}): macro $v{"XML MARKUP: " + s}; case _: throw new haxe.macro.Expr.Error("not an xml literal", expr.pos); } }

이 기능의 의도는 Hax를 게임 개발 거품에서 밀어내는 데 도움이 되는 것입니다(물론 거기에도 사용되지만). 컴파일러 수준에서 구현되기에 충분히 일반적이므로 위의 매크로에서 Haxe API가 필요하지 않습니다. 그러나 특정 DSL을 확인하는 것은 컴파일러 팀과 커뮤니티가 알아낼 다음 질문입니다.

Haxe 4의 실험적 Null 안전성

1965년 null 참조가 발명된 이후로 null 안전 문제는 Haxe 프로그래밍 언어와 같은 nullable 형식 환경에서 개발자의 골칫거리였습니다. Aleksandr Kuzmenko는 GitHub가 1천만 개 이상의 null 포인터 참조 오류를 수정하는 데 커밋했다고 추정합니다.

Haxe 4에는 지정된 정의 바로 앞에 @:nullSafety 줄을 포함하여 활성화할 수 있는 컴파일 시 null 안전 매크로가 내장되어 있습니다. @:nullSafety(Loose) (기본값) 및 @:nullSafety(Strict) 모드로 제공되며 @:nullSafety(Off) 를 사용하여 필요에 따라 비활성화할 수 있습니다. Strict 모드는 null 안전 비활성화 컨텍스트에서도 null을 할당할 수 있는 필드 변형에 대한 함수 호출을 살펴봅니다.

Ruby 개발자는 편리한 안전 탐색 연산자(Ruby의 ?. )가 레이더에 있는지 궁금해할 수 있습니다. 아직까지는 아니지만 Haxe 프로그래밍의 많은 측면과 마찬가지로 이를 위한 매크로가 있습니다(대신 !. 를 사용합니다.)

Haxe 4를 사용한 DX(개발자 경험): 구문 추가, 구문 설탕 등

Haxe 프로그래밍 언어 및 Haxe IDE 지원에 대한 DX 관련 추가는 Haxe 4 경험을 다양한 면에서 다른 프로그래밍 언어와 동등한 수준으로 제공합니다. 어떤 면에서 Haxe는 모든 사람에게 모든 것이 되고자 하지만 컴파일러 팀은 다른 언어의 가장 유용한 기능과 규칙을 통합하기 위해 사려 깊은 접근 방식을 취합니다.

그 결과 Haxe 프로그래밍 언어와 표준 API는 안정성, 감수성 및 응집력을 손상시키지 않으면서 진화했습니다. 이 Haxe 리뷰의 모든 것이 과장된 것처럼 보일 수는 없으며 이것이 바로 요점입니다. DX가 개선되고 있으며 이것은 단순히 화려한 " 주르 의 기능"을 쫓는 데 찬성합니다.

하지만 균형이 필요합니다. Haxe의 변경은 다른 언어가 따르고 있는 패턴에 대한 인식으로 이루어지며 Haxe 4는 확실히 더 인기 있는 언어의 신규 사용자에게 어필하기 위해 노력합니다.

새로운 "함수 유형" 구문

그 점에서 Hax는 이제 함수 유형을 나타내는 두 가지 주요 방법을 지원합니다. 원래 기능 제안에 따르면 이전 구문은 "자동 커링 및 부분 응용 프로그램이 지원되지만 지원되지 않습니다"라고 제안합니다.

 Int -> String -> Void

새 구문은 명명된 인수를 허용하여 DX를 향상시킵니다.

 (id:Int, name:String) -> Void

그러나 DX는 제쳐두고, 함수 유형에 대해 Haxe 4의 새로운 구문을 사용하는 것은 좋은 습관입니다. 이전의 열등한 구문은 향후 주요 버전에서 제거될 수 있기 때문입니다.

구문 설탕 ... 일종의

획기적인 것은 아니지만 Haxe 4의 구문 개선은 특정 개발 배경을 가진 기존 Hax 개발자(예: ES6)와 Hax를 처음 사용하는 개발자 모두에게 반가운 소식이 될 것입니다.

이제 화살표 함수("짧은 람다") 구문이 지원되며, Haxe의 경우 function 및 return 을 입력하기 위한 바로 가기에 불과합니다. 이제 키-값 및 인덱스-값 반복 구문(각각 맵 및 배열용)도 지원됩니다. 정적 확장을 사용하는 형식 선언은 해당 정적 확장 메서드가 사용되는 모든 곳에서 필요하지 않고 전역적으로 하나의 using 문만 사용할 수 있습니다.

열거형 및 열거형 추상에는 몇 가지 다른 개선 사항이 있으며, 그 중 하나는 후자가 매크로의 범위에서 컴파일러를 직접 지원하도록 이동했다는 것입니다. 유사하게 이동된 다른 기능에는 최종 클래스, 최종 인터페이스 및 extern 필드가 포함됩니다.

매크로에 의존하는 일부 기능은 매크로에 의존했지만 그럼에도 불구하고 개선되었습니다. 연산자 오버로딩이 필드 설정자를 포함하도록 레벨업되었으며 이제 메타데이터를 로 네임스페이스를 지정할 수 있습니다 . @:prefix.subprefix.name 과 같은 구분 기호.

위의 변경 사항을 구문 설탕 이라고 부르는 것은 명백히 지나치게 단순화되지만 독자는 더 자세한 내용이 필요한 Haxe 4의 릴리스 노트에서 링크된 원래 제안을 파헤칠 수 있습니다.

더 많은 Haxe 4 DX 부스트

다양한 컴파일된 대상에 대해 Hax에서 대화식 디버깅이 이미 가능했지만 새로운 eval 대상은 해석된 코드에 대해 대화식 디버깅을 가능하게 합니다. 간단한 예를 들어 Haxe "Hello, World" 튜토리얼의 프로젝트 디렉토리에 다음과 같은 whatever-you-want.hxml 파일을 추가할 수 있습니다.

 --main HelloWorld --interp

... 다음과 같이 간단히 VSCode IDE에서 대화형 디버깅을 얻을 수 있습니다.

1. VSCode에서 프로젝트 디렉토리 열기
2. 어딘가에 중단점 추가하기 그리고
3. F5 키를 누르고 드롭다운에서 "Haxe Interpreter"를 선택합니다.

이 기능을 사용하면 실제로 --interp 를 사용하는 대신 java 와 같은 특정 대상에 대해 컴파일하는 경우에도 동일한 방식으로 매크로 코드를 대화식으로 디버그할 수 있습니다. Haxe 및 VSCode 자체 외에 유일한 설치 요구 사항은 Haxe VSCode 확장입니다.

IDE 서비스

IDE에 대해 말하자면 Haxe 4는 최신 VSCode Haxe 확장인 vshaxe에서 이미 활용되고 있는 새로운 IDE 서비스 프로토콜을 도입했습니다. 상당한 성능 향상 외에도 vshaxe는 다음을 포함하여 매우 유용한 DX 개선 사항을 제공할 수 있습니다.

• (오랫동안 기다려온) 자동 가져오기
• 자동 완성 호버 힌트는 "이 필드는 어디에서 왔습니까?"
• 예상 유형 완성, 후위 완성 및 재정의 완성과 같은 몇 가지 매끄럽고 새로운 방식으로 매우 철저한 자동 완성
• 코드를 입력하는 동안 다운 투 키스트로크 최적화

관련 vshaxe 변경 로그의 뛰어난 시각적 데모를 통해 이러한 가치를 훨씬 쉽게 확인할 수 있습니다. vshaxe 가 있는 vshaxe는 Haxe IDE 주변의 유일한 Haxe IDE가 아닙니다. HaxeDevelop 및 Kode Studio는 Haxe 전용이며 IntelliJ IDEA, Sublime Text, Atom 등을 위한 Haxe IDE 플러그인이 있지만 면에서 팩보다 앞서는 것 같습니다. IntelliJ-Haxe가 뒤를 이은 Haxe 4의 새로운 IDE 서비스 프로토콜을 사용합니다.

유니코드 리터럴

실제 유니코드 문자열 리터럴을 사용하려는 개발자는 Haxe 4에서 이에 대한 지원을 찾을 수 있지만 알아야 할 몇 가지 뉘앙스가 있습니다.

읽기 전용 배열

표준 Haxe API에는 이제 읽기 전용 배열이 있습니다. 이는 변수를 유형으로 선언하는 것만큼 사용하기 쉽습니다(예: haxe.ds.ReadOnlyArray<Int> ). 그 후 값을 설정, 푸시 또는 팝하려고 하면 다양한 컴파일러 오류가 발생합니다. 선언에 final 키워드를 추가하고 배열 자체를 재할당하는 것도 허용되지 않습니다.

호출 사이트 인라이닝

호출 사이트 인라이닝은 개발자가 함수가 인라인되는 위치를 세밀하게 제어할 수 있도록 하는 새로운 Haxe 언어 기능으로, 전반적인 크기-성능 트레이드오프가 손실 결정이 될 수 있는 자주 호출되는 함수를 최적화할 때 유용합니다.

이것들은 이미 우수한 Haxe 프로그래밍 언어에 추가할 가치가 있습니다. Haxe 4가 출시된 지금 Haxe 커뮤니티의 개발자들은 무엇을 만들고 있습니까?

Haxe 게임 엔진 너머: Haxe 4를 사용한 웹 개발

Haxe의 사용자 기반은 역사적으로 게임 프로그래머가 지배했습니다. 그러나 프론트엔드 및 백엔드 개발을 위해 비즈니스 스택, 모바일 앱 및 웹과 같은 다른 부문에서 대규모로 Hax를 사용하는 예가 많이 있습니다.

이를 위해 Haxe 4는 재생성된 HTML extern을 제공합니다. 즉, Haxe의 js.html 표준 API가 MDN이 정의한 대로 더 넓은 웹 API와 함께 최신 상태로 업데이트되었을 뿐만 아니라 버그를 수정하고 누락된 API를 추가했습니다. (예를 들어, Haxe 4에는 이제 푸시 API가 포함됩니다.)

Juraj Kirchheim의 강연인 Weaving Better Web with Hax에서 그는 Haxe 기반 웹 솔루션이 엔터프라이즈 환경에서 훨씬 더 효율적이면서도 더 강력하다고 지적했습니다.

그는 또한 Rails 아키텍처 접근 방식(폴더 계층 구조 측면에서)에 반대하지만 Rails와 같은 완전한 웹 프레임워크를 선호하는 개발자는 여전히 찾을 수 있습니다. 다른 경우에는 개발자가 완전한 웹 프로젝트의 소스를 검토하는 것이 도움이 될 수 있습니다. 이 경우 Haxe 4를 지원하는 크라우드 기프팅 플랫폼인 Giffon의 공개 리포지토리를 살펴볼 가치가 있습니다. JavaScript 분할 Haxe Modular와 같은 소스 Haxe 라이브러리, 일반 thx.core 및 그 자매 라이브러리, 유서 깊은 Haxe 웹 툴킷 Tinkerbell은 모두 이미 Haxe 4를 지원합니다. 웹 컨텍스트를 지원하지만 크로스 플랫폼 UI 솔루션인 HaxeUI도 마찬가지입니다. 비즈니스 및 데스크탑 앱 개발을 포함하여 훨씬 더 넓은 범위를 대상으로 합니다. 특히 새로운 Hax 언어 릴리스까지 꾸준히 발전했습니다.

웹, 게임, 엔터프라이즈… 플랫폼 및 앱 유형에 상관없이 개발 팀(심지어 한 팀으로 구성된 팀 포함)이 목표로 삼고 있는 Haxe 개발자는 결국 종속성 관리와 씨름해야 합니다. 이를 위해 Haxe 개발자가 검토할 수 있는 유용한 리소스는 Adam Breece의 강연인 Scaling well with others의 슬라이드입니다.

게임을 위한 최고의 프로그래밍 언어로서의 Hax

게임 개발을 위한 하나의 "최고" 언어가 존재합니까? 이것은 주관적인 질문이며 열띤 토론을 찾기 쉬운 질문입니다. 커뮤니티의 규모만으로 예상할 수 있는 것보다 더 큰 Haxe가 게임 개발 분야에서 성공을 거둔 것은 확실히 우연이 아닙니다. Joe Williamson은 2019년 Ludum Dare 45 게임 잼에서 우승한 것에 대한 인터뷰에서 이것이 Haxe 4에서 계속될 가능성이 있는 이유에 대한 통찰력을 제공합니다.

Haxe의 오리지널 제작자인 Nicolas Cannasse는 이미 Shiro Games의 Northgard와 함께 Haxe 4를 프로덕션에 사용하고 있습니다. Motion Twin은 또한 Dead Cells의 프로덕션에 Haxe 4를 사용하고 있습니다. 두 게임 모두 Steam에서 수만 건의 긍정적인 평가를 받았으며 PC(Win, Mac, Linux)와 콘솔 모두에서 사용할 수 있습니다. 두 게임 모두 소규모 개발 팀이 있지만 수백만 명의 사용자 기반을 가지고 있다는 점을 고려할 때 정말 강력한 결과입니다. Dead Cells에는 iOS 버전도 있으며 Android 버전도 레이더에 있습니다.

라이브러리 측면에서, 여러 주요 Haxe 게임 엔진은 확실히 Haxe 4의 변경 사항을 따라가고 있습니다. Haxe 4 호환 엔진에는 Kha(및 그 위에 구축된 많은 엔진 중 일부(예: Armory)), HaxeFlixel 및 주요 종속성 OpenFL, NME 및 Heaps가 포함됩니다. 당연히 Northgard와 Dead Cells가 사용하기 때문입니다. HaxePunk는 또한 Haxe 4 호환성을 위해 노력하고 있습니다. 한 경우에는 Nape라는 라이브러리가 Haxe 4와 함께 작동하도록 분기되었습니다.

일부 개발자는 이미 나와 있는 많은 엔진 중 하나를 사용하는 대신 자체 엔진을 만들기도 합니다. 예를 들어, Kirill Poletaev는 자신의 3D Hax 게임 엔진을 작성한 방법과 이유를 자세히 설명합니다. 해당 엔진은 사내에 있기 때문에 아직 Haxe 4로 마이그레이션하지 않은 프로젝트의 한 예라고 할 수 있습니다.

Haxe 4: 우수한 도구 모음의 원활한 진행 지속

Haxe의 활용도가 매우 높기 때문에 가장 중요한 Haxe 4 기능은 개발자마다 다르므로 이 Haxe 리뷰는 결코 완전한 것이 아닙니다. 다음을 포함하여 Haxe 4의 변경 사항 중 일부가 위에 누락되었습니다.

• JavaScript 대상에 대한 ES6 출력 추가
• 기능(일부는 hx3compat 라이브러리를 통해 계속 사용 가능) 및 대상(PHP5 및 곧 AS3) 제거
• CLI 플래그가 일반 도구와 보다 일관되게 만들어집니다(예: -lib .hxml 파일은 -L 또는 --library 로 변경해야 함).
• 이제 final 이 키워드(따라서 변수 이름으로 사용할 수 없음)가 되는 것 외에도 operator 및 overload 도 새로 예약된 키워드입니다.

또한 몇 가지 주요 변경 사항이 있었지만 너무 적기 때문에 적극적으로 유지 관리되는 많은 라이브러리에서 Haxe 4 호환성을 명시적으로 발표하는 데 신경조차 쓰지 않습니다. 일반적으로 Haxe 3에서 마이그레이션하는 것은 매우 간단하다고 합니다. 결국 Haxe의 목표 중 하나는 많은 수의 대상 플랫폼에 대한 지원을 저글링하는 가운데 안정성이며 Haxe 4는 여기서 실망하지 않습니다.

신규 사용자는 어떻습니까? 결국 Haxe가 게임을 위한 최고의 코딩 언어인지, Haxe 생태계가 웹 개발을 위한 가장 강력한 라이브러리를 제공하는지, 또는 Haxe 전용 도구가 특정 워크플로에 가장 합리적인 DX를 제공하는지 여부를 결정하는 것은 독자의 몫입니다. 최소한 Hax는 많은 분야에서 계속 실행 가능한 경쟁자이며 거의 모든 개발자에게 비밀스러운 이점을 제공합니다.

추가 정보: Haxe를 처음 접하는 개발자는 John Gabriele의 상당히 새로운 Haxe 튜토리얼과 Haxe 4.1.0 및 Haxe 4.1.1의 릴리스 정보에 관심이 있을 수 있습니다.