次世代言語14 Go Rust Swift Kotlin TypeScript

2018/09/11(火) 20:07:34.76

スレタイ以外の言語もok

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

>>1の1行目に記入
!extend:on:vvvvv:1000:512

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2018/10/07(日) 13:45:25.33

消去法で自殺する

2018/10/07(日) 13:46:16.30

>>379
いじれないんですね。
ありがとうございました！

2018/10/07(日) 15:20:20.15

>>363
現状では、wasmから直接DOM操作することはできないよ(将来的にはできるようになる予定)
でも、Rustならwasm-bindgen, web-sys, stdwebとかがあって、
JSのグルーコードを吐いてくれるからRustオンリーでDOM操作することも可能
ただし、結局JSを経由するわけだから生JSで直接DOM操作したほうが実行速度は多分速い
どうしてもRustでクライアントサイドの開発したい奇特な人向けかな

2018/10/07(日) 16:53:23.11

webassemblyで
rustみたいなmozillarﾛｰｶﾙのｳﾝｺ言語使うﾔﾂいないわ
普通にだれもがc/c++使うことになる

そもそも、webassemblyはc/c++で先にできるしな

2018/10/07(日) 17:00:16.81

>>378
頭がペチクソパァのクソバカ（エンジニア定年超え）にそんなスキルあるわけないんだよなあ

2018/10/07(日) 17:14:55.54

>>384
数か月前の情報だから今は分からないけど、
C++のwasmに関しては例外がまだ非対応だったはず
wasm関連は意外とRustの方がしっかり対応してるよ
wasmだとC/C++よりGoが強敵になりそう

2018/10/07(日) 17:23:20.97

Blazorに期待しとくわ

2018/10/07(日) 17:33:21.00

>>385
いや、君自身に聞いてるんだけど
前職では随分糞PHPerの糞コードに悩まされたそうじゃないか
全取っ替えしようとは思わなかったのかい？

2018/10/07(日) 17:51:15.11

>>388
さっさと転職してあんなゴミ臭い連中とは縁切りましたわ

なぜ俺様が糞バカ中世土人のクソパーに技術を与えてやらねばいけないんだい？

**デフォルトの名無しさん** (ｽﾌｯ Sd94-3Vr4) · 2018/10/07(日) 17:57:54.26

>>389
じゃあお前が心配するこた何も無いだろw
なんで毎回いちいち必死に息巻いてんの？w

**デフォルトの名無しさん** (ｽﾌｯ Sd94-3Vr4) · 2018/10/07(日) 18:02:19.59

「あいつら無能だったんで教育しときました」←有能
「あいつら無能だったんでクビにしました。代わりに俺やりますわ」←まあわかる
「あいつら無能だったんで辞めました」←無能

2018/10/07(日) 18:09:05.39

みじんも心配なんかしてないよ
ただ事実を書いてるだけさ

2018/10/07(日) 19:08:58.85

もう縁がないなら事実も何もお前の中に最新情報も無いんだし、更新されない情報で一生ディスってるなら人として袋小路だから黙っとけな。
事実かどうかはおいといて、お前の主張はそういう事なんだよ。
縁切りましたわ、ってそういう事。
だから無能なの。

2018/10/07(日) 19:12:58.15

連鎖あぼーんだらけで草

2018/10/07(日) 19:50:09.65

こういう自分の主張が無条件に受け入れられる最高の居場所（と本人だけが思っていた場所）を追い出されたキチガイが発狂して凶行に走るんでしょ
ネット界隈ってあちこちでそれ繰り返してるよね

2018/10/07(日) 22:00:20.04

>>383
wasmからDOMいじれるようになったらけっこうフレームワーク界隈楽しいことになりそうだなあ

2018/10/08(月) 04:55:21.27

>>383
もしWASMからdom操作できるようになると、おそらくjavascriptを
使うより高速にdom操作できるようになるんじゃない？
そうなるとwebのフロントエンドでWASMを出力できる実行速度最優先言語が流行るんじゃないかな

2018/10/08(月) 07:06:33.06

同じapi使うんだから速度はかわらんような

2018/10/08(月) 09:33:16.36

64bit整数型, 構造体, スタック配置が使えるから
呼び出し時のマーシャリングの処理コストは減るかもな
セキュリティ的にチェック処理は無くせないだろうけど

2018/10/08(月) 09:38:25.63

js以外の言語でwasm使うとランタイム的なコードが増えて結局通信量増えたりせんのかな

2018/10/08(月) 09:51:29.35

DOMはネイティブ側の解析やレンダリングがボトルネックだから言語を変えても速くはならない
仮想DOMにおいてJS側とネイティブ側の処理時間の割合が具体的にどの程度なのかは知らないけど、ほぼ無視できる程度にはJSは十分速いんじゃないかな

2018/10/08(月) 10:18:53.65

Webで使う場合のホスト言語は事実上jsしかないし、そこを気にする意味もないだろう。

2018/10/08(月) 10:30:26.99

もともとwasmはDOM操作以外の部分を高速化するために作られた機能だからな
DOM操作の高速化については現状では未知数かな？
そもそもwasmのDOM操作用API策定の優先順位もそれほど高くなさそうだし当分先の話なんじゃないかな？
確かまだスレッドさえ実装できてなかったような…
高速化が目的なんだからマルチスレッド処理の方が優先順位高いでしょ
従来のJSのweb workerとは別物らしい…たぶんOSのスレッドとほぼ同じものにするんじゃないかな？

2018/10/08(月) 10:36:37.69

もうJavaScript自体がDOM操作の為に大概最適化されてるだろうしね

2018/10/08(月) 12:35:30.90

>>404
大概？

2018/10/08(月) 12:49:51.13

突っ込むとこそこかww
レス全体があまりにもいい加減だと思うぞ

2018/10/08(月) 12:55:48.59

いや、実際wasmにしたからってDOM操作が早くなるとは限らんって事だけど

2018/10/08(月) 13:52:59.39

それは予測だから好き勝手言って論じていいと思うけど、

メジャーな実装のソースも読めて幾らでも検証できるのに
断言でも伝聞でもなく想像として書くのは未開っぽいと思ったんだよ
宇宙人が作ってる仕組みのわからないものじゃないんだからさ

2018/10/08(月) 14:12:49.06

？！？！
API策定されてないのにどうやって検証するの？

2018/10/08(月) 14:34:29.33

エンジニヤの銀の決まりだろ
黙れ、計測しろ

2018/10/08(月) 15:56:31.47

もしかしてここって話通じないヤツしかいないの？

2018/10/08(月) 17:13:42.76

そうだよ

2018/10/08(月) 17:30:26.37

みんな独自の次世代言語でしゃべってるからね
仕方ないね

2018/10/08(月) 17:39:56.67

個別独自仕様の自然言語を使ってたのかぁ…そりゃ驚いた

2018/10/08(月) 18:44:36.61

あれとかそれみたいな言葉ばかり話してるのは動的言語かな

2018/10/08(月) 18:50:07.46

指示語が多いのはオブジェクト指向なんじゃない

2018/10/09(火) 23:23:20.51

知能が低いﾔﾂほど
こそあど言葉を多用する傾向がある

何か分からない何かを指すためと
考えられる

2018/10/10(水) 08:59:41.65

>>417
そういう君はそれとあれの日本語的な意味の違いちゃんとわかってる？

**デフォルトの名無しさん** (ｽﾌｯ Sd70-3Vr4) · 2018/10/10(水) 11:13:05.20

半角さんにレスしても無意味だよ

2018/10/10(水) 21:08:16.44

知能が低いﾔﾂほど
ストアドSQLを多用する傾向がある

2018/10/10(水) 21:14:33.97

ストアドが害悪な事に関しては同意

2018/10/10(水) 21:50:23.61

重あど

2018/10/11(木) 03:04:04.82

>>409
404 名前:デフォルトの名無しさん (ﾜｯﾁｮｲ e29f-fe/1) [sage] :2018/10/08(月) 10:36:37.69 ID:NFI2fQQ+0
もうJavaScript自体がDOM操作の為に大概最適化されてるだろうしね

この憶測を検証するのにAPIの策定が必要な異世界に住んでいるのか？

2018/10/11(木) 03:07:57.66

>>409はおそらく>>407を検証しろと言われたと読み違えたんだろうけど、
そっちの方は予測だから好き勝手に論ずればいいと1行目で明確に書いている。

2018/10/11(木) 07:53:05.86

>>423
それは検証するまでもないし検証する意味も無くね
その辺は当たり前のこととして、さらに上回る余地があるかという話だと思うし

「なると思う」「ならないと思う」という小並感は意味無いとしても
原理から演繹する思考実験は出来る

リニアメモリと低水準命令セットの仕組みや強い型付けがあることは
ネイティブコールとの結合でもJavaScript+JITより有利
JavaScript側に、numpyやベクトル計算機ように操作自体をまとめて指示できるAPIがあるならともかく
個体ごとの操作しかないからWebAssemblyの仕組みは尚更有効

2018/10/11(木) 08:59:15.93

>>425
あくまでCPUバウンドな処理において、の前置き付きでな
DOM操作に拘るならパフォーマンスの検証は現状でも容易だ
ReactやVueのような仮想DOMを使用したレンダリングにおけるJS側とブラウザ側の処理時間の比 (x : y) を測定してやれば、
WebAssemblyに置き換えたときの理想的なパフォーマンスは y/(x+y) と近似できる
俺は検証するまでもなく絶望的な結果になると思ってるけどね

2018/10/11(木) 10:01:23.32

実際メリットがないから実装のプライオリティが低いんじゃないの？

**デフォルトの名無しさん** (ｽﾌｯ Sdff-DAVC) · 2018/10/11(木) 10:12:47.40

知能が低い奴ほど正しいストアドを見たことが無いだけだろ。
正しくDBエンジニアたちが作ったストアドとViewは、いい感じに疎結合になってるし、
DBとアプリどっちの変化も吸収してくれる上に、そのへんのやつが書いたSQLよりも安定して早いぞ。
カーソル使う/使ってるようなストアドは存在自体が間違ってるとは俺も思うが、
まともなストアドは中途半端に作ったDBや、ORマッパーお任せのDB作成/クエリーよりは良いと思う。

DBエンジニアが居ないような現場だとクソなのかな。

2018/10/11(木) 10:15:04.37

>>428
いいと思ってるのは結局書いた本人だけ

**デフォルトの名無しさん** (ｽﾌｯ Sdff-DAVC) · 2018/10/11(木) 10:18:33.91

Wasmの関数に整数以外を渡すときは結構手数がいるし、型付と言ってもWasm内ではただのバイト列だから死に方はWasm作るために使った言語次第だよ。
だから、単純にwasmにすれば多少パフォーマンス上がるって言い切る事もできない。むしろ遅くなるかもしれん。
Gopherjsとgo+wasmで、gopherjsの方が早かったって結果をebitenの作者が書いてたよ。
あれは画像とかも渡してるけどね。

**デフォルトの名無しさん** (ｽﾌｯ Sdff-DAVC) · 2018/10/11(木) 10:19:00.89

>>429
使ってる側が良いと思ってるよ…？

2018/10/11(木) 10:22:31.73

ちゃんとストアドでできる奴はそっちのが良いと思うけどな
自分は正直あまり自信ないし、デプロイとかフレームワークのこと考えるとO/Rマッパー使っちゃうけど、言ってることは間違ってないと思うわ
ちょっと前にqiitaにもストアドおじさんいたなぁ

2018/10/11(木) 10:25:25.45

>>431
ブラックボックスとして使える内はね
製作者が退職した後にその構造を変えたり足したりしようとしたら阿鼻叫喚になる

**デフォルトの名無しさん** (ｽﾌｯ Sdff-DAVC) · 2018/10/11(木) 11:55:00.62

>>432
デプロイは確かに悩みどころ。
migrationでストアドも載せ替えてくような感じにするしか無いな。
なので、DBの改修って扱いになる

>>433
そんなのライブラリ関数でも同じようなもんだよw
ライブラリ関数作ってるアーキチームみたいな感じ、でDB屋も集まってる感じ。

2018/10/11(木) 12:50:58.56

>>430
>Gopherjsとgo+wasmで、gopherjsの方が早かったって結果をebitenの作者が書いてたよ

嘘ではないけど正確に書いて欲しいな
ChromeではGopherjsの方が速くFirefoxではgo+wasmの方が速かったって結果だよ
最終的に一番パフォーマンスが良かったのはGopherJS on Chromeだったけど

2018/10/11(木) 13:06:45.99

>>434
ライブラリ関数の戻り値は基本的にシンプル値とかリストくらいだけど
ストアドの戻り値は多くの場合整形された複雑なViewじゃん？
前者の場合変更が起こる確率はそれほど高くないし手間も大きくはない

**デフォルトの名無しさん** (ｽﾌｯ Sdff-DAVC) · 2018/10/11(木) 14:56:25.16

>>435
面目ない、wasmが早くないって事のインパクトが大きくて端折ってしまった。
まあ、今のところGoのwasmは「パフォーマンスとかおいとくよ」って言ってるし、伸びしろはあるのかもしれないし、不正確だったな。

>>436
実感的には更新はストアド、取得はView(場合によってはマテリアライズド・ビューだったり、Triggerで生成されるテーブルだったり)が多いんじゃないかな。
ぶっちゃけ後者も同じ程度だよ。ガチで運用すると。

むしろアプリ側から見たら割と純粋だし、手間は思ってるよりも無いよ。
眺めるためのviewではなくて、アプリのためのviewだし。

2018/10/11(木) 16:23:13.10

>>428
> 知能が低い奴ほど正しいストアドを見たことが無いだけ

知能が低い人間としては是非見てみたいので
いい感じに疎結合になっているストアドとViewの低脳でも分かりやすいミニマルな例を出してみてくだしあ

**デフォルトの名無しさん** (ｽﾌｯ Sdff-DAVC) · 2018/10/11(木) 17:58:18.47

>>438
単に半角さんへの煽りだよ。
とはいえ、割と見たことあるからそこまでレアなアーキテクチャじゃないと思うけど。
医療で、そこそこの規模の開発はだいたいそういう感じでやってた。金融でも同じ作りは聞いたよ。

サンプルでミニマルだと、ストアドが鬱陶しく見えるだけだと思うわ。

2018/10/11(木) 21:36:11.52

>>428
低知能は自分の低知能に気付けない説

あるおねｗ

2018/10/11(木) 21:38:47.27

医療と金融ｗ
事なかれ主義の土方ども墓場じゃないですかーｗ　やだーｗ

2018/10/12(金) 00:33:10.55

単に煽りだよって平然と吐く性格の悪さ

**デフォルトの名無しさん** (ｽﾌｯ Sdff-DAVC) · 2018/10/12(金) 07:59:55.85

>>441
意外に新しい物も使うぞ。
ただいろんな法律や保医発みたいな通達に縛られてるだけで。
電子カルテがクラウドに長いこと乗せられなかったのは、センシティブ情報ってのもあるけど、診療録は院内に置くことって決まってたからだし。
充分な試験さえすれば新言語ぐらい使える。

2018/10/13(土) 01:11:03.24

現場によるわな。
終わらないことで有名な某銀行のシステム開発じゃemacsさえ入れられん。。

2018/10/13(土) 01:18:25.70

今どきイマカスとかチンカス並やな

2018/10/13(土) 19:44:26.77

>>444
あんまり研究開発費も使えないからな…
下請けさんの単価って下請けさんの社員さんが思ってるより高いから…

2018/10/13(土) 21:31:42.51

工数買う方からしたらPG一人の拘りを尊重したところで全体の生産性なんかほとんど変わらん
これは決してマクロな視点だからというわけではなくて、
個人単位で見ても、実際のところ、拘りを無視しても本人が主張するような生産性の低下はほとんど見られないもんなんだよ

2018/10/14(日) 01:16:00.58

そしてウンポコペチプーによるウンコードの山盛りウンコがひり出されていく

2018/10/14(日) 04:43:10.13

>>447
そりゃツールの一つや二つならそうだろうけれど、問題は全てに渡って
最低基準に合わされるってところなわけだよ。

2018/10/14(日) 08:56:53.22

変えるならプロパーが検証してから一気に環境変えるわな。
環境構築を言い訳にされたくないし。
「みんな同じ環境で結果出してますよ」ってのは真実であるべきだし。
そのためにほんとに必要だと思うなら直談判して入れさせれば良いと思う。

何度か「確かに。導入してみる？」って導入したものあるよ。

2018/10/14(日) 09:17:10.17

>>449
金融系の最低基準ってISPFっていう大昔のSF映画に出てくるような黒画面に緑色の文字のCUIだぞ？
そんなバカなと思うかもしれないがこれは本当の話で、現代においてもそれほど珍しいことではない
SEはそういうレベルで言ってるんだよ
ところが面白いことに、Javaと比較してもそれほど生産性は大きく変わらなかったりする
システム開発の生産性ってのはSEが何をどのレベルで要求するかでほとんど決まる

2018/10/14(日) 09:20:04.50

開発環境の最低基準では？
医療もレセプト関係の医事課さんが使うようなやつは、罫線で引いたような画面でも許されると言うか、重いぐらいならそうしろって言われるな。

2018/10/14(日) 09:29:10.65

>>452
ところが開発環境の話なんだよなあ
30年以上前に作られたとは思えないくらい意外とまともなエディタが付いてるぞw

2018/10/14(日) 09:52:56.66

まともなエディタって秀丸エディタのことでも言ってるのかな、この程度の低さよ、ペチパー並だな

**デフォルトの名無しさん** (ｽﾌｯ Sdff-DAVC) · 2018/10/14(日) 10:04:21.65

>>453
それはキツいなw
医療はIDE縛りはあるけど、さすがにGUIだった。
変なIDEだったけど(笑)

2018/10/14(日) 14:21:00.57

MUMPSとかまだ現役なんかな？( ; ﾟДﾟ)

**デフォルトの名無しさん** (ｽﾌｯ Sdff-DAVC) · 2018/10/14(日) 16:28:56.70

>>456
残念ながら現役だよw
ってか知ってる方もどうかしてる。

**デフォルトの名無しさん** (ｽﾌｯ Sdff-DAVC) · 2018/10/14(日) 16:31:33.98

ってかどの段階で残ったか移ったかをぼかしとかないと特定されるなw

2018/10/14(日) 22:25:00.00

おじいちゃん、もう寝る時間よ

**デフォルトの名無しさん** (ｽﾌｯ Sdff-DAVC) · 2018/10/15(月) 08:49:30.29

30半ばってもうおじいちゃんかな…。

2018/10/15(月) 21:18:10.18

　私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。

2018/10/17(水) 03:36:58.40

>>451
みどりの窓口でキップとるのに使ってるシステムも今でもそんなだったような

2018/11/05(月) 06:59:43.91

Kotlin 1.3正式リリース。ネイティブコードで実行されJavaVMに依存しないKotlin/Nativeバンドル開始
https://www.publickey1.jp/blog/18/kotlin_13javavmkotlinnative.html

2018/11/05(月) 11:07:38.98

>>462
8bitパソコンで作ったような画面ね
グラフィック画面をオーバーレイするのではなく
それこそBASICのLINE命令で線を描いたような画面

2018/11/05(月) 20:37:28.83

軽量PHPフレームワークSlimは何が「軽量」なのか？～特徴と環境構築 (1/2)：CodeZine（コードジン）
https://codezine.jp/article/detail/11179?p=2

クソバカガイジペチプーは、まーたフレームワークを作ってるらしい
いつまでフレームワーク作ってるんだこいつらｗ
肝心のプロダクトコードはゴミ山ｗ

2018/11/05(月) 21:10:56.09

よっぽどPHPが好きなのなお前

2018/11/05(月) 21:14:47.89

NGすんのめんどくさいから言い方統一して

2018/11/05(月) 21:25:53.24

>>466
未だに時々沸いてくる小バエがうるそうてのう
プチプチ潰していかんとな、プチプチ糞プチパァｗ

2018/11/06(火) 08:57:30.60

お前は結局PHPに対する未練が拭い去れない哀れな敗北者
よっぽど感心がなきゃ流行るかどうかも分からんようなマイナーでマニアックなフレームワークなんて気にもしないだろ
PHPに関するヘイト発言も結局のところこんな仕事辞めてやると息巻いて退職したももも結局PHPしかできるスキルがなくて再就職できない自分への自虐か何かなんだろ？

2018/11/06(火) 09:35:02.30

ももも

2018/11/06(火) 09:59:40.58

ていうか今更Slim知るって
山奥で暮らしてんのか？

2018/11/06(火) 10:18:37.49

都会人特有のウンコの色でマウントを取ろうとするのはみっともないからやめなさい

2018/11/06(火) 10:50:57.63

イヤでイヤで逃げ出した古巣を叩くのは良くある話
そして、実はそこしか居場所がなかった、なんてのも
もし抜け出して上手くいってるなら思い出したくもならんしね

2018/11/06(火) 10:54:39.07

マウントを取るのに最適な言語を教えてください

2018/11/06(火) 10:58:56.98

乙py

2018/11/06(火) 11:45:52.86

PHPに詳しいとこのスレでマウント取れる環境になりつつあるｗ

2018/11/06(火) 19:46:04.14

マウント取るなら
haskell,rust,c++あたりだな。
実際プライドの高い馬鹿が一番多い。

2018/11/06(火) 22:08:43.22

>>469
負け犬ペチPoorの遠吠えが心地よい
ふつうに転職して年収700もらっとるで
ペチPoorな言語なんてもうしばらく見てもいないね

君、禿げたつむじから$が見えとるでｗ

◆QZaw55cn4c (ﾜｯﾁｮｲ ba60-uQtw) · 2018/11/06(火) 22:32:37.25

>>477
ruby を勉強している身としては ruby でマウントが取れるかどうかが気になります、実際どうなんでしょうか？

2018/11/06(火) 22:51:28.61

python好きからすると友達にはなれない