ハクソク

世界を動かす技術を、日本語で。

Java 30周年：ジェームズ・ゴスリングへのインタビュー

374日前原文(thenewstack.io)

概要

  • Javaは2024年5月23日で 30周年 を迎えるプログラミング言語。
  • 創始者James Goslingの 生涯と業績 が現代コンピューティングへ多大な影響を与えた。
  • Javaの進化や 設計哲学、オープンソースやAIへの見解を紹介。
  • Sun Microsystems時代の イノベーションと文化 も振り返る。
  • Goslingの 倫理観と技術的好奇心 がキャリア全体を通して貫かれている。

Java誕生30周年とJames Goslingの軌跡

James Gosling: Javaの父、その人物像

  • James Goslingは「 Javaの父」として知られる、謙虚で天才的なプログラマーであることを確認。
  • 難解な概念を シンプルに説明 する能力に長けていることを強調。
  • Java誕生30年を経て、Goslingはその進化と自身の経験を振り返ることができる人物であることを示す。

プログラミングへの道：創意工夫の少年時代

  • 貧しい家庭環境から創造力を発揮し、 不要品から電子機器を自作 した経験を持つことを紹介。
  • 初めてのコンピュータは電話会社の廃棄品から リレーラック を使って自作したことを強調。
  • カルガリー大学の コンピュータセンター訪問 が転機となり、以降の好奇心を説明。
  • 高校時代から大学の物理学部で 衛星データ処理ソフト開発 を担当、実践的な経験を積んだことを述べる。
  • IBMメインフレームでのPL/1やFortran、PDP-8アセンブリ、CDC 6400コードなど幅広い言語経験を持つことを確認。

学術界から産業界へ：現実主義の選択

  • Carnegie Mellon大学の 博士課程 を「安価な労働力」と率直に評し、実務経験を重視する姿勢を示す。
  • 学業中断後、ベイエリアのスタートアップで働き、実務と学業を両立したことを強調。
  • IBM Researchでの勤務経験を、ユーモアを交えて 批判的に評価 することを紹介。
  • Sun Microsystemsでは、技術力と創造性が両立する 稀有な職場環境 で活躍したことを述べる。

Sun Microsystems時代：イノベーションと遊び心

  • Sunでの思い出として、 エイプリルフールの壮大なイタズラ 文化を紹介。
    • 例：CEOのオフィスにゴルフコース設置、フェラーリを池に浮かべるなどの創造的なプロジェクトを実施。
  • 技術的な課題解決と遊び心が共存する 職場文化 がGoslingの発想力を育んだことを強調。

Java誕生：世界を変えたレガシー

  • Javaの設計哲学は「 Write Once, Run Anywhere」を実現し、開発者に大きな影響を与えたことを確認。
  • JDK 8で追加されたラムダ式など、初期に実装したかった機能や 言語設計の慎重さ を解説。
  • GenericsやLambdasの実装は難易度が高く、「最初の90%は簡単だが最後の10%が非常に難しい」と述べる。
  • OracleによるJavaの運営については「思ったより良いが期待値は低かった」とし、 コミュニティの貢献 を高く評価。
  • Javaは クラウド環境 への適応やマルチコア、ガベージコレクションの進化により、現代でも健在であることを強調。

Sun退職後：新たな挑戦と倫理観

  • OracleによるSun買収後、Googleを経てLiquid Roboticsに移籍し、 自律型海洋ロボットの制御システム 開発に従事。
  • 環境モニタリングとベンチャー資金の現実、 防衛用途への転換に対する倫理的懸念 から退職を決断。
  • Amazon Web Services（AWS）ではGreengrassや開発ツールに従事し、2023年に退職したことを説明。

オープンソースと業界動向：冷静な分析

  • オープンソースは コラボレーション、開発者リレーション、マーケティング の側面を持つと分析。
  • 「ローコード/ノーコード」についてはCOBOL時代からの繰り返しとし、 特化領域以外では複雑性に弱い と指摘。
  • AI・機械学習については「 高度な統計手法」と呼ぶべきであり、過剰な期待や誤解を懸念する立場を表明。

開発ツールと好み：進化を受け入れる姿勢

  • 主に NetBeans IDE を利用し、オープンソースかつ活発なコミュニティを評価。
  • 古いツール（例：Vi）に固執する開発者への 批判的な見解 を示し、実用的な用途ではモダンな環境を推奨。

JVMのビジョン：学術的発想から世界標準へ

  • Java Virtual Machine（JVM）の発想は大学院時代の アーキテクチャ非依存配布形式 の研究から生まれたことを説明。
  • 「Write Once, Run Anywhere」というビジョンが 世界のソフトウェア開発手法を変革 したことを確認。

近年の取り組み：AWSでのIoT推進

  • AWS GreengrassプロジェクトでIoTアプリケーションの スケーラビリティ問題 を解決する枠組みを開発。
  • OTAアップデートやセキュリティ管理などの 煩雑な要素を抽象化 し、開発者の負担を軽減することを重視。
  • Greengrassのデバイス側をオープンソース化し、 コミュニティによる移植性向上 に満足感を示す。

AIへの懐疑的見解

  • AI革命については「 ほとんど詐欺」と断言し、AIという用語自体が ミスリーディング であると主張。
  • AIの本質は「高度な統計技術」であり、 人間の知能とは異なる ことを強調。

Hackerたちの意見

その通りだね、ジェームズ・ゴスリングの仕事は素晴らしいし、彼とJavaエコシステム全体に感謝してるよ。最初のJavaワールドツアーのカンファレンスに行って、そのことについてちょっとしたブログ記事を書いたんだけど、それがサンのホームJavaページに約1年間リンクされてたんだ。すごくラッキーだったし、長い間「Javaコンサルタント」で最初に検索に引っかかってたおかげで、妻と一緒に田舎に住む自由が得られて、10年間リモートワークができたんだ。感謝の気持ちを表すついでに、Clojureチームにも素晴らしいエコシステムをJavaとJVMの上に作ってくれてありがとうと言いたい。何百万もの人々の生活にポジティブな影響を与える仕事ができるなんて素晴らしいよね。

└

ジェームズ・ゴスリングにも本当に感謝してるよ。1995年の秋、タリジェント（アップル、IBM、HPの合弁会社）でC++を使ってたときに初めてJavaをダウンロードして試してみたんだ。最初の「Hello, World」プログラムを書いたときは、文字通り飛び跳ねて喜んだよ。タリジェントのCommonPointアプリケーションフレームワークを作ってたのとは全然違って、新鮮な風が吹いた感じだった。タリジェントが崩壊したときに退職金をもらって、その時やってたことを全部やめて、それ以来ずっとJavaとその関連ソフトウェアで働いてる。

└

ジェームズ・ゴスリング（Java）とリッチ・ヒッキー（Clojure）は素晴らしいクリエイターだね！それぞれの時代にプログラミングに新しい風を吹き込んだ。

Javaのパフォーマンスは一番速いわけじゃないけど、それは大丈夫。C/CPPのすぐ後ろの3位って悪くないし、Goよりも前にいて、PythonやRubyよりも10倍以上は速いよ。Javaの構文は完璧じゃないけど、一貫性があって予測可能だしね。で、もしIdeaやEclipseを使ってるなら（メモ帳やAtomじゃなくて）、一日中control-spaceを押してれば大丈夫だよ。Javaのメモリ管理はUnixの哲学から見ると変に思えるけど、何が起こってるかを理解すればそうでもない。完璧じゃないけど、良いトレードオフだよ。これらのトレードオフで何が得られるかっていうと、スピードとメモリの安全性だね。でもそれに加えて、動的な呼び出し機能（インターセプションみたいなことができる）やホットスワップ/ライブ再定義（C/CPPではできないこと）がある。完璧？いや、でも実際の使用ケースにはとても実用的だよ。

└

Javaのメモリ管理はUnixの哲学から見ると変に思えるけど、何が起こってるかを理解すればそうでもない。完璧じゃないけど、良いトレードオフだよ。GCの話は本当に素晴らしい。管理されたメモリ言語のエコシステム全体で、ほぼ最高のものだよ。異なるGCアルゴリズムが実装されていて、自分のユースケースに最適なものを選んで調整できるんだ。もちろん、部屋の中の象はZGCで、ストップ・ザ・ワールドのGCの停止時間を大幅に短縮してくれる。私はそれが一貫してミリ秒未満の停止時間を提供するのを見たけど、他のアルゴリズムは通常40-60ミリ秒かかるんだ。言うまでもなく、GCなしのコードを書くこともできるよ、必要ならね。あまり宣伝されてないけど、実現可能なんだ。

└

大学を出たとき、まだ「Javaはすべての解決策だ」という考えにしっかりと囚われていた頃、実は私の憧れはJVMと当時の他の何よりも進んでいたJavaアプリサーバーツールに対するものだったって気づかなかったんだ。基本的には、2年以上前のDocker + K8sみたいなもので、JVM上で動くものにとっては。Javaという言語は、2006年から2007年頃に改善が始まるまで、生産性が非常に低かったので、私を遠ざけたんだ。今は、JVM上で動く他の言語、JRuby、Clojure、Scala、Groovy、Kotlinなどに目を光らせてる。個人的には、JRubyが最も興味深いと思う。なぜなら、それを使うことで2つの非常に成熟したエコシステムにアクセスできるから。JavaがProject Loomを導入して、JVM上でRubyのFibersを仮想スレッドを通じて使えるようになったとき、両者にとってウィンだったよ。チャールズ・ナッターはそこでの彼の仕事に対して十分な評価を受けていないと思う。

└

30年以上にわたって一貫して3位というのは、すごく大きなことだよ。公平を期すために言うと、JVMの最先端GCにかなりの投資がされているし、研究から出たばかりのものもある。

└

言語には年々改善されてきた粗い部分があるけど、強い型付けのオブジェクト指向言語を頑丈なIDE（例えばIdea）で使う開発者体験は本当に他に比べるものがない。デバッグプロセスもすごくシンプルだしね。Javaは企業向けの膨れたシステムと同義になったのには理由があるけど、どんな泥だらけのJavaシステムでも、デバッガーでクリーンにステップスルーできないものはないよ。それに、採用を加速させた彼らの最大のアイデアの一つ、javadocも加えたい。これが100%オリジナルなアイデアかどうかは分からないけど、インラインドキュメントをコンパイラに組み込んでHTMLドキュメントを自動生成するのは、ライブラリを構築してすぐに使えるようにするための本当に神の恵みだった。強い型付けもドキュメントをハイパーリンク可能にするのにうまく合ってた。Javaは、単独の開発者よりも大規模なエンジニアリングチームの問題を解決するために作られたんだ。

└

Javaのパフォーマンスは最速ではないけど、それは大丈夫、C/CPPのすぐ後ろの3位は悪くないよ。それに、Goよりも前にいて、PythonやRubyよりも10倍以上は前にいる。何の速さで、正確には？

└

Javaのパフォーマンスは最速ではないけど、それは大丈夫、C/CPPのすぐ後ろの3位は悪くないよ。Javaが人気になった1999年から2001年頃、C（またはC++）のすぐ後ろの3位ではなかった。その当時、あのマシンでCで書かれたプログラムとJavaで書かれたプログラムの間のギャップは、今のJavaで書かれたプログラムと純粋なPythonで書かれたプログラムの間のギャップとほぼ同じだった。

└

Javaの構文は完璧じゃないけど、一貫性があって予測可能なのがいいよね。最近のJavaの変更でこれをすごく評価してる。シールドクラスやスイッチ式、プロジェクトLoom、レコードを既存のJava構文にうまく組み込んだと思う。ヒープダンプアナライザーやスレッドダンプアナライザー、GCアナライザーのツールも最高だし。

└

それに、もしIdeaやEclipseを使ってるなら（ノートパッドやAtomじゃなくて）、Javaのツールは本当に素晴らしいよ。JavaのためにIntelliJを使うのは、他の言語のIDEを使うのとは全然違う世界に感じる。Goの話をすると、Goコミュニティが並行データ構造のためのコンテナ開発にあまり熱心じゃない理由を知ってる人いる？GoのコードにはMutexやロックが散見されるけど、Javaコミュニティでは並行処理コードを書くときの一番のアドバイスはJavaの素晴らしいコンテナを使うことだよ。時々、java.util.concurrentやJCToolsが恋しくなる。

└

JavaはGoよりも先に行ってないよ、同じくらいだけど、Goの方が速いことが多いし、2〜10倍少ないメモリを使うからね。値型のおかげでGoでの最適化がずっと楽になるし、Goを具体的に挙げるってことは色々説明がつくよ。ちなみに、C#はJavaよりも速いから、3位じゃなくて、むしろ5位くらいだね。 https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

└

SREとして、JVMには感謝してるよ。メモリ不足は今や開発者の問題で、俺やマシンの問題じゃないからね。ディスクを埋め尽くすlog4jのゴミを処理するだけで済む。

Javaを成功ストーリーとして尊敬しているけど、いろんな理由で深く根付いた嫌悪感も持っている。多くの理由は、Javaが膨れ上がった企業の言語としての遺産や、過度に冗長で魔法のようなフレームワーク、そして質の低いコードを生み出したことに起因していると認めるよ。Javaという言語は、コードは炉に投げ込む石炭のようなもので、私たちはすべての希望を捨てて平凡さを受け入れるべきだという考えと密接に結びついている。JVMに対する他の問題は、プラットフォームの観点からどれだけブラックボックスになっているかで、これが標準的な運用ツール（straceやgdbなど）でのデバッグを非常に面倒にしている。JVMのメモリの過剰割り当ては、実際のワークロードのパフォーマンスに関する真の洞察をカーネルから奪ってしまう。JVMを使うと完全にロックインされてしまうし、もしJVMの専門家がいないと、デバッグやプラットフォーム実装にどう変換されるかを解明するのが大変だよ。それに、奇妙なライセンス、Oracleとの関連、JDKのバージョン管理、2025年には魅力がなくなること、そして膨大なレガシーが足を引っ張っている（これはJavaに特有のことではない）。私はJavaにほとんど触れずにキャリアを成功させてきたし、今では最小限のランタイムをサポートするGC付きの高性能な言語があふれていて、普通のバイナリのように見えるから、JavaやPythonのVMが解決する問題はもはやそれほど重要ではなくなっている - ただ運用の複雑さを増すだけだ。繰り返しになるけど、私はJGを尊敬しているし、技術者なら誰でもそうあるべきだと思う。Javaの成功は明らかだけど、使わなくて済むのは嬉しいよ。

└

ITファクター！今、ファッションサイトにいるの？ どんな議論なんだそれ？ それに、Javaでstraceやgdbを使う理由は何なの？ JDKには非常に高性能なデバッグツールがあるし、IDEのデバッグ統合は他に比べるものがないよ。

└

JVMに関する他の問題は、プラットフォームの観点から見るとどれだけブラックボックスかってこと。デバッグが本当に面倒なんだ。Javaには素晴らしいデバッグ機能がある。動的ブレークポイントや条件付きブレークポイント、コードをホットデプロイした後にスタックフレームを再起動することもできる。メモリ内の変数を上書きしたり、未捕捉例外のブレークポイントを設定したり、デバッガーが接続するのを待ってからJVMを開始することもできる。他の言語ではこれらすべてを実現するものはないよ。そして、IdeaやEclipseに相当するものは他の言語にはゼロ。ランタイムの動的な部分については、JMX/JConsoleが日常的な使用には十分だし、Java Flight Recorderは深い洞察を与えてくれる。直接アクセスできないシステムでもね。JVMでjstackを実行するのも良いデバッグツールだよ。それでもダメなら、普通のHPROF（他の言語に似てる）やEclipse Memory Analyzerがあるし。> それからもちろん、変なライセンスの問題もある。JVMはオープンソースだから、ライセンスの問題はないよ。OpenJDKは自由にダウンロードして、制限なしに本番環境で実行できる。もし本当にOracleからJVMを買いたいなら…それはあなたの自由だね。> 2025年におけるそれの欠如、sdkman > 大量のレガシーがそれを妨げているけど、どのレガシーコード？

└

20年以上Javaを使っているけど、straceやgdbを使ったことは一度もない。Java自体は素晴らしいデバッガーサポートがあって、IDEにはステップスルー機能が組み込まれている。パフォーマンスの文脈でJavaとPythonを同じように言うのは本当に奇妙だ。Pythonはパフォーマンスに関してはJVMには全く及ばない。

└

ツールは最初はちょっと怖いけど、結構簡単に学べるし、少なくともGCチューニングのコンテキストではJVMの専門家になるのは1週間もかからないかも。ただ、デフォルトの設定には驚くこともあるよね。それに、カーネルとGC、mmapとバッファプールの間には何か並行するものがあると思う。GCはアプリケーションのスコープ内でより良いコンテキストを持っているからね。ただ、他のプロセスが絡むと、確かにプロビジョニングの複雑さがあるけど。

└

Javaのデバッグは素晴らしいよ、他の人も言ってるけど。これはおそらく、どのプラットフォームでも利用可能な最高のリモートデバッグ機能を含んでいる。みんなが使っている事実上の標準バージョンであるOpenJDKは、GPLバージョン2とクラスパス例外の下でライセンスされている。失礼だけど、あなたは単に情報が不足しているだけだよ。

└

JVMに関する他の問題は、プラットフォームの観点からどれだけブラックボックスになっているかで、デバッグが面倒だってこと。あなたはJavaをあまり使わないって言ってるけど、上のことがそれを確認しているよ。Javaのデバッグと診断ツールは他に類を見ないからね。

みんなにこれを思い出してほしいな: https://www.joelonsoftware.com/2005/12/29/the-perils-of-java... 私はJavaの学校に通ってたんだけど、オペレーティングシステムの授業ではJavaでOSのシミュレーションコードを書くことがあったんだ（例えば、コンテキストスイッチのためのラウンドロビンとか）。ハードウェアの複雑さを最小限に抑えれば、アルゴリズムを理解しやすくなるっていうのが理由だったんだけど、その気持ちは分かるけど、Javaは正しい選択じゃなかったと思う。Pythonの方が同じことをもっと上手くやってくれたはず（アルゴリズムの理解）。業界からの影響で、大学生に最初からJavaを教えることになったんじゃないかな。私は高校の時にBASICと少しCを独学で学んでたから、シミュレーションのために高級言語を学ぶのはちょっと後退した気がした。

└

ジョエルがその記事で言ってる多くの議論はPythonにも当てはまるし、ポインタを考えさせないほかの高級言語にもほぼ当てはまるよ。皮肉なことに、彼はGoogleがJavaで作られたMapReduceでMicrosoftに大きな飛躍を遂げたことを指摘してる。

└

私の学校では、最初にCでマイコンプログラミングを始めて、次にJavaでデータ構造とOOPの入門をやって、その後またC（とMIPSアセンブリ）でシステム/OS/並行処理を学んだ。データ構造/アルゴリズムに関しては、Javaの方がPythonよりも抽象データ型と基盤となるデータ構造の明確な区別があるのがいいと思う。Pythonだと間違ったメンタルモデルになりやすいから。でも、JavaでOSの概念を教えるのはちょっとクレイジーだと思う。

ここ数年、.NET/C#で働いてきたけど、満足はしてるものの、JVM/Javaが今までで一番いいエコシステムだと思ってる。Javaエコシステムが正しくやってることが、.NETでは間違ってることが本当に多いんだ。例えば、Javaは作業の盗み用にフォーク/ジョインプールを導入して、短命のタスクに推奨してたけど、.NETは単にグローバルスレッドプールに作業の盗みを追加しただけ。結果として、非同期ライブラリを同期コードベースに組み込む唯一の方法であるsync-over-asyncコードが、.NETではアプリ全体のデッドロックを引き起こすことが多くて、この問題はよく文書化されてる: https://blog.stephencleary.com/2012/07/dont-block-on-async-c... このブログの解決策は「すべての同期コードを非同期に変換する」ってことだけど、大きな既存のコードベースでは実現不可能なこともある。こういうケースには本当にたくさん遭遇するよ。Javaエコシステムには多くのミスがあったけど、ほとんどがライブラリやフレームワークレベルだったから、人々が最終的に行き止まりに気づいた時には移行が楽だった。でも、標準ライブラリやランタイム、言語でミスをすると、修正が非常に難しくて、Javaはここでは他のどこよりも正しくやってるように見える。

└

[フラグ付き]

└

.NETのスレッドプールの枯渇問題に遭遇するとイライラする。個人的には.NETフレームワークの時代以来、遭遇していない。スレッドプールの実装は、年々この問題の影響を減らすために調整されてきた。最新の調整は.NET 10に入る予定だよ: https://github.com/dotnet/runtime/pull/112796 スレッドプールの実装が誤用に対して免疫を持つことができるかは分からない（プール内の他のタスクの完了を同期的にブロックする多くのタスクがあるから）。できることは、スレッドを増やすか、タスクの実行順序を賢くすることだけだ。私はスレッドプールの専門家じゃないから、何を言っているのか分からないかもしれない。

└

面白いね。私は.Netプログラマーじゃないけど、いつも.NetはJavaエコシステムから勝ち取ったアプローチを取り入れていると思ってた。Javaのアプローチやフレームワークは先駆的で競争的だけど、.Netはそれを追いかけてベストなものをつかむ感じ。だから、競争するアプローチやフレームワーク（例えばORMみたいな）ではなく、.Netにはただ一つ、みんなが使っている最高のものがあるって感じ。でも、あなたのメッセージを読むと、そうは聞こえないね。

Java、特に現代のJavaは素晴らしい言語だよ。JVMは素晴らしいランタイム。もうそれを否定するのは疲れた。

└

大多数のJava開発者は、現代のJavaに触れることもなく、その機能や能力について全く知らないんだ。今、文字通り何千台ものサーバーと何万ものアプリをクラウドに移行しているけど、現代のJavaに近いものは何もない。このクライアントでは、ほとんどがJava 8で、Java 17以上のものは一つもない。だから、素晴らしい現代の機能があるのは一つのことだけど、Java開発者になるなら、実際にまともなバージョンを使えるようになるには努力や運が必要だよ。C++も似たような話だね。最先端のチームにいるなら、新しいものを使えるかもしれないけど、最新でもC++11に relegated される可能性が高い。ここでの.NET側では、そんなにひどいことは見たことがないよ。確かにレガシーなASP.NETアプリはたくさんあるけど、.NET Coreアプリも結構ある。まだCore以降のバージョンには到達してないけど、Javaよりは健康的な状態だと思う。要するに、「古代」のプログラミング言語の現代のバージョンは素晴らしくて、実際に物事を改善するんだけど、古いプログラミング言語を使っていると、レガシーなものを維持することに縛られて、キラキラしたものを使う機会はないってことだね。平均的なプログラマーはFAANGの面接すら受けようとしないし、ここでよく見られるように、何週間もleetcodeやプログラミング言語のトリビアを頑張るなんてことはないだろうし。

Javaは素晴らしい成功物語だよ。ただ、正直に言うと、ジェームズ・ゴスリングが火付け役だったけど、彼が管理者ではなかった。Java 1.1や1.2の頃から、ランタイムやライブラリ、言語の決定に特に関与していなかったし、後にはジェネリクスの鍵でもなかった。マーク・ラインホルドは1.1からずっとハンズオンのリーダーで、初期のJITやHotSpot、1.2の10倍クラス爆発を統合して、Oracleの買収を経てチームを運営してきた。KotlinやClojureのような動的言語に適したJVMを作り、オープンソース化し、リリースのペースを速め、現代の言語機能の基盤となるJVMメソッドやフィールドハンドルを推進し、GC間の移行を行ってきた。私が知る限り、Javaを素晴らしくしているすべては、マーク・ラインホルドが推進し、導いてきたおかげだよ。

└

コアチーム全体が素晴らしい。ゴスリングは開発の観点から実用的な言語を求めていた。年月が経つにつれて、開発体験の上にかなりの機械的な共感を持つ言語に洗練されてきた。マーク・ラインホールドやブライアン・ゴエッツのような人たちのおかげだ。オラクルという大企業には愛着はないけど、そのグループを前進させ続けてくれたことには深く感謝している。

└

Javaは素晴らしい成功物語だね。ただ、正直に言うと、ジェームズ・ゴスリングが火付け役だったけど、実際には管理者じゃなかった。これは、リーナスがgitのために2週間だけゼロからハッキングしたから、彼がただの火付け役だと言っているようなもんだ。今や世界中がgitを使ってるし。

└

KotlinやClojureのような動的言語についてだけど、Kotlinは動的言語じゃなくて、Javaと同じく静的型付けなんだよね。

ゴスリングがサンにいた頃、彼はNeWSウィンドウシステムの二人の主要アーキテクトの一人だった。Xウィンドウシステムは「ダム」な表示デバイスのために設計されていて、表示要素はすべて静的で、サーバーからあまり作業を必要としなかった。NeWSは（サン）ワークステーションで動作するように設計されていて、計算能力が豊富にあったので、Postscriptに基づいていた。NeWSクライアントは、静的なコマンドだけでなく、サーバーにプログラムを送信した。ゴスリングは当然のことながら、JavaをNeWSモデルを念頭に置いて設計した。ウェブページは静的なHTML文書ではなく、プログラムだった。私が彼に「The Java Programming Language」のコピーにサインしてもらったとき、JavaはNeWSの復讐かと尋ねたら、彼はただ微笑んだ。

└

これの結果がDisplay PostScriptだった。最初の仕事では、SPARCStation 2とSPARCプリンターがあったんだ。SPARCStationは本当に素晴らしいもので、ストレージペデスタルと豪華なサンモニター、カラーフレームバッファの上に素敵なOpenWindows GUIがあった。デスクに座っているオペレーターはしばしば初心者の事務員だったけど、私たちはそのマシンでいくつかのインターネットサービスも運営していた。しかし、私たちの部署はそのSPARCプリンターに依存していて、毎日何百枚もの紙を出力していた。でも、プリンターが正常に動作し続けるとは限らなかった。Winmodemって聞いたことある？SPARCプリンターは基本的にそれだった。すべてのイメージングロジックがソフトウェアに含まれていて、サーバーで実行される「ダムディスプレイデバイス」として設定されていた。ページはPostScriptで書かれ、印刷サーバーでレンダリングされ、プリンターにフレームバッファ/モニターのように送信されていた。残念ながら、何らかの理由でサーバーのソフトウェアはあまり信頼性がなく、プリンターのハードウェアも信頼できなかったため、この奇妙な共生的寄生関係のせいで、プリンターが詰まるとサーバーもダメになってしまった。すべてのプロセスが「D」状態になり、負荷平均が急上昇して、私たちの作業は完全にストップ。デスクトップから作業者を引き離して、サーバー全体を再起動し、プリンターを再設定し直さなければならなかった。そのプリンターは、私が事務員からネットワークオペレーター、そしてシステム管理者に移行する間、ずっと夢に出てきた。そして、2011年になってやっとプリンター全般と和解できた。SunOS 4とSPARCエコシステムが恋しいけど、Display PostScriptにはさよならだ。

└

WaylandがXの現代の後継であるように、NeWSの現代の後継もあるよね。それはJavaScriptを使ったブラウザで、PWAやElectronがよりスムーズなデスクトップ統合を提供してる。Goslingが、NeWSが結局勝ったこと、しかもMicrosoftのシステムでもそうだったことについてどう思ってるのか気になるな。

他の言語やエコシステムを試してみた後、Java（とJVM）をもっと評価するようになった。みんながJavaよりずっと良いと言ってたから。結局、毎回「隣の芝生は青い」って感じだった。実際に大きな改善だと思ったのはRustだけ（今のところは楽しく使えてる）。スタートアップにとって「クール」な選択肢として見られないのは残念だと思う。今のところ、他の言語と比べて生産性の差は小さいか、存在しないから。

└

まったく同感。Goは特に失望した。すべてを約束していたけど、Javaからのサイドグレードにしか感じなかった。むしろダウングレードだよ、Goのエラーにスタックトレースが付くまでは。

└

同じく！ほぼ30年のキャリアの途中で飽きてしまって、非JVMプロジェクトを試してみようと思った。2年間、他の言語を使ったプロジェクトをやってたけど…キャリアの中で最悪の2年間だった :)

└

面白いね。ここ2ヶ月、フルタイムでRustを試してるけど、サーバー開発に関してはJavaと比べて「楽しい」と呼べるのが本当に不思議だ。Rustは地雷原を歩いているような感じで、午後の生産性を台無しにするようなライフタイム問題に出会わないことを祈っている（最近、既知のコンパイラバグかもしれない何かで午後を無駄にしたけど、あまりにもひどいシグネチャのメソッドだったから確信が持てなかった。結局、マクロを使って再コーディングした）。型安全性の感覚は満足できるけど、全体の体験を「楽しい」と呼ぶの？

└

私の意見はプロジェクトの規模に関することだね。通常、人々は10年以上の経験がある100人以上のエンジニアがいるJavaプロジェクトから、グリーンフィールドの進化したハローワールドに移るから、そりゃあ気分も良くて生産的に感じるよね。それに、オープンソースの人たちが言うように、「書き直しは常に良い」っていうのもあるし、いいセキュリティレビューにもなる。でも、企業は定期的に完全な書き直しをするリソースがないことが多いから、Googleでしか見たことないな。

└

個人的にはC#はJavaよりも遥かに進んでいると思うし、意味のある方法でね（例えば、ジェネリクスの実装が劇的に良いし、値型はもうずっと前から存在してるし、使うのが嫌にならないFFIシステムもあるし）。でも、Unity以外でC#について話す人はあまりいないみたい。マイクロソフトは昔、これを広めるチャンスを逃したね。

└

同じだね。小規模から中規模のプロジェクトでjs/tsを使った後、Javaが本当に好きになった。中規模から少し大きめのプロジェクトで働いた後は、Javaを愛するようになったよ。

キャリアの大部分をJVMでコーディングしてきたけど、ここ数年はJava以外の言語、Scala、Clojure（個人的にはこれが一番好き）、Kotlinでやってきた。しばらく失業してたけど、やっとPythonの仕事のオファーをもらった。JVMの経験の需要が減ってきているように見える。そろそろ次に進む時かもね :shrug: 年も取ったし…安定した給料がある限り、君が言う言語でコーディングするよ。今はちょっとした個人プロジェクトをScalaでやってるけどね。 :)