次世代言語18 V Julia 他

**デフォルトの名無しさん** · 2019/09/30(月) 23:11:51.54

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2019/10/11(金) 09:04:33.43

>>487
つまり採用済なら有効なテクニックてことじゃん

**デフォルトの名無しさん** · 2019/10/11(金) 09:07:25.52

COBOL最高まで読んだ

**デフォルトの名無しさん** · 2019/10/11(金) 09:44:43.53

>>489
せやで
数年前にScalaとかを仕組んでたら中々の腕前だよ

**デフォルトの名無しさん** · 2019/10/11(金) 09:54:57.98

COBOLが昔から変わらないとしても
読みやすいと感じる人の割合は乱高下する

相場操縦はないものとする

**デフォルトの名無しさん** · 2019/10/11(金) 10:18:32.92

再代入ループより高階関数の方が宣言的でシンプルに書けるけど、
map, filter あたりはともかく reduce あたりから理解があやしいヤツが出現し始める

**デフォルトの名無しさん** · 2019/10/11(金) 10:26:51.38

>>488
採用段階でレベル低いの入れなきゃいいじゃん

**デフォルトの名無しさん** · 2019/10/11(金) 10:50:38.25

つまり入ったら勝ち。型パズル推進する価値あり。

**デフォルトの名無しさん** · 2019/10/11(金) 11:04:09.86

>>493
内部動作まで分かっていれば良いけど、使い方だけ分かってる程度の人が書くと
外見綺麗で中は水垢が詰まった配管のようなコードが出来上がる場合もある

大量データに遅延評価版でないmap使ってメモリ食いつくしたり
純粋関数型言語でもないのにreduceで副作用無くそうとして非効率な合成したり
そういう人は大人しくforで書いてくれた方が安全だから無理させなくていい

**デフォルトの名無しさん** · 2019/10/11(金) 11:43:54.79

>>494
こんなブラック業界に好んで入ってくる「レベルの高い人」は少数なんだよ

**デフォルトの名無しさん** · 2019/10/11(金) 11:44:11.80

静的型に反対するなら動的型
これ超わかりやすかったのに
賛成派も反対派もどっちもダメとか、パズルみたいなこと言い出した奴いるよね

**デフォルトの名無しさん** · 2019/10/11(金) 13:06:16.26

静的と動的が合体した言語があればいいんだが

**デフォルトの名無しさん** · 2019/10/11(金) 13:19:27.12

それがまさにTypeScriptでは？

**デフォルトの名無しさん** · 2019/10/11(金) 13:53:18.81

TSのアプローチは素晴らしいけど
ブラウザ環境や外部との連携が多すぎて
型を諦めざる終えないのがきつい
外部の広告モジュールとか型ないじゃーん！
そこ一番型欲しいとこなのに！ってなる

**デフォルトの名無しさん** · 2019/10/11(金) 14:09:18.41

any使えば良いじゃん？

**デフォルトの名無しさん** · 2019/10/11(金) 14:13:47.95

全部anyつければ解決

**デフォルトの名無しさん** · 2019/10/11(金) 14:23:51.72

全部つけるの面倒だし省略したいな

**デフォルトの名無しさん** · 2019/10/11(金) 14:25:54.81

つ noImplicitAny: false

**デフォルトの名無しさん** · 2019/10/11(金) 17:03:32.31

>>502
>>503
嘘つきがたくさんいますねぇw

**デフォルトの名無しさん** · 2019/10/11(金) 18:43:21.71

型付けて喜んでたら肩叩かれた

**デフォルトの名無しさん** · 2019/10/11(金) 19:49:03.04

私物かたづけとけよってか

**デフォルトの名無しさん** · 2019/10/11(金) 20:25:33.17

>>501
それが真に動的な型なんでなければ自分でtype guard function書いて型を付けてやればいい。

**デフォルトの名無しさん** · 2019/10/11(金) 23:07:02.77

型パズルというのはピンポイントすぎて盛り上がらないな
科学パズルとか資本主義パズルとかスケールの大きい議論の方が参加者も増える

**デフォルトの名無しさん** · 2019/10/12(土) 00:05:58.58

>>501
歴史的理由で型無しライブラリを使う場合でも
そこだけ any にできる
質は局所的に落ちるが、全体の低下は防げる

**デフォルトの名無しさん** · 2019/10/12(土) 00:11:56.33

TypeScriptは革命的言語だなあ
漸進してゆく世界、

**デフォルトの名無しさん** · 2019/10/12(土) 00:46:37.40

しょせんはＪａｖａＳｃｒｉｐｔ
クライアントサイド以上の仕事はできない

コンパイルの手間増えただけじゃないの

**デフォルトの名無しさん** · 2019/10/12(土) 01:05:37.94

node.jsでサーバーサイドもいけるぞ

**デフォルトの名無しさん** · 2019/10/12(土) 02:56:56.44

>>513
サーバーサイドで使ってるが

**デフォルトの名無しさん** · 2019/10/12(土) 03:34:27.68

そういえばdenoというnode.jsとは別のサーバーサイドJavaScript/TypeScript実行環境の開発が進んでいるらしい
https://github.com/denoland/deno

**デフォルトの名無しさん** · 2019/10/12(土) 06:05:59.10

>>513
webpackに通すbabelがtypescriptに変わるだけだゾ

**デフォルトの名無しさん** · 2019/10/12(土) 06:40:50.34

スクリプトの話はもうやめよう
所詮おもちゃなんだし

**デフォルトの名無しさん** · 2019/10/12(土) 06:51:03.18

Cしか勝たん、

**デフォルトの名無しさん** · 2019/10/12(土) 12:48:29.54

TSやフレームワークで蓋しても臭いものは臭いんだよなぁ
サーバサイドをTSで開発し始める動きもあるが型の共有とか夢物語だろ

**デフォルトの名無しさん** · 2019/10/12(土) 13:00:26.48

吹いたｗ
いつの時代の人だよ

**デフォルトの名無しさん** · 2019/10/12(土) 17:54:26.13

開発し始める動きどころかお前が知らんだけでもうそこら中でTSサーバー動いてますがな
JS/TSは言語としてはうんこだが処理系のnodeっつーかV8はスクリプト系の言語ではダントツで速いから仕方ないね

**デフォルトの名無しさん** · 2019/10/12(土) 19:36:17.61

さすがにゼロイチの話と受け取られるとは思わなかったわ

**デフォルトの名無しさん** · 2019/10/12(土) 19:45:29.89

いや、0-1じゃなくて程度問題だろ？

**デフォルトの名無しさん** · 2019/10/12(土) 20:04:40.50

新規事業での言語選択としてGolangの方に需要が流れていたがTSの方に揺り戻しが起きたというのが俺の認識だ

**デフォルトの名無しさん** · 2019/10/12(土) 20:07:41.11

言語としてTSはいいけどnodeをサーバーサイドで運用するのはかなり無理ゲー

**デフォルトの名無しさん** · 2019/10/12(土) 22:19:30.50

早くdeno流行れ
nodeは過去の遺産が豊富で生きてるけど
色々と4んでるわ

**デフォルトの名無しさん** · 2019/10/12(土) 22:41:42.70

色々って何が？
具体的に。
そのままだとあたらしもの好きにしか見えないので。
きばってどうぞ。
さあ！
↓

**デフォルトの名無しさん** · 2019/10/12(土) 23:08:08.01

とりあえず名前がださい

**デフォルトの名無しさん** · 2019/10/13(日) 01:51:50.70

サーバーサイドJSがあれだけ盛大に爆死して
フロント裏のAPIサーバ用途はGoが覇権取ったのに
TSに回帰する動きってどこの異世界だよ

そもそもサーバサイドJSが死んだ理由のひとつは
node本体のメモリリークとかプロセス不審死とかの不安定さだろうに
TS化してもnodeである以上同じ結果にしかならんだろ

**デフォルトの名無しさん** · 2019/10/13(日) 01:55:22.10

>>530
いわゆるBFFではまだjsサーバー生きてるな

**デフォルトの名無しさん** · 2019/10/13(日) 02:35:14.13

分かったけどそれでなんでdenoが流行ると解決すると思い込んでるのかがわからん

**デフォルトの名無しさん** · 2019/10/13(日) 02:41:27.85

denoはセキュアでシンプルなアーキテクチャ目指してるらしいから
アンチnodeらしい

**デフォルトの名無しさん** · 2019/10/13(日) 03:16:02.61

アンチというか反省を活かして、だろ。
node作った人なんだから。

**デフォルトの名無しさん** · 2019/10/13(日) 05:43:39.31

まずgoが覇権ってどこ情報だよ

**デフォルトの名無しさん** · 2019/10/13(日) 06:14:04.94

長年Javaを使ってたアドテク業界でもGoを使う流れがきてる

**デフォルトの名無しさん** · 2019/10/13(日) 06:43:44.16

アドテクとかいえば渋谷の緑だけど
あそこはscalaだった気がする

**デフォルトの名無しさん** · 2019/10/13(日) 07:04:51.62

>>537
緑はもうGoだろ
Scalaは黒歴史の負債として残ってるだろうけど

**デフォルトの名無しさん** · 2019/10/13(日) 10:42:19.34

Go強いけど書き手視点での言語仕様が特別良いわけじゃなく
コンパイラやランタイムの性能が尋常じゃないのが大きいと思う

レイテンシ
https://github.com/ixy-languages/ixy-languages/raw/master/img/latency-hdr-hist-1.png
スループット
https://github.com/ixy-languages/ixy-languages/raw/master/img/batches-3.3.png

低レイテンシのガベージコレクションの研究にかなりのリソースを投入しているそうで
GC言語でありながらレイテンシの低さがC/Rustにかなり近づいている

**デフォルトの名無しさん** · 2019/10/13(日) 11:52:52.64

グラフを見たけどRustにするわｗｗｗ

**デフォルトの名無しさん** · 2019/10/13(日) 11:59:26.23

>>530
渋谷・五反田・六本木・銀座・中目黒辺り

**デフォルトの名無しさん** · 2019/10/13(日) 12:07:14.59

>>539
言語仕様が単純だからチューンしやすいってのはあるだろう。

**デフォルトの名無しさん** · 2019/10/13(日) 12:13:04.65

C#強いな

**デフォルトの名無しさん** · 2019/10/13(日) 12:45:57.87

RustとHaskell使えれば最強って感じね

**デフォルトの名無しさん** · 2019/10/13(日) 12:48:56.60

>>544
C#の性能が驚異的だな
高度なランタイムに依存する言語ならではのグラフの変なガタツキもないし

**デフォルトの名無しさん** · 2019/10/13(日) 12:49:17.53

ちりもつもれば..
>>539みるとクラウドで金節約するためにJSなんか使わない方がいいな。リリースの無駄遣いって事？

**デフォルトの名無しさん** · 2019/10/13(日) 12:53:05.97

>リリースじゃなくてリソースやな
結局C#バランス最強ってことかな。さすがmicrosoftや。

**デフォルトの名無しさん** · 2019/10/13(日) 12:54:38.53

広告屋のGoogleごときが技術でMSに勝てるわきゃねーわな

**デフォルトの名無しさん** · 2019/10/13(日) 13:04:01.41

>>539
Rustすげえええ
Cをやっと捨てられる

**デフォルトの名無しさん** · 2019/10/13(日) 14:53:34.59

レイテンシの右側が高い程、CG等による遅延のブレが大きいということ
なのでパフォーマンスの安定性は C/Rust ＞ Go ＞ Java ＞ C#

スループットに関してC#が優秀なのはその通り

あとこのスレに居て今更Rustに驚いてる人はRustをどういうものだと思ってたの
パフォーマンス、開発効率、メンテ性などのレードオフがあるから
C言語一強にならなかったわけで

**デフォルトの名無しさん** · 2019/10/13(日) 14:54:59.70

トレードオフ

**デフォルトの名無しさん** · 2019/10/13(日) 15:26:24.04

このパフォーマンスならC#使うのがバランスいいな

**デフォルトの名無しさん** · 2019/10/13(日) 15:46:00.98

やっぱC#にするわ。

**デフォルトの名無しさん** · 2019/10/13(日) 16:51:06.08

トレードオフって言ったら賢く見えるのはよくわかるけど
結局何と何がトレードオフで、どういう理由でその一方を取るのか説明できない奴が多すぎる

**デフォルトの名無しさん** · 2019/10/13(日) 16:58:44.07

>>554
じゃあお前が説明しろよ

**デフォルトの名無しさん** · 2019/10/13(日) 18:16:19.45

実行速度、メモリ使用量と開発効率。
開発効率については主観的とかいって馬鹿は排除しにかかるけどな。
ビルド速度なんかは明らかに重要なのに。

**デフォルトの名無しさん** · 2019/10/13(日) 18:40:50.43

Rustは開発効率も良い

**デフォルトの名無しさん** · 2019/10/13(日) 18:44:03.34

そうなんか？

**デフォルトの名無しさん** · 2019/10/13(日) 19:14:38.24

その種のウソを信じたいのだろう。
https://github.com/gnzlbg/slice_deque/issues/57
こういうバグ見ると結局それなりの性能が必要なところでは
それなりの危険なコードが必要だということをrust信者は意図的に無視している。

**デフォルトの名無しさん** · 2019/10/13(日) 19:50:56.00

rustは習得できたらラクだけどそのレベルになるまでが苦労する

**デフォルトの名無しさん** · 2019/10/13(日) 19:54:22.94

>>559
Haskellではクイックソートが数行で書ける！！（性能はお察し）（性能を出そうとすると結局愚直に書くことになる）
みたいなやつを思い出したわ

**デフォルトの名無しさん** · 2019/10/13(日) 20:18:59.16

rustが完全無欠だなんで信者ですら言ってないだろ
どんな言語も弱点はあるが、rustはマシだから選ばれてる

**デフォルトの名無しさん** · 2019/10/13(日) 20:28:54.42

>>538
Scala祭りにスポンサードする程度にはScalaエンジニア募集してるっぽいけどな

**デフォルトの名無しさん** · 2019/10/13(日) 22:26:02.69

>>559
バグがあるから性能が必要なところでは危険なコードが必要ってどういうこと？
言語仕様的にこの類のバグは解消不能ってこと？

**デフォルトの名無しさん** · 2019/10/13(日) 23:02:11.59

オールオアナッシングでしかものを考えられないヤツが何回も何回もひとつのバグをあげつらい続けているけど、C++が今まで出してきたバグの数と比較したら……

**デフォルトの名無しさん** · 2019/10/13(日) 23:08:52.23

逆に言うとそれしか叩ける所がないってことかもね

**デフォルトの名無しさん** · 2019/10/13(日) 23:26:24.13

Rustは良い言語だと思うがGCのコストが許容できる用途だと所有権やら何やらが完全に無駄に難しいだけというのが辛いし
Rustを持ち上げてる奴を見るとお前が書いているプログラムはそんなに超高速な性能が必要なのかと問い詰めたくなる

**デフォルトの名無しさん** · 2019/10/13(日) 23:33:27.08

一つのバグね。。
主張している安全性がどういう壊れ方をするかがよくわかる例なんだがな。
まあどうせまともにコードを読んでないんだろうが。

**デフォルトの名無しさん** · 2019/10/13(日) 23:34:03.53

確かにややこしいがちょっと勉強するだけだし
速いにこしたことはないもの

**デフォルトの名無しさん** · 2019/10/13(日) 23:36:01.31

超速い言語と激安いハードを組み合わせるのは良い作戦じゃないか

**デフォルトの名無しさん** · 2019/10/13(日) 23:37:32.33

>>568
誰も壊れないなんで言ってないから
なにを主張したいのか分からん

>>570
速いは安いってのを理解してないやつが多いよな

**デフォルトの名無しさん** · 2019/10/13(日) 23:51:38.82

てかそのバグも実際unsafe関数の中で起きてる話じゃん

｢安全じゃない書き方は基本的にNGだよ、でも必要な場面があるのも事実だからそのチェックをスルーする方法も提供するよ☆｣
｢ただしその場合はコンパイラは安全性を保証出来ないからコード書く人の自己責任だよ☆｣
｢それでも原因はunsafeで囲った中に限定されるからデバッグとかしやすいかもね☆｣

まさにRustの意図した通りの動作やな

**デフォルトの名無しさん** · 2019/10/13(日) 23:56:03.62

>>572
問題はそのコードにおいてなぜunsafeを使う必要があるか？ってところなんだがな。
低レイヤーを触らん奴には問題ないんだろう。
だったらrustを使う意味もないがな。

**デフォルトの名無しさん** · 2019/10/14(月) 00:00:13.00

｢まともにコードを読んでないんだろうが｣
｢低レイヤーを触らん奴には問題ないんだろう｣

いきなり意味不明な決めつけで飛躍した論理展開、ガイジかな？

**デフォルトの名無しさん** · 2019/10/14(月) 00:01:59.18

結局そのコードがなぜunsafeを使うことになるかわからんのだろ？
だったらそれで君にとっては問題ないから何も考えずにrustを信じて使ってたらいいよ。

**デフォルトの名無しさん** · 2019/10/14(月) 00:10:47.41

いいたいことがあるならハッキリシャッキリ言えやモヤシ野郎

**デフォルトの名無しさん** · 2019/10/14(月) 00:14:07.91

unsafeとかどうでもいいよ
>>564の疑問に答えてくれよ

**デフォルトの名無しさん** · 2019/10/14(月) 00:14:43.91

いやイキってすいません自分はrust勉強し始めたばっかなんでどんな問題なのか教えてほしいだけです教えてください先生(´・ω・`)
Rustの保証の概念の無いCのコード呼んでるからちゃうんですか？

**デフォルトの名無しさん** · 2019/10/14(月) 02:34:00.32

モヤシをバカにするな！
モヤシはシャッキリしてるだろうが！
シナってんのはお前が安物買ってるからだ！

**デフォルトの名無しさん** · 2019/10/14(月) 08:36:51.30

>>559の1行目って>>557に対するものじゃないの？

その後も>>573 >>575でしきりにunsafeのこと話してるけど
unsafe不要とかバグが出ないとか主張してる奴は居ないわけで
話の前提や言いたいことを落ち着いて整理した方が良いと思う

**デフォルトの名無しさん** · 2019/10/14(月) 08:52:45.75

>>568
で、C++でこのようｂﾈバグが今までｂﾇれだけ出て来ｂﾄ、どれだけ解血�ﾉ苦労してきｂｽか知ってるの＝H

**デフォルャgの名無しさん** · 2019/10/14(月) 09:03:42.68

559の説明をするけど、これqueueの実装で、インデックスがある閾値を超えたら
戻すみたいな処理をやってんだよ。
で、こういった配列インデックスに対するアルゴリズム的なアクセスってのは
どうしてもunsafeになるってわけだ。
こういう普遍的に発生する話に対してなんも考えてないって馬鹿にされても仕方ないと思うんだがね。

**デフォルトの名無しさん** · 2019/10/14(月) 09:11:58.05

>>582
＞で、こういった配列インデックスに対するアルゴリズム的なアクセスってのは
＞どうしてもunsafeになるってわけだ。
うん、それRust公式で普通に言われてる話ね
こういうところでは普通にunsafe使わざるを得ないから用法容量を守って正しくお使いくださいと言われてるよ
それで？　お前の中ではそれひとつでRustで解決されてるありとあらゆるC++の欠陥がなかったことになるの？

**デフォルトの名無しさん** · 2019/10/14(月) 09:17:14.79

ここまで言ってもそう思うもんなら何言っても無駄だろうね。
>こういうところでは普通にunsafe使わざるを得ないから用法容量を守って正しくお使いくださいと言われてるよ
これ言い出したらじゃあcでもよくね？で終わるってこと少しは自覚してるのかな？

**デフォルトの名無しさん** · 2019/10/14(月) 09:23:36.77

>>584
＞これ言い出したらじゃあcでもよくね？で終わる
unsafeにならざるを得ない処理をモジュールに切り出したりしないで、
プログラム内のありとあらゆる場所をunsafeで囲ってるならそうですね

**デフォルトの名無しさん** · 2019/10/14(月) 09:30:19.19

「MCCじゃないテストはすべて無意味」論者あらわる(´･ω･｀)

**デフォルトの名無しさん** · 2019/10/14(月) 09:42:34.81

>じゃあcでもよくね？で終わる

ここ彼の一連のレスの基かな

**デフォルトの名無しさん** · 2019/10/14(月) 09:43:47.38

実際、CとFORTRANだけあれば十分だからな