次世代言語17 Go Rust Kotlin TypeScript Julia

**デフォルトの名無しさん** · 2019/09/04(水) 22:10:19.21

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2019/09/28(土) 12:36:06.89

>>835
JSは今やフレームワークやライブラリなしが1番扱いやすいというおかしなことになってるからな…

**デフォルトの名無しさん** · 2019/09/28(土) 12:37:44.62

ランタイム選べないんだから仕方ない
wasmにご期待ください

**デフォルトの名無しさん** · 2019/09/28(土) 12:40:56.71

これとか頭おかしい

要チェックな10個の Node.js フレームワーク
https://qiita.com/ymasaoka/items/3db3f44990911a181ffc

**デフォルトの名無しさん** · 2019/09/28(土) 13:04:20.04

node.jsとかもその典型だよな
シングルスレッドの扱いやすさを熟知してるレベルなら自前で
簡単にピュアJSで組めるから不便さを補うライブラリ程度で良いんだよな

**デフォルトの名無しさん** · 2019/09/28(土) 13:47:42.15

>>805
ワシもw

**デフォルトの名無しさん** · 2019/09/28(土) 14:31:30.39

ハードの性能から逆算してソフトの仕様決めてるんじゃないか
予算を全部使い切る公務員のように

**デフォルトの名無しさん** · 2019/09/28(土) 14:53:17.60

C/C++は糞
やっぱり次世代言語だよな

LLVM、定数として宣言されたメモリ領域への代入を削除する最適化を導入
https://developers.srad.jp/story/19/09/27/1626210/

**デフォルトの名無しさん** · 2019/09/28(土) 14:59:07.53

>>829 >>828
じゃマシン語もか？

**デフォルトの名無しさん** · 2019/09/28(土) 16:12:09.98

ゴミみたいなJavaScript言語があるからこそ、毎年新しいフレームワークだので無理やり仕事つくれる。
仕事なくさないために、JavaScriptみたいなゴミ言語が必要。金より楽したい俺にはうんざりだわ。

**デフォルトの名無しさん** · 2019/09/28(土) 16:17:28.65

こんなに新しいフレームワークが生まれたり消えたりしてるなは、技術革新というより、元になるJavaScriptがあまりにも糞だっために、何度も試行錯誤せざるを得ないだけ。

**デフォルトの名無しさん** · 2019/09/28(土) 16:48:08.27

俺的なイメージでいうと、大昔にシー言語やアセンブラむちゅかしくてわかんない!でもベーシックだったらできる!
ていってた連中と、ひと昔前に JavaScript に群がってた連中と今 Python に群がってる連中が全部同じ空気感を放ってる

**デフォルトの名無しさん** · 2019/09/28(土) 17:02:09.69

オジサンCよりJavascriptの方が難しい(泣)
なんでスコープを抜けてもローカル変数にアクセスできるの？

**デフォルトの名無しさん** · 2019/09/28(土) 17:15:03.51

>>847
スコープ理解できない人のため

**デフォルトの名無しさん** · 2019/09/28(土) 17:15:27.68

>>847
おじさん向けにわかりやすく説明すると
スタックフレームはGCが開放するから
ローカル変数を参照しているものがあれば
その変数は生き続ける

**デフォルトの名無しさん** · 2019/09/28(土) 18:46:39.82

スコープ抜けたら参照できないでしょ

**デフォルトの名無しさん** · 2019/09/28(土) 19:10:59.05

うんvarはスコープ抜けても参照できるんじゃなくて関数スコープなだけだしな。何スコープなのか分かってないと予想。

**デフォルトの名無しさん** · 2019/09/28(土) 19:43:03.61

結局IT業界ってクラウドぐらいしかこの10年で進んでないよね
言語が変わってもお前らがやることはCRUDだけw

**デフォルトの名無しさん** · 2019/09/28(土) 19:43:25.82

なんでそんなふうに決めちゃったんだって言ってるんだろ！
わかりにくいのに

理解できないやつのためとか人を見下ししすぎ小学校でカッコが理解できたらできるだろ

**デフォルトの名無しさん** · 2019/09/28(土) 19:57:17.31

ただバグを探して直すだけでも前に進んでいる
これが事実

デバッグが苦手な人ほど、この事実を認めようとしない

**デフォルトの名無しさん** · 2019/09/28(土) 20:04:15.41

一番進んでないのは進んでないと言ってる本人という事実

**デフォルトの名無しさん** · 2019/09/28(土) 20:10:10.19

>>855
おっ？俺に言ってんのか？
俺はCRUDエンジニアと違って機械学習の案件に数年携わっていたが？🤩

**デフォルトの名無しさん** · 2019/09/28(土) 20:15:02.67

機械学習（）

**デフォルトの名無しさん** · 2019/09/28(土) 20:24:31.46

>>850
できるよ
クロージャがまさにそれ

**デフォルトの名無しさん** · 2019/09/28(土) 20:25:56.33

>>858
？
やってみてよ

**デフォルトの名無しさん** · 2019/09/28(土) 21:03:05.39

たしか出来ちゃう言語あったよね
emacs-lispみたいなスコープが入り混じった感じのヤツ

**デフォルトの名無しさん** · 2019/09/28(土) 21:09:39.43

>>853
分かりにくいと思ったから後でlet作ったんでしょ

**デフォルトの名無しさん** · 2019/09/28(土) 21:26:55.54

>>859
function foo() {
var a = 1;
return function () {
return a;
};
}

var x = foo();
x(); // 1

fooの呼び出しが終わったのに
クロージャによりaがキャプチャされてるから生き残る
最近のC++でもクロージャは書けるから
似た感じのことはできる

**デフォルトの名無しさん** · 2019/09/28(土) 21:45:02.03

>>862
それのことね、そうだね

**デフォルトの名無しさん** · 2019/09/28(土) 21:50:36.65

恥ずかしくないんかなこいつ

**デフォルトの名無しさん** · 2019/09/28(土) 22:05:24.19

スコープとはその名前で参照できる範囲だから参照出来たら範囲内だ
人間が決めた前提としての定義だから
宇宙が滅んでも無理
絶対的真実

**デフォルトの名無しさん** · 2019/09/28(土) 22:10:32.81

お前は正しい

**デフォルトの名無しさん** · 2019/09/28(土) 22:34:56.87

Ruby では、関数スコープがあるから、
関数外の変数が、関数内では参照できないけど、

JavaScript, Python は出来るから、すぐバグるので超危険！

**デフォルトの名無しさん** · 2019/09/28(土) 22:37:39.92

C++のラムダ式のシンタックスと挙動知ってたらスコープ抜けてるとか口が裂けても言えないんだよなぁ

**デフォルトの名無しさん** · 2019/09/28(土) 23:22:13.75

いや普通に const 使えばええやん
今さら var の話題とか本当にここは次世代言語スレか？
ガイジは特別学級に帰れよ

**デフォルトの名無しさん** · 2019/09/28(土) 23:22:58.40

おじさんの雑談スレだから

**デフォルトの名無しさん** · 2019/09/28(土) 23:37:41.46

で、そのconstはIE6-10に対応してるのかい？🤔
富裕層のジジイを相手にしてる俺にはIEで使えるか使えないかってのが重要なんだよ😏

**デフォルトの名無しさん** · 2019/09/28(土) 23:41:24.41

>>871
最高に旧世代なレスで草だｗ

**デフォルトの名無しさん** · 2019/09/28(土) 23:42:13.91

次世代言語スレで化石環境サポートを語る

**デフォルトの名無しさん** · 2019/09/28(土) 23:44:46.92

ま、スマートの俺はBabelを華麗に使ってconstを使ってるけどな😎
ついていけないやつらは振り落とされないようにつかまってろよ？🤯

**デフォルトの名無しさん** · 2019/09/28(土) 23:45:32.11

constで品質が安定すると思ってるのは若い証拠だね

**デフォルトの名無しさん** · 2019/09/28(土) 23:49:00.63

安定を要求するなら枯れた言語でいいじゃん
次世代言語スレなんだから投機的に新機能を使っていくんだよ

**デフォルトの名無しさん** · 2019/09/28(土) 23:54:36.68

Chromeでは上手くいくのにFirefoxでは上手くいかない
他のブラウザでは上手くいくのにSafariでは上手くいかない
Androidのバージョン7以下では上手くいかない

こういう面倒くさい対応が嫌すぎてフロントからは足を洗った

サーバサイドはこういうわけわかんねーことで悩まされることないから楽だわ。。。

**デフォルトの名無しさん** · 2019/09/28(土) 23:57:47.98

>>831
裾野のさらに底辺という救いようなく酷い奴らという意味なんじゃないの

**デフォルトの名無しさん** · 2019/09/28(土) 23:59:20.69

>>839
Node.jsを使わずにデスクトップアプリをどうやってJavaScriptで書けば良いんじゃ…

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

>>847
varでなくlet使え、

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

>>850
キャプチャすれば逝ける

**デフォルトの名無しさん** · 2019/09/29(日) 00:02:01.29

YouTube で有名な、KENTA も、クライアント側をやらない！

デバイス・環境は数百種類ある。
それらに対応していると、ドンドン時給が下がってくるから！

**デフォルトの名無しさん** · 2019/09/29(日) 00:04:46.15

>>879
VSCode も、Electron 製

Electron = Node.js + Chromium + V8

**デフォルトの名無しさん** · 2019/09/29(日) 00:45:32.87

ちなみに今やPCゲーマーの必須アイテムDiscordもエレクトロン製
どうでもいいがDiscordのアップデートの御知らせ文はおもろい

**デフォルトの名無しさん** · 2019/09/29(日) 01:04:19.87

>>875
内部にステートもったいなオブジェクトを更新しまくってたりしたら意味ないが、
そういうケースを除くと保守性は確実にconst＞＞＞＞＞＞＞＞＞＞＞＞＞let＞varだよ

**デフォルトの名無しさん** · 2019/09/29(日) 01:08:18.56

ベターを知らないお爺さんには伝わらないよ

**デフォルトの名無しさん** · 2019/09/29(日) 01:11:36.90

Electronアプリ死んでくれねーかなぁ
Javaやドトネトよりはマシだけどよ
やっぱデスクトップアプリはネイティブで作ってほしい

**デフォルトの名無しさん** · 2019/09/29(日) 01:45:03.41

>>887
大丈夫、VS-codeも君に使って欲しくないから。
相思相愛だね！

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

>>838
adonisいいよ

**デフォルトの名無しさん** · 2019/09/29(日) 07:44:24.39

結局のところGoぐらいしか次世代言語としてマシなのが無い
フロントに関してはWASMが本格化してから投資すればいいし

**デフォルトの名無しさん** · 2019/09/29(日) 07:49:09.18

もうじき待望の次世代言語C++20が来る

**デフォルトの名無しさん** · 2019/09/29(日) 08:11:44.01

デスクトップもFlutterの時代

**デフォルトの名無しさん** · 2019/09/29(日) 08:17:55.94

>>887
Office365のUIの多くはreact-native-windowsで作られている
ネイティブ部品で画面構成されるがミドルより上はネイティブコードでない
これはどっちの判定？

**デフォルトの名無しさん** · 2019/09/29(日) 08:38:12.62

MASMと空目した

**デフォルトの名無しさん** · 2019/09/29(日) 08:51:31.67

JavaScript以外のフロントの言語が普及したら楽しそうだよなー

そもそもNode.jsでサーバ側もJavaScriptにするって方向性が謎だった

**デフォルトの名無しさん** · 2019/09/29(日) 08:53:55.94

まともなプロダクトのフロントエンドってReact以外見たことないな
Vueを熱烈支持している人たちはハローワールドばかり作ってるのか？

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

「まともなｘｘ」
「本当のｘｘ」
「正しいｘｘ」

都合の悪い現実に目をつぶる言葉

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

wappalyzer眺めてみ
お前の知ってるプロダクト全部Reactだぜ

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

>>898
すまん、ほとんどjQueryだったわ……

**デフォルトの名無しさん** · 2019/09/29(日) 09:13:50.66

これが現実

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

ﾜﾛﾀ

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

まぁでもReact使ってるとこも割と多いな。webpackしか書いてないとこも多いが

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

reactのcomponentとかいい意味で普通のguiパーツって感じだ。

**デフォルトの名無しさん** · 2019/09/29(日) 11:19:49.49

言語のセンスは雑談してる間も右肩上がり
毎日筋トレしてるようなもの
じゃあGUIのセンスってどうやって鍛える？

**デフォルトの名無しさん** · 2019/09/29(日) 11:30:17.17

現状コードがなんでメンテしずらいのか本気で考えてるかどうか。
それ以外にない。

**デフォルトの名無しさん** · 2019/09/29(日) 14:55:16.04

動的型付け言語を嫌う人がたくさんいるけど
だったらなんでJavaAppletは淘汰されたんですかね

**デフォルトの名無しさん** · 2019/09/29(日) 14:59:53.00

Java7以前はゴミだから

**デフォルトの名無しさん** · 2019/09/29(日) 15:04:33.88

その話に型は関係ない
serveletは生きてるし

**デフォルトの名無しさん** · 2019/09/29(日) 15:28:26.90

JavaScriptから逃れたいからWebAssemblyでプロダクトが作れるようにはやくなって欲しいね

**デフォルトの名無しさん** · 2019/09/29(日) 16:00:24.40

TypeScriptは実質JavaApplet

**デフォルトの名無しさん** · 2019/09/29(日) 16:33:31.84

vueかReactどっちがいいんかね
とっつきやすさではvueなんだけど
親コンポーネントへの通知の仕方とか
v-bindとかセンスのなさをところどころに感じる
一方Reactは自由過ぎてなかなかとっつきにくい
Reduxも複雑過ぎる
ちょうどいい感じのReduxが欲しい

**デフォルトの名無しさん** · 2019/09/29(日) 16:45:16.39

そうだなあ
jspとjQueryとかどうだろう

**デフォルトの名無しさん** · 2019/09/29(日) 16:50:03.26

reduxまでは別にそこまで複雑ってわけでもないだろ。
state管理の方がよっぽど複雑になるわ。
api処理をどうするか考えたときにどうすんねんとはなるとは思うが。

**デフォルトの名無しさん** · 2019/09/29(日) 16:51:45.75

ajaxやコンポーネント化をささえるような
サーバ側の技術ってないのか
なんでクライアント側ばっかり

**デフォルトの名無しさん** · 2019/09/29(日) 17:33:59.43

鯖側をJavascriptで作ろうって発想がそもそもキチガイじみてる

**デフォルトの名無しさん** · 2019/09/29(日) 17:35:47.30

マジでキチガイじみているからやめろ

**デフォルトの名無しさん** · 2019/09/29(日) 17:37:00.23

だれがＪａｖａＳｃｒｉｐｔで作るなんてゆった（怒

**デフォルトの名無しさん** · 2019/09/29(日) 17:50:48.63

vueとreactの差が問題になるようなところで勝負したら負けかなと思っている

**デフォルトの名無しさん** · 2019/09/29(日) 18:04:18.60

>>915
君は今は鯖側はどんな言語で作ってるんだい？

**デフォルトの名無しさん** · 2019/09/29(日) 18:05:02.34

あ、煽りじゃなくて純粋な質問です

**デフォルトの名無しさん** · 2019/09/29(日) 18:46:48.18

Goってシンプルすぎてプログラミングやってる気にならない
このまま楽な方になっていけば10年後にはコーディング量が今の10%ぐらいになってそう

**デフォルトの名無しさん** · 2019/09/29(日) 18:53:12.71

>>921
開発現場からすればお前のやってる感とかどうでもええわって話になる。

**デフォルトの名無しさん** · 2019/09/29(日) 18:55:36.05

よさそうなんだけどな
例外ないのだけ気になる
あれ握り潰し横行せんか？

**デフォルトの名無しさん** · 2019/09/29(日) 19:00:02.11

バグを減らし生産性を高める最良の手段は、プログラマのオナニーを封じることである
COBOLが正しかったことが改めて証明されたな
ただ、いずれはCOBOLと同じく反動で複雑な方へ戻ってしまうと思うんだよな
そうならないためには、抑圧されたプログラマの自己顕示欲をどう処理するかが今後の課題だ

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

cobolが最良だったらみずほがあんなに年月かかるわけねーだろｗ
なんでこう両極端に走ることになるのか、これが問題の本質な気がするわ。

**デフォルトの名無しさん** · 2019/09/29(日) 19:11:37.53

>>923
実際にはGoではエラーの握り潰しは極めて少ない
Javaで例外の握り潰しが横行した最大の理由は、例外処理にかかる心理的負担が大きいこと
このメソッドはどんな種類の例外を投げるのか、最スローするべきか、ラップするべきか、ラップするなら検査例外にすべきか
プログラマはメソッドを呼ぶ度に高度な判断を毎度強いられることになる
一方Goは殆どの場合何も考えず猿のように定型句のifを書いてリターンするだけでいい

**デフォルトの名無しさん** · 2019/09/29(日) 19:19:16.64

deferのためなんだろうけど、返り値全捨てでの握り潰しがコンパイルエラーにならないのは不満

**デフォルトの名無しさん** · 2019/09/29(日) 19:23:00.21

型なんてプログラマのオナニーなんだから無い方がいいってことだな

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

少なくともJavaやC#における型は(IDEとコンパイラ以外にとって)
何の意味もないのでGoみたいにメモリサイズの計算のためだけに存在してるのが正しい姿かなと
型が意味あるのはHaskellだけだと思う
後は全部中途半端

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

IDEとコンパイラは生産性に寄与しないってことだよね、わかるわかる

**デフォルトの名無しさん** · 2019/09/29(日) 21:02:07.14

なんでバカって極論が好きなんだろうな

**デフォルトの名無しさん** · 2019/09/29(日) 21:16:55.37

正しいとはまた強い言葉を使うなぁ
まぁGoは一つの落としどころとして間違いないと思うしIdrisまでいくと人間の手に負えたものでは無いんだろうけどサ

むしろコンパイラの検査とIDE支援の容易化としての型が私は嬉しいのでC#程度の型が人間の扱う丁度良さだと思ってるよ

**デフォルトの名無しさん** · 2019/09/29(日) 21:18:34.68

>>931
AIだから

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

そらそのほうが楽だからな
だから責任ある立場になれず、他人の決定に問題ばかり言ってるのさ

**デフォルトの名無しさん** · 2019/09/29(日) 21:32:44.59

サーブレット実務で使ってるひとたちには申し訳ないがこいつが標準で同梱されているせいで.NETよりSDK一式がでかくなってるんじゃないのか