次世代言語15 Go Rust Bosque Kotlin TypeScript

**デフォルトの名無しさん** · 2019/04/19(金) 22:19:00.41

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2019/06/07(金) 06:29:06.55

BUT the language itself is too poor. Lack of immutability, lack of generics, mediocre module system, very poor package management at the time … made it doesn’t really scale.

It’s really easy to write HTTP servers in Go, but nothing more, the business layer is completely rotten by the imperative paradigm. The worst thing being pointers.

なるほどね

**デフォルトの名無しさん** · 2019/06/07(金) 12:18:53.00

prologブームの遺児みたいなimmutabilityに
googleの仕事が奪われる

**デフォルトの名無しさん** · 2019/06/07(金) 18:43:06.16

>>281
いつかメンテナンスできなくならなければいいんだが

**デフォルトの名無しさん** · 2019/06/07(金) 18:51:12.09

一時期ブームに乗ってscala採用した企業は今どうやってメンテナンスしてるんだろ

**デフォルトの名無しさん** · 2019/06/07(金) 18:52:53.52

どうって？

**デフォルトの名無しさん** · 2019/06/07(金) 19:45:47.00

文献の貯蔵は十分か？

**デフォルトの名無しさん** · 2019/06/07(金) 20:33:49.35

>>284
何言語使えば将来のメンテが安心？COBOL？

**デフォルトの名無しさん** · 2019/06/07(金) 20:58:05.33

rustだったgoのがメンテしやすいだろ。

**デフォルトの名無しさん** · 2019/06/07(金) 21:41:24.93

両方書いてそう思うとは思えないな

**デフォルトの名無しさん** · 2019/06/07(金) 21:42:46.89

scalaはtwitterが使ってたよね

**デフォルトの名無しさん** · 2019/06/07(金) 21:49:11.58

>>290
両方書いてそう思うが。
逆に両方書いてそう思わないのが不思議。

**デフォルトの名無しさん** · 2019/06/07(金) 22:27:17.36

そうか
感性の違いだな

**デフォルトの名無しさん** · 2019/06/07(金) 22:33:20.57

scalaはコンパイル重杉重三さんなのが致命的だったね
劣化scalaのkotlinなんぞに負けるとは情けない

**デフォルトの名無しさん** · 2019/06/08(土) 00:09:04.82

何と戦ってるか知らんが
scalaで負けたならkotlinを投入しても結果はほぼ同じだろ
結果を変えたいなら学習コストも保守コストも桁違いの手段を使えばいい

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

>>293
サンクコストにひきづられるかどうかの違いだよ。
まあそれも感性か。

**デフォルトの名無しさん** · 2019/06/08(土) 08:36:13.18

>>292
>>293
これ興味ある。感性の違いで片付けずに戦ってみてくれないか？
規模の違いとかoopっぽく書いたかどうかとかなんかな
それとも人員確保の話なのかな

**デフォルトの名無しさん** · 2019/06/08(土) 10:32:52.62

行数の分だけバグは増えるぞ

**デフォルトの名無しさん** · 2019/06/08(土) 13:00:28.02

暗黙の動作が多い言語ほどバグを引き起こす。

**デフォルトの名無しさん** · 2019/06/08(土) 13:02:28.86

>>288 バカ言ってんじゃないよ。どこからそんな考えが出てくるのやら。情報処理試験からも削除された化石言語だぞ。

情報処理試験の C Java Python なら心配する事は無い。

**デフォルトの名無しさん** · 2019/06/08(土) 13:29:35.68

>>299
それはただの副作用ですよね

**デフォルトの名無しさん** · 2019/06/08(土) 14:11:25.45

「ただの」と言い切ってしまう感性のやつはプログラムをやらない方がみんな幸せそうだと思うよ。

**デフォルトの名無しさん** · 2019/06/08(土) 14:41:41.32

>>299
rupyのことですね分かります

**デフォルトの名無しさん** · 2019/06/08(土) 15:21:17.99

手続き型でコードをたくさん書くのが幸せと感じる、個人の趣味と混同するようなレベルの低いプログラマーとは
いっしょに仕事したくないね

**デフォルトの名無しさん** · 2019/06/08(土) 15:49:24.97

>>300
どう見ても冗談だと思うけど…

**デフォルトの名無しさん** · 2019/06/08(土) 16:27:41.85

>>305 どこが？むしろ COBOL の方が冗談きついだろ。

**デフォルトの名無しさん** · 2019/06/08(土) 16:41:08.79

COBOLは何十年前のコードがそのまま動くし
今書いたコードが突然非互換アップデートで死ぬ心配もない

**デフォルトの名無しさん** · 2019/06/08(土) 17:46:22.81

マシンには読めても人には読めなくなる。マシンが読むには不要な意味や意図が読めないのなら、そのシステムは進化も変化もできなくなる

**デフォルトの名無しさん** · 2019/06/08(土) 18:21:42.01

COBOLが悪いんやない
設計も実装もできない趣味で手続き型量産してる>>302みたいなガイジがCOBOL書いたから悪いんや

**デフォルトの名無しさん** · 2019/06/08(土) 18:23:20.95

レッテル貼りとは情けない

**デフォルトの名無しさん** · 2019/06/08(土) 18:24:28.68

>>307 全くどうしようもない奴だな。誰がCOBOL で書かれたシステムをメンテナンスするんだ？
COBOL なんて老人ホームの人間しかメンテナンス出来ないぞ。少し強調しすぎたが。

言語と言うのはどんなニッチな言語でもかなりの期間は使い続けられるが、それをメンテナンスできる人間が継続して育つかと言うのとは別問題。

**デフォルトの名無しさん** · 2019/06/08(土) 18:29:56.76

COBOLはついこの前まで原発を動かしていた
メンテナンス出来る人間は一応いる

というか今でも日本のどこかで動かしてるんじゃないの？

**デフォルトの名無しさん** · 2019/06/08(土) 18:30:53.46

というか今でも日本のどこかで動かしてるんじゃないの？というのは原発のこと

**デフォルトの名無しさん** · 2019/06/08(土) 18:40:57.88

>>311
COBOLなんか誰でもできる
不足しているのはCOBOL工ではなく、メインフレームを運用できる技術者
オープン系より遥かに難易度が高く、高度な修練が必要とされる職人芸の世界

**デフォルトの名無しさん** · 2019/06/08(土) 18:44:49.33

>>311
python2とかRuby1.xとかPHP4とかのメンテは
人が育つとかの次元じゃねーぞ

**デフォルトの名無しさん** · 2019/06/08(土) 18:53:06.08

今から本気の本気でscala勉強しようとする人はいるのか？
しかも超優秀で使い物になる人で

**デフォルトの名無しさん** · 2019/06/08(土) 19:53:22.51

>>315
cobolのシステムより価値がなく
cobol並にレガシーな言語
悪夢だわな

**デフォルトの名無しさん** · 2019/06/08(土) 19:58:45.02

>>317
COBOLは言語処理系自体が消えるとかは
無いのでそこはちょっと違う

**デフォルトの名無しさん** · 2019/06/08(土) 21:56:54.48

コンテキストによって使えるAPI制限できる言語ってありますか？
割込みコンテキストとかイベントループでsleep禁止のような

**デフォルトの名無しさん** · 2019/06/09(日) 03:00:13.29

>>319
言語自体に？聞いたことない
というかコーディングルールで決めてLINTみたいなもので自動チェックさせるんじゃない？

**デフォルトの名無しさん** · 2019/06/09(日) 03:38:53.80

あとはRoslynのAnalyzerはめっちゃ強力で自由度も高い

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

コンテキストってのを明示的にsleepに渡すのがセオリーだよな
つまりsleepの引数を一個増やす

ただしコンテキストの捏造はないものとする
その型のコンストラクタ使用禁止
同じ型の変数定義禁止またはその変数への代入禁止や所有権移動禁止

**デフォルトの名無しさん** · 2019/06/09(日) 06:22:10.99

センスがないな

**デフォルトの名無しさん** · 2019/06/09(日) 07:15:38.36

>>297
俺はGoが嫌いだからそれはできないな

**デフォルトの名無しさん** · 2019/06/09(日) 07:46:59.42

例えば英語圏の外の人がいくら勉強しても英語のセンスがないとか
英語の本格的な発音を聞いただけで笑ってしまうとか
感性とかセンスとか言ってる場合じゃないだろ

**デフォルトの名無しさん** · 2019/06/09(日) 08:24:12.13

>>104 Python 実装系の一つ PyPy は、静的型付けの有る RPython と言うPython のサブセットで書かれている。
RPython はC のソースコードなどを吐き出す。しかもJIT で動く。
概ね、PyPy は、CPython (本家のPython) より4倍くらい早い。( JIT の効果 )

RPython で作られたRuby実装で Topaz が有るが早いみたい。(実験的に作られただけ見たい)
同じくRPython でPHP実装も作られてる。

**デフォルトの名無しさん** · 2019/06/09(日) 08:41:41.42

つまりCってことなんだよな
なら最初からCで書けって話になる

**デフォルトの名無しさん** · 2019/06/09(日) 09:03:13.51

>>327 最初からCで書いた実装が、CPython なんだよ。

それよりなぜ早くなるかと言うと、VM 上でJIT が動くからだよ。
PyPy がインタプリタとして動くときは、C のコードを吐き出すんじゃなくて、バイトコードを吐き出し、そのバイトコードをVM 上でJIT が動かしている。

CPython もバイトコードインタプリタなんだけどJIT で動いていない。その一部をJIT で動くようにしたのがNumba

**デフォルトの名無しさん** · 2019/06/09(日) 09:24:23.09

>>319
そういう問題を技術で解決しようと思うのが間違ってる。
322の意見のようなクソシンタックスを無駄に増やすだけだから。

**デフォルトの名無しさん** · 2019/06/09(日) 09:36:31.41

つまり精神論で解決しろと。

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

>>330
こういう極論言うバカにコードを触らせるなということ。

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

冗談抜きにほとんどの事例において「バカにコードをいじらせない」が
ベストソリューションなケースはかなり多いのになんで採用されないのかね？

**デフォルトの名無しさん** · 2019/06/09(日) 10:11:45.69

>そういう問題を技術で解決しようと思うのが間違ってる。

こういう極論？

**デフォルトの名無しさん** · 2019/06/09(日) 10:30:57.11

今現在では極論じゃなくて正論だと思う
精神論じゃなくて技術や設計で解消ということではないかな

コーディング時にsleep自体禁止しても他のメソッド内でsleep使ってたりするのを避けたいのかもしれないけど
もし外部の言語で作ったDLLで使ってたりするとわからない
内部で動的にコード生成してたらすり抜ける（そもそもこれはアウト）

sleep単体だけならいいけどあれこれ禁止するならシグネチャーが複雑になる
結局あっても頼りきりにもできないけどめんどくさい制約にしかならないと思う

**デフォルトの名無しさん** · 2019/06/09(日) 10:31:09.24

だってジャップランド土人村にはその「バカ」が９割じゃん

**デフォルトの名無しさん** · 2019/06/09(日) 10:38:00.85

ユーザーからぼくの考えた最強issueがガンガン上がって来ていらない機能がどんどん追加されて
学習コストが高いだけの誰も使わないクソ言語

**デフォルトの名無しさん** · 2019/06/09(日) 10:56:34.15

こういうののユーザーはなんもわかってないから

**デフォルトの名無しさん** · 2019/06/09(日) 11:18:22.23

しかし、バカ予備軍こと質問者が現れた時点で早くなんとかしようと思わなかったのかね
それらしい答えが出てから慌てて文句言っても遅い

**デフォルトの名無しさん** · 2019/06/09(日) 11:56:10.75

一応JavaのSecurityManagerでできるけど
信頼できないリモートコード制限用の機能だから
普通のアプリじゃ使いにくい

**デフォルトの名無しさん** · 2019/06/09(日) 14:03:25.15

>>319
基盤実装とスクリプトに分けるとかは？
スクリプトに対してはいろいろ禁止できるかと

**デフォルトの名無しさん** · 2019/06/09(日) 14:28:28.36

>>340
どんな感じで禁止できますか？
静的にみつけられるでしょうか？
例を教えてもらえるとうれしいです。

**デフォルトの名無しさん** · 2019/06/09(日) 14:36:28.82

>>341
単純にスクリプトにsleep APIを公開しない、みたいなのを考えてた

**デフォルトの名無しさん** · 2019/06/09(日) 14:43:11.20

なるほど・・・
しかしスクリプト側で使用可能APIを一括で管理ってできるでしょうか？
例えば仮にPythonだとして標準のライブラリのimport禁止など可能なんでしょうか？

**デフォルトの名無しさん** · 2019/06/09(日) 14:47:35.09

luaはそこらへん簡単でredisとか標準ライブラリが割と無い
python組み込みは詳しくないけど可能そうなもんだけどな

**デフォルトの名無しさん** · 2019/06/09(日) 14:50:20.90

いずれにせよ、そういう言語ってなさそうですね。
仕事でリアルタイム系のシステム組んでいるのですが、sleepしない、blockしないとか、
他にもdead lockしないとか、定期的にこれらのルールをやぶるコードが紛れるので
なんとかならないかと思っています。
静的解析のツールで解決できたりするのでしょうか？

**デフォルトの名無しさん** · 2019/06/09(日) 15:05:51.96

並列性とか非同期性がそういう問題の根源なので、
直列実行しかできないスクリプトに切り出して、
基盤側を単純にしたらいいのではと思ってしまう
リアルタイム系の経験が無いからよくわからんけど

**デフォルトの名無しさん** · 2019/06/09(日) 16:48:10.91

明らかにsleep呼んでる側がおかしいのにsleepの内部で何か対策考えるとか
それがバカだって言ってんだよ。
そういうのを解決しようと思えば最終的にグローバル変数から状況を読み込んで
「いい感じに処理する」みたいなクソなことがまかり通るようになる。

こんな当たり前のことを「精神論」とか言って遠ざけて
無駄な技術をゴテゴテ投入すれば解決すると思う方がよっぽど精神論だわ。

**デフォルトの名無しさん** · 2019/06/09(日) 16:57:08.28

リアルタイム系ならそもそも言語の選択肢が殆ど無いような

**デフォルトの名無しさん** · 2019/06/09(日) 17:25:04.36

外部ツールで特定の処理を呼んでないか調べる位しかできないだろ

**デフォルトの名無しさん** · 2019/06/09(日) 18:38:09.36

>>348
はい、普段C/C++なんですがもう卒業したい気分でいっぱいです・・・
実はRustはもしかしたらという気持ちで質問させてもらいました。(Rustの詳細知りません)
原理的には型システムで解決できる問題のような気がするんですけどね

**デフォルトの名無しさん** · 2019/06/09(日) 20:20:15.46

何がもしかしたらじゃボケ
そんな甘ったれた根性を次世代言語スレに持ち込むな

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

ひーイェッサー
お言葉ですがその調子だとMicroPythonに逃げられるっす
（リモコンそんなので作られた日には電池持ちがおそろしいことになりそう）

**デフォルトの名無しさん** · 2019/06/10(月) 08:50:34.25

>>352 もう少し他の人にわかるように話してくれないかな。少し興味のある言葉が出てきたので。
micro:bit か何かをリモコンとして使おうとしてる？

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

わかりやすさの基本は嘘を書かないことだ
それ以外のことを改善しても誤差程度にしかならん

**デフォルトの名無しさん** · 2019/06/10(月) 11:57:54.61

micropythonでいいじゃん

**デフォルトの名無しさん** · 2019/06/10(月) 13:36:54.01

>>321で出てるけどRoslynでできないんかな？

**デフォルトの名無しさん** · 2019/06/10(月) 13:51:46.71

>>356
なにが？

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

>>357
>>319への対処

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

>>358
できるよ

**デフォルトの名無しさん** · 2019/06/10(月) 15:03:28.43

最近の話の流れは、　>>345 の続きかな？

>>345 RTOSは使ってるんでしょ？
MicroPython なんて持ち出してるってことは、RTOSを入れていない？
RasberryPi だと、RTOSとして　RT Preempt なんて使ってるね。
RTOSを入れていればそれほど言語に厳しい制約をかけなくてもよさそうな気がするけど。　

このサイトを見ると似たようなサイズのアプリケーションに、RTOS（Zephyr）（ゼファーと読むのかな）をいれてMicroPython で動かしてるね。
https://open-degu.com/downloads/20190315_degu.pdf

Zephyr入門
https://qiita.com/ueba/items/c5fe99bedd8862854ebd

OSサイズは11KBとコンパクト
PyPi にもラッパーが登録されているのでPythonからも使える。　

日本だから、μT-Kernel（μITron）が普及するとよいと思うけど。
μT-Kernel 2.0がベースのIEEE 2050-2018がIEEE標準として正式に成立
https://www.tron.org/ja/2018/09/press0911/

**デフォルトの名無しさん** · 2019/06/11(火) 20:49:00.58

await asyncが使えればsleepでスレッドをブロックしないのに

**デフォルトの名無しさん** · 2019/06/11(火) 22:45:27.77

割り込みハンドラの話だろうからawaitの仕組み(イベントループ+コールバック)でどうにかなるものじゃないと思うよ

**デフォルトの名無しさん** · 2019/06/11(火) 23:02:57.60

>>360
Pythonの話にはのりましたが、実際にはスクリプトでそのあたりの処理書くのは採用できないです
GC走る言語はsleepされるのといっしょですからね
Roslynってのは知りませんでしたが.NET限定の技術なんですかね？

**デフォルトの名無しさん** · 2019/06/11(火) 23:10:03.46

>>363
RoslynはC#/VB.NETのコンパイラー
DiagnosticsやRefactoringのAPIも提供してて、簡単にAnalyzerを書ける

**デフォルトの名無しさん** · 2019/06/12(水) 05:13:51.19

既に上がっている次世代言語のスコープではなく
そのような要望を満たすものがない

**デフォルトの名無しさん** · 2019/06/12(水) 08:05:40.60

>>365
どのような要望？

**デフォルトの名無しさん** · 2019/06/12(水) 08:13:15.38

新しい言語を一通り触ってjavaScriptかC言語に戻ってくる
C/C++とか書く奴いるけどC++も大概クソだからな
結局Cでできるように書き直したほうが簡潔になるっていう

**デフォルトの名無しさん** · 2019/06/12(水) 08:24:04.66

生産性低いおっさんは要らないから

**デフォルトの名無しさん** · 2019/06/12(水) 08:55:30.78

Cに戻ると言いながらJSと二刀流してるだろ
二刀流が正統派にでもなったら革新的じゃないか

**デフォルトの名無しさん** · 2019/06/12(水) 08:56:29.46

>>363 自分でgc をenable disable にしてコントロールしたり、gc を自分で呼んで(collect) 明示的にgc を起こさせるのいうような方法でリアルタイム性は確保できるんじゃないの？
MicroPythonですらそれらの方法が利用できる。

沢山のIoT デバイスで使われてるだろうから、GC が勝手に動く心配をする必要はないように思うけど？

例えばRTOS Zephyr では、main thread とidle thread で区別してる。

**デフォルトの名無しさん** · 2019/06/12(水) 09:43:44.27

リーナスと同じこと言ってる俺かっこいい的な

**デフォルトの名無しさん** · 2019/06/12(水) 11:05:36.47

俺かっこいいはポジティブ思考
リーナスはネガティブ思考のくせに建設的だぞ

**デフォルトの名無しさん** · 2019/06/12(水) 11:06:33.06

>>371 Linus Torvalds か、面白いやっちゃな
https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%BC%E3%83%8A%E3%82%B9%E3%83%BB%E3%83%88%E3%83%BC%E3%83%90%E3%83%AB%E3%82%BA

記録からみるLinus TorvalsのC++観
https://cpplover.blogspot.com/2013/05/linus-torvalsc.html
メモリー確保のようなものを隠したがるコンパイラーや言語は、カーネル用にふさわしい選択ではない。

**デフォルトの名無しさん** · 2019/06/12(水) 14:34:52.90

>>367
C言語にデストラクタ的な機能が入ればすごく嬉しい。

**デフォルトの名無しさん** · 2019/06/12(水) 15:44:31.00

>>373
リーナスは人間的にはだいぶクソな奴らしいが
技術的な意見についてはさすがにおかしなことはいってない
カーネルレイヤーにC++が相応わしいかというとたしかに微妙だ
だが、アプリレイヤでC++でなくCのほうが良いというのはただの勉強不足

**デフォルトの名無しさん** · 2019/06/12(水) 16:05:20.23

「神がいないと言うのは勉強不足。もっと勉強しろ。そうしたら分かる」

**デフォルトの名無しさん** · 2019/06/12(水) 17:09:53.27

足りないのは勉強でも努力でもない

勉強でも努力でもない何かが存在することくらいはすぐ分かりそうなものだが
必死に勉強したらしいのに分かってない奴がそこにいるのが証拠だ

**デフォルトの名無しさん** · 2019/06/12(水) 17:32:01.72

Linus と Unix を掛け合わせて、Linux にしたんだな。
良いネーミングになったけど。

昔々、安価に使える記憶媒体が5’ のフロッピーディスクしかなかった頃、初めて取り寄せたUnix は、512KB のフロッピーディスク12枚に入って送られてきた。
6MB だよね。
その頃からCがもてはやされ始めた。 C もUnix も基本はシンプル。

**デフォルトの名無しさん** · 2019/06/12(水) 20:41:19.44

>>374
それだったらgoのdefer文入れた方がいいわ。
デストラクタはcには馴染まん。

**デフォルトの名無しさん** · 2019/06/12(水) 20:44:28.68

>>375
gitもcだが？

**デフォルトの名無しさん** · 2019/06/12(水) 21:06:53.07

リーナスの持論からいくと、メモリ管理を手のひらでコロコロできるレベルの低レイヤーが触れない言語は等しくファックなんだよ
つまり次世代言語は

**デフォルトの名無しさん** · 2019/06/12(水) 22:03:42.09

まあメモリ管理を隠蔽しようとするからおかしなことになってる感はあるよな