次世代言語14 Elixir Crystal Julia Rust Swift

**デフォルトの名無しさん** · 2018/09/11(火) 21:28:24.70

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

**デフォルトの名無しさん** · 2018/09/13(木) 06:59:35.21

ﾜｯﾁｮｲありの次世代言語スレ↓
https://mevius.5ch.net/test/read.cgi/tech/1536664054/

**デフォルトの名無しさん** · 2018/09/13(木) 14:39:41.76

隔離スレ
https://mevius.5ch.net/test/read.cgi/tech/1536664054/

また自演で自爆してる

**デフォルトの名無しさん** · 2018/09/13(木) 20:32:17.00

>>44
ルビーはアルミで水晶はケイ素だから、同じアルミのサファイアのほうが云々

**デフォルトの名無しさん** · 2018/09/13(木) 21:08:24.91

rustの仕事探しているんだけど全然ないな
もうkotlinはイヤなの

**デフォルトの名無しさん** · 2018/09/13(木) 22:01:54.58

やっぱりな地雷だと思ったぜkotlin

なにがいかんかったん

**デフォルトの名無しさん** · 2018/09/13(木) 22:07:11.17

業務でRustはまだ時期尚早じゃないの流石に

**デフォルトの名無しさん** · 2018/09/13(木) 22:35:41.31

JVMはもうだめだ

**デフォルトの名無しさん** · 2018/09/13(木) 23:25:04.31

>>49
今度はKotlinかよ

**デフォルトの名無しさん** · 2018/09/13(木) 23:32:53.57

>>26
普通にSmalltalkって書けよ。

**デフォルトの名無しさん** · 2018/09/13(木) 23:34:57.50

>>35
同意。もうtypescriptに一本化してくれと思う。

**デフォルトの名無しさん** · 2018/09/13(木) 23:37:42.72

>>48
kotlinのどの辺がいや？煽りでなく。
ちなみに俺はrustもkotlinも使ったことない。

**デフォルトの名無しさん** · 2018/09/13(木) 23:43:36.28

やけに言語のネガキャンが多くない？
ﾜｯﾁｮｲスレから荒らしが出張でもしnに来てんの？

**デフォルトの名無しさん** · 2018/09/13(木) 23:51:36.90

Kotlinは他言語の目ぼしいものをパクり終えて独自のアイデアを入れ始めてから迷走しまくってるよね
驚きが極めて少なくて類推でなんとなく書けることだけが強みだったしそのコンセプトこそが受けたんだから、
変な色気を出さずにパクリ言語に徹するべきだった

**デフォルトの名無しさん** · 2018/09/14(金) 00:01:04.01

地雷とまでは言わないよ

パッケージマネージャがゴミ
メモリばか食い
gradle使わされる
間抜けなnull安全
例外

などjavaから引き継いだ負の遺産に縛り付けられて嫌なの
あとkotlinが悪いわけじゃないが同僚の書くコードがビックリマークだらけでくたばれと思う

kotlin nativeはいい言語になると思うよ

**デフォルトの名無しさん** · 2018/09/14(金) 00:05:35.87

自演かよ

**デフォルトの名無しさん** · 2018/09/14(金) 00:18:59.09

>>58
同僚が糞なだけやん
Javaが糞なだけやん
お前が糞なだけやん
だけやん？

**デフォルトの名無しさん** · 2018/09/14(金) 01:33:30.03

結局自分が使ってる言語がグローバルになればいい
っていうことだろ。どの言語がいいって主張もそれ以上のものは何もない。

**デフォルトの名無しさん** · 2018/09/14(金) 04:36:31.64

言語を叩いても意味無いだろ

**デフォルトの名無しさん** · 2018/09/14(金) 08:20:05.02

>>58
その中だとこの２つの詳細が気になるな
> パッケージマネージャがゴミ
> 間抜けなnull安全

**デフォルトの名無しさん** · 2018/09/14(金) 10:03:36.88

気に入らない言語はほっといて気に入ったのを使えば良い。
なんだったら自分で言語を作れ。
技術力がなくてすぐには作れなかったとしても仕様公開しておけば誰かが作ってくれるかも知れないから全く実現不能ということはない。

**デフォルトの名無しさん** · 2018/09/14(金) 15:51:39.46

ﾜｯﾁｮｲスレは相変わらず回線使った自演しかおらんな
と、思ったらこっちを荒らしに来てたのかよ

**デフォルトの名無しさん** · 2018/09/14(金) 18:51:15.78

仕事で使うのだからほっとくことは出来ない
仕方ないので転職するってわけさ

**デフォルトの名無しさん** · 2018/09/14(金) 21:14:10.82

オフショアのベトコンモンキーどもが頭悪すぎて草も生えない
JS→TS移行の途中段階で今後TSに寄せるって話してんのに
連中型が理解できないらしく、全部素のJSで送ってきやがる
●してやりてぇわ

**デフォルトの名無しさん** · 2018/09/14(金) 21:15:06.63

ここ十数年で色々なパラダイムが流行ったけど、
次はどういったパラダイムが流行ると思う？

**デフォルトの名無しさん** · 2018/09/14(金) 21:16:58.81

>>67
お前いい加減しろ
ﾜｯﾁｮｲスレへ帰れ

**デフォルトの名無しさん** · 2018/09/14(金) 21:22:16.32

>>69
お、型無し能無し糞バカモンキーか？
もういっぺん枯葉剤でも食ってろや池沼が

**デフォルトの名無しさん** · 2018/09/14(金) 21:50:39.57

低レイヤー言語の覇権はOSに依存しがちというのは多分間違ってないんだろうけど窓林檎がRustを採用する未来が見えない

**デフォルトの名無しさん** · 2018/09/14(金) 21:54:34.47

ﾜｯﾁｮｲスレの自演がヒドすぎる

**デフォルトの名無しさん** · 2018/09/14(金) 22:00:31.90

このﾜｯﾁｮｲなしスレ荒れてんじゃん
コテハンのﾜｯﾁｮｲスレの方が冷静に各言語について語り合ってる
ﾜｯﾁｮｲなしスレの方が口汚くののしり合ってる
悪口言い合ってるだけじゃなく、ちゃんと言語談義しろよ
ﾜｯﾁｮｲスレより、このスレの方が素晴らしいと素直に感嘆できるところを見せてくれ

**デフォルトの名無しさん** · 2018/09/14(金) 22:03:08.08

言語を「叩く」っていうのが噴飯物なのよ
何を根拠にまぁえらそうに
知識も経験も無いからこそなんだろうけど
オカンのただ飯食わせてもらいながら飯批判するが如し

**デフォルトの名無しさん** · 2018/09/14(金) 22:10:53.32

たしかに

**デフォルトの名無しさん** · 2018/09/14(金) 22:28:47.17

俺はちゃんと人を叩いてるぞ
型も理解できないモンキーどもは、森に帰るか死んで欲しい
迷惑だ

**デフォルトの名無しさん** · 2018/09/14(金) 22:48:27.13

ちがうそうじゃない

**デフォルトの名無しさん** · 2018/09/14(金) 22:53:34.35

コードも憎んで人も憎む
どいつもこいつもバカどもは
憎しみだけで人が殺せたらどんなにいいかと毎日考えてるわ

**デフォルトの名無しさん** · 2018/09/14(金) 22:59:35.16

自演で荒らすな
ﾜｯﾁｮｲスレへ帰れ

**デフォルトの名無しさん** · 2018/09/14(金) 23:01:19.24

>>78
まずはお前が自殺しようなｗ

**デフォルトの名無しさん** · 2018/09/14(金) 23:02:56.56

黙れ奇形のベトコンめ

**デフォルトの名無しさん** · 2018/09/14(金) 23:03:48.94

型理解してないゴミのコードってマジでゴミでしかないよな

**デフォルトの名無しさん** · 2018/09/14(金) 23:20:49.66

どれだけワッチョイスレへ誘導したいんだ荒らしは？
一人で寂しいからって俺らには関係ねえだろ

**デフォルトの名無しさん** · 2018/09/14(金) 23:33:34.32

◆QZaw55cn4cか

**デフォルトの名無しさん** · 2018/09/14(金) 23:42:55.08

叩くのはエンターキーだけにしろ \ドッワハハハ/

**デフォルトの名無しさん** · 2018/09/14(金) 23:49:36.15

あー全員●したい

**デフォルトの名無しさん** · 2018/09/15(土) 00:51:34.66

芋ほりか

**デフォルトの名無しさん** · 2018/09/15(土) 00:52:16.14

rustのclippyゴイスー
よくこんなめんどくさそうなの作ろうと思ったもんだ
近代的なlintはみんな同じくらいめんどくさそうなことことしてくれるの？

**デフォルトの名無しさん** · 2018/09/15(土) 01:48:02.06

>>68
次のパラダイムは人工知能に関連した何かだと思う

**デフォルトの名無しさん** · 2018/09/15(土) 02:48:23.69

>>89
Lisp復権の時か！

**デフォルトの名無しさん** · 2018/09/15(土) 08:06:42.27

>>89
まず、言葉の定義からして
そんな適用範囲の狭すぎるものはパラダイムとは呼ばないと思うのだが

**デフォルトの名無しさん** · 2018/09/15(土) 10:27:53.40

オブジェクトのコピー、参照の明示化
const的な不変性の明示化
副作用の取り扱い

この辺じゃないのかね。
とはいえrustはなんか違うとは思うが。

**デフォルトの名無しさん** · 2018/09/15(土) 10:58:28.10

LabVIEWある程度やったことある人なら分かるんだけど
ほとんどの言語が変数でやることを配線でやるってなると
（もちろん、ローカル変数グローバル変数ともに実はあるんだけど）
その配線を引くのが手間で仕方ないし
配線がまさにスパゲッティの様相を呈してくる

その反面、そこが苦痛であるがゆえに促される事前の設計というものがある
配線をスッキリさせたいと常に思うような力になってる
こういうのこそ実はパラダイム

**デフォルトの名無しさん** · 2018/09/15(土) 11:31:06.97

>>92
完全にrustじゃん

**デフォルトの名無しさん** · 2018/09/15(土) 11:38:12.15

>>93
LabVIEW懐かしいな
アレでコーディングするコツは変数を構造体化？して一本化してからループに繋いで
Swich-caseみたいなページで処理を分けて書けば随分シンプルで見やすい配線図にできたはず

**デフォルトの名無しさん** · 2018/09/15(土) 13:07:49.43

javaがval導入してればもう少しシェア維持できたろうにな
final varとか書くんだろ？バカちゃう？バカちゃう？
ワイがrfc書いた方がずっとマシですわｗ

**デフォルトの名無しさん** · 2018/09/15(土) 13:13:21.48

どうでもいいだろ
Javaを使ってる会社がJava10以降へ移行する際にまずやることは、
ラムダのときと同じくコーディング規約に「varは使用しないこと」の一行を追加することだよ

**デフォルトの名無しさん** · 2018/09/15(土) 13:16:57.41

>>94
オブジェクトのコピー、参照の明示化
副作用の取り扱い
について,rustは問題あるだろ。
= をコンテクストで意味判断するってのがそもそも問題あるんじゃねーかと思ってる。
副作用あるなしももう少しやりようある気がするけどね。

**デフォルトの名無しさん** · 2018/09/15(土) 14:49:13.19

来なかった次世代のD言語をインストールしてみた

**デフォルトの名無しさん** · 2018/09/15(土) 15:31:59.52

>>99
D使うならDUBはチェックしとき
https://qiita.com/yasei_no_otoko/items/2724eebab10f5cd0a02f
https://code.dlang.org/

**デフォルトの名無しさん** · 2018/09/15(土) 17:23:17.28

PHPにプロパティ型指定だったな
良いことだと思うが
根本的に言語が腐ってるから二度と近寄りたくないし、手遅れ

**デフォルトの名無しさん** · 2018/09/15(土) 21:09:05.46

本気で思うんだがオブジェクト指向で作られたプロジェクトを手続きや関数型で作ってたら本当に困ることになるんかしら？

**デフォルトの名無しさん** · 2018/09/15(土) 21:13:47.35

>>98
具体的にどんな問題が？

**デフォルトの名無しさん** · 2018/09/15(土) 22:26:29.72

メモリもリソースの一種だとみると、副作用って簡単に判じることは難しいんじゃないか
それともメモリをどう荒らしても純粋関数って呼ぶことにする？副作用の有無の価値が大分減るように思えるが

**デフォルトの名無しさん** · 2018/09/15(土) 22:33:31.76

純粋/副作用有りの2択にせずに、noexceptみたいにnoheap, nostack, noio...って小分けすればいいだろ
凄い面倒そうだけど

**デフォルトの名無しさん** · 2018/09/15(土) 23:17:27.00

>>104
これ考えたらやっぱりFortranのpure subroutineが良い

**デフォルトの名無しさん** · 2018/09/15(土) 23:18:18.51

純粋関数型で有名なHaskellだが遅延評価で最適化を行っている時点でメモリとしては極めて状態的なんだよな
ただそのメモリ上表現が純粋関数で得られたものであるという保証があるから成り立っているし、そうでないものはモナドで順序性を保証してるから問題が出ない

**デフォルトの名無しさん** · 2018/09/15(土) 23:24:47.82

モナドで順序性の保証って別に言語実装が保証してるわけじゃないがな。
あくまでモナド実装者が保証するべきものであって。

**デフォルトの名無しさん** · 2018/09/15(土) 23:26:31.34

Rustの副作用の取り扱いの問題って何だ？

所有権移動に関する話で、
いわゆる関数型の副作用とは別の話をしているようにも見える

**デフォルトの名無しさん** · 2018/09/16(日) 00:44:17.96

単純に見た目だけじゃmoveかcopyかわからないって話じゃない？
何かのコンテナ型を自分で実装する時、とりあえず中身にi32を入れて書いて後でジェネリクスにしよう、とかやってると
ボローチェッカにしこたま怒られることがある。見直すと9割が設計ミス

**デフォルトの名無しさん** · 2018/09/16(日) 00:59:06.26

有名な純粋関数型言語といえど遅延評価による最適化は状態的という話なので言い回しの緩さは許してくれ

noioやnoheapなんかはそれこそHaskellではIOモナドやSTモナドで包んで明示してる訳だよな

**デフォルトの名無しさん** · 2018/09/16(日) 08:48:36.18

copyと参照の違いはwriteすれば分かるが、副作用がなかったら違いを知る必要がない
copyとmoveの違いはreadすれば分かるので副作用がなくても違いが分かる

**デフォルトの名無しさん** · 2018/09/16(日) 09:42:39.79

Rustのmoveは確かにイマイチ

ローカル変数は = でmove出来るが
構造体フィールドは = では不可なためmem::replaceを使う
ライフタイムの違いによるものとはいえ記述の一貫性に欠ける

この点はC++のstd::moveの方が一貫性がある

**デフォルトの名無しさん** · 2018/09/16(日) 10:35:29.39

具体例が無いのも何なので一応

RustとC++コード例 >>113での要点はfooの中身
https://ideone.com/jo5Ymj
https://ideone.com/JIAr9h

**デフォルトの名無しさん** · 2018/09/16(日) 17:04:17.35

>>113, >>114
構造体のフィールドはmove出来ちゃまずいから
この場合はむしろC++のコンパイルが通ってることが問題だよ

記述の一貫性のためだけに未定義動作の危険性を許しちゃダメでしょ

**デフォルトの名無しさん** · 2018/09/16(日) 18:21:37.55

Rustの構造体 T のフィールドはmoveできる
&mut T は全体のmoveもフィールドのmoveもできないがreplaceならできる

**デフォルトの名無しさん** · 2018/09/16(日) 18:24:03.24

>>115
このコードに問題も未定義動作も無いぞ
unique_ptrのムーブコンストラクタにより適切に所有権が移動される

**デフォルトの名無しさん** · 2018/09/16(日) 20:39:05.75

>>116
すまん言葉足らずだった
Rustに関してはその通りだよ
でもC++はRustみたいに強力なボローチェッカーがないからmoveはまずい

>>117
そのコードは確かに未定義動作は起こさない
でも未定義動作を起こす危険性を含む
C++の方のfooメソッドの最後の一行をコメントアウトしても
コンパイルが通ってしまうって言えば何が危険か分かるよね
それを防ぐためにはC++の方もreplaceでなきゃダメ

**デフォルトの名無しさん** · 2018/09/16(日) 21:15:13.47

>C++の方のfooメソッドの最後の一行をコメントアウトしても
>コンパイルが通ってしまうって言えば何が危険か分かるよね

俺よくわからないんで解説plz

**デフォルトの名無しさん** · 2018/09/16(日) 21:18:37.65

>>118
fooの最後の一行をコメントアウトしても何も危険は無いんだが
C++のムーブセマンティクスの動作や仕様を理解出来てないんじゃないか？

**デフォルトの名無しさん** · 2018/09/16(日) 21:32:49.26

もしかしてmoveされた側が不定値にでもなると勘違いしてるのかね

**デフォルトの名無しさん** · 2018/09/16(日) 22:03:54.40

rustのmoveが分かりにくいという主旨だと思っていたけど違うのかな？

moveかcopyか分からんてのは確かにだけどプリミティブ型はcopyされると覚えるだけでよくない
しかしなぜプリミティブはcopyのコストを受け入れてよいことになっているの？

**デフォルトの名無しさん** · 2018/09/16(日) 22:31:43.85

>>121
すまん。俺の間違いだった。
move後はnullptrになる事が保証されてることを今知った
今までずっと未定義だと思ってた
(てか会社の先輩にそう教わったんだあの野郎デタラメ教えやがって)
俺の勘違いでした m(__)m

**デフォルトの名無しさん** · 2018/09/16(日) 22:36:54.71

>>123
マニュアルくらい読めよ
https://doc.rust-jp.rs/book/second-edition/

**デフォルトの名無しさん** · 2018/09/16(日) 22:43:00.14

てか軽くググってみても「move後は未定義」って書いてあるサイトが
チラホラ存在するんだが…めっちゃ紛らわしい

>>124
Rustの公式マニュアルは読んどるわ
問題はC++の方だよ
公式のマニュアルは無いわ
ネットの情報は(偽情報含めて)多すぎるわで
まんまと踊らされたわ

**デフォルトの名無しさん** · 2018/09/16(日) 23:28:36.73

後にデストラクタが動くということを考えたら未定義になるわけないし
そこがC++のmoveのイマイチなとこでもある

**デフォルトの名無しさん** · 2018/09/16(日) 23:34:24.03

ここ読んでるとrustはめんどくさそう

**デフォルトの名無しさん** · 2018/09/16(日) 23:37:09.77

めんどくさいのはrustというよりrust信者だけどな。

**デフォルトの名無しさん** · 2018/09/16(日) 23:50:37.70

C++はコンストラクタが複雑過ぎる
Rustにはコンストラクタがない代わりに初期化前やmove後の変な状態がある

**デフォルトの名無しさん** · 2018/09/17(月) 02:01:59.79

実際のところrust使いは満足してるの？

**デフォルトの名無しさん** · 2018/09/17(月) 04:53:12.24

結局の所、その言語によるコードの書き方にメリットを感じる人間がどれ位いるのか、
が重要なわけか

**デフォルトの名無しさん** · 2018/09/17(月) 09:34:55.97

お前ら次スレは
次世代言語15 Rust Rust Rust Rust Rust
にしなさいね

**デフォルトの名無しさん** · 2018/09/17(月) 09:42:03.98

>>129
右辺値参照やconst修飾などの、型の仕様/関数全般の仕様まで一緒くたにしてないか
コンストラクタ自体には大して複雑な仕様は無いと思うけどな
RAIIの理解が要るくらいで

**デフォルトの名無しさん** · 2018/09/17(月) 10:11:10.46

結局の所、メリットを感じる人間ではなく
複雑さのコストを感じない人間が最強なわけよ
ライオンは科学的な練習とかしなくても強い

**デフォルトの名無しさん** · 2018/09/17(月) 10:31:45.23

そういった思想からメンテ不可なゴミコードが生成されるんだと思うよ。

**デフォルトの名無しさん** · 2018/09/17(月) 10:47:39.16

では具体的にはC++処理系とD言語処理系はどっちがメンテ不可のゴミコードになるのかね

**デフォルトの名無しさん** · 2018/09/17(月) 10:49:13.60

バカが書けばどっちもゴミコード

**デフォルトの名無しさん** · 2018/09/17(月) 11:01:37.27

>>136
言語の問題でなくて
>複雑さのコストを感じない人間が最強なわけよ
こういうカス思想の問題だと言ってるんだが。

**デフォルトの名無しさん** · 2018/09/17(月) 11:15:08.74

コストとリスクと不確実性を区別したら面白そう
コストには敏感なくせに不確実性は想定外とかいうカス思想

**デフォルトの名無しさん** · 2018/09/17(月) 11:17:12.97

メンテだけに関して言えばC++の方が闇深コードは生まれやすそう

**デフォルトの名無しさん** · 2018/09/17(月) 11:17:23.87

いまだにpython2使ってそう

**デフォルトの名無しさん** · 2018/09/17(月) 11:26:05.14

C++は闇の作りやすさが問題なんだよな

**デフォルトの名無しさん** · 2018/09/17(月) 11:31:21.72

C++は俺すげぇ感を刺激することに関しては最高

**デフォルトの名無しさん** · 2018/09/17(月) 11:31:24.02

C++は本人以外理解できないコードが容易にできてしまうからなぁ。

Type a = b;

たったこれだけのコードがどんな動作するのか、Typeやbの定義を
隅から隅まで調べないと特定できない。