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

**デフォルトの名無しさん** · 2020/04/19(日) 15:06:02.92

スレタイ以外の言語もok

前スレ
次世代言語18 Go Rust Elixir Kotlin TypeScript (実質20)
https://mevius.5ch.net/test/read.cgi/tech/1569866283/

**デフォルトの名無しさん** · 2021/05/09(日) 08:54:38.49

VM言語は起動がやっぱり遅いからなぁ。
.NETもReadyToRunしても限界があるし。
とはいえスクリプト言語もやりたくはなく。
nodeがネイティブコンパイルなり、ReadyToRun的な事ができるようになってくれたら言うことがないんだが、
最近GoかDartばっかり書いてる。

**デフォルトの名無しさん** · 2021/05/09(日) 09:02:23.88

Dartは何がいいの？書いたことないからわからん
見た目からもエロスは感じんし

**デフォルトの名無しさん** · 2021/05/09(日) 09:12:03.41

俺もflutterから入ったんだけど、なんせ無難。
基本的にシングルスレッドだけど、容易に他スレッドと連携できたり(ただGoほどコンテキストスイッチが軽くはない)
色んなAPIがasync awaitネイティブなので深く考える必要なく非同期で書ける。
その割にちゃんと型安全だし、VS CodeのExtensionもよくできてて書きやすいよ。
標準でコードに対して静的解析かけられるのもありがたい。
配布がAOTかけたネイティブバイナリにもなったし。
ライブラリも増えきたし、良い事多いかも。

**デフォルトの名無しさん** · 2021/05/09(日) 09:34:29.08

>>844
流行る流行らないが取捨選択の手段であって目的でないのは全くその通りなんだけど、そういう言語のユーザは人口の価値を過小評価し過ぎじゃない？と思う事があるよ
ここで言いたいのは、流行ってないって事はその機能の内いずれかがそれほど求められてないって結果じゃない？（そして今回の場合それは高階多相だし、モナド系列の抽象化やそれで提供される副作用や機能の分離じゃない？）という話

まぁその流れだとカリー化+部分適用とかも求められてない可能性があって辛みなんですが

**デフォルトの名無しさん** · 2021/05/09(日) 09:38:57.23

Rustは流行らない、なぜなら流行ってないからだ

**デフォルトの名無しさん** · 2021/05/09(日) 10:32:20.15

シンタックスとかしょーもないことに力入れないで
ビルド速度とGC性能あげりゃいいってのがgoの結論だわな。
バカにしたがってくっだらない機能を入れる必要なんかないわ。

**デフォルトの名無しさん** · 2021/05/09(日) 10:52:01.42

しくったら修正リリースすればいいっしょ？っていうスタイルの事業とリリースのコストが半端ない事業とを
ごっちゃにするから訳わかんねー結論になる

前者は馬鹿でも扱える軽量級言語、
後者は型パズルとかないとコンパイルもできない重量級言語が良い

**デフォルトの名無しさん** · 2021/05/09(日) 12:54:17.04

後者の問題を言語だけで解決しようとしてんのがそもそも馬鹿だと思うが。

**デフォルトの名無しさん** · 2021/05/09(日) 13:12:43.67

まあ、コンパイル時に解決ってのがあるだけでかなり違うのはわからんでもないけどな。
単体テストの嵐になったり、言語によっては結合試験したら発生する不具合なんてのもあるし。
それは単純なコンパイル言語ってだけでは駄目だけど。
constつけたら書き込まれる事は本当に無い、って前提があると助かる部分は多い。

**デフォルトの名無しさん** · 2021/05/09(日) 13:34:55.78

その程度で解決できる問題なら「リリースのコストが半端ない事業」とは言えんけどね。

**デフォルトの名無しさん** · 2021/05/09(日) 13:41:12.04

ダウンロード販売の万能感に酔っていたらいつの間にか医療関係の物流が無能になっていた

**デフォルトの名無しさん** · 2021/05/09(日) 14:19:39.02

>>854
それだけで完全解決するわけじゃないけど、足しにはなるよ。
コンパイラと静的解析変えるって話になった時も、コスト試算したけどなかなか変わったし、実際効いたけどね。

**デフォルトの名無しさん** · 2021/05/10(月) 00:01:38.43

>>850
でも結局ジェネリクスとか入れようとしてるやん

**デフォルトの名無しさん** · 2021/05/10(月) 00:56:07.37

>>857
かなり迷ってるやん。
それこそビルド速度犠牲にしてまで入れるか？コードジェネレイターで十分では？
メタプロバカが発生しないか？とかね

**デフォルトの名無しさん** · 2021/05/10(月) 01:09:00.90

goに入れて欲しいと言われてる機能をみんないれたら
最初からgoじゃない言語勉強しとけとか
goのメリットと言われているものが死ぬと思う

**デフォルトの名無しさん** · 2021/05/11(火) 20:09:45.37

goは劣化java
20年遅れとる

**デフォルトの名無しさん** · 2021/05/11(火) 21:04:36.32

Goより20年も進んでるなら
次世代通り越して次々世代だな

ジジイだけに

**デフォルトの名無しさん** · 2021/05/12(水) 00:45:58.33

>>860
機能を詰め込めばいいと思ってるバカ。

**デフォルトの名無しさん** · 2021/05/13(木) 01:14:29.82

でも最近go聞かなくなった気がする
取り入れるところはみんな取り入れたからかもしれないけど

**デフォルトの名無しさん** · 2021/05/13(木) 10:54:49.47

黙々と使われてる言語は話題にはならんよ。

**デフォルトの名無しさん** · 2021/05/13(木) 15:00:45.66

仕事に使ってる人は忙しい

**デフォルトの名無しさん** · 2021/05/14(金) 14:37:46.88

GitHub における大規模なモノリポのパフォーマンスの向上
https://github.blog/jp/2021-03-19-improving-large-monorepo-performance-on-github/

＞ GitHub の有名な Ruby モノリスを解体し、GitHub のすべてのユーザーのためにリポジトリのパフォーマンスを向上させる新しいマイクロサービスを Go で作成しています。

**デフォルトの名無しさん** · 2021/05/14(金) 22:52:04.67

パフォーマンスのネックruby

**デフォルトの名無しさん** · 2021/05/26(水) 22:03:29.71

マイクロソフトら、CO2削減に寄与するコーディングを目指す業界団体を設立

**デフォルトの名無しさん** · 2021/05/26(水) 22:24:07.47

二酸化炭素を全てダイヤやカーボンファイバーにすればいいよ

**デフォルトの名無しさん** · 2021/05/26(水) 22:51:53.02

時価総額は、Github が8千億円

今世紀最大の起業家、Vagrant/Terraform の作者・Ruby/Go の神・
Mitchell Hashimoto のHashiCorp が5千億円

時価総額が数千億円になったら、RubyからGo, Elixir へ変えればよい

Shopify は15兆円、民泊のAirbnb は、大手ホテル3社の合計以上の10兆円。
このクラスでも、Rails

食べチョクみたいな女性1人の起業では、Rails, Heroku, React, Bootstrap で十分。
時価総額が千億円を超えるまでは、Rails で良い

**870** · 2021/05/26(水) 22:56:29.42

Ruby on Rails で、若い女性1人で起業した、食べチョクでも、
売上50億円だから、時価総額50億円は行く

近いうちに上場するだろうし

**デフォルトの名無しさん** · 2021/05/30(日) 23:18:30.05

久々にFlutter触るからDartのセミコロン問題どうなってるか調べたらまだ議論しててワロタ
https://github.com/dart-lang/language/issues/69

**デフォルトの名無しさん** · 2021/06/01(火) 00:32:03.52

Flutterはしんでいいな

**デフォルトの名無しさん** · 2021/06/07(月) 08:42:28.96

>>868
ネタじゃないのかよｗ

**デフォルトの名無しさん** · 2021/06/08(火) 15:14:19.36

>>831
> 言語が自由すぎて俺用言語になりがち
どういうこと？Kotlinにそんな機能あったっけ？

**デフォルトの名無しさん** · 2021/06/08(火) 16:36:51.33

>>875
中置記法

**デフォルトの名無しさん** · 2021/06/09(水) 12:47:10.31

中置もいいけど引数のtuple定数化強要とドット記法で丸括弧減らすとかさ
コードゴルフにゃ向かないけど読み解きにくい妙な圧縮記述を減らすのには効果あるんじゃね？

**デフォルトの名無しさん** · 2021/06/09(水) 14:20:57.68

Kotlin は何かとわざわざヒネった発想を無理強いしてくるのが気にいらない
min で 2 つの値の小さい方をとろうとしてるコードにいちいち coerceAtMost (値を制限する)関数つかえ
とサジェストしてくるが、たしかに値を制限するのも理屈は同じではあるが
わしはここでは2つ値がでてきてその小さいほうをとろうとしてるロジックを強調したいのに
値を制限するでは意味がボヤけるんだよっヽ(`Д´)ﾉ

**デフォルトの名無しさん** · 2021/06/09(水) 14:23:04.09

ちなみにツッコみとしては「なるほど coerceAt を無理強いされるのが気にいらない、とこういうことか」
みたいなレスを期待

**デフォルトの名無しさん** · 2021/06/09(水) 14:33:59.27

>>878
coerceAtMost(n)と書かれるとn以下なら何でもいいように見えちゃって曖昧に感じるね
普通にAPIの設計やネーミングのセンスに問題があると思う

**デフォルトの名無しさん** · 2021/06/09(水) 15:08:53.26

それは無視してminつかえばいいんじゃ

**デフォルトの名無しさん** · 2021/06/09(水) 15:40:50.01

minOf(a, b)じゃなくて？

**デフォルトの名無しさん** · 2021/06/17(木) 10:36:08.05

Kotlin って派手な機能はないけど、実用的な機能が色々あって結構好きだわ
特にクラスのコンストラクター引数をそのままフィールドで受け取れるのとかすげえ便利
null 安全性も Swift みたいに if let ... とかでチェックさせられるんじゃなくて単なる比較で書けるからわかりやすいし

**デフォルトの名無しさん** · 2021/06/17(木) 15:46:16.23

発想に慣れるまでがちょっと時間がかかるが
発想に慣れるとやたらと短かくソースを書けるようになる
そこがちょっと快感
それがKotlin

**デフォルトの名無しさん** · 2021/06/17(木) 16:38:25.67

まだJavaの延長(というかカジュアル版)の感覚でしか書けないなぁ

**デフォルトの名無しさん** · 2021/06/17(木) 16:52:48.02

JVMから脱却するしかない

**デフォルトの名無しさん** · 2021/06/18(金) 15:29:47.42

結構JVM依存でkotlinネイティブは最適化でどうにもならなそうなぐらいパフォーマンス厳しいってのが暗黙の了解なような

**デフォルトの名無しさん** · 2021/06/19(土) 01:25:26.86

ずっとGo信者だったけど、最近Rustはまりつつあって凄い言語だなって思ってる。

**デフォルトの名無しさん** · 2021/06/19(土) 01:53:56.18

crystal触ってるけどrubyっぽさが凄いね。nimがpythonっぽい何かなのに比べて、crystalは better rubyだわ

**デフォルトの名無しさん** · 2021/06/19(土) 11:22:01.73

方向性違うけどpost PythonはnimかJuliaか

**デフォルトの名無しさん** · 2021/06/19(土) 13:22:42.63

nimプロダクトで使ってるところ見た事ないけど、なんちゃって運用ツールとかにしか使えない感じなの？

**デフォルトの名無しさん** · 2021/06/19(土) 13:34:40.76

python選ぶやつはnim選ばない
python選ばないやつはnim選ばない
ということだ

**デフォルトの名無しさん** · 2021/06/19(土) 15:34:32.94

C/C++ 使えてるし困ってない

**デフォルトの名無しさん** · 2021/06/19(土) 18:20:46.92

>>892
nim 結構いいのに Python 臭いとこがやだよね。

**デフォルトの名無しさん** · 2021/06/21(月) 18:23:45.07

Swiftも!あんじゃん

**デフォルトの名無しさん** · 2021/06/22(火) 01:19:34.45

そりゃビックリ！

**デフォルトの名無しさん** · 2021/06/22(火) 07:17:18.33

swiftのResultBuildersってなんか面白そうだな

**デフォルトの名無しさん** · 2021/06/22(火) 09:26:37.53

>>893
いつも思うんだが、こういう奴ってなんでこういうスレに来るの？
うざいんだが

**デフォルトの名無しさん** · 2021/06/22(火) 20:38:29.50

その言葉、そっくりそのままお返しします。

**デフォルトの名無しさん** · 2021/06/23(水) 02:30:54.55

>>899
いやスレの趣旨に合わないやつが居座ってんのどっちだって話

**デフォルトの名無しさん** · 2021/06/23(水) 13:28:38.76

居座ってるってどうやって確かめたんだ？
たまたまスレが目に入っただけかも知れんだろ

**デフォルトの名無しさん** · 2021/06/27(日) 01:52:23.46

>>893
Rustをオススメします

**デフォルトの名無しさん** · 2021/06/27(日) 04:28:46.15

Kotlin もよろしく

**デフォルトの名無しさん** · 2021/06/27(日) 05:55:26.60

C/C++のかわりにおすすめするってことはKotlinってJVMへの依存切ってシングルバイナリで動くの？
できたとしてもランタイム重そう

**デフォルトの名無しさん** · 2021/06/27(日) 12:57:27.73

なんで D は無かったことにされてるのですか？

**デフォルトの名無しさん** · 2021/06/27(日) 23:00:58.14

>>905
度々自らの過去を無かったことにしたことでプログラマに愛想を尽かされて無かったことにされた

**デフォルトの名無しさん** · 2021/06/27(日) 23:40:14.19

もうlazy くらいしか特徴が無いデカいし将来性の無い環境だからねー
デカいスタティクライブラリとコンパイラメッセージは仕方ないとしても
ビルド環境はメジャーなんに幅広く寄生すればいいのに

**デフォルトの名無しさん** · 2021/06/29(火) 00:20:13.47

>>904
一応 Kotlin native は既にある。でもまだ作ってる最中って感じかな? 遅いらしい。

**デフォルトの名無しさん** · 2021/06/29(火) 00:24:49.55

まあしかし C はまだいいけど C++ は複雑で分かりにくいように思う。
学習に時間が掛からないか?

そしてよく使われていたであろう Windows ネイティブのプログラムはじわじわと廃れていく。

**デフォルトの名無しさん** · 2021/07/01(木) 07:59:54.15

デジタルなんだからじわじわ劣化しないよ
っていう単純化された理論が崩壊したのは事実だが

実装レベルのC++は複雑だが破綻はしてない

**デフォルトの名無しさん** · 2021/07/01(木) 19:20:24.95

bool
polymorphism
match
と来て次の層はどんなんになるんかな

**デフォルトの名無しさん** · 2021/07/01(木) 20:52:42.10

WebAssemblyアプリ開発で最も使われている言語はRust、注目の機能はスレッドなど。The State of WebAssembly 2021
https://www.publickey1.jp/blog/21/webassemblyrustthe_state_of_webassembly_2021.html

**デフォルトの名無しさん** · 2021/07/04(日) 10:42:07.67

注目の機能スレッドってなんかそういう独自の機能があるのかと思ったわ

**デフォルトの名無しさん** · 2021/07/10(土) 18:17:31.11

L言語とな？
https://github.com/microsoft/L

**デフォルトの名無しさん** · 2021/07/10(土) 21:06:58.55

注目の機能は、と問うスレッドが5chでも建ったんじゃないの

**デフォルトの名無しさん** · 2021/07/11(日) 15:36:58.13

>>910
「,」、「&&」、「||」周りのオーバーロードとか完全に破綻しとるわ。

**デフォルトの名無しさん** · 2021/07/11(日) 17:17:40.29

llangってぱっと見なんだかわからんな
またネーミング失敗じゃない？

**デフォルトの名無しさん** · 2021/07/14(水) 00:32:39.09

そういえばZenってお前ら的にどうなの
https://www.zen-lang.org/ja-JP/

**デフォルトの名無しさん** · 2021/07/14(水) 00:42:40.34

>>918
つまらん言語だな
GCのないGo処理系を作れば済む話だったのではないか

**デフォルトの名無しさん** · 2021/07/14(水) 08:15:42.46

>>918
ゴミ言語という印象しかない　https://ziglang.org/news/statement-regarding-zen-programming-language/

**デフォルトの名無しさん** · 2021/07/14(水) 10:52:37.13

Zigのパクりでしょ

**デフォルトの名無しさん** · 2021/07/14(水) 13:41:04.37

zigってnimとかvlangとかに比べてどこらへんがいいん？

**デフォルトの名無しさん** · 2021/07/14(水) 14:03:16.32

>>922
やりたいことはわかるが、わざわざ言語を作るほどのことではない
スルーしてよし

**デフォルトの名無しさん** · 2021/07/14(水) 15:48:49.76

このスレなんのスレだっけ？

**デフォルトの名無しさん** · 2021/07/14(水) 16:02:12.04

自分の気にいらない言語を貶めるスレ

**デフォルトの名無しさん** · 2021/07/15(木) 03:40:50.12

ここまできてはじめて
スレ住人全員が同意する意見が書きこまれた >>925

**デフォルトの名無しさん** · 2021/07/15(木) 06:11:01.98

勝手に同意した事にするなよ…
主語がでかすぎる

**デフォルトの名無しさん** · 2021/07/18(日) 12:01:23.40

プログラミング言語とか、勘違いしやすく物忘れも激しいという
人間の非理想的な特性に対する対策なのだからそれ自体が宇宙の真理ﾚｳﾞｪﾙの美しさを備えることは難しい
C++はその対人間の対策にすら失敗している気配がするが、
プログラミング言語の理想を言い出したらキリがないことも上のことから明らかなので、
必要な仕事をやれるのだからC++でも及第点とも言える

**デフォルトの名無しさん** · 2021/07/18(日) 12:04:40.99

「より良いソリューションに対する最も危険な敵というのは、十分に良い既存のコードベースなのだ
（the most dangerous enemy of a better solution is an existing codebase that is just good enough.）」
とゆー格言はプログラミング言語にも当てはまる

**デフォルトの名無しさん** · 2021/07/18(日) 16:07:40.62

なんかキモいね

**デフォルトの名無しさん** · 2021/07/18(日) 18:39:25.82

褒められたと思っておこう（ｷﾘ

**デフォルトの名無しさん** · 2021/07/19(月) 01:55:47.55

ていうか最も危険な敵っていってるけど
そんだけ十分によいソリューションになってるってことじゃねーか
「より良い」ってのがただの思いこみってのが真相だろう
手前ミソを売りこむのに邪魔、っていうのをいいかえただけだな

**デフォルトの名無しさん** · 2021/07/19(月) 08:27:19.09

「betterの敵はenough」で十分なのに、既存の格言はやけに長いな

**デフォルトの名無しさん** · 2021/07/22(木) 17:21:37.86

Sather

**デフォルトの名無しさん** · 2021/08/09(月) 14:42:17.17

Pythonより30％高速目指す「Pyston」--開発者が語る次の目標

**デフォルトの名無しさん** · 2021/08/09(月) 18:34:55.62

のちのピストン運動である。

**デフォルトの名無しさん** · 2021/08/20(金) 21:52:24.83

Rustのボローチェッカーとは動作が異なるようなのですが、
Nimにはすでに「借用チェッカー」に似たものがあるそうです
https://forum.nim-lang.org/t/5459

Nimでもボローチェッカーで参照の有効性を検証することによって
メモリ安全性を保証できるのでしょうか？
何方か詳しい方がいましたらご教示お願い致します

**デフォルトの名無しさん** · 2021/08/21(土) 03:28:29.09

>>937
まだ実装されてないけど、ボローチェッカーに似たようなものを作る予定はあるようだよ。
http://nim-lang.github.io/Nim/manual_experimental.html#view-types

**デフォルトの名無しさん** · 2021/08/21(土) 06:03:46.59

>>937
Nimはガベージコレクション(GC)のある言語
だからGCのないC/C++/Rustとは別分野なのでそれらの代替にはならない

**デフォルトの名無しさん** · 2021/08/21(土) 06:50:02.55

>>938
ご教示ありがとうございます。
さっそくリンク先をgoogle翻訳してみたのですが、
Nimバージョン：1.5.1でRustのボローチェッカー
に似た「View types」が実装されるんですね

Nim　Version 1.0.0 正式リリースされてから
1年も経過しないうちにARCとORCが実装されたよう
なので、一年後（現在Version 1.4.8）には
「ボローチェッカー(View types)」も実装されそうですね

**デフォルトの名無しさん** · 2021/08/21(土) 07:04:18.79

GCが無い事実は保証できる
速度のベンチマークが嘘じゃないことは保証できない

だから自称超高速GCがもしあっても普及しない
GC無しで高速化した方が確実

**デフォルトの名無しさん** · 2021/08/21(土) 07:09:56.98

>>939
>Nimはガベージコレクション(GC)のある言語

Nimはガベージコレクション(GC)を任意で外せるから、
ガベージコレクション(GC)を外して「ボローチェッカー(View types)」
で参照の有効性を検証することによってメモリ安全性を保証できないのでしょうか？

**デフォルトの名無しさん** · 2021/08/21(土) 07:27:43.27

>>941
>GC無しで高速化した方が確実

NimはオプションでGC無しにできるので、
Nimバージョン：1.5.1でRustのボローチェッカー
に似た「View types」が実装されればGC無しで
高速化出来ますか？

**デフォルトの名無しさん** · 2021/08/21(土) 07:45:38.03

>>939
>だからGCのないC/C++/Rustとは別分野なのでそれらの代替にはならない

NimにGC有りは事実なのですが、
NimはオプションでGC無しにできるので、
Nimバージョン：1.5.1でRustのボローチェッカー
に似た「View types」が実装されれば
GC無しで、View types参照の有効性を検証する
ことによってメモリ安全性を保証しつつ高速化して
C/C++/Rusの代替にt出来ますか？