次世代言語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/03/20(土) 09:27:09.06

>>654
まだ1.5じゃね？

**デフォルトの名無しさん** · 2021/03/20(土) 09:38:24.94

よし見慣れた
早く使いたい

**デフォルトの名無しさん** · 2021/03/20(土) 11:47:53.86

>>655
go

**デフォルトの名無しさん** · 2021/03/20(土) 13:16:39.14

linux kernelにrustディレクトリが出来たみたいだね
次世代言語として磐石な立ち位置を確立したね

**デフォルトの名無しさん** · 2021/03/20(土) 13:40:40.93

どの部分を置き換えるんだろうな？

**デフォルトの名無しさん** · 2021/03/20(土) 13:46:03.02

Pythonブーム終われと思ってる

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

Ruby on Rails 6 の本を出している人の、入門書が出た。
Erlang/OTP 上で動く、Ruby風の関数型言語

Elixir実践ガイド、黒田努、2021/2/5

Ubuntu 20.04, Docker CE 19.03, Elixir 1.11

>>655
皆Python から、MIT製のJulia へ移行してる

**デフォルトの名無しさん** · 2021/03/20(土) 14:08:30.45

Pythonブームが終わるのはいいけど
その次のやつはテンプレートメタプログラミングをやるのかやらないのか
早く判断しないと話が始まらない

**デフォルトの名無しさん** · 2021/03/20(土) 14:31:20.03

>>660
いまのところ書き換えは狙ってないって宣言されてるよ
新しいカーネルモジュールをRustで書けるようにするのが目標みたい

https://lwn.net/Articles/829858/

**デフォルトの名無しさん** · 2021/03/20(土) 14:33:14.82

>>664
そうなんだ
でもすごい事だな

**デフォルトの名無しさん** · 2021/03/20(土) 19:00:58.65

>>662
juliaなんて流行るわけねーだろあんなfortranくさい言語

**デフォルトの名無しさん** · 2021/03/20(土) 19:07:26.91

とりあえず言語の名前は固有名詞で唯一無二のネーミングを新たに創造してほしい

**デフォルトの名無しさん** · 2021/03/20(土) 21:01:13.23

5文字ぐらいの単語をランダムに生成して辞書引きでヒットしなかったものを使うしかないけどそんなの流行るかな？

**デフォルトの名無しさん** · 2021/03/20(土) 21:10:08.83

そんな極端なことしなくても、ちょっと綴りをもじるぐらいで良いじゃん。
BluRayみたいな。

**デフォルトの名無しさん** · 2021/03/20(土) 21:17:55.54

AV女優ばっか検索かかっちゃう言語名で良いのかね

**デフォルトの名無しさん** · 2021/03/20(土) 21:53:24.28

xxx langで大抵ははじけるけどな

**デフォルトの名無しさん** · 2021/03/20(土) 21:57:26.85

外国人はきちんとlangつけてて国内の人はlangつけてないって傾向ある？

**デフォルトの名無しさん** · 2021/03/20(土) 22:01:58.22

JavaのやつC#でもうあったわ

**デフォルトの名無しさん** · 2021/03/21(日) 11:30:16.19

rustで検索するとネトゲしか出て来ない時期あったな

**デフォルトの名無しさん** · 2021/03/21(日) 17:56:17.54

とりあえず Go おまえの名前はだめだ
Go の何がだめといって名前がクソすぎる

**デフォルトの名無しさん** · 2021/03/22(月) 00:46:24.50

Goだと検索に引っかかりにくいという難点はあるな

**デフォルトの名無しさん** · 2021/03/22(月) 10:30:05.11

外国人は一文字言語の頃からちゃんとlangと付けてたのかねえ

**デフォルトの名無しさん** · 2021/03/22(月) 10:40:46.73

clangがな

**デフォルトの名無しさん** · 2021/03/22(月) 12:24:42.48

Cとかはインターネット自体がまだそんなに普及してなかったからな

**デフォルトの名無しさん** · 2021/03/22(月) 17:29:55.95

>>655
Nim

**デフォルトの名無しさん** · 2021/03/22(月) 21:57:37.36

つかググラビリティを気にするようになったのは2000年以降だろう

**デフォルトの名無しさん** · 2021/03/22(月) 21:59:15.41

その頃はまだヤフってたわ

**デフォルトの名無しさん** · 2021/03/22(月) 23:37:25.80

千里眼使ってたわ。

**デフォルトの名無しさん** · 2021/03/23(火) 21:05:10.36

Microsoft Power Fx のご紹介
https://community.dynamics.com/365/b/dynamicsblog-ja-jp/posts/microsoft-power-fx

**デフォルトの名無しさん** · 2021/03/25(木) 09:09:11.03

>>655
Julia

**デフォルトの名無しさん** · 2021/03/25(木) 16:48:07.88

プログラミング言語Crystal、初のメジャーリリースとなるバージョン1.0を公開

**デフォルトの名無しさん** · 2021/03/25(木) 17:03:45.18

Rubyが好きな人のためのコンパイラか

**デフォルトの名無しさん** · 2021/03/25(木) 18:30:54.53

最近は、Go, Rust よりも、Elixir が熱い

動的型付けの関数型で、型を書かないのが楽チン

**デフォルトの名無しさん** · 2021/03/25(木) 20:04:29.48

Erlang VMのお世話が大変だろ
なんでJava等と比べてGoがデプロイ楽と言われてるか
シングルバイナリで行けるからだろ
ScalaやClojureはJavaVM、ElixirはErlangVMから実行時まで逃れられない

**デフォルトの名無しさん** · 2021/03/25(木) 20:17:34.37

Ｇｏなんではやらんのか
例外ないとかきいてうえってなったけど
panicあったらいいじゃん

**デフォルトの名無しさん** · 2021/03/25(木) 21:02:19.53

普通に使われてるだろGO

**デフォルトの名無しさん** · 2021/03/25(木) 21:22:28.63

golangは悪くは無いんだが、この分野ではgoだよねというシーンが無いというか

**デフォルトの名無しさん** · 2021/03/25(木) 21:32:12.66

>>689
ScalaやClojureはnative compileできるようになったからJVMなくても動くよ
Scalaは普段使いしないけどClojureはCLIのツール作るのに便利

**デフォルトの名無しさん** · 2021/03/25(木) 22:20:19.07

Goはなにが駄目といってまず名前が駄目
あとエラー処理が面倒すぎる!

**デフォルトの名無しさん** · 2021/03/25(木) 22:27:03.79

そうなのか

**デフォルトの名無しさん** · 2021/03/26(金) 12:21:14.41

Elixir も、パターンマッチの戻り値で判定するから、
例外機構を使わないのが普通

YouTube で有名な、雑食系エンジニア・KENTA いわく、
Go だけは、普及のキャズムを超えた

Rust, Elixirは超えられなかった

Elixirは、VSCode, Remote Container(Docker)で、
文字列処理などのツールでは楽

**デフォルトの名無しさん** · 2021/03/26(金) 13:15:37.07

goはjavaのダメな点を修正したってだけな気もするが、だがそれがいい。

**デフォルトの名無しさん** · 2021/03/26(金) 13:17:22.27

こっとりーん

**デフォルトの名無しさん** · 2021/03/26(金) 16:43:15.75

>>693
native compileされたバイナリの依存関係はどうなってるの？

**デフォルトの名無しさん** · 2021/03/26(金) 21:27:15.39

あとGoはマスコットがキモすぎる

**デフォルトの名無しさん** · 2021/03/26(金) 21:32:54.53

lispよりマシ

**デフォルトの名無しさん** · 2021/03/26(金) 22:00:57.79

どっちもかわいいのに…

**デフォルトの名無しさん** · 2021/03/26(金) 23:26:17.82

gopherはもうちょいデフォルメすればかわいい(たぶん)
LISPは諦めてもろて

◆QZaw55cn4c · 2021/03/27(土) 00:16:06.66

>>701
Lisp にマスコットなんかあったっけ？

**デフォルトの名無しさん** · 2021/03/27(土) 00:40:16.75

https://i.imgur.com/KEJ1wAI.jpg

Goのひっぱたきたくなるやつよりはかわいいかな

**デフォルトの名無しさん** · 2021/03/27(土) 01:07:42.58

Javaの☆のやつのがきもい

**デフォルトの名無しさん** · 2021/03/27(土) 01:09:38.24

>>705
ごーふぁー君はイラっとくるキモさだが
こいつはリアルに純粋にキモいなw

**デフォルトの名無しさん** · 2021/03/27(土) 02:04:50.15

しかも名前がLispエイリアンとかふざけてる

**デフォルトの名無しさん** · 2021/03/27(土) 02:39:16.96

舌足らず(lisp)なのかな

**デフォルトの名無しさん** · 2021/03/30(火) 02:28:48.17

>>614
よく分からないなら職場の先輩に聞いてください。あなたのくだらない煽りに答える所ではありません。
無視しても良かったのですが、あまりにも気持ち悪すぎるので書いておきます

RustのRc、Arcと言っているのに、それにまったく気づかない文章読解能力の無さどうかと思います。
ARC (automatic reference counting) というのアルゴリズムです。
言うまでもなくRcは(reference-counting)です。単純な参照カウントを改良・自動化したのがARCです。
改良すべきは細かい話になりますが、1つ目が値の受け渡しによるコピーをなくすためのムーブ操作です。
理論上は、ムーブセマンティクスと呼ばれる、C++11/14からある所有権のムーブで、メモリーコピーを
防ぎます。これは「所有権」という言葉からRustを想像すると思いますが、まさしくそれでRustはムーブを
明示的にシンタックスで行いますが、VやNimbleなどはそれが自動化されます。strong/weak/unownedの
キーワードが必要になりますが、確かSwiftもARCです。Vの場合はmutが必要です
２番目にスレッド間でのデータが共有されるため、ここも単純なRCと比べて改良されています。
他にもRCに比べて利点があります。多くの単純な例ではオーバーヘッドと見做されるようなカウント操作を
行わないようになります。これは明示的に所有権の移動を行うRustと同じです。Rustの利点はGCが不明な
箇所では行われない事です

簡単に表せば、最も単純な例では関数を抜けた後にメモリ解放を必要とする変数のデストラクタ呼び出しを
コンパイラが自動的に挿入します。（ここでカウント操作はありません）ただ循環参照を処理する場合には
参照カウンターとは別にサイクルカウンターが必要となります。
Rustはunsafeを使わずとも「循環参照は、メモリをリークすることもある」と認めていますが、独自データ
構造で循環参照を作った場合、メモリーリークしないよう保証するのは実装者の自分自身が必要です。

JavaなどのGCがあるとされる言語は多くはこれを解決するために、マークアンドスウィープを使用して結果的に
Stop the Worldが発生します。これを解決して抑えるためコンカレントGCを作りましたが、常にGCされるので
に結果的にパフォーマンス低下します。

**デフォルトの名無しさん** · 2021/03/30(火) 09:11:59.50

>>710
RustのArcはAtomically Reference Countedの略な

**デフォルトの名無しさん** · 2021/03/30(火) 09:44:21.64

>>710
RcとArcの違いが全然分かってなさそうだけど大丈夫か？
カウント操作にアトミック命令使ってるかどうかだけなんだが。

**デフォルトの名無しさん** · 2021/03/30(火) 15:01:48.57

あまりにも気持ち悪すぎるwワロス
こいつらマウント取りたくて必死すぎだろwなんも反論になってないw
そんなにVが嫌いならダメな所あげたら良いのに

**デフォルトの名無しさん** · 2021/03/30(火) 16:45:27.89

ReScript良さそうだな

**デフォルトの名無しさん** · 2021/03/30(火) 16:50:58.07

見たくないものは見えないんだなあ

**デフォルトの名無しさん** · 2021/03/30(火) 18:21:16.68

最新の言語ってデバッグのための値操作とかどうやるんですか

ＪａｖａやＣだと変数値は変えられるのがデフォだから
一応元の処理は流したうえで値を書き換えてやるのが基本だった気がするけど
最近のってletでデフォconstじゃないですか

**デフォルトの名無しさん** · 2021/03/30(火) 22:53:17.23

デバッガからなら書き換えられるのも多いのでは？

**デフォルトの名無しさん** · 2021/03/30(火) 23:09:39.66

メモリ操作するよりセーブしてからファイル操作してロードできればいいのにな
GCにたとえるとストップアンドコピーってとこか

**デフォルトの名無しさん** · 2021/03/30(火) 23:25:34.80

純粋関数型言語で値の書き換えできるやつってあるのかな
HaskellとかElmで変数(とは言わないかもだが)表示しながらステップ実行とか式の評価の履歴みれるのは知ってるけど

**デフォルトの名無しさん** · 2021/03/30(火) 23:31:06.76

できない理由はないんじゃない？メモリ上に置かれないような最適化とかされない限り。

**デフォルトの名無しさん** · 2021/03/30(火) 23:58:23.09

24日、最新版となる「Julia 1.6」をリリースしたと発表した。

**デフォルトの名無しさん** · 2021/03/31(水) 00:29:37.70

ステップ実行やりたいがためにCのライブラリ呼び出しすんな派と
Cライブラリ呼び出しーや派
言語の流行はほぼこれで説明がつく

**デフォルトの名無しさん** · 2021/04/01(木) 20:50:12.42

「AsyncAPI Initiative」がLinux Foundationに参画、イベントドリブンなAPIの記述標準化を目指す
https://www.publickey1.jp/blog/21/asyncapi_initiativelinux_foundationapi.html

**デフォルトの名無しさん** · 2021/04/08(木) 04:40:42.69

>>710はスルー力検定？

**デフォルトの名無しさん** · 2021/04/08(木) 08:12:35.42

Rust言語でAndroidはより強固・安全に～GoogleがOS開発への導入を進める
C/C++コードの完全な置き換えは非現実的だが、新規コードへの活用は不具合の予防に効果あり
https://forest.watch.impress.co.jp/docs/news/1317183.html

**デフォルトの名無しさん** · 2021/04/08(木) 15:38:13.33

Rustほんと人気だね

**デフォルトの名無しさん** · 2021/04/08(木) 15:43:04.97

Javaのパクっておｋの勝訴の影響はどうなるの

**デフォルトの名無しさん** · 2021/04/08(木) 19:17:59.07

フェアユース

**デフォルトの名無しさん** · 2021/04/08(木) 21:12:55.75

googleがイニシアチブとってくるとかなり変わってくるな

ただfirefoxの遅れ取り戻すために作ったものが今後chromやedgeにも使われるとなるとどうなんだろ？

**デフォルトの名無しさん** · 2021/04/09(金) 01:33:52.25

GoogleのJavaはそもそもドロイドのアプリ層でしか使ってないとオモウ
なのでOpenJDK標準になってたりKotlin押しになってるアプリ開発環境は変るかも

**デフォルトの名無しさん** · 2021/04/09(金) 07:43:56.69

節子！それ盗作ちゃうで！インスパイアかフェアユースや！

**デフォルトの名無しさん** · 2021/04/09(金) 11:54:55.40

フェアユースの定義はどう見ても自然科学の管轄外なので
どちらかといえばコミュ力に近い能力が役に立つ事案

**デフォルトの名無しさん** · 2021/04/09(金) 20:44:39.89

やったもん勝ちでいいじゃんいいじゃん

**デフォルトの名無しさん** · 2021/04/10(土) 09:37:11.94

中国人みたいなこと言いよる

**デフォルトの名無しさん** · 2021/04/10(土) 09:56:08.18

そういう判決だったからな

**デフォルトの名無しさん** · 2021/04/16(金) 16:43:46.37

Go言語はos.Open()の戻り値のエラーはスルーできないのに
File.Close()の戻り値のエラーは普通にスルーできるのが気持ちわるくてやめた
（だいぶ前の話だから今どうなってるかは知らない）
せめて
_ := f.Close()
にしないと警告出すくらいのチェックはほしい

**デフォルトの名無しさん** · 2021/04/16(金) 17:20:31.43

>>736
どういう事？
voidではない関数の戻り値もかならず代入文によって捨てるコーディングがしたいってこと？

**デフォルトの名無しさん** · 2021/04/16(金) 18:28:46.84

>>737
そういうことです
当時そういうオプションとか探したけど見つからなかった

**デフォルトの名無しさん** · 2021/04/16(金) 20:10:02.72

>>738
うーん、他の言語もタプルとかとして受け取るなら一部だけ受け取るなんてこと出来ないんだし、一般的な仕様だと思うけどな。

**デフォルトの名無しさん** · 2021/04/16(金) 22:00:20.82

>>739
その部分だけで考えれば普通なんだけど言語全体で考えるとバランスが悪い感じ

Openの方は

f, err := os.Open(..) // errを使わないとコンパイルエラー
f, _ := os.Open(..) // 敢えてエラーチェックはしない

の二択だけど、Closeの方は

err := f.Close() // errを使わないとコンパイルエラー
_ := f.Close() // 敢えてエラーチェックはしない
f.Close() // エラーチェックしないの？

の三択になって、例外を使わずに変数の使用を強制することでエラー処理を明示的にするっていう
Go言語のスタンスがぼやける気がする
（そのスタンス自体が私の思い違いかもしれないけど）

Closeだとエラー無視しても大したことないけど、Chdirあたりだと
エラーをスルーできて例外も飛ばないのは危険さを感じてしまう
C言語と同じだと言えばそれまでだけど、変数の不使用はコンパイルも通さないのに
戻り値の不使用は警告も出さないっていう仕様はアンバランスだと思った

**デフォルトの名無しさん** · 2021/04/16(金) 22:43:53.10

>>740
errを使わないとコンパイルエラー、は違うよ。
_ = err
と捨ててもコンパイルエラーは避けられる。

例外を使わず、は正しいけど、変数の使用は実質強制されてない。

そういう、errを捨てるような書き方は、Javaのthrows書きたくないからとExceptionで大雑把に例外を握りつぶしてるメソッドみたいなもんで、躾の問題だと思うよ。

**デフォルトの名無しさん** · 2021/04/16(金) 23:39:26.78

>Javaのthrows書きたくないからと
極刑を望む

**デフォルトの名無しさん** · 2021/04/16(金) 23:53:42.11

「使う」の意味が曖昧だったかな
errを使うっていうのはエラーをチェックをするという意味じゃなく
コードの中でそのerrをどう扱うかを明示するって意味で書いた
（普通はエラー処理だけど）

>>741の例だと
_ = err
の中で「そのエラーはチェックしない」って意図を明示するためにerrを使ったことになる

_ := f.Close()
と
f.Close()
の違いは、下の書き方だと
・そこでエラーが返される可能性
・そのエラーを無視するという意図
の２つが伝わりにくくなること

もしかしたらコードを書いた本人もCloseがエラーを返す可能性を見落としてるかもしれなくて
そうなると想定しない状態でプログラムが動き続けて予期しない結果を招くかもしれない

もしコンパイラが戻り値を受け取らないパターンを弾いてくれればそういう見落としは防げるようになる
（そこで何も考えず戻り値を捨てる書き方をして予期しない結果になったならそれはもう躾の問題だけど）

Javaで例えるならExceptionで握りつぶすというよりcatch(Exception)して何もしない感じかな
自分は「飲み込む」と表現してる

**デフォルトの名無しさん** · 2021/04/17(土) 02:30:54.76

そんなに説明しなくても>>736だけで十分わかるよ
https://github.com/golang/go/issues/20803
https://github.com/golang/go/issues/20148 <― Rob Pike

**デフォルトの名無しさん** · 2021/04/17(土) 02:59:32.14

同じこと言った記憶あるなあと思ったら一昨年だった

https://mevius.5ch.net/test/read.cgi/tech/1567602619/927
927 デフォルトの名無しさん sage 2019/09/29(日) 19:19:16.64 ID:siw3JIyP
deferのためなんだろうけど、返り値全捨てでの握り潰しがコンパイルエラーにならないのは不満

**デフォルトの名無しさん** · 2021/04/17(土) 09:13:21.49

>>743-744
これは俺が不勉強だった。Issueも立ってたのか。
この議論は確かに有益だな。
issueで書かれてるように、deferで雑に閉じたいとかそういうケースが確かに漏れるか、ってぐらいだな。

うーん、なかなかバランス難しいもんだな。
とはいえRustみたいな気難しいコンパイラになられるのもなかなかだし。

**デフォルトの名無しさん** · 2021/04/17(土) 09:39:43.53

>>742
それは形式的に判断できるものじゃなくて、大雑把かどうかはその内容によるわな。
握りつぶしていい例外は存在するしそれは握りつぶしていい。

**デフォルトの名無しさん** · 2021/04/17(土) 11:00:28.48

throwsを書くのは関数や変数の型を書くことと同じ
それに対し「型を書かなくていい変数は存在する」と
言い返したのと同じだから痛快だね

全ての変数に型を書くのに今までどれだけ無駄な努力をしていたか

**デフォルトの名無しさん** · 2021/04/17(土) 12:15:23.05

>>748
Javaの検査例外はたしかに例外を型安全に扱うための仕組だけど、throwsを書かないのは
いわばvoid型のようなもので、型推論や動的型付けで型を書かないのとは違う。

**デフォルトの名無しさん** · 2021/04/17(土) 12:35:03.15

検査例外は「ただの大域jmp、しかも行き先が自分ではわからないやつ」っていう例外の悪い部分をうまく取り扱うための、そこそこいい仕組みだと思うんだけど、
いかんせん例外で対応することが多すぎた気がする。
このメソッドより外側には漏れ出しません、ってのは俺はいい宣言だと思うんだけどな。

今はかなり改善されてるんだろうけど、Javaにいい印象なくてなかなかJava系の言語やる気持ちになれないや…。

**デフォルトの名無しさん** · 2021/04/17(土) 13:37:15.96

Javaの例外処理は独自の例外クラスを作って低層の例外を取り込んでいく設計を知らないと
throwsの中身が膨れ上がって大変なことになるね
throwsが面倒っていう人は独自の例外クラスを作るのが面倒なんだと思う

GoとかRustは返せるエラー型が原則１つに制限されるから必然的にそういう設計を迫られる

**デフォルトの名無しさん** · 2021/04/17(土) 17:29:58.69

>>751
C#で言うInnerException的な？
まあ、業務ロジックでハンドリングするならアプリケーションで定義した例外に包むわな、確かに。

**デフォルトの名無しさん** · 2021/04/17(土) 22:12:19.57

Javaの検査例外は直上でのハンドリングを強制したのが失敗
Goみたいに一種類だけならまだしも、全種類はさすがにノイズになりすぎた
コンパイル時にチェックしたいだけならthrowsは暗黙的にコンパイラが生成し、最終的にキャッチされないままの例外があったら警告出すくらいで十分だったんだよ
結局Javaはmulti catch導入して、型を緩める方向に舵を切っちゃった

**デフォルトの名無しさん** · 2021/04/17(土) 22:53:24.71

throwsを暗黙的に生成するのはそんなに簡単じゃない気がする

**デフォルトの名無しさん** · 2021/04/17(土) 22:59:40.59

検査例外がというより、そこは例外に多彩な型を持たせること自体が失敗だったと言うべきだろうな。
例外というものは呼び出し階層の複数の階層を越えて上位層が下位層に依存してしまうんで
それをSOLID原則のに従うようきっちり依存性逆転させるのは骨が折れる。