次世代言語29 TypeScript Swift Go Kotlin Rust Nim

**デフォルトの名無しさん** · 2022/09/17(土) 19:05:49.83

スレタイ以外の言語もok

前スレ
次世代言語28 TypeScript Swift Go Kotlin Rust Nim
https://mevius.5ch.net/test/read.cgi/tech/1661739736/

**デフォルトの名無しさん** · 2022/11/06(日) 18:19:41.71

>>878
プリプロセスで処理されるとか具体的な解析実装はどうでもよくて
TSXという言語の文法としてはあの要素はXMLリテラルとしか言いようがないだろう

**デフォルトの名無しさん** · 2022/11/06(日) 18:46:39.02

>>879
じゃXML使ったテンプレートエンジンじゃダメなの？
というかフロントでC#が使われないのはXMLリテラル（）のあるなしの問題じゃないんだけどな
つまり>>877の
> でもフロントはやっぱReact使いたいんだわ
> React.NETがあれば移行するんだけどねC#はXMLリテラルが無いから難しいだろうな
だと、暗にC#にXMLリテラルが無いからC#でReactみたいに書けるReact.NETのようなものが出ないと言ってるようだが、
そうではなく単純にパフォーマンスとランタイムの容量の問題でやってないだけ（あるいはあるのかもしれないけど流行ってないだけ）だと思うよ
C#をフロントで動かすわけだから
知らんけどBlazorとかで挑戦したんじゃないの？
でも流行らなかったのは詰まるところこれでしょ

**デフォルトの名無しさん** · 2022/11/06(日) 18:57:13.32

うわ

**デフォルトの名無しさん** · 2022/11/06(日) 19:06:37.80

人気の機能なら、フレームワークが対応するだろ

**デフォルトの名無しさん** · 2022/11/10(木) 01:33:05.52

Rustでメモリリーク、あれれ？
https://github.com/lapce/lapce/issues/1668

**デフォルトの名無しさん** · 2022/11/10(木) 09:48:20.76

メモリリークなのかそれ？

**デフォルトの名無しさん** · 2022/11/10(木) 11:50:14.96

rustはメモリリークを防ぐ事を目標とはしません。

**デフォルトの名無しさん** · 2022/11/10(木) 11:55:23.60

メモリリークはRustにおいてはメモリ安全であることを意味します。

**デフォルトの名無しさん** · 2022/11/10(木) 13:18:29.70

そもそも誰かが安全を約束した記憶がないぞ

まずは記録、次に記憶、最後に安全だ

**デフォルトの名無しさん** · 2022/11/10(木) 19:37:50.25

>>886
*メモリリーク除く
て書くべきだよなぁ。

**デフォルトの名無しさん** · 2022/11/11(金) 09:36:33.47

つまり漏れても安全と

**デフォルトの名無しさん** · 2022/11/11(金) 09:53:10.02

問題は2種類ある
消してはいけない記憶を消すのは安全か？
記憶を消した方が得なのに記憶が残っているのは安全か？

**デフォルトの名無しさん** · 2022/11/11(金) 10:48:49.86

Rustならメモリーリークがあっても安心安全なんだよ

**デフォルトの名無しさん** · 2022/11/11(金) 15:34:56.64

>>891
これ、皮肉じゃなくてまじだから

**デフォルトの名無しさん** · 2022/11/11(金) 16:38:39.70

メモリリークってメモリ安全ではないだろ
Rustのメモリ安全性に対する立場誤魔化しすぎやわ

**デフォルトの名無しさん** · 2022/11/11(金) 17:30:26.12

メモリリークって処理系が対処しうる脆弱性なのかね。
どんな言語使ってもそこはアプリケーション開発者の責任にせざるを得ない気がする。

**デフォルトの名無しさん** · 2022/11/11(金) 17:31:41.06

メモリリークで迷惑すんのはOSやユーザなのに
何言ってんだ

**デフォルトの名無しさん** · 2022/11/11(金) 17:56:15.97

まぁよくあるのがイベントハンドラとかの登録解除忘れで
これはGCでも回収できないよね
そういう意味でもメモリリークは安全性に含まないという立場は妥当だと思うけど
（含めてもいいけど、そうすると全部の言語が不安全ということになるからあまり意味ない）

**デフォルトの名無しさん** · 2022/11/11(金) 17:58:17.45

それはリソースリーク。広義のメモリリークかもしれんが

**デフォルトの名無しさん** · 2022/11/11(金) 18:00:02.42

言語処理系自身がどのように努力しても回収できないメモリリークは言語処理系自身のバグでしょ
イベントハンドラの登録解除はプログラマが努力すればリークは防げる
ただrustにはプログラマがどのように努力しても解放できないメモリリークが存在する
だからrustはメモリ安全ではない

**デフォルトの名無しさん** · 2022/11/11(金) 18:07:18.89

トロッコ問題も2種類ある
命に関わらないケースでじゃんじゃん犠牲者を出すタイプ
命に関わる時だけ突然必要悪や合理主義について語り出すタイプ

**デフォルトの名無しさん** · 2022/11/11(金) 18:39:03.33

トロッコの定義がありません

**デフォルトの名無しさん** · 2022/11/12(土) 12:18:21.51

メモリ安全性についてRustばかり注目されてるけど、Ponyも同等以上の安全性だよね
Ponyはアクターモデルで実現している

**デフォルトの名無しさん** · 2022/11/12(土) 14:24:46.04

>>901
アクターモデルの作り方わかってる？
アクターひとつひとつメッセージ待ち受けのループまわするだぜ？負荷が違いすぎるだろ

**デフォルトの名無しさん** · 2022/11/12(土) 14:36:15.84

Ponyはループで待ってんの？
普通はselectとか使うんでは？

**デフォルトの名無しさん** · 2022/11/12(土) 15:48:42.14

>>903
お前はポーリングと勘違いしてそう

**デフォルトの名無しさん** · 2022/11/13(日) 01:05:00.14

>>904
man selectして言ってる？

**デフォルトの名無しさん** · 2022/11/13(日) 04:27:18.51

https://www.theregister.com/2022/11/11/nsa_urges_orgs_to_use/
> NSA は、組織が C や C++ などのプログラミング言語から、C#、Rust、Go、Java、Ruby、Swift などのメモリセーフな代替言語に移行することを奨励するガイダンスをリリースしました。

るるる、るびぃｗｗｗｗｗ

**デフォルトの名無しさん** · 2022/11/13(日) 06:03:11.05

いつの間にかC++とか本屋で入門書すら売られてないんだよな

**デフォルトの名無しさん** · 2022/11/13(日) 14:20:01.12

>>907
でかい本屋しか売ってないね
しかも売れてなさそう

**デフォルトの名無しさん** · 2022/11/13(日) 15:04:33.03

まあ今から最初の言語としてC/C++選ぶのはかなりレアだろうししゃーないわな

**デフォルトの名無しさん** · 2022/11/13(日) 17:21:55.25

いやいや C や C++ は人気上位言語なので
入門書が売れすぎて品不足になっているだけ

**デフォルトの名無しさん** · 2022/11/13(日) 17:58:48.98

arduinoとかで使ってるCにちょっとC++要素が入ってる言語が丁度良い感じする

**デフォルトの名無しさん** · 2022/11/13(日) 18:34:42.17

最近は最初の言語として何選ぶの？Python？

**デフォルトの名無しさん** · 2022/11/13(日) 18:50:35.95

>>912
基幹系・勘定系はJavaだけど
ウエブサイトのフロントエンジニアは今はなんだろ？
なんだかんだいってRubyかPHPだろ

**デフォルトの名無しさん** · 2022/11/13(日) 20:19:47.76

Rubyはランキング入りの人気言語だからな
https://i.imgur.com/QE0WMb7.jpg

**デフォルトの名無しさん** · 2022/11/13(日) 20:20:37.65

ブラウザさえあれば動くjsが一番やりやすい気が

**デフォルトの名無しさん** · 2022/11/13(日) 21:49:19.01

>>905
当然pselectのとこを見る。
お前は待ち受けループという言葉をどう思ってんだ？

**デフォルトの名無しさん** · 2022/11/13(日) 21:51:55.61

>>913
フロントはtypescriptがデファクトスタンダードじゃろ。
勘定系はCOBOLをJavaに書き写しただけのJOBOLだよ。クソ。

**デフォルトの名無しさん** · 2022/11/13(日) 21:58:46.65

>>913
みずほはReact
https://www.mizuho-rt.co.jp/publication/column/2022/infocomm0126.html

**デフォルトの名無しさん** · 2022/11/13(日) 22:02:42.83

>>918
みずほが採用してるってことは、近寄ったらダメってことでは？

**デフォルトの名無しさん** · 2022/11/13(日) 22:05:34.78

>>916
epoll、kqueue、iocpを調べること。

**デフォルトの名無しさん** · 2022/11/13(日) 22:56:17.75

NotionもReact
https://blog.allstarsaas.com/posts/notion-interview-20201111

**デフォルトの名無しさん** · 2022/11/14(月) 00:23:35.41

>>916
うーん、確かにそういう意味ではループ回してるか。すまん、ビジーループでイベント待ってるのを想像してた。
グリーンスレッドにするにしても確かにメッセージポンプ的なのは回すわな。

**デフォルトの名無しさん** · 2022/11/14(月) 10:45:40.10

リソース消費はともかく、各種安全性に関してはアクターモデルは強力だよ
MicrosoftがPonyに影響受けたveronaを公開して研究してるし

**デフォルトの名無しさん** · 2022/11/14(月) 11:41:07.23

C/C++ のメモリ管理を知ってて
手を抜くために別の言語を使うのは合理的だが
最初から C/C++ を知らなくて良いという結論にはならないな

**デフォルトの名無しさん** · 2022/11/14(月) 12:37:18.65

知らなくていいだろ
んでCやったらアセンブリやれだろバカバカしい

**デフォルトの名無しさん** · 2022/11/14(月) 13:49:53.93

アセンブリからCよりも
パンチカードからアセンブリのほうがエポックメイキングだったよな
アセンブリとCはたいして変わらない
複数のターゲットCPUのためにそれぞれアセンブリ書きたくなかったから中間層ひとつ足しただけ

**デフォルトの名無しさん** · 2022/11/14(月) 14:14:09.05

アセンブラがマクロアセンブラに進化しただけで
それまでと大違いで、いたく感動したものだけどな
ましてＣ言語に触れた時はなおさら

**デフォルトの名無しさん** · 2022/11/14(月) 14:34:42.91

今でもCが一番互換性高い言語になってるってのもなんか不思議な話だわな。

**デフォルトの名無しさん** · 2022/11/14(月) 14:48:50.75

ほんまかいな

**デフォルトの名無しさん** · 2022/11/14(月) 14:50:40.71

言語ランキング、首位Pythonが差を広げる中、新興言語でトップ20に入った注目株は？
https://atmarkit.itmedia.co.jp/ait/articles/2211/14/news050.html

TIOBE SoftwareでCEO(最高経営責任者)を務めるポール・ジャンセン氏は、「Rust」が2022年10月にトップ20入りし、11月も20位だったことに対し、次のように解説している(なお、Rustの過去最高順位は、2020年9月の18位)。

将来性のある新興プログラミング言語のほとんどは、ごく短い期間だけ脚光を浴びるものの、本当に流行することはない。われわれは『Kotlin』『Dart』『Julia』といった言語がTIOBEインデックスのトップ20に入るのを何年も待っているが、実現していない。そうした中で唯一の例外がRustのようだ。Rustの人気が上昇している主な理由は、速度と安全性のユニークな組み合わせにある。Rustの今後に要注目だ。

**デフォルトの名無しさん** · 2022/11/14(月) 15:35:15.59

>>923
リソース消費をともかくで片付けるなよ
Rustみたいな低レイヤのプログラミング言語を語る上では全てといってもいい
Lispがなぜ理想で終わってて実用に向かないかと同じ。なんでも再帰で片付けられれば数学的には美しいが実用的ではない。

**デフォルトの名無しさん** · 2022/11/14(月) 18:00:47.25

>>931
同意

**デフォルトの名無しさん** · 2022/11/14(月) 19:35:23.20

これJavaじゃなくてRustじゃないと速度面を犠牲にすることになるだろ
Rustがここで推奨されれば一気に覇権なんだが

米国家安全保障局、CやC＋＋からメモリー安全性の高いJavaなどへの移行を推奨
https://japan.zdnet.com/article/35195997/

**デフォルトの名無しさん** · 2022/11/14(月) 19:43:38.95

>>933
国家安全保障局なんだから、実績のある技術優先だわな。
Rustを推奨するのは実績できてからの話かと。

**デフォルトの名無しさん** · 2022/11/14(月) 19:52:43.88

ここまでくるとfree ware潰しだろ
企業にハンドリングされてないコンパイラの存在を消そうとしてる

**デフォルトの名無しさん** · 2022/11/14(月) 20:03:48.89

>>933
ヌルポがあるJavaがメモリ安全とはこれいかに

**デフォルトの名無しさん** · 2022/11/14(月) 20:03:49.96

>>933
C#にすればいいのにMicrosoftからの強力なバックアップ受けれるのになぁ

**デフォルトの名無しさん** · 2022/11/14(月) 20:04:31.99

ファームウェアとかデバドラはもうrustで良いよ

**デフォルトの名無しさん** · 2022/11/14(月) 20:14:00.66

>>936
Rustは中華圏が中心だから論外だよ

**デフォルトの名無しさん** · 2022/11/14(月) 20:35:43.46

>>937
同意

**デフォルトの名無しさん** · 2022/11/14(月) 20:37:19.52

>>935
被害妄想くさすぎ

**デフォルトの名無しさん** · 2022/11/14(月) 21:57:00.21

>>934
よく読んだらRustも推奨してるぞ

米国家安全保障局（NSA）は米国時間11月10日、ソフトウェアのメモリー安全性強化に向けたガイダンスを公開した。同機関はその中で開発者らに対して、ハッカーらによるリモートコード実行（RCE）をはじめとするさまざまな攻撃からコードを保護するために、C＃やGo、Java、Ruby、Swift、Rustといったメモリー安全性の高い言語に移行するよう推奨している。

**デフォルトの名無しさん** · 2022/11/14(月) 22:04:05.64

>>942
Swiftいらんやろ

**デフォルトの名無しさん** · 2022/11/14(月) 22:13:30.87

>>942
そしてこの中で低レイアのソフトウェアを開発できる言語はRustだけとなる

**デフォルトの名無しさん** · 2022/11/14(月) 22:36:44.63

>>944
なんの分野でもいいからオンリーワンというのは強いよね

メモリ安全性、低レイヤ、NSA推奨はRustだけ

**デフォルトの名無しさん** · 2022/11/15(火) 02:43:50.64

マルチスレッドデータ共有、結局mutexかactorで、stmでも実用的な速度を目指すとロック使ってるし、ロックフリーなstmやconcurrent revisionsみたいなのはなかなか実用に至らないね

**デフォルトの名無しさん** · 2022/11/15(火) 13:53:17.58

そもそもそんな細かい並列処理する？
Webだと、複数台に分散する必要がある程度に十分な数のリクエストがあるなら、CPUバウンドな処理をローカルで並列化する意味はほぼ無いからね

**デフォルトの名無しさん** · 2022/11/15(火) 13:56:07.55

ああ、もちろん画像処理みたいな単純に処理対象のデータ量が多いケースは別ね
でもその場合は並列処理といってもデータ並列なんで、結局ループを並列化してぶん回すだけであって>>946が期待してるような問題とはだいぶ違うよね

**デフォルトの名無しさん** · 2022/11/15(火) 15:10:13.06

並列分散処理もいまや多岐に渡ってるから
ドメインによって問題が全く違うのよ
だから自分がしないからといって決めつけは良くない

**デフォルトの名無しさん** · 2022/11/15(火) 15:29:04.50

シングルスレッドのプロセスが、それぞれ複数のリクエストを処理するnginxは一定の成功をおさめた

**デフォルトの名無しさん** · 2022/11/15(火) 16:45:12.55

決めつけてるんじゃなくて、実際のユースケースを知りたいんだ
反例も挙げずに人それぞれとだけ言われても、それこそ決めつけじゃないかな？
>>949はどんな並列処理してるのか教えてほしい

**デフォルトの名無しさん** · 2022/11/15(火) 17:45:58.35

解きたい現実の問題がない計算方法がロックフリーかつ超並列可能でもしゃーねーからなぁ。

**デフォルトの名無しさん** · 2022/11/15(火) 17:47:55.58

分野は違うけどニューラルネットワークとかも応用が見つかったから寂れてた分野が再び脚光浴びたわけで。

**デフォルトの名無しさん** · 2022/11/15(火) 19:53:37.58

>>951
まず数値計算で使ってる
ゴリゴリの差分法(単なるクソでかい連立方程式)を解く
これを解くのに行列演算をするのだがこれにCUDAを使ってる
これはいわゆる「データ並列」
行列演算の個々の要素は完全に独立しているので並列処理が可能
GPUのグリッド、ブロック、スレッドを使った超並列処理をしている

次にそれらの計算を行うためのジョブキュー
これはグローバルに一つのキューがあって計算ジョブをエンキュー、デキューする必要がある
ここでキューの実装にロックフリーアルゴリズムいわゆるcompare and swapを使ってる
これを使うことでミューテックスにかかるコストをゼロにしながら高速にキューを処理できる

俺が普段並列処理をしている分野はこの程度だからしょぼいよ
分散環境の並列処理は分散サーバーに対してロックを取ったり
リーダー選挙問題などさらに上位の概念をしなきゃならんのでさらに難しい

**デフォルトの名無しさん** · 2022/11/15(火) 20:31:52.61

目的が不明の仕様が最初から入っているのは仕様変更しないことが目的なんだろう
用途が判明してから言語仕様変更するのはJavaやGoのジェネリクスのようなパターン

**デフォルトの名無しさん** · 2022/11/15(火) 21:50:49.27

>>953
ディープラーニングは単なる応用じゃないぞ
リントンがやったことは応用じゃなくてブレークスルーだよ
しかもまだなぜそれがうまくいくのかわかっていないｗ

**デフォルトの名無しさん** · 2022/11/16(水) 15:43:42.81

>>956
応用とブレークスルーはべつに排他じゃないだろ

**デフォルトの名無しさん** · 2022/11/19(土) 19:04:23.11

これは厳しい

go のわかりにくい型推論
https://qiita.com/Nabetani/items/495da28ee31c660f7331

**デフォルトの名無しさん** · 2022/11/19(土) 21:18:23.55

rustビルド遅いゴミ

**デフォルトの名無しさん** · 2022/11/19(土) 21:43:35.74

>>959
sccacheを使うと少しマシになるかも

**デフォルトの名無しさん** · 2022/11/20(日) 01:45:23.94

型推論を自動でするんじゃなくて手動でやればいい
明示するんだよ

**デフォルトの名無しさん** · 2022/11/21(月) 19:58:15.79

次スレはZigとJai言語入れてください
Nimは引退で。

**デフォルトの名無しさん** · 2022/11/21(月) 20:10:04.47

あとCarbonとCppfrontも入れて
SwiftとKotlinは引退で。

**デフォルトの名無しさん** · 2022/11/21(月) 21:43:43.17

zigはver1になってからで

**デフォルトの名無しさん** · 2022/11/21(月) 22:13:58.36

>>963
Carbonいるか？
誰も話題にしてないし、実際要らんと思う。

**デフォルトの名無しさん** · 2022/11/21(月) 22:55:25.02

Carbonと聞いてもPHPの日時操作系のライブラリしか思い出さんわｗ

**デフォルトの名無しさん** · 2022/11/22(火) 00:53:36.22

RustとRubyは宣伝は凄いけど実力がイマイチだから、次スレからOUTで。

**デフォルトの名無しさん** · 2022/11/22(火) 09:57:46.60

CarbonてObjective-CだかNeXTstepとかで聴いたようなMacのだっけ

**デフォルトの名無しさん** · 2022/11/22(火) 10:27:47.27

ちがうちがうIBMのデザインシステムだよ

**デフォルトの名無しさん** · 2022/11/22(火) 10:43:28.61

Zig製スクリプト言語buzz
これも入れよう
https://github.com/buzz-language/buzz
なんでクラス作る構文がObjectなんだろう？

**デフォルトの名無しさん** · 2022/11/22(火) 11:05:10.12

すまんみんなが確実に生き残ると確信した言語だけにせんか？

**デフォルトの名無しさん** · 2022/11/22(火) 11:05:19.38

zigにはstructはあるがclassがまだ無いので遠慮してobjectを使った
つまりzigには今後c++のようにclassが増える可能性がある
……あたりだと思われる

**デフォルトの名無しさん** · 2022/11/22(火) 11:13:09.17

Zigは一番残る可能性高そうだけどまだエコシステムがどうとかって段階じゃないし、消えてもおかしくはない
CarbonもGoogleはしれっと捨てそうだからChromeあたりに本格的に使われるようになるまでは信用し難いなぁ

**デフォルトの名無しさん** · 2022/11/22(火) 12:58:31.59

次スレ
https://mevius.5ch.net/test/read.cgi/tech/1659660050/

**デフォルトの名無しさん** · 2022/11/22(火) 16:11:01.08

型推論なんてビルド速度犠牲にしてまでやることじゃねーな。

**デフォルトの名無しさん** · 2022/11/22(火) 17:26:04.85

Passerineも面白いから入れよう
まさに次世代言語だし

**デフォルトの名無しさん** · 2022/11/23(水) 12:03:19.93

>>958
Goのその仕様はわかりにくい上に使い勝手もよくないね
バグを引き起こしやすいから要注意だわ

**デフォルトの名無しさん** · 2022/11/23(水) 13:46:41.35

https://gigazine.net/news/20221117-github-top-programming-languages-2022/
GitHub上で使用されている2022年の最も使用されたプログラミング言語
1位：JavaScript
2位：Python
3位：Java
4位：TypeScript
5位：C#
6位：C＋＋
7位：PHP
8位：シェルスクリプト
9位：C言語
10位：Ruby

2022年に前年比での使用率が最も増加したプログラミング言語
1位：HCL(成長率56.1％)
2位：Rust(成長率50.5％)
3位：TypeScript(成長率37.8％)
4位：Lua(成長率34.2％)
5位：Go(成長率28.3％)
6位：シェルスクリプト(成長率27.7％)
7位：Makefile(成長率23.7％)
8位：C言語(成長率23.5％)
9位：Kotlin(成長率22.9％)
10位：Python(成長率22.5％)