Qiita 3 - キータぞ、来たぞ、キータだぞー

**デフォルトの名無しさん** · 2023/05/28(日) 09:56:01.47

Hello hackers !
Qiitaは、エンジニアリングに関する知識を記録・共有するためのサービスです。
コードを書いていて気づいたことや、自分がハマったあの仕様について、
他のエンジニアと知見を共有しましょう ;)

https://qiita.com/

Qiita（キータ）は、Incrementsが運営するプログラミング情報のナレッジコミュニティ。
2016年現在で日本最大のプログラマーコミュニティとされている[1]。

https://internet.watch.impress.co.jp/docs/news/1025972.html

前スレ Qiita
https://mevius.5ch.net/test/read.cgi/tech/1542357242/
Qiita 2 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1658762410/

**デフォルトの名無しさん** · 2023/12/14(木) 11:15:16.07

プロセス間通信にコストがかかるからでは？
知らんけど

**デフォルトの名無しさん** · 2023/12/14(木) 11:18:51.20

何万スレッド起こそうが、通信デバイスが一つなら
一つのスレッド以外後はひたすら待ってるだけだしなぁ

**デフォルトの名無しさん** · 2023/12/14(木) 11:19:33.74

>>725
https://atcoder.jp/contests/abc332/submissions?f.Task=abc332_a&f.LanguageName=AWK&f.Status=AC&f.User=
AWKで2msだから准教授が持てる力の全てを発揮して本気で作ったElixirプログラムはインタプリタより遅いことになるな

**デフォルトの名無しさん** · 2023/12/14(木) 11:19:57.78

単なる待ち行列の捌き方の違いでしか無いんだよなぁ

**デフォルトの名無しさん** · 2023/12/14(木) 11:27:56.68

>>750
現在の何万接続も同時に捌く最新型の各種サーバーはそのように作られている
ネットワークデバイスやその通信データに対してそれ以外の方法で作るとCPUは暇で遊んでしまうため

>>751
マルチプロセスにするメリットはないため1つのプロセス内でマルチスレッドを使う
CPUコアスレッド数よりも多くのスレッドを動かすのは無駄にスレッドスイッチングが発生し不利となるため限定した数のスレッドを動かしている
そのCPUコアスレッド数分のマルチスレッド上で数万個の軽い非同期タスクを動かすことでCPUの待ち時間を可能な限り無くしている

**デフォルトの名無しさん** · 2023/12/14(木) 13:11:25.11

>>748
Elixirが本当にGPU処理をカンタンに書けるなら、もっと有名だったろう
一時期openCL使ってたけど、まず使えるようにするまでも面倒だったな
（今は簡単なのかもだけど）
使えるようにしてからは、ヤッホ～イだったw

**デフォルトの名無しさん** · 2023/12/14(木) 13:17:27.28

>>756
それだと10万のプロセスが扱える利点なくね？w

**デフォルトの名無しさん** · 2023/12/14(木) 13:32:55.03

>>758
プロセスではなくマルチスレッド上に何万もの非同期タスクを動かしてるんだよ
Rustならスタックレスなコルーチンで実現されていてGoならスタック付きgoroutine

**デフォルトの名無しさん** · 2023/12/14(木) 13:43:48.30

ていうか現にElixirだと捌ききれなくてRustで書き直したという事例がそこにあるわけだがいつまで机上の空論を支えにしてるんだ

**デフォルトの名無しさん** · 2023/12/14(木) 13:45:00.14

>>759
十万のプロセス使わないなら使える利点なくね？
という話だぞ？

**デフォルトの名無しさん** · 2023/12/14(木) 14:03:29.37

>>760
>>747の事かな？
747はElixirのMapSet、List、OrdsetをFFIで外出ししたと言う話だね
discordのgithubでピン留めされてるのはElixirプロジェクト(とJS/TS)

discord自前のRustプロジェクトは1年以上コミットが無いですよ

**デフォルトの名無しさん** · 2023/12/14(木) 14:41:05.58

>>758
プロセスはスイッチングコストが非常に大きいため、
プロセスを動かせば動かすほど損をするという基本常識を理解しよう。
そのためメモリを共有しスイッチングコストが軽減されたスレッドが代わりにある。
そのスレッドもスイッチングコストが大きいため、
1スレッド1クライアント接続だと何万もクライアントが同時接続したら動かない。
よってスイッチングコストが極めて軽量で非同期に動くマイクロタスクを用いるのが主流となっている。

**デフォルトの名無しさん** · 2023/12/14(木) 14:55:20.21

>>763
そこまでわかってるならなんで10万プロセス使えるってホルホルしたの？w

**デフォルトの名無しさん** · 2023/12/14(木) 14:58:52.36

俺じゃないので知らん。
そんなバカな主張してるやつもいないだろ？

**デフォルトの名無しさん** · 2023/12/14(木) 15:05:17.25

10万のプロセスと書き込んでいるアホは>>744と>>758

**デフォルトの名無しさん** · 2023/12/14(木) 15:08:18.14

地球温暖化とコンピュータのエネルギー消費の問題にElixirで立ち向かう〜「コンピュータと地球温暖化は 決して無縁ではない」(2022年版)
https://qiita.com/zacky1972/items/a67459bf36f7b369b946

地球温暖化とコンピュータのエネルギー消費の問題にElixirで立ち向かう〜機械学習の消費電力あたり性能の改善に向けて
https://qiita.com/zacky1972/items/fc74503c33839b64d0a3

Elixirを使ってコンピュータの電力消費を抑える目論見みたいだけども実行効率で他の言語に劣るElixirを使う意図がわからん。

都合が良い話しかしてないようにも見える。

**デフォルトの名無しさん** · 2023/12/14(木) 16:07:24.88

ああなるほど
>>740を無かったことにしたくて頑張ってスレを流してたのかw

**デフォルトの名無しさん** · 2023/12/14(木) 16:13:09.80

>>758
>>764
10万個動くのは
Goならgoroutine
Rustならtask
Elixirならlightweight process
OSのプロセスの話なんて誰もしていないことに気づかなきゃ
そのへんの今どきの言語どれかをかじったことがあるならすぐわかるでしょ

**デフォルトの名無しさん** · 2023/12/14(木) 16:42:29.46

だから、ネット1回線あたりにそんなキャパは無いからw

**デフォルトの名無しさん** · 2023/12/14(木) 17:34:03.34

>>769
プロセスはOSが作るんだぞ？w
そこから説明がいるんかいw
実行ファイルを実行した時のプロセスと同じものだぞ？w

**デフォルトの名無しさん** · 2023/12/14(木) 17:34:30.30

>>753
非同期プログラミングどころかネットワークプログラミングすらしたことのない子供が暴れてるのか？
まずネットワーク通信はOSにより抽象化されているためプログラムで通信デバイスを直接操作したり待つことはない
次に古典的なブロッキング同期でマルチスレッドを使う単純な方法でもlisten/accept専用スレッドはacceptするとすぐに別スレッドに任せてその別スレッドが通信を行なう
プログラミングをしたことのない子供だから知らないのか？

**デフォルトの名無しさん** · 2023/12/14(木) 17:36:36.25

>>767
CPUは使いまくるし実行速度は遅いしで絶対電力効率悪いわな

**デフォルトの名無しさん** · 2023/12/14(木) 17:39:47.54

>>772
今度はスレッドの数も必要ないと言い出したがそれだとプロセスに続いてますますElixirの利点なくならね？w

**デフォルトの名無しさん** · 2023/12/14(木) 17:42:38.14

>>771
みんなが話しているのは一つのOSプロセス内の話ですよ
一つのOSプロセス内で複数のOSスレッドが動くのです
一つのOSプロセス内で複数の軽量プロセス／軽量タスク／軽量コルーチンが動くのです
だから誰もOSプロセスの話なんてしていません
ここまで読んだところ発端の>>740の人も軽量プロセスを意味する「小プロセス」と書いていますね

**デフォルトの名無しさん** · 2023/12/14(木) 17:55:03.81

>>751
常識だろ
同じメモリ空間を使うためスレッドを使い、CPUを限界まで使いこなせるようにするためCPUコアの分だけスレッドを起動する
GoもRustのtokioもそれが指定しない時のデフォルト挙動となっている

**デフォルトの名無しさん** · 2023/12/14(木) 18:07:20.47

>>772
馬鹿はハードの事情も知らずにサービス開始と共にキャパオーバーで障害発生させるのかw

**デフォルトの名無しさん** · 2023/12/14(木) 18:27:59.46

>>775
えっと、OSプロセスって何？w
プロセスを作るにはOSに依頼しないといけないわけで実行ファイルを実行しようがAPIを呼ぼうがファイルをロードしないだけで同じだぞ？w

**デフォルトの名無しさん** · 2023/12/14(木) 18:30:01.63

>>776
プロセス10万作る君に10万作ったプロセスはどうすんのって聞いたというところから説明が必要な感じ？w
なんかわかってないやつと話すといちいち話を戻されてめんどうだなー

**デフォルトの名無しさん** · 2023/12/14(木) 18:32:21.00

どれだけ話をごまかそうとElixirが遅いことに変わりはないんだな
計測すればわかること

**デフォルトの名無しさん** · 2023/12/14(木) 18:32:58.40

>>778
各モダン言語の軽量タスク相当はプロセス内で大量に生成するため新たにプロセスを作る必要はない
無知をさらしていないでまずは基礎知識を身につけてはどうか

**デフォルトの名無しさん** · 2023/12/14(木) 18:36:52.31

>>779
あんさん一人だけElixirの軽量プロセスとOSのプロセスの区別ができてなくね??
OSのプロセスを10万はリソース的にありえないと誰でもわかるからさ
区別つかないなら知的境界

**デフォルトの名無しさん** · 2023/12/14(木) 19:13:15.18

>>781
作れる利点がなくなるよねって話の三回目に入る？w

**デフォルトの名無しさん** · 2023/12/14(木) 19:13:56.39

>>782
もうちょい調べてから書かないと恥の上塗りになるだけだぞw

**デフォルトの名無しさん** · 2023/12/14(木) 19:22:47.99

自演で恥ずかしい過去ログ流してもElixirは速くなったりしないしスレが消えたりもしないんだよなあ

**デフォルトの名無しさん** · 2023/12/14(木) 19:27:28.75

他の言語に比べれば大量の軽量プロセスサポートがあるElixir・Go・Rustなどが圧倒的に有利なのは当たり前だが
Elixirはイミュータブルに拘りすぎていてガベージが大量発生するからかその中では遅いよな
GoもElixirと同じくガベージコレクションを抱える言語だけどミュータブルも使えるしエスケープ解析でヒープ利用回避もあってElixirより速い
RustはC/C++と同じくガベージコレクションがないだけでなくヒープ利用回避がGoよりさらに積極的に可能でさらに速い

**デフォルトの名無しさん** · 2023/12/14(木) 19:30:41.46

インタプリタの数百倍遅いのにガベージどうこういう話じゃないだろ

**デフォルトの名無しさん** · 2023/12/14(木) 19:31:52.15

そもそも大量の軽量プロセスなんか使うことないからまったく意味ないって結論出たろうに

**デフォルトの名無しさん** · 2023/12/14(木) 19:35:21.32

>>788
GoでもRustでもウェブバックエンドなどを中心に普通に使われまくっているぜ

**デフォルトの名無しさん** · 2023/12/14(木) 19:58:49.62

【11万文字越え】プログラミング初心者に贈る即戦力ガイド
https://qiita.com/nuco_bk/items/27f5ad03d0c4b41241fc

> 4. よく使われる英単語一覧（全759語）
> なお、ここで紹介した単語の一覧についてはこちらの記事から引用させていただいております。
> プログラミング必須英単語600+ | プログラミング英語検定

759語のコピペは引用じゃないと思ったが？
引用マークの「>」を付けてないし引用にしては数が多すぎる

**デフォルトの名無しさん** · 2023/12/14(木) 20:16:06.62

10年後のために「私自身が」今勉強しておきたい技術〜Elixir, Nx, SIMD/ベクタ命令, GPU, FPGAプログラミングの高速化を極めたい！
https://qiita.com/zacky1972/items/16551040cc42696127fb
> 取り組みたいこと
> しかしながら，コード最適化の専門家としては，より高速なNxバックエンドを作ってみたいという野心が私に芽生えました。

「コード最適化の専門家」だそうだ。

**デフォルトの名無しさん** · 2023/12/14(木) 20:29:36.51

>>791
その人の少し前の記事を見たら
Elixirの遅さをちゃんと認識してるな

＞現状の Elixir の実行時環境である Erlang VM (アーランブイエム) は，Rust や C/C++ などのネイティブコードにコンパイルするプログラミング言語処理系と比べて低速です。
＞
＞そこで，Elixir (というか Erlang VM) には，NIF(Native Implemented Function)というネイティブコード実行に関わるAPIが整備されています。
＞NIFは通常C/C++で書くのですが，Elixir では Rustler (ラスラー)というライブラリによって NIF を記述するプログラミング言語として Rust を利用することができるようになります。
＞
＞Rustler によって Elixir と Rust は共存共栄の道を辿ることができます！

**デフォルトの名無しさん** · 2023/12/14(木) 21:05:29.39

> Rustler によって Elixir と Rust は共存共栄の道を辿ることができます！

Rustだけで良くね?

**デフォルトの名無しさん** · 2023/12/14(木) 21:59:19.62

>>789
次にお前は「使われているのはスレッドだ」と言う

**デフォルトの名無しさん** · 2023/12/15(金) 01:07:06.13

前にも書いたけど、

例えば、C で100 スレッド起動するよりも、
Go で100 goroutine 起動すると、
6 スレッドしか使わずに、実行時間も半分になる。
つまり、スレッドの起動時間が遅い

OS のプロセス/スレッドは遅い

Elixir, Rust, Go の
軽量プロセス／軽量タスク／軽量コルーチンの方が速い

**デフォルトの名無しさん** · 2023/12/15(金) 01:26:29.98

地球温暖化とコンピュータのエネルギー消費の問題にElixirで立ち向かう〜「コンピュータと地球温暖化は 決して無縁ではない」(2022年版)
https://qiita.com/zacky1972/items/a67459bf36f7b369b946
> このような状況の時に，クロック周波数を上げることで乗り切るか，クロック周波数を抑えたまま複数のコアに負荷分散して並列処理するかという選択肢があると思うのですが，後者の方が消費電力的には有利であることが多いのではないかという主張になります．

> FortranやC++等によるマルチスレッドによる実装には，デッドロックや性能低下の問題が起こりやすいという点を指摘したかと思います．Elixirを用いることで，それらのほとんどを回避することができると主張しています．

複数にコアにまたがる処理でElixirが高効率という主張かあ。

なんか実例挙げて言ってんのかな、自称コード最適化の専門家は。

**デフォルトの名無しさん** · 2023/12/15(金) 01:34:51.66

遅い言語で並列化するくらいなら速い言語で逐次処理しますわ

**デフォルトの名無しさん** · 2023/12/15(金) 02:16:26.21

スパコンの電力当たりのみたいに、どの言語がどの程度効率いいか比較するのもいいかもね
どのような処理内容にするかも思案のしどころだけど
あ、オレはgoとかrustとか全然わからんからムリ
（もうあるかは知らない）

**デフォルトの名無しさん** · 2023/12/15(金) 02:17:25.67

あ、R23でいいのか汗

**デフォルトの名無しさん** · 2023/12/15(金) 02:18:03.31

>>799
あ、違うわ…寝ます

**デフォルトの名無しさん** · 2023/12/15(金) 07:19:04.05

>>797
並列化は当たり前で
並行化の話がされている
批判している人はこの区別がついていないのかな

逐次処理は論外
例えば1000ヶ所と通信するとして順に処理していったら待ち時間で時間かかりすぎる

**デフォルトの名無しさん** · 2023/12/15(金) 08:16:29.01

>>801
実際に測ってCの逐次よりElixirの並列が遅かったら笑うが
Rustで並列処理をすればいいだけでElixirを使う意味がないよね

**デフォルトの名無しさん** · 2023/12/15(金) 08:23:02.74

ていうかもしかしてElixirに並列処理させるより接続数の数だけJavaやPHPのプログラムを立ち上げて排他はDBに任せた方が速いんじゃないかっていう

**デフォルトの名無しさん** · 2023/12/15(金) 10:02:52.05

>>801
だから、通信は一度に一つの相手としか繋げられないんだから、どう書こうが変わらないよ
変わるとすれば切り替えのオーバーヘッドの違いだけ

**デフォルトの名無しさん** · 2023/12/15(金) 10:24:30.21

>>804
>通信は一度に一つの相手としか繋げられない
これはpingが200msの相手達(複数)とは1秒間に合計5回しか通信出来ないと思ってるのか？

**デフォルトの名無しさん** · 2023/12/15(金) 10:36:14.71

>>805
馬鹿は話し掛けるなw

**デフォルトの名無しさん** · 2023/12/15(金) 10:42:34.89

>>802
まずは並列(parallel)と並行(concurrent)の違いを勉強しなさい
速さを求めるならRustが良いのはその通り

>>804
通信は同時に数万ヶ所と繋いで通信できる
ネットワーク通信プログラミングの基礎を学びなさい

**デフォルトの名無しさん** · 2023/12/15(金) 10:47:32.82

>>807
だからさ、そんなマクロな視野でコード組むから
リリースした途端にサーバ落ちるんだよw
一つのくちから1パケットづつ順に送り出してんだからさw
受信も一つのくちからしか入って来ないからな
CPUの時間単位で考えたらかなりの待ち時間だぞ

**デフォルトの名無しさん** · 2023/12/15(金) 10:50:21.81

>>807
ずっと並列でホルホルしてたのに並列が意味ないとわかった途端に並行の話に切り替えるの笑うわ
並行ならなおさら10万プロセス必要ないとわかったらおとなしく遅いの認めろよw

**デフォルトの名無しさん** · 2023/12/15(金) 11:02:05.12

数万同時接続ってさあ
数万のパケットが同時にくるわけじゃなく一定時間に数万通りのipの書かれたパケットが届くことなんだよねえ

同時なのは接続数(最初のパケットが届いてから後、最後のパケットが届いてタイムアウトするまでが1接続)であって通信じゃないんだわ

普通はそれを複数のサーバーにふりわけるから一つのコンピューターで全部処理する必要ないんですわ
でもってそれぞれのサーバーのLANカードの数は物理的に限られてるしそれを処理するCPUのコア数も限られてるから10万の並列(並行ではなく)処理を誇っても意味ないんすわ

ましてや10万のプロセスなんてほぼ休んでるだけなんすわ

**デフォルトの名無しさん** · 2023/12/15(金) 11:07:46.44

だから結局大事なのは並列じゃなく並行の方なんだけど逐次処理がインタプリタの数百倍遅い言語で並行処理しても処理しきれないで取りこぼすだけなんすわw

**デフォルトの名無しさん** · 2023/12/15(金) 11:13:07.61

並行処理ってわかるかなあ？
要はタスク毎に逐次処理するんじゃなく複数のタスクをちょっとずつ順に処理することなんだけど、結局合計でかかる時間は逐次処理と変わらないのわかる？

それどころか切り替えにかかる時間を入れると逐次処理よりも時間がかかるのが並行処理なんだよねえ

だから逐次処理の無茶苦茶遅いElixirは並行処理にも向いてないの理解できる？
できるかなあ？
ちょっとまだ難しいかなあ？

**デフォルトの名無しさん** · 2023/12/15(金) 11:17:58.27

>>810-812
その通りだから>>762のように
discordは逐次処理のMapSet、List、Ordsetだけネイティブコードにして
全体はElixirのままで十分なんだよな

**デフォルトの名無しさん** · 2023/12/15(金) 11:25:03.44

>>812
あまりにも無知でプログラミングをしたことないみたいだから
練習に数十ヵ所のWebサーバーからデータをとって来るプログラム書いてみな
逐次処理は無駄に時間がかかり並行処理はすぐに済むことがわかる
これはネットワークプログラミングの基礎知識だよ

**デフォルトの名無しさん** · 2023/12/15(金) 11:32:29.38

>>814
うーん、何というか、君って悲しい存在だねw
JavaScriptが1スレッドで並行処理を実現してることを知ったら穴掘って埋まりそうw

**デフォルトの名無しさん** · 2023/12/15(金) 11:33:35.63

>>813
そもそも全体をElixirで書く必要がないんだけどw

**デフォルトの名無しさん** · 2023/12/15(金) 11:43:37.92

>>814
数十箇所ならElixirでもどうにか処理できそうだけど数万箇所だと取りこぼしそうって話がわかってないやつおるな

遅い言語でいくら複数のプロセスやスレッド作ってもハードの制限で並列化できる数は限られてるから意味がないよ
並行処理だと休みなくパケットが来たときに合計実行時間が逐次処理以上になるから処理の遅い言語は並行処理に向いてないよ

**デフォルトの名無しさん** · 2023/12/15(金) 11:48:08.48

>>815
並行処理だからもちろんシングルスレッドでいいんだよ
ちなみにマルチスレッドを必要とするのが並列処理
JavaScript普通にNode.jsでいいから先程の例をプログラム書いてごらん
逐次処理は遅く並行処理は速いというネットワークプログラミングの基礎知識がわかるから

>>817
Elixirとかいう言語には一切興味がないのでそこまでは知らん

**デフォルトの名無しさん** · 2023/12/15(金) 12:21:47.92

>>818
お前一人だけ初歩的な話をしてることに早く気づけ
痛々しいわw

大規模アクセスつまりパケットが常に行列に並んでて待ち時間が無い時には並行処理で早くならんということこそ基本だぞ？w
なんでお前一人だけ自分のPCの話をしてんだよw

**デフォルトの名無しさん** · 2023/12/15(金) 12:30:29.65

大規模サーバーは並行処理をやっていて逐次処理をやっている古いプログラムはとっくに淘汰されたもんな
最近の言語がいずれも並行処理に力を入れてるのも需要を反映してる

**デフォルトの名無しさん** · 2023/12/15(金) 12:47:22.02

>>819
サーバーとクライアントと言うべき

> 大規模アクセスつまりパケットが常に行列に並んでて待ち時間が無い時には並行処理で早くならん
これはサーバーの話

> なんでお前一人だけ自分のPCの話をしてんだよw
これはクライアントの話

おまえは説明が下手

**デフォルトの名無しさん** · 2023/12/15(金) 12:51:02.58

逐次処理があり得ないくらい遅いElixirでは並行処理も早くならんし他の言語でも今やasync/awaitが常識だしやっぱりElixirをわざわざ選ぶ理由はないよな
取りこぼしてエラー連発するのが落ち
普通のサイトなら普通にPHPやRubyでいいし速度を望むならRustで書けばいい
一番得意な分野で力を発揮できないって設計思想から間違ってるんじゃね？

**デフォルトの名無しさん** · 2023/12/15(金) 12:52:03.81

>>821
説明が下手というよりお前が(
いやなんでもない
初心者はほめて伸ばさなきゃな

**デフォルトの名無しさん** · 2023/12/15(金) 12:56:17.44

他の言語vsElixirの話は逐次処理vs並行処理の話にすりかえろって指示でもどっかから出てんのかな
並行処理がElixirの独壇場って時代が存在したっけ？

**デフォルトの名無しさん** · 2023/12/15(金) 12:58:42.00

分散処理も区別してください

**デフォルトの名無しさん** · 2023/12/15(金) 13:23:32.97

> ジョーアームストロング氏は、2013 年の Rackspace とのインタビューで次のように述べています。「もし Java が '一度書いたらどこでも実行できる'場合、Erlang は「一度書いたら永久に実行できる」

> Sun Microsystems の Web テクノロジー担当ディレクター、Tim Bray 氏は次のように述べています。 2008 年 7 月のオライリーオープンソースコンベンション (OSCON) での基調講演:
> 誰かが私のところに来て、実際に常時稼動する必要があり、一度に何年もダウンさせるわけにはいかない大規模なメッセージ処理システムを構築するために大金を払いたいと思ったら、私は迷わず Erlang を選ぶでしょう。それを組み込んでください。

> Elixir は、(Erlang 抽象形式経由で) BEAM バイトコードにコンパイルされるプログラミング言語です。

://en.wikipedia.org/wiki/Erlang_(programming_language)

> PhoenixはElixirで記述するWebフレームワーク。
> ちょうどRubyとRailsのようなもの。
://zenn.dev/hiroe_orz17/articles/647ec2155d8088

> Elixirは、低レイテンシで分散型のフォールトトレラントシステムや、Webや組み込みシステムの領域で成功を収めている、Erlang VMを利用します。
://elixir-lang.jp/

> OSネイティブなプロセスよりもはるかに軽量な「プロセス」を持ち、独自の実行環境（Erlang VM）上で動作する。
> また、Erlangのプロセスは他のプロセスからは分離されていて、メモリ領域を他のプロセスと共有することがなく、プロセス間でのデータ共有はメッセージパッシング機構を使用して行う。
> このため、Erlangではあるプロセスに問題が発生しても、他のプロセスに影響が及ぶことが少ない。
> こうした特徴から、Erlangではスケーラブルでリアルタイム性を持った、可用性の高いプログラムを構築できる。
://atmarkit.itmedia.co.jp/ait/articles/1608/30/news021.html

**デフォルトの名無しさん** · 2023/12/15(金) 13:35:08.42

実際のところ何年もダウンさせない需要もないよ
どうせ時代に合わせてセキュリティーパッチを入れたりハードを交換したりしなきゃいけないし

そういう時に普通にやってる方法は運用しながら新しいプログラムを新ハードで動かしてデータをインポートしてデータが完全に同期したら新しい方のサーバーを公開する
それだけ

古いハードは使えるなら増強用として再利用したり別のところで使うしデータを完全に消去して中古として売ることもできる

**デフォルトの名無しさん** · 2023/12/15(金) 13:38:40.54

要するにElixirの強みを活かせる場がないのに遅いという明確な弱点があるから流行らないというだけ

10万のプロセスが作れるとか一流のプロジェクトマネージャーが金と時間をかけて作れば何年もメンテ不要になるわずかな可能性があるとかそういうの求めてる場所ってほとんど無いから

**デフォルトの名無しさん** · 2023/12/15(金) 19:44:55.47

某准教授は一流のプロジェクトマネージャーということだな

**デフォルトの名無しさん** · 2023/12/15(金) 20:14:12.96

何年も動いてるシステム作ったことあるの？

**デフォルトの名無しさん** · 2023/12/16(土) 14:21:28.83

【11万文字越え】プログラミング初心者に贈る即戦力ガイド
https://qiita.com/nuco_bk/items/27f5ad03d0c4b41241fc

高評価されてる様子な記事だけど

> def calc(a, b):
> 　　sum = a + b
> 　　return sum

↑が「引数のa, bがどのような変数を受け取るのかわかりません。」だそうで改善版が

> def add(first_integer, second_integer):
> 　　total = first_integer + second_integer
> 　　return total

という説明だけど、名前に型含めるとかいまどき正気かな?

def add(a: int, b: int) -> int:
　　return a + b

型ヒントで良くね?

> def print_fruits(fruits_name):
> 　　print(fruits_name)

「この関数名なら「フルーツの名前を出力する」と認識することができ、可読性が高くなります。」だそうだけど

def print_fruits_name(fruits_name):
　　print(fruits_name)

フルーツの値段や重さじゃなくて名前を出力するならそれが分かる関数名にするべきだろう。

**デフォルトの名無しさん** · 2023/12/16(土) 14:23:22.83

あとコメントで指摘されてるけど

> def add(int_1: int, int_2: int) -> int:
> 　　return int_1 + int_2
>
> def print_num(int: int) -> str:
> 　　print(f"This num is {int}")
>
> num: int = add(5, 10)
>
> print_num(num)

酷い。業務でプログラミングに携わった者の書いたコードとは思えん。
本とか読んで勉強はしてるんだろうけど理解して身についてる感じじゃないなあ。

**デフォルトの名無しさん** · 2023/12/16(土) 14:26:59.75

会社の宣伝として公開してる記事なんだろうけど社内でレビューすらやってない感じ。

**デフォルトの名無しさん** · 2023/12/16(土) 14:39:20.13

返事がないところを見ると無いようだな

**デフォルトの名無しさん** · 2023/12/16(土) 14:41:58.89

記事を書く気持ちになれ
自分の利益のために記事を書くんだよ
それが学習したことを書くタイプの記事
従業員が学習したら会社の利益になる

**デフォルトの名無しさん** · 2023/12/16(土) 14:53:08.81

ハンガリアン流行らせたい勢がいるんだろ

**デフォルトの名無しさん** · 2023/12/16(土) 14:54:01.36

>>835
それ公開する必要ある？

**デフォルトの名無しさん** · 2023/12/16(土) 15:07:42.06

>>837
記事を公開したことない？
（公開したことがあるとしたら）学習したことを書いてない？

**デフォルトの名無しさん** · 2023/12/16(土) 15:13:35.73

クソ記事は公開しないほうが良かろう。

**デフォルトの名無しさん** · 2023/12/16(土) 15:40:27.21

>>835
コメントに返信すらないことから察するに正しい知識をまとめよう、みたいな意識はないと思うよ。
ボリュームで圧倒して記事の内容気にしない人にアピールしたいだけだろう。

**デフォルトの名無しさん** · 2023/12/16(土) 16:06:35.20

わかってしまってると（無意識に）省略してしまう
わからない人に向けてを意識しすぎると、クドくなる（どこまでクドくすればいいか難しい）

記事書いたことない奴にはわからんだろな

**デフォルトの名無しさん** · 2023/12/16(土) 16:13:51.23

記事ではVSCodeも紹介してるけどVSCodeならPythonの型ヒント見て型情報の表示や警告出してくれるプラグインくらい当たり前にあるだろう知らんけど。
ハンガリアン勧める気がしれない。
記事の章が噛み合ってないよう見えるのは筆者の理解が浅いからだろうなあ。

**デフォルトの名無しさん** · 2023/12/16(土) 17:09:54.66

>>838
学習したことなんか書くわけ無いじゃんアホなの？
なんでN番煎じの記事を書かなきゃいけないのよ？w
研究成果を書くに決まってんだろ

**デフォルトの名無しさん** · 2023/12/16(土) 17:11:55.77

>>841
どこまでって対象読者を設定するもんだぞw

**デフォルトの名無しさん** · 2023/12/16(土) 17:23:08.70

>>838
お前小学校の読書感想文の宿題であらすじ書いてただろ。

**デフォルトの名無しさん** · 2023/12/16(土) 17:25:16.67

https://qiita.com/zacky1972/items/810a7e8567dbd1688ae3
超初心者向けの問題がElixirを使うと難問に化ける模様
ほんとここまで使えない言語って他にあるのか？

**デフォルトの名無しさん** · 2023/12/16(土) 17:27:54.04

>>843
学習したことを書く理由やN番煎じの記事を書く理由がわからないのはおまえがアホだからだ
そういう記事が大量にあるってことも認めない？

**デフォルトの名無しさん** · 2023/12/16(土) 17:29:32.66

>>845
なんで小学校の読書感想文の話になるのかがわからないが
おまえは小学校の読書感想文で何を書いてたの？ｗ

**デフォルトの名無しさん** · 2023/12/16(土) 18:01:33.39

ID:vLHzsqrkが底なしの馬鹿であることは分かった

**デフォルトの名無しさん** · 2023/12/16(土) 18:08:08.94

横からだけどID:vLHzsqrkのタイプにはインタラクティブな勉強会が必要だな
記事じゃダメだ(書く側でも読む側でも)

記事の数だけ量産して独り善がりするタイプ

**デフォルトの名無しさん** · 2023/12/16(土) 18:13:12.55

自分の他記事リンクでひたすらたらい回ししたり
内容がポエムだったり、何を読んだ勉強しただのリストだったり
とにかく数を書いてランクインしたいとしか見えない