次世代言語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/06(土) 15:14:33.91

でお前らF#使ったことあるん？

2018/10/06(土) 15:26:03.42

本は買った
C#書いてる

2018/10/06(土) 15:39:51.60

関数型言語は、これからElmが流行ると思う
簡単だし実用性高い
言語マニアには物足りないかもしれないが

2018/10/06(土) 15:41:40.56

日本と海外で比較するのは変。
だって日本と日本以外の国全てとの比較なんかしたら必ずどこかの国が日本を部分的に抜かしていて当然だろう。

2018/10/06(土) 15:43:23.11

特定の言語のﾌﾟﾛﾌｪｯｼｮﾅﾙです（ﾌﾟｯ
ﾄﾞｶﾀにありがち

2018/10/06(土) 16:53:07.46

人類最底辺池沼ペチプァとかな

2018/10/06(土) 21:08:28.43

経験ゼロで、今から３つ言語覚えるとしたらどれがいい？

2018/10/06(土) 21:09:51.93

>>334
使う人は使うかも知れんけど流行る事はないと思うしそれでいいんじゃない？

2018/10/06(土) 21:10:06.16

VBA
敬語
英語

2018/10/06(土) 21:10:56.30

>>335
IEのシェアにしてもiPhoneのシェアにしても何かしら日本は特異な存在なんだよ困ったことに

2018/10/06(土) 21:11:33.87

>>338
とりあえずJavaScriptから

2018/10/06(土) 21:16:14.71

学習の順序はｺﾚでいい

1. C、 shell
2. sql、html/css/javascript
3. C++

ｺﾚできたらjavaでもc#でも
その他のどうでもいいｳﾝｺ言語でも
すぐに分かるようになる

2018/10/06(土) 21:19:04.86

>>343
C++は要らんと思う
C言語で事足りる事はC言語でやればいいしそれで不都合なものは別言語のがいい

2018/10/06(土) 21:29:09.05

まずCをさらに覚えることを兼ねて
C++が適切

2018/10/06(土) 21:46:07.19

C言語でモチベ続くんならCでいいな

2018/10/06(土) 21:54:23.27

ホビーに絞るなら
javascript Pyhton C#

実務を見据えたら
c　java javascript

かな

2018/10/06(土) 21:58:50.08

結局Cなのかよw

2018/10/06(土) 22:01:14.63

そこよりjavascriptが幅を利かせてるとこを気にしなきゃ

2018/10/06(土) 22:03:22.50

その後は
go typescript と好きな関数型言語を一個えらべばいい

2018/10/06(土) 22:05:01.11

オブジェクト指向言語で組まれたシステムって不具合改修する際に元の製作者居なくなってたらもう１から組み直した方がいいんじゃないか？ってレベルになるよね
手続き型言語ならまだ関数単位では流用できるかもってなるけど

2018/10/06(土) 22:12:12.88

結局Cなのはもうしょうがない
共通の祖だし現役だし

2018/10/06(土) 22:23:35.60

>>338
言語覚えて何したいの

2018/10/06(土) 22:25:56.93

ｃは文法中心の入門書をなぞっていくだけじゃ
メモリリークの深刻さが体験できない

2018/10/06(土) 22:26:39.72

>>338
C ML Octave R

おっと4つだ

2018/10/06(土) 22:31:53.09

DOMを操作するのにもjavascriptは必須

webでは
ｸﾗｲｱﾝﾄｻｲﾄﾞでの処理でjavascriptは外しようがない
ｻｰﾊﾞｰｻｲﾄﾞでもjavascriptがどんどん猛威をふるってる

2018/10/06(土) 22:34:41.30

javascriptすらできないﾔﾂは
webの技術者にすらなれない

webでjavascriptは必須の技術要件

その他ｳﾝｺｽｸﾘﾌﾟﾄはｵﾌﾟｼｮﾅﾙでどうでもいいことになる

2018/10/06(土) 22:46:16.86

>>338
tscpy

2018/10/07(日) 00:01:21.67

PHPやっておけば食うには困らんぞ
一生他人のひり出したウンコの保守だが

2018/10/07(日) 01:21:39.79

>>344
読むくらいはできないと既存のいろんなものが読めない人になるぞ

2018/10/07(日) 02:16:50.58

>>357
RustがあればJavascriptも要らないよ
Wasmがあるから

2018/10/07(日) 02:25:31.66

javascriptとデータ受け渡すのに？

2018/10/07(日) 02:50:01.56

wasmからdomいじれるん？

2018/10/07(日) 03:00:06.37

C++とPerlの読みにくさはどっちもどっち

2018/10/07(日) 03:04:12.98

断言するが >>364 はwebkitやlibavformat のコードは読めhaskel で書かれたコードは読めもしないだろう

2018/10/07(日) 03:04:43.27

「は読め」は「は読めて」の編集ミス

2018/10/07(日) 07:55:06.85

PHPかPerlやらないと殺すって言われたらどうする？

2018/10/07(日) 08:00:22.59

PHPやりますっていう

2018/10/07(日) 08:31:15.52

>>368
かわいそうなヤツｗ

2018/10/07(日) 09:43:21.64

PHPなんて過去の人が書いたコードは気に入らなきゃファイル単位で全取っ替えで差し替えて行けばいいから楽なもんだがな
害悪なのはCMSとフレームワーク

2018/10/07(日) 09:56:33.25

>>359
＞PHPやっておけば食うには困らんぞ
ためになるお言葉に感涙の嵐となっております…

2018/10/07(日) 10:14:16.79

PHPにやたらヘイト溜めてる人居るけど
改修するのにわざわざ元のコード活かしながらやってたの？

2018/10/07(日) 10:42:22.84

ペチプァはガイジだからみんなオレオレフレームワーク作ってオレオレロックインしてるよ
一生ウンポコペチプーウンコードの保守やってろゴミ

◆QZaw55cn4c (ﾜｯﾁｮｲ ea60-GsMS) · 2018/10/07(日) 11:03:21.30

wikipedia も PHP…

2018/10/07(日) 11:55:59.53

>>371
>>359
>一生他人のひり出したウンコの保守だが

こっちの一言に感涙したんだろｗ
正直になれｗ

2018/10/07(日) 11:59:28.56

>>375
長期的に保守するってんならじわじわ全取っ替えすればいいだけだしな

2018/10/07(日) 12:14:50.81

>>376
ガイジペチプァはPHPしか書けないのに何に全取っ替えするっていうんだ？
ウンコをウンコに全取っ替えしてもそれはウンコだぞ

2018/10/07(日) 12:27:55.16

>>377
気に入らないなら言語毎変える事だって出来るだろ？
それともインフラ周りの能力がまるでないのか？

2018/10/07(日) 12:51:23.46

>>363
いじれるようになるよ

2018/10/07(日) 12:52:36.35

Perlはない
絶対ない

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にもストアドおじさんいたなぁ