次世代言語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/12(水) 14:13:32.22

スレタイに文句言うのはいつものお約束みたいなもんだから。。
別にほっとけばいいのさ。

**デフォルトの名無しさん** · 2018/09/12(水) 18:28:16.06

Kotlinはいらんやろ申し訳ないけど

**デフォルトの名無しさん** · 2018/09/12(水) 19:05:25.46

どうせrust以外の話ないしなんでもいいけどな
検索しやすいようにしたほうがいいと思うど

**デフォルトの名無しさん** · 2018/09/12(水) 19:23:27.40

荒らしはワッチョイスレを立てたんだからそれで満足しろよ

**デフォルトの名無しさん** · 2018/09/12(水) 19:31:58.18

何を以て荒らしなのか

**デフォルトの名無しさん** · 2018/09/12(水) 19:58:51.32

静的言語は人工知能に向いてないらしいよ。これから人工知能全盛になるのに？
だからRustよりも意外とJuliaに将来性があるのでは
Juliaは次期Pythonのイスを狙ってるみたいだし

**デフォルトの名無しさん** · 2018/09/12(水) 20:41:23.27

向こうの隔離スレは酷いことになってるな

自演をやるにしてもやり方というのがあるだろうに

**デフォルトの名無しさん** · 2018/09/12(水) 21:00:29.51

>>20
人工知能やったこと無いから分からんのだけども
どういうところが静的言語と合わないの？
具体例教えて

あとちょっと前まではHTML(DOM操作)も静的型付けと相性が悪いって言われてて、
だから動的型付け言語のJavaScriptが適してるとか言われてたけど、
TypeScriptが出てきて静的型付けでも全然行けるじゃんってなったという
過去があるから動的静的とか関係ないと個人的には思ってるんだけど…

**デフォルトの名無しさん** · 2018/09/12(水) 21:20:11.19

ElixirとCrystal、まだ流行ってないってだけの理由で
次世代言語のスレタイにまで挙げるのはどうかと思う

某言語に似てシンタックスがゴミだから、どうせ流行らないしね

**デフォルトの名無しさん** · 2018/09/12(水) 21:28:52.57

>>20
AmazonはJavaで、GoogleとMicrosoftはC++でDeepLearningを使ったシステムを運用している
トライアンドエラーを繰り返す初心者のアドホックオナニーには面倒臭いだけで、
本格的にシステムを構築するとなれば選ばれるのは静的言語だよ

**デフォルトの名無しさん** · 2018/09/12(水) 21:47:11.11

スレタイは前スレにいろいろ意見上がってたんだから今いっても仕方が無い
ｱｳｱｳｶｰとﾜｯﾁｮｲonlyの自演専用スレもあるんだから

**デフォルトの名無しさん** · 2018/09/12(水) 22:25:05.47

小話がこのスレで嫌われがちなのは重々承知なんだが次世代言語で小話みたいなメッセージベースOOPな言語って無いよね

**デフォルトの名無しさん** · 2018/09/12(水) 22:44:29.33

自演専用スレがレスのかさ上げしはじめてるけど
アレは何か意味があってやってるの？

**デフォルトの名無しさん** · 2018/09/12(水) 22:47:12.31

コンセプトが初志貫徹してるから、俺ならもっといい言語が作れる！ってなりにくいんじゃない？

個人的にはSQLより楽なデータベース操作言語が欲しい
集合論をベースにした言語ってのは分かるんだけど、それって抽象化の手段を提供しない理由にならねえよなって思う
アセンブラレベルの面倒くささを何で許容しなきゃならないんだって

**デフォルトの名無しさん** · 2018/09/12(水) 22:59:37.27

>>28
ほならね

**デフォルトの名無しさん** · 2018/09/12(水) 23:04:29.01

◆QZaw55cn4cや自演をあっちのスレに排除できるなら何でもいい

**デフォルトの名無しさん** · 2018/09/12(水) 23:04:36.64

>>28
そりゃ結局DBが速度面で一番ボトルネックになるからだろ。
抽象化して性能でなけりゃ本末転倒なわけで。

**デフォルトの名無しさん** · 2018/09/12(水) 23:09:53.33

SQL って集合論をベースにした言語なの？
そんな優雅な空気は感じないけど

**デフォルトの名無しさん** · 2018/09/12(水) 23:28:31.46

集合論というか一階述語論理だなぁ。
記述がああなのは、自然言語に近ければプログラマ以外の人でも使えるだろうという当時の流行で。

**デフォルトの名無しさん** · 2018/09/12(水) 23:35:58.38

SQLなんか行と列の表を操作するだけの言語だからな

低学歴知恵遅れでも使えた気になれる
このｽﾚにいるようなｳﾝｺruby厨やｳﾝｺpython厨でも使える

**デフォルトの名無しさん** · 2018/09/12(水) 23:51:05.00

Dartやる気あるのかないのかはっきりしてくれ
Flutterの手軽さは好きだけどDartやだ

**デフォルトの名無しさん** · 2018/09/12(水) 23:55:43.34

SQLに対する不満はSELECTでいちいちカラム指定が必要なことくらいだな
COBOLなんかの固定長レコード時代の名残だよねあれ
ドライバがもうちょっと賢ければ全く必要ない

**デフォルトの名無しさん** · 2018/09/12(水) 23:55:57.89

>>34
おまえはPyキチやろうが
なにシレッと騙っとんねん

**デフォルトの名無しさん** · 2018/09/12(水) 23:57:15.41

つーかワッチョイスレから出てくるな荒らしが

**デフォルトの名無しさん** · 2018/09/12(水) 23:58:05.48

ｺｺはｳﾝｺruby厨の隔離ｽﾚか

**デフォルトの名無しさん** · 2018/09/12(水) 23:59:31.64

荒らしは荒らしの立てたスレに引きこもってろボケ

**デフォルトの名無しさん** · 2018/09/13(木) 00:10:09.54

◆QZaw55cn4cはうざいな

**デフォルトの名無しさん** · 2018/09/13(木) 00:24:13.82

別回線で荒らした所で
別人だと馬鹿正直に信じてもらえると思ってるのかな？

**デフォルトの名無しさん** · 2018/09/13(木) 03:46:49.46

SQLって1000個位のデータじゃ使わないし個人が大きい会社のデータまとめて管理するのだと1万程度になるデータもあるやろからそれ専の雑で書きやすいSQLは何か気になる
近頃のマシンなら万データも余裕かしら？

**デフォルトの名無しさん** · 2018/09/13(木) 04:16:42.40

Crystalは初耳ですがRubyのインスパイア系だからそういう名前なのか

**デフォルトの名無しさん** · 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++のコンパイルが通ってることが問題だよ

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