DEV Community: Ken Okabe

Node.js やReact、ESM、Viteの説明

Ken Okabe — Sun, 22 Jan 2023 07:36:00 +0000

まず、大元の話をします。

インターネットというものが登場し、ホームページあるいはウェブサイトという代物が登場しました。

ウェブサイトは、HyperText Markup Language HTMLというハイパーリンク機能があるハイパーテキスト記述言語、マークアップ言語で書かれています。

各ウェブサイトは、ハイパーリンク機能でリンクされていますから、世界規模で、まるで蜘蛛の巣（ウェブ）のようなネットワーク構造を形成しはじめます。

How the World Wide Web Was Born

これがWorld Wide Webです。

WorldWideWebを自在に移動(Explore/Navigate)しながらウェブサイトを閲覧(Browse)

するためにWebブラウザというソフトウェアが登場しました。

Netscape Navigator

Microsoft Internet Explorer

の2トップです。Netscape社とMicrosoft社はインターネットというとつてもない新市場を前に苛烈なシェア争いをします。第一次ブラウザ戦争 1990-2000です。

この頃の最初の最初のウェブサイトは単なるHTMLの文書です。動いたりしません。静的なサイトのみです。

しかし動いたほうがいいということなり、Netscapeの開発者がスクリプト実行機能を搭載した次世代ブラウザNetscapeNavigator2.0をリリースします。

そのとき、たまたまJavaが人気を集めていたので、まるで別物ですが単なるマーケティング上の理由からそのスクリプト言語はJavaScriptと名付けられます。

JavaScriptで動作する動的なWebサイトの登場です。

遅れをとった競合するMicrosoft社は、自社の次世代ブラウザであるIE3.0にもJavaScriptを搭載しようとしましたが、戦争してるわけでNetscapeはライセンス供与を拒否して、泥沼状態になります。

結局NetscapeはMicrosoftのWindowsという圧倒的なシェアを誇るOSとIEブラウザの囲い込み戦略により敗退しますが、Firefoxというブラウザにその技術はオープンソースプロジェクトとして継承されます。

IEのJavaScriptエンジンはクローズドですが、FirefoxのJavaScriptエンジンであるSpiderMonkey はオープンなのでGoogleが資金援助とかやっていました。

しかしFirefoxはオープンソース界隈でよくあることですが、開発が停滞するんですね。Googleのエンジニアはイライラします。ちゃんと仕事をしろ。俺達の技術力ならもっとマシなものを全力で作れるのに、と。こいつらへの資金援助は無駄だと。

Firefoxを見切って開発されたのがGoogle V8 JavaScript Engineというとんでもない実行スピードを叩き出すJavaScirptエンジンであり、それを搭載したChromeブラウザでした。

JavaScript Performance Rundown (https://johnresig.com/blog/javascript-performance-rundown/)

V8エンジンの圧倒的スピードとChromeブラウザのシンプルさはギーク界隈を震撼させます。

第二次ブラウザ戦争 2004-2014年の勃発です。

IE、Firefox、Opera、Safari、Chromeの五択となり当初情勢は混迷を極めますが、ギークだけではなく一般市民までGoogle謹製という信頼性とChromeの筋の良さが評価された結果、現在はご存知のとおりです。

IE 11が増加 - 4月ブラウザシェア

Googleは、V8エンジンだけをChromeブラウザから単体分離してオープンソースで公開しました。自分はリアルタイムでこの辺見てましたが、ああこれはものすごいポテンシャルがあることだなと喜んでいました。これだけ高速なJavaScriptエンジンならばWebブラウザ外でも色々使えるに決まっているからです。

Webブラウザ、レンダリングエンジン、JavaScriptエンジンを整理して図視化してみた - Qiita

2008- node.jsとnpmの台頭

同じように感じたギークは世界中にいて、ライアン・ダールがV8エンジンに入出力を扱えるようにC++で書いたイベントループ機構を足して、ブラウザ外の独立した実行環境としてリリースしました。それがNode.jsです。

Node.js は、イベント化された入出力を扱うUnix系プラットフォーム上のサーバーサイドJavaScript環境である。Webサーバなどのスケーラブルなネットワークプログラムの記述を意図している。ライアン・ダールによって2009年に作成され、ダールを雇用しているJoyentの支援により成長している。

V8 JavaScriptエンジンで動作するが、ChakraCoreバージョンやMozillaによるSpiderMonkey移植のプロジェクトも存在する。

Node.jsは、だからブラウザから分離したJavaScript実行環境であって、ブラウザのほうの表示がどうとかいうのはまったく関知していません。

Node.jsは、非常に効率の良いWebサーバとしてサーバーサイドで活用されはじめると同時に、独自のモジュール/パッケージ管理システムであるnpm

を発展させ（JavaScriptの標準仕様としてモジュールが存在しないので独自に発展させるしかしようがない）、2019年現在まで一大エコシステム・コミュニティを形成してきました。

2011- Browserifyの登場　“bundler”

JavaScriptのモジュール化の標準化が定まらない中、独自のエコを発展させたnodeベースの膨大なJavaScriptモジュール資産（npmエコ）をWebブラウザでも活用すべくBrowserifyが登場します。これは実際結構な力技で、当初自分はよくこんなハックが出来たなと衝撃を受けたものですが、npmの依存関係に従ってモジュールを単一のJSファイルにつなぎあわせる、というものです。現在は、webpackのほうが人気だとは思いますが、いわゆる"bundler"（バンドラ）と呼ばれるものの先駆的存在です。

2013- Reactの登場

HTMLはJavaScriptでイジる仕組みになっているわけです。これは現在も一環して揺るぎません。

HTMLの構造は、ドキュメントオブジェクトモデル (DOM)

としてツリー構造のオブジェクトモデルとして抽象化されています。

動的なWebサイトを実現するためには、JavaScirptからは結局HTMLというよりかはこのDOMを操作していくんですが、JavaScriptのDOM操作APIは出来が悪かったのです。

そして最悪なことに、例のブラウザ戦争の沙汰のせいで、ブラウザによってこのAPIやら挙動が微妙に異なるので、素のDOM操作をして動的なWebサイトの開発は困難を極めました。

そこで登場したのが、jQueryというライブラリです。

jQueryには次のような機能・特徴がある。

ブラウザに依存しないオープンソースのセレクタエンジン Sizzle を使ったDOMエレメントの選択（Sizzle は jQuery プロジェクトからスピンアウト）[3]

DOM操作と変更（CSS 1-3 と基本的なXPathのサポートを含む）

jQueryは開発者コミュニティから絶大な支持を受けていましたが、Facebookのある天才が、とある事実に気づきます。

そもそもDOMがJavaScriptの外部モデルとして存在していて、JavaScriptの操作対象になっているからやりにくい、と。

ならばもう、DOMはJavaScriptの値（ファーストクラスオブジェクト）にしてしまおう。

そうFacebookの技術者は考えました。

ぶっちゃけこれはとんでもないコペルニクス的発想であり、

JavaScriptとは？HTML(DOM)を操作するために生み出されたスクリプト言語

という存在意義、アイデンティティの根幹をひっくり返すような発明です。

しかもそれは、JavaScriptの言語仕様を勝手に変更するということに他ならないので、極めて受け入れられにくいことでしょう。Facebookという巨大なバックがある技術者だから言い出せたことで、結果受け入れられたことだと思います。

要するにこういうことです。

JavaScript ＋ HTML（DOM）＝　JSX

Swatee Chand's answer to How can I learn React JS from scratch?

JavaScriptでは、HTML(DOM)＝操作する対象

であったものが、

JSXでは、HTML(DOM)＝拡張されたJavaScript(JSX)の値（ファーストクラスオブジェクト）

として統合されます。

具体的には、

const helloNode = <div>Hello!</div>;

こう書けます。DOMがJavaScriptの値として組み込まれてしまいます。

こういうのを、仮想 DOM といいます。

この原理をきちんと理解さえできれば、DOMなんてものは、ただのJS(X)の値なので、いくらでも自由に操作できます。

単純なWebアプリならば、静的（動的）なHTMLにたいして、適当に外側のJSから操作することが単純だ、と思いがちですが、ちょっと動的に複雑になれば、途端に破綻します。

プログラムの複雑性に耐久性がなく一貫性もなくなるわけですから、ソフトウェアデザインとして堅牢ではない、ということです。

Vue.jsっていうのもそれですね。Vueっていうのは、こういうJSXがなんたるか？っていうのをイマイチ理解できていない技術者が好む仮想DOMライブラリです。

他方でJSXは素晴らしいのですが、Reactというライブラリが良いか？というと別に良くもありません。これも複雑に肥大しすぎなので見切られてVueのほうへ流れる開発者が多いという事情は理解します。

この辺り踏み込むと泥沼で長くなるので割愛し、ここではJSXの仮想DOMの話だけをします。

たとえば、よくあるToDoリストを考えましょう。

リストが増えたり減ったりするやつです。この場合、DOM自体が増えたり消えたりするわけで、増えたり、消えたりするDOMに対して、外側のJSからどうやってデータを紐づけたりするんでしょうか？

はい、DOMを足せ、DOMを消せ、っていう命令を出すしかないんですね。非常にやっかいです。

一方で、仮想DOMの場合はどうでしょうか？

DOMってのは単なるJS(X)の値です。まあ普通に考えて、DOMのリストっていうのは、JSの配列(Array)のデータ構造になっているでしょうから、その配列の要素を1個増やしたり減らしたりするだけです。

const addArray = arr => item => 
 arr.concat(item); 

const removeArray = arr => index => 
 [...arr.slice(0, index), 
 ...arr.slice(index + 1)];

たとえば配列listにToDoのデータが入っていて、これをリストタグに展開したいのであれば、Array.map を使って、以下のように展開してやればよいでしょう。

const newNode = <ul> 
  {list.map(item => <li>{item}</li>)} 
 </ul>

新しいDOMをこさえるわけですが、こういう新しいDOMを全部ひっくるめる、全部のDOMを構築します。

そして最後に古い全部のDOMと新しい全部のDOMをバーっと比較計算して、差分だけ書き換えろ、というJSネイティブのDOMの命令を「裏側」でやらせます。プログラマは関知しません。ただ新しいDOMを構築して投げるだけです。

ちなみにJSXというのはそのままJavaScriptエンジンでは動作しませんから、JavaScriptへトランスパイルしてやります。

2014- ECMAScript標準化の加速

ブラウザ戦争が収束するのと並行して、ブラウザ世界でもJavaScriptの標準化= ECMAScript標準化が活発化していきます。

ES6(ES2015)ではようやくモジュールが標準化され、importとexportの仕様が固まりました。今後も、 ES2015-2018と立て続けに続くようで標準化は順調に加速していくようです。

2018 すべてのモダンブラウザがES6-Module(ESM)を実装完了

import

より関数型プログラミング的な、dynamic import（動的読み込み）がFirefoxにはまだ実装されていませんが、とりあえず基本的なモジュール化はモバイルも含めすべてのモダンブラウザ（EdgeじゃないIE除く）で実装完了されており、プロダクションレベルでも積極的に利用可能な情況になっています。

Webブラウザがモジュールをそのまま実行してくれるようになってくると（本来そうであるべき）、わざわざなんか面倒で複雑なバンドラって必要？ということになってきます。ReactのJSXをトランスパイルしなければいけないというのも、実はTypeScriptのTSXで書いていたらTypeScriptがやってくれるのでBabelというトランスパイラは不要とかいろいろすっきりしそうな気がします。というか自分はそうしています。

ESM/NPM(CJS)２つの互換性のないモジュールシステムの問題発生

2018年になって、ようやくモバイル含めてもうすべてのモダンブラウザがES6-Module(ESM)が普通に使えるようになった、素晴らしい。ではこれから書くライブラリはすべてESMで行こう！それならわざわざwebpackつかって面倒なセットアップと開発フローはなくて済むんでしょ？

現状はこういう流れになりつつあるのは間違いありません。それが本来の標準化されたモジュール化なのだから。

しかしここで問題はすでに確立されたnode.モジュールのnpmエコがあるということです。nodeのモジュールフォーマットであるCommonJS(CJS)ば後発のブラウザ標準のESMと互換性はありません。２つのメジャーなモジュールエコが互換性なく並立しているというのが現状です。

Reactのコンポーネントはモジュールにそのまま呼応するので、Reactのドキュメンテーションではかなり早くからES6のimport/export準拠で書かれていました。ブラウザでモジュールが実装される前からこのようにES6準拠となるのは、同時期に台頭したトランスパイラ（Babel）と上記バンドラ(Browserify/webpack)に依存して技術を先取りできているからです。

従って、Reactなどの先進的なフロントエンド開発をする際には、もうトランスパイラとバンドラをセットで使うのがデフォという感じになっています。そして驚くべきことに、React開発陣が完全にこの大前提にたっているためにReactライブラリ自体をES6Module(ESM)の仕組みでimportさせるのにネイティブにESM対応モジュールをリリースしておらず、トランスパイラとバンドラにNPM用のモジュールを読ませて変換させるというリリースの仕方をしています。

現状、別に規格化されているわけでもなんでもないnpmというモジュール/パッケージ管理システムとそれを単一ファイルに統合するバンドラを前提にフロントエンド開発が当たり前のように行われている、というのは、すべてブラウザ戦争により標準化されたモジュール化が立ち遅れたことが原因で、なかなか不安定な過渡期であると言えます。

reactライブラリは現在、npmというNodeのエコのパッケージマネージャーで配布()されていて、WebPackやらのバンドラでブラウザのコードとするのは間違いないですが、これは劣った設計です。

すでにnpmエコにおいてもコミュニティは積極的にimport/export準拠でライブラリ・パッケージをリリースしているのですが、それはもちろんwebpack/browserifyのバンドラが処理してくれるという前提で皆そうしているようです。nodeはそもそもが自前のCJSモジュールベースで実装されているわけで、本来互換性のないESM対応についてはチーム内でもなかなか意見がまとまらないようで現状も混迷を極めており、早急な進展も望めない情況のようです。

2023/01 UPDATE

https://esbuild.github.io/

そしてesbuildをベースにした、

https://vitejs.dev/

が主流になりつつあります。

https://2022.stateofjs.com/en-US/libraries/build-tools/build_tools_experience_ranking

VSCodeでF#.NETの開発環境構築する方法を解説

Ken Okabe — Fri, 13 Jan 2023 20:53:06 +0000

事前準備

ポータブル.NETプロジェクト〜開発プロジェクト毎に隔離された異なる.NET Framework SDKバージョンをインストールする方法を解説

VisualStudioCodeが適切にインストールされているとき、

プロジェクトのルートディレクトリから

$ code ./

とすることでVS Codeを立ち上げることが出来ます。

Extensionsからnet を検索

.NET Extension Packをインストール。Microsoft公式提供です。

F#開発に必要なのはこのなかで

Ionide for F#ですが、.NET Extension Packに含まれています。

場合によっては必要ないかもしれませんが、VSCodeが（ターミナルから）起動している文脈に関わらず、適切にローカルディレクトリの相対PATHでdotnetコマンドが使えるように、VSCodeのSettingでdotnetで検索し、

./.net/とSDKの相対ルートPATHを指定しておきます、

https://learn.microsoft.com/ja-jp/dotnet/fsharp/get-started/get-started-vscode

カレントディレクトリがプロジェクトルートであることを確認した上で、

dotnet コマンドのテンプレート機能を利用して、F#プロジェクトのコンソールプログラムを作成します。

$ dotnet new console -lang "F#"

結果、以下のようなプロジェクトになります。

fs-test
├── bin
│   └── Debug
├── fs-test.fsproj
├── .net
│   ├── dotnet
│   ├── host
│   ├── LICENSE.txt
│   ├── packs
│   ├── sdk
│   ├── sdk-manifests
│   ├── shared
│   ├── templates
│   └── ThirdPartyNotices.txt
├── obj
│   ├── Debug
│   ├── fs-test.fsproj.nuget.dgspec.json
│   ├── fs-test.fsproj.nuget.g.props
│   ├── fs-test.fsproj.nuget.g.targets
│   ├── project.assets.json
│   └── project.nuget.cache
└── Program.fs

Program.fs に、たとえば以下のようなコードを追加して、

let f = fun a -> fun b -> a + b

結果、自動的に、TypeAnotation（型注釈）が表示されるようになれば成功です。

初期設定では、異なる表示になると思いますが、好みで上手く調整してみてください。

コードを実行するには、プロジェクトのルートディレクトリで、

$ dotnet run                 
Hello from F#

ポータブル.NETプロジェクト〜開発プロジェクト毎に隔離された異なる.NET Framework SDKバージョンをインストールする方法を解説

Ken Okabe — Fri, 13 Jan 2023 20:46:28 +0000

.NETの異なるバージョン

https://dotnet.microsoft.com/ja-jp/download

.NETにはバージョンがあります。

異なるバージョンの互換性の問題

通常の手順に従うとローカルマシンのグローバル環境にインストールすることになり、たとえば、.NET6.0から.NET7.0にアップグレードする際など、既存の個別の.NETプロジェクトでバージョン互換性の問題が発生してしまいます。

Dockerなどのコンテナ技術は、このような複数の異なるバージョンを互いに安全に隔離して、異なるバージョンでそれぞれ開発されたプロジェクトやアプリケーションを運用するために開発された技術であると言えます。

環境の隔離

Docker（ドッカー）は、コンテナ仮想化を用いてアプリケーションを開発・配置・実行するためのオープンプラットフォームである[5]。

.NET Framework での side-by-side 実行

https://learn.microsoft.com/ja-jp/dotnet/framework/deployment/side-by-side-execution

side-by-side 実行は、アプリケーションまたはコンポーネントの複数のバージョンを同じコンピューターで実行する機能です。共通言語ランタイムの複数のバージョン、および 1 つの共通言語ランタイムを使用するアプリケーションとコンポーネントの複数のバージョンを同じコンピューターで同時に実行できます。

https://atmarkit.itmedia.co.jp/fdotnet/technology/idnfw11_04/idnfw11_04_01.html

.NET Frameworkのバージョン・ポリシー

　これまで、開発者はソフトウェアのバージョンについて、次のような悩みを抱えていた。

ユーザーにできるだけ新しいバージョンを使ってもらいたい。

下位互換性のテストはやりたくないし、完全にはできない。
　また、ユーザーはユーザーで次のような悩みを抱えていた。

新しいバージョンを入れた結果、既存のアプリケーションが動かなくなるのは困る。

新バージョンに問題がある場合は、素早く簡単に、うまく動作していた以前のバージョンに戻したい。

　.NET Frameworkには、これまでの反省が大いに活かされている。ここからは、.NET Frameworkのソフトウェアのバージョン管理方法を解説しよう。

.NETでは実行時からして、バージョン非互換の問題が発生しないようなバージョン・ポリシーがある優れた設計です。

ポータブル.NETプロジェクトの作成が可能

.NET Frameworkでは実行時だけではなく、開発プロジェクト毎に異なるSDKバージョンをインストールすることができます。いわばポータブル.NETプロジェクトが作成可能なのです。

繰り返しですが、通常の手順に従うとローカルマシンのグローバル環境にインストールすることになり、たとえば、.NET6.0から.NET7.0にアップグレードする際など、既存の個別の.NETプロジェクトでバージョン互換性の問題が発生してしまいます。

しかし、ちょっとした工夫でDockerのような仕組みを必要とせず、プロジェクト・ディレクトリー毎に異なる.NET Framework環境を安全に隔離することができます。

ポータブル.NETプロジェクトの作成アウトライン

1. .NET-SDKダウンロード

公式サイトから任意のプラットフォームの特定バージョンの.NET-SDKのバイナリ（アーカイブ）をダウンロードする

2. プロジェクト・ディレクトリにSDKを配置

プロジェクトディレクトリ下に.NET-SDKディレクトリを作成し、そのディレクトリ下で解凍・展開

3. PATHを通す

ターミナル環境とVSCodeで.NET-SDKの相対PATHを通す

1. .NET-SDKダウンロード

公式サイトから任意のプラットフォームの特定バージョンの.NET-SDKのバイナリ（アーカイブ）をダウンロードします。

https://dotnet.microsoft.com/ja-jp/download

おすすめ 、とも書いてあるし、最近安定リリースされた.NET 7.0をLinux環境にインストールすることにします。

全 .NET 7.0 ダウンロード

ここで、通常のインストールならば、OS毎の インストーラー を選択することになるのですが、ポータブルSDKインストールのためにはバイナリを個別に指定してダウンロードします。また、dotnet-install scriptsでもできないことはないかもしれませんが、事前知識やコマンドが煩雑になると思います。

今回は、LInux/x64プラットフォームのバイナリをダウンロードします。

dotnet-sdk-7.0.102-linux-x64.tar.gz というような特定のバージョンと特定のプラットフォームのアーカイブファイルがダウンロードされるはずです。

2. プロジェクト・ディレクトリにSDKを配置

プロジェクトディレクトリ下に.NET-SDKディレクトリを作成し、そのディレクトリ下でダウンローしたアーカイブファイルを解凍・展開していきます。

任意のプロジェクト・ディレクトリを作成します。今回はfs-test という名前のF#(.NET)のためのプロジェクトを作成します。

以下ターミナル環境

$ mkdir fs-test

作成したディレクトリへ移動し、さらに.NET-SDKのディレクトリを作成します。なんでも良いのですが、.netという名前のディレクトリを作成します。

$ cd fs-test
$ mkdir .net

適当なアンアーカイバ−を利用し、すでにダウンロードしているファイルを解凍し、このディレクトリ下に配置します。

結果、以下のようなディレクトリ構成になるようにします。

fs-test
└── .net
    ├── dotnet
    ├── host
    ├── LICENSE.txt
    ├── packs
    ├── sdk
    ├── sdk-manifests
    ├── shared
    ├── templates
    └── ThirdPartyNotices.txt

3. PATHを通す

ターミナル環境とVSCodeで.NET-SDKの相対PATHを通します。

https://dotnet.microsoft.com/ja-jp/download/dotnet/thank-you/sdk-7.0.102-linux-x64-binaries

には、

とありますが、これは$HOMEに配置されたSDKへのPATHを通す方法です。

$HOME/dotnet の代わりに./.net/dotnet と相対パスにする方法もありますが、自分はZSHの.zshrcで、以下のようにdotnetコマンドのエイリアスを作りました。

alias dotnet='.net/dotnet'

ターミナル環境（ZSH）を再度立ち上げるなどして、環境偏向を反映させます。

カレントディレクトリがプロジェクトルートの fs-testであることを確認した上で、dotnetコマンドが通るか？正しいバージョンが表示されるか？確認します。

$ dotnet --version
7.0.102

これで、別の.NETプロジェクトでたとえばNET6.0-SDKを配置した場合、同じコマンドで、相対PATHでプロジェクトローカルのSDK特定されるので、異なる適切な.NETバージョンが表示されるはずです。

ポータブル.NETプロジェクトのSDKのディレクトリである.netのサイズは535.6Mでした。

VSCodeでF#.NETの開発環境構築する方法を解説

Arch Linuxのインストールが超かんたんになっている ~ Arch Installer

Ken Okabe — Fri, 13 Jan 2023 20:39:40 +0000

Archはそもそもインストールすることが難しかった

インストールガイド (難しい)

最近公式からインストールスクリプトが公開

Arch Installer

記事を書こうと思っていたら、すでに書いている人がいた。

Installing Arch Linux Using archinstall Automated Script [Complete Guide]

GUIデスクトップ環境のインストールまで世話をしてくれて、自分の場合はGnomeであるが再起動したらスムーズにGUIデスクトップ環境になった。

基本、鬼門はWifiネット環境の構築なのだが、足場となるイーサネットLAN環境がなくても、今どきはスマホのテザリングでUSBネット接続が可能なので、それをLAN接続代わりにして、あとはスクリプトでGUIデスクトップまで持っていくと、すでにGUIでWifi設定すればいいだけになっている。

あと、通常はGRUBブートの設定がかなり難解なのだが、これはLinuxカーネルのスタブ起動みたいなやつを直接設定してくれており、GRUBを介さずに速やかに起動する構成になるのは素晴らしかった。GRUBフリー。

Manjaroはなぜ人気であり続けたのか？

Ken Okabe — Wed, 14 Sep 2022 00:34:18 +0000

以下の文章は、かつで自分が出没していた某所（Quora）に書いたものです。
2019年

UbuntuよりもManjaroをおすすめしている理由って何ですか?

僕は最近はなんとなくUbuntuを使うことが多かったのですが、この回答で初めてManjaroの存在を知って、少し気になっているところです。

のA2Aです。

★短い答え

Arch Linuxの血統で毛並みが良い（後述）。

Archの利点である、シンプルな設計で、ローリング・リリースの「常に最新バージョンでシステムが統合される」という特徴を継承しながら、初心者にとって導入が難しいということや、常に最新すぎて安定性を損なうので自己対処スキルが必須というハードルの高さを解消している。

Ubuntuで採用されている固定リリースよりも、継続的な使用感をもたらすローリング・リリースのほうが好まれている。またManjaro掘り下げると、Archのシンプル設計の筋の良さがUbuntuよりも優れているし、その情報は確実にArchのドキュメントに存在している。

★長い答え

Linuxディストリビューション情報サイトのDistroWatch

Put the fun back into computing. Use Linux, BSD.

では、一昔は圧倒的人気であったUbuntu それからMintを軽く抑えてManjaro Linuxが人気です。

Manjaroは、Arch Linuxがベースになっています。

ArchはLinux上級者に人気のディストリビューションで、シンプリシティ、ミニマリズムの設計哲学があります。

Arch Linux は、x86_64 向けに独自に開発された、あらゆる用途に対応できる万能 GNU/Linux ディストリビューションです。その開発は、シンプリシティ、ミニマリズム、およびコードの簡潔性に焦点を当てています。Arch は最小限の基本システムの状態でインストールされ、ユーザー自身が、ユーザーの理想とする環境のために必要なものだけをインストールして構築することができます。GUI の構成設定ツールは公式には提供されず、ほとんどのシステム設定はシェル上でテキストファイルを編集することで行います。Arch はローリングリリースモデルをベースとしており、常に最先端であるように努め、ほとんどのソフトウェアは最新の安定バージョンが提供されます。

原則

シンプルであること

シンプリシティは Arch の開発における絶対的な主たる方針です。多くの GNU/Linux ディストリビューションは自身を「シンプル」だと定義していますが、シンプルであること自身にはいろいろな意味があります。

Arch Linux はシンプリシティを、「不必要な追加、修正、あるいは複雑化を行わない」ことと定義し、ユーザーごとに、必要に応じた軽量な UNIX ライクベースのシステム構築を可能とします。要するに、エレガントで最小主義なアプローチだということです。

これは、たとえばPCの上級者が、市販のPCの規定のスペックや、いろいろ不要な仕様には満足できず、ベアボーンから自由に構成して自作PCにする、というのと同じです。とにかくパーツとマニュアルだけ寄越せと。

それ故、必然的にArchは玄人好みのディストロだし、自作PC同様、初心者にはかなりハードルが高いディストロです。しかし、自分で構成させるので、Wikiが他のディストロを寄せ付けないレベルで充実しています。Ubuntuコミュニティも強力で情報は豊富ですが、細かい設定の情報はArchのほうが上で、実際Linuxで困ったことがあれば、”arch” とキーワードくっつてググると的を得た情報がヒットすることが多いです。

１からパーツを組み立てるので勉強にもなります。かといってソースコードから逐一コンパイルする必要もなく、ちゃんとバイナリベースのパッケージシステムがあり、それがローリングリリースされています。

公式以外にもコミュニティベースのレポジトリは充実しており常に最新にメンテナンスされています。Linuxで使えるアプリでArchで使えなかったアプリは今までにひとつもありませんでした。

Ubuntu＝メーカーが販売してるPC　素人向けの情報豊富

Arch = ベアボーンからパーツ組み立てる自作PC　玄人向けの情報豊富

みたいな棲み分けです。

Archは素晴らしいので自分も数年ほどずっと使っていました。しかし、不満も出てきました。

１．ローリングリリースでカーネル含め、あまりにも頻繁に最新バージョンにアップデートするので、更新作業がうっとうしくなる、ちょっとアップデートさぼってたら、カーネル、デスクトップ環境、各種コアライブラリ、軒並み全部アップデートするはめになりしんどい。何よりカーネルもデスクトップ環境もさほど安定してないのを掴まされることはある。

２．インストールはCUIでいいんだけど、さすがに何回も毎度同じ作業をするのはしんどい。

これを解消しているのがManjaroです。

Manjaroのレポジトリーは、Archのレポより１テンポくらい遅く管理されていて、ArchのStableバージョンはManjaroのTestバージョン相当、という具合により慎重で安定したバージョンが提供されており、アップデートもさほど頻繁ではありません。

とにかく足元のカーネルがそんなしょっちゅうアップデートされて安定性も損なったら話にならないわけで、カーネルの安定性が一番重要。

ManjaroのキラーコンテンツはManjaro settings managerで、カーネルのアップデートの状態がわかりやすく、コントロールしやすいことです。

だいたい、一番新しい、LTS+RecommendedのLinuxカーネルをインストールして走らせておけば間違いありませんし、この選択自体ころころ変わるということもありません。

後の使い勝手は、Arch長年使ってたのでよくわかりますが、まったく変わりません。コアシステムの部分は上記のとおりManjaro独自のレポですが、非公式のコミュニティレポはArchと共通なので豊富な資産はそのままということになります。

また、最初からデスクトップ環境とパッケージでGUIインストール環境も提供されているので、初心者への導入ハードルの高さもまったくありません。

あれ、それなら別にUbuntuじゃなくても良くない？ローリングリリースのほうが良いし、ってのが今の流れだと思います。

関数型プログラマーにとっての関数型プログラミングと命令型・オブジェクト指向のイメージ

Ken Okabe — Sun, 11 Sep 2022 09:33:47 +0000

プログラミングの本質は数学的構造の構築
現実世界で時間変化する値に紐づく構造も例外ではない（FRP）
コンピュータのハードウェアのリソースは有限であり、計算速度、メモリの物理的制約がある
したがって数学構造をそのままハードウェアにマッピングするのは無理
そもそも命令型プログラミング、オブジェクト指向（定義の流派問題はとばす）は、数学よりもハードウェアの挙動（時間的変化）に素朴な感覚で着想しデザインされている
数学は本質的にシンプルで論理構造に無駄がなく間違いがない
少なくとも構造を定義するときに間違いがあれば見つけやすい
人間の思いつきや発明、方針、設計には間違いが多い、余計な発明をして問題を複雑にする事を好む
人間の間違いは見つけにくい
間違っていることが明らかであっても間違いを認めず政治的論争になることもある
複雑な構造のほうがいいと信奉する人間はプログラマーに向いていないし、時間の無駄だし、KISSの原則を学べ
プログラミング　＝　数学　＋　人間のエンジニアリング
いろいろ思いついて発明して人間のエンジニアリングの層を厚くしようとするな、人間はそれほど賢くない
数学の土台に手を加える人間のエンジニアリングの層（Wrapper）は薄いほうが望ましい
なぜならば、そのほうが間違うリスクを最小にできるから
だから関数型プログラミングのアプローチはより優れている
オブジェクト指向は、本来、関数、代数構造という数学で実現可能なコードをオブジェクト、クラスという人間の発明で実現しようとした
人間の思いつきや発明、方針、設計には間違いがあるので案の定失敗して、今では回避される傾向にある
当初のカプセル化、継承によりコードが良くなるという哲学はなかったことにされて「正しいオブジェクト指向」とかゴールポストを動かして正当化しようとする人たちは未だに多いのだが、そういうことじゃないから
数学、数学構造は堅牢であり、人間の発想により活用はされるが、時間が経過して、やっぱり使いにくい発明だった、とかゴールポストが動いて元来の方針がチャラになるようなことはない
関数型言語の差異は薄いWrapperであり、本質的に習得した数学部分の知識が無駄になることはない、ずっと共通して使い回せる
図の左側はC#、右側はF#、Microsoft.Netのツートップではあるが、比較するとF#は極端なまでに使われていないし虐げられてるとすら言える(MAUI初日からサポートしてくれという嘆き)、それでも.netの威力で関数型言語の中ではトップクラスに使われている言語なのでもっと増えて欲しいし、MSはもっと大規模な資本投下をF#にむけてすべき

DEV Community: Ken Okabe

Node.js やReact、ESM、Viteの説明

VSCodeでF#.NETの開発環境構築する方法を解説

事前準備

ポータブル.NETプロジェクト〜開発プロジェクト毎に隔離された異なる.NET Framework SDKバージョンをインストールする方法を解説

ポータブル.NETプロジェクト〜開発プロジェクト毎に隔離された異なる.NET Framework SDKバージョンをインストールする方法を解説

.NETの異なるバージョン

異なるバージョンの互換性の問題

環境の隔離

.NET Framework での side-by-side 実行

ポータブル.NETプロジェクトの作成が可能

ポータブル.NETプロジェクトの作成アウトライン

1. .NET-SDKダウンロード

2. プロジェクト・ディレクトリにSDKを配置

3. PATHを通す

1. .NET-SDKダウンロード

2. プロジェクト・ディレクトリにSDKを配置

3. PATHを通す

Next

VSCodeでF#.NETの開発環境構築する方法を解説

Arch Linuxのインストールが超かんたんになっている ~ Arch Installer

Archはそもそもインストールすることが難しかった

最近公式からインストールスクリプトが公開

Manjaroはなぜ人気であり続けたのか？

関数型プログラマーにとっての関数型プログラミングと命令型・オブジェクト指向のイメージ