Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Gleyzer氏によって開発された言語です。2019で発表されました。Director、HTTP、JDBC、Exalogic関連製品に関わっていました。同言語とそれが解決を目指した問題について、氏にインタビューしました。Ecstasyは汎用目的でタイプセーフなモジュラープログラミング言語です。クラウドのために開発されました。私たちが過去30年間で学んできたことを活かして、改良し、使いやすい言語を作り上げました。Coherenceの開発に使えたならば、と思うような言語になっています。Webやバックエンドサービスの開発にこれが使えれば、というものを形にした言語なのです。Cloudインフラストラクチャのパーツ開発に着手した時に、こういうことができれば、と思っていたような言語でもあります。セキュリティや構成や可読性を重視する一方で、リポジトリや継続的インテグレーション(CI)、DevOps、継続的デプロイメント(CD)、クラウドとクライアントの可搬性、エッジ/CDN/5G統合、地理的分散システムといったものを明確に意図して設計されています。ただの新言語ではありません。compilation)をサポートするために設計された新たなマネージドランタイムをベースとする、新しいバイナリフォーマットにコンパイルされます。システムプログラミング言語ではありません。オペレーティングシステムやドライバ、あるいはメモリの管理を行ったり、ワードプロセッサのようなものを記述するために設計された言語ではない、ということです。汎用言語ですから、そういった目的に用いることも理屈の上では不可能ではありません。プログラミング言語には目的といものがあります。この言語は、クラウド用アプリケーションの構成と改善を支援することを目的として作られたものなのです。この種のアプリケーションは多くの部分から成り立っていて、それぞれがクラウドプロバイダのデータセンタやCDN、通信会社の5Gインフラストラクチャ、各ISPの提供するエッジ、ダウンロードされたクライアントデバイス、さらにはそのクライアント上で動作するブラウザ内など、さまざまな場所で動作しています。私たちの目標は、JavaやC#(いずれも私自身が以前からプログラムしていた言語です)、Swiftなどを知っていれば、事前に学習しなくてもEcstasyのコードを読むことができて、数時間ないし数日あればコードを書くことができるようになることです。言語機能の大部分はCやC++開発者ならばよく知っているもので、技術的にはCファミリーに属する言語ですが、そういった人たちが中心的なターゲットではありません。KotlinやPython、Erlang、Elixir、Smalltalk、Rubyなどのユーザにも、Ecstasyはすぐに理解できると思います。Ecstasyの持つ言語的なアイデアや機能は、これらの言語がすでに備えているか、あるいは導入過程にあるものだからです。JavaやC#と同じように、Ecstasyもマネージドランタイム環境用にデザインされていますが、後発の強みを活かして、マネージドランタイム環境のコンセプトをより活用できるような設計になっています。Ecstasyでは、スレッドの概念を表面には出していません。ランタイムが並列性を動的に管理する上で障害となるからです。(プログラム言語でスレッドの概念を表に出さないことには、他にも多くのメリットがあります。開発者が正しい並列コードを書こうとして落とし穴に陥ることを防ぐのも、そのひとつです。Ecstasyでは、潜在的な並列性や非同期性を持った処理へのスレッドの割り当てはランタイムによって行われます。私たちは並列性とスレッドの問題に対して、Javaの"Hotspot"対応コンパイラの概念を適用しました。これによってランタイムは、コードの実行中に収集した経験的証拠を使用して、同じコードを次回に実行する時に最適化することが可能になります。さら設計面ではアヘッドオブタイム(AOT)コンパイルも考慮されていて、コンパイルや最適化に関わる重い処理をコード実行前に行っておくことが可能です。活用することができます。私たちは、JVMやCLRが開発された1990年代以降の、ハードウェアの劇的な変化についても理解しています。現在では携帯電話でも、その程度のスペックを備えています。私たちがEcstasyの設計に着手するにあたって、プロセス毎に数十TBのRAMを備え、プロセス毎に数千のハードウェアスレッドを実行するようなサーバでの動作を念頭に置きました。その結果として、"スレッド"や"同期"といった概念を言語から取り除き、不変性(immutability)のような概念を加えることになりました。"ヒープ"のような基本的な概念についても、極めて意図的に排除しています。アクタモデルを(SmalltalkのメッセージやErlangのプロセスのように)組み込みで採用することにより、アーキテクトや開発者がアプリケーションを、潜在的に並列性を持ったユニットに簡単に分割できるようにしました。このユニットを、Ecstasyではサービスと呼んでいます。メモリやスレッディング、セキュリティに関するルールはすべてサービスの観点で説明されるため、結果として非常に明確なものになりました。ひとつ、言語の美しさを明確にしているものが、型システムです。Ecstasyは静的に型付けされた言語で、優れた型推論とジェネリックな具象化を備えています。それだけではありません。型システムの設計とランタイムの設計に一貫性があるのです。別の言い方をすれば、これら2つが同時にモデル化されたものであるため、型システムがランタイム定義に対して合理的であるとともに、ランタイムも型システムの観点から合理的な設計が行われています。プロパティや変数、オブジェクト参照などもオブジェクトであるため、ランタイムのリフレクションが自然なものになり、ランタイムと型システムが共生的に動作します。このような設計判断は、型システムにおいて証明可能な(provable)クロージャの設計、階層的(ネスト可能)なランタイムコンテナのサポート、セキュアでダイナミックなコードローディングの設計などにおいて、非常に重要な意味がありました。この分野は、言語とランタイムの設計にあたって意図的に重視した部分です。私たちの考え方の一部は、多種多様な環境において、さまざまなライブラリやフレームワークやサービスと共に使用されるような、ライブラリやフレームワーク、アプリケーションを開発した経験に基づいています。以前に私が働いていたある企業では、XML解析にSAXやDOMのライブラリを使用していました。ある日、まったく互換性のないAPIの変更が行われたため、古いバージョンと新しいバージョンの両方に対応するコード記述と構築を行って、どちらが選択されても対応できるようにする必要が発生しました。不都合なことに、このライブラリは多くのアプリケーションサーバで使用されていたため、古いバージョンのアプリサーバでは古いバージョンのライブラリを使用し、新しいバージョンではライブラリの新しいバージョンを使用するような状況になったのです。独自のXMLパーザを(依存性を回避するために)用意して、それをずっとサポートせざるを得なくなったのです!もうひとつの例として、私たちは、Springと当社の製品が正しく動作するようにしたいと思っていました。その結果、通常ならば1行のコードで書けるようなものが20行のコードになった上に、そのような複雑な処理があちこちに散らばることになったのです。KODOも同じように追加したのですが、今度はこのような"オプション"ライブラリのさまざまな組み合わせが問題になりましたリフレクションを使えばJavaのModularityの利用が可能になりますが、これは大変な作業です。OSGiを導入して簡略化できないか試してみましたが、結果はさらに複雑になってしまいました。アプリケーションを開発する企業と共同で作業する時には、多くの場合において、これらと同じ問題が発生していました。これらすべての経験から学んだことを取り入れて、Ecstasyをゼロから設計して、このような問題を解決したのです。最初に、コンパイル単位がモジュール、あるいはモジュールのセットになるように設計を行いました。モジュール間に循環参照が存在する場合などには、これが必要になります。Identifier)形式で宣言できるようにして、リポジトリのサポートを組み込みました。モジュールが依存関係を持つ場合には、その依存関係はURIとして表現されます。この関係を、依存モジュールがインポートされる、と呼んでいます。話題から外れますが、モジュールのインポートの簡単さとその動作のエレガントさはとてもクールです。インポートされたモジュールは、インポートしたモジュール内のパッケージ(つまり名前空間)として表現されます。インポートされたモジュールの内容がすべてパッケージにコピーされたような状態なので、パッケージ内ではすべてローカル名でアクセスできるようになるのです。すべてのモジュールは"Ecstasy.xtclang.org"(URI)を"Ecstasy"パッケージとしてインポートするので、Ecstasyモジュールの"collections.HashMap"クラスには、どのモジュールにおいても"Ecstasy.collections.HashMap"クラスとして表現することができます。一般的には開発バージョンか、あるいはCIバージョンが使用されます。2.0.0仕様をサポートしたバージョン番号も含まれます。バージョンのスタンプは変更可能なので、テストにおいてレグレッションのなかったCIビルドにはQCあるいはプレリリースビルドと記録しておくことができます。ロールアウトの準備が整ったら、プレリリースのマークを取り除けばいいのです。これらはすべて自動化を念頭に設計されていて、組織の既存プロセスに適応するための柔軟性を備えています。ひとつのモジュールに、同じモジュールの異なるバージョンを含むことができるのです。違うバージョンのモジュールを組み入れても、モジュールのサイズはその差異分が増加するだけです。これによって、ひとつのモジュールファイルにひとつのサポートバージョンだけでなく、次期バージョンのプレリリース版や、旧バージョン用の公式パッチなどを含むこともできます。この背景にあるのは、ロールフォワードとロールバック、A/Bテスト、オプションパッチの安全な配布、すべての提供物をひとつのパッケージにする、といった考え方です。モジュール依存性はハードな依存性である必要はありません。モジュールAを"required"、モジュールBを"desired"(参照可能であればリンクする)、モジュールCを"supported"(依存グラフ内の他のモジュールがそのモジュールをリンクする場合にのみリンクする)というように参照することが可能です。モジュールを組み込む(embedded)、つまり、物理的に取り入れることもできます。これは主として(組織的な理由などから)複数のモジュールで構成されたものを、単一のモジュールとして提供したい場合を意図したものです。有効な使い方は、これらの機能の組み合わせにあります。モジュールは実行時に存在する場合もあれば、そうでない場合もあります。存在したとしても、必要なバージョンである場合とそうでない場合もありますし、特定のクラスや機能を含んでいない場合もあります。これがいわゆるDLL地獄の実態です。Ecstasyでは、クラスとコードの存在を、バージョンや他のクラスの存在に対して条件付き(conditional)とする機能を提供しています。コンパイラはこのような条件を、複数のバージョンをひとつのモジュールに配置する場合とほぼ同じような方法でコンパイルして、最終的なモジュールに格納します。そのモジュールは、他のモジュールが存在する場合としない場合、あるいはバージョンの異なる場合をサポートすることが可能なように、動的リンクプロセスの一環として生成されるのです。これにより、モジュールに対するハードな依存性や、特定のバージョンのモジュールに対する依存性を回避することができると同時に、モジュールが存在した場合には、そのモジュールないしバージョンを統合してフル活用することが可能になります。これらの情報はすべてモジュールにエンコードされているので、すべての条件のテストを自動で行うことができます。テストに関して言えば、ユニットテストや機能テスト、統合テストをモジュールに統合することも可能です。特定のバージョンが必要でない場合と同じように、実運用で使用するモジュールにはテストは含まれません。私たちが重視して、その設計に多大な労力を注いだものがこれであることは、現在では間違いありません。さまざまな理由の中から特にあげられるのは、CVEやゼロディ、非互換的な変更が製品に持ち込まれるからです。"どのバージョンがどのバージョンでテスト済か"、というマトリックスが、必要な時に用意されている状況を想像してみてください。判断できるようになれば、と思わないでしょうか。これらの機能をサポートする設計は可能ですが、ツーリングや自動化(基盤部分の機能に依存します)の部分が整っていないので、まだ実現はしていません。そのとおりですが、簡単に実現するものではありません。skew)が付き物であり、プログレッシブデリバリはバージョンスキューの一例に過ぎない、という事実です。古いバージョンのアプリケーションクライアントと新しいサーババックエンド、あるいはバックエンドのサービスインスタンス間というように、アプリケーションの異なるバージョンを実行すれば、バージョンスキューはいつでも発生します。いずれの場合においても、プロトコルの相互運用性や状態の互換性が必要になります。この要件は、それ自体が重要なものです。状態に関しては、旧バージョンのコードが、新しいバージョンのデータでも破綻なく動作する必要がありますし、新バージョンのコードは、古いバージョンのデータを受け入れられる(さらに自動的にアップグレードできる)必要があります。私たちは、バージョンスキューは例外ではなく、現実的なアプリケーションにおいては必然的に発生する一般的な状況なのだ、という事実をまず受け入れることにしました。Format)の設計を行った時、スキーマの前方互換性と後方互換性を実現する作業の中で、この問題を実際に経験していました。その中で、バージョンスキューを受け入れて安全性を確保することは、プログレッシブデリバリや増分型ロールアウト、従来型のA/B(およびその自動化)などにおいても、前提となるものであることを理解したのです。スケールアウト環境において、サービスの中断を回避するためには、アプリケーションの新バージョンの立ち上げと並行して、旧バージョンのアプリケーションの運用を一定期間続ける必要があります。(新バージョンのロールアウトで何らかの問題が発生すると、事態はさらに複雑になります。そのため、私たちの設計作業では、オブジェクトのシリアライズやデータベースのインターフェース設計がこの要件を満たすように、当初から考慮していました。強力なモジュールバージョニング機能とリソースインジェクション(アプリケーションが外部とコミュニケーションする唯一の手段)を取り込むことによって、新バージョン(すべてのテストモード機能を有効にしたもの)と旧バージョンを実行すると同時に、新バージョンによる状態変更を不可視にして、クライアントに対する応答を実際には配信しないような"箱の中"に留めることのできるような、自律的インフラストラクチャが実現できました。これにより、運用データベースにダメージを与えたり、エンドユーザに影響を与えるようなリスクを回避しながら、実運用のワークロードで新バージョンをテストすることが可能になります。同じように、自律的なインフラストラクチャであれば、インクリメンタルに始めて、新バージョンを実行するサーバをウォーミングアップし、旧バージョンから新バージョンへ段階的にトラフィックを移行するという、同じような方法でアップグレードをロールアウトすることが可能になります。問題が発生した場合には、元に戻すこともできます。実際のワークロードを旧バージョンから新バージョンに移行する前に、アプリケーションの新バージョンを一定期間、明確なレグレッションが存在しないことを実証できるまで運用することが可能であれば、それが理想的です。同じように、最初は旧バージョンのトラフィックの一部を移行して、その後で大部分を移行していくような方法を採用すれば、アプリケーションを利用するエンドユーザが問題に直面した場合にも、影響を限定的にすることが可能になります。データベースAPIに関しても、最終的にステートフルなシステムを階層的構成のインフラストラクチャ全体で運用するような意図を持って設計されています。Network)とエッジティアで運用して、最終的に5Gタワーに移行することが最終的な目標です。これを実現するためEcstasyは、セキュアに組み込み可能な言語として設計されています。データベースAPIではアクタベースのモデルを採用して、動作ユニットと最終一貫性について考慮した設計が行われています。最終的には、同じAPIのサポートをクライアントレベルにまで広げることが目標です。することで、ネットワーク接続が断続的な場合やオフラインでも、アプリケーションが機能するようになるからです。これらはまだ構想段階ですが、APIの初期バージョンが固まった時点で、どのようにサポートできるのかを示す概念実証を提供したいと思っています。明言しておきたいのは、現時点ではサポートしていませんが、x86/x64とARMに加えて、WASMも設計目標のひとつだということです。Ecstasyの目標のひとつは、ユーザの目の前にあるものから、バックエンドシステムの奥の奥まで、すべての共有コンポーネントをサポートすることにありました。これはつまり、ブラウザ内部に至るまでプログラムモデルがポータブルである、ということです。クライアントの普及において、ブラウザは重要な部分を占めているからです(クライアントのiOSやAndroid、macOS、Windows上でネイティブに動作することに加えて、です)。ブラウザをターゲットにする場合は、JavaScriptへの変換と、WASMへのコンパイルが可能です。私自身は生成されたJavaSciptをデバッグするのはまっぴらなので、どちらを選ぶかは明らかです。忘れてならないのは、LLVMがすでにWASMをサポートしている点です。WASMはLLVMプロジェクトの重要な部分を占めていますし、私たちはコンパイラバックエンドとしていつもLLVMを想定しているのです。私たち自身がすでに製品開発に使用しています。Esctasyを一度使用すると、もう他の言語に戻ることは困難だ、ということをすでに体験しています。病みつきになる言語です。その一方で、現在も活発な開発が行われているので、まだ中核的言語というレベルには達していません。現実的なアプリケーション開発にはまだ不十分です。言語やコンパイラ、ツールチェーンに特に関心がないのであれば、Ecstasyの採用は時期尚早でしょう。2年経ってプロダクションユースに耐えられるようになれば、誰が使うのか分かります。クラウド用のアプリケーション、さまざまなクライアントで動作する必要のあるアプリケーション、ステートフルなサーバレスバックグラウンド開発などで使用されることになるでしょう。自動化やサービス性、管理性、ソフトウェアライフサイクルの大幅な削減を可能にする言語設計、といったものに恩恵を受ける開発者が採用することになると思います。私が過去25年間に勤務した企業の大部分では、IT予算の95パーセント(通常はもっと!)を、古いシステムの運用に費やしていました。そのような状況では新たな開発はもちろん、既存アプリケーションの大幅な改善であっても、困難か、あるいは不可能です。長い時間を掛けてそのコストモデルをひっくり返すための、これが最初のチャンスです。Ecstasyは、発想の世代交代なのです。Ecstasyはオープンソースです。ランタイムも、ツールチェーンも、クラスライブラリも、すべてです。完全にオープンなのです。ライセンスには、標準的なApacheオープンソースライセンスを使用しました。フォークすることも自由ですし、組み込みも可能です。EcstasyのトレードマークはEcstasyプロジェクト(言語をメンテナンスする組織)が所有しますが、ブランド以外、企業や開発者が望むことはすべて自由に行うことができます。Ecstasyはサーバレス用に設計された初の言語です。マーケティング的なナンセンスにも聞こえますが、そうではありません。これ以前の言語は(JavaScriptなどわずかの例外を除けば)、ネイティブなクラスライブラリと実装、オペレーティング・システム(あるいはOSの公開する領域)、物理的マシンによる階層構造の上に構築されていました。それには理由があるのです!Amazonの現在のサーバレスを見てください。実際には専用のサーバを提供しています。サーバレスワークロードが実行する対象をその環境とOSと"マシン"(もちろん仮想です)にすることで、複数のアカウントがマシンを共有することによるリスクを回避しているのです。Ecstasyはマシンを表に見せません。OSや、OS上で検索したライブラリもそうです。Control)を使用します。アプリケーションが起動後、リソースを見つけるためにコンピュータの中を探し回るのではなく、Ecstasyがアプリケーションにリソースをインジェクトするのです。こちらをお使いください。こちらをお使いください。こちらをお使いください。こちらをお使いください。こちらをお使いください。アプリケーションコードの実行環境をすべて隠蔽するように明示的に設計された言語は、これが初めてです。アプリケーションがホストされる(Ecstasy)コンテナのさまざまなリソースのすべてを、言語が完全に管理することのできるというのも初めてのことです。Ecstasyはセキュリティ層を重ねた後付けのものではなく、セキュアに設計された言語です。Ecstasyは、設計レベルからサーバレスです。Kubernetesについて言うならば、当初は存在しなかったような恐ろしく複雑な問題に対処する、素晴らしいエンジニアリングソリューションだと思います。多くのプロジェクトで採用されていますから、Kubernetesは非常にうまくいくと思っています。それらの複雑なシステムの運用を続ける上で、Kubernetesは最も抵抗の少ない手段なのです。現在のアプリケーション開発は、極めて複雑なものになっています。数十の、時には数百にも及ぶライブラリやコンポーネントを取りまとめなくてはなりません。Nodeや、他の言語の同等なものを見ても、セキュリティの確保やメンテナンスはほぼ不可能に近いものになっています。Ecstasyがこの状況を変えられれば、と思うのです。Purdy氏は11xの開発者で、プログラム言語Ecstasyの開発者のひとりです。Coherenceの開発者のひとりでもあります。現在はxqitz.itの創業者兼CEOです。Director、Exalogic製品を担当していました。Format(POF)の著者でもある氏は、分散コンピューティングやデータ管理に関する特許も多数著しています。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。