次世代言語18 V Julia 他 YouTube動画>1本 ->画像>4枚

スレタイ以外の言語もok

前スレ
次世代言語17 Go Rust Kotlin TypeScript Julia
http://2chb.net/r/tech/1567602619/

Go Rust Kotlin TypeScript Dart
Elixir Swift Crystal Hack Bosque

Most Loved, Dreaded, and Wanted Languages
https://insights.stackoverflow.com/survey/2019#most-loved-dreaded-and-wanted

TIOBE Index
https://www.tiobe.com/tiobe-index/

皮肉がきいてていいな

あのなんか辛気臭い名前の奴も入れてやればよかったのに

誰も使おうとすらしない言語
完璧な次世代言語だな

永遠に次世代というヤツか

>>4
Bosqueのこと？

>>1
そのスレタイならボスケを入れるべきだった
と書こうとしたら既に書かれてた

> 990 名前：デフォルトの名無しさん[sage] 投稿日：2019/09/30(月) 22:39:32.68 ID:GRXEfX8t
> 関数型の流派として高階関数やモナドで遊びたい派と宣言的で明瞭完結なコードを書きたい派があって、
> Scalaは前者のオモチャにされてしまったのが最大の敗因かと思う

そうかなぁ
我が社では関数型に憧れた無能おじさんどもが Scala で static おじさんコード書いてメンテ不能になった経緯で
「Scalaは難しいから禁止！」となったよ
こういうケースも多いんじゃない？

でもてめえらが書いたコードならJavaでもメンテ不能だったろうよと言いたいね
唯一救いがあるとすれば、全員退職済みということだ

またlispの方言が増えたくらいにしか見えない

関数型は宗教だから

前スレの >>968
親父が好きだったので。
あのころ吉幾三の「田舎のプレスリー」とか「ハンダースの想い出の渚」とかバラクーダの「日本全国酒飲み音頭」とコミックソングが流行った。

モナド自体も実用上は
順次的・逐次的な処理をしたいときは結合法則と単位元を意識したコンテナライブラリとして書くと使いやすい
ぐらいのものでしかないのだが、衒学趣味の連中に数学で威圧するためのオモチャにされてしまった

実際のプロダクトに求められるのはレベルの低い人が参入してきてもメンテできるものなんだよなぁ

マウント取るために数学使って高度なことしてるやつは研究職に就けない中途半端な学歴のゴミが多い

そんな技術的に低レベルなものしか作らないから日本にOracleやGoogleが生まれないのでは？

>>15
世界的な大企業が生まれるかのうかは技術者の問題じゃないだろw

日本にはウォズニアックはたくさんいるかもしれんが
単純にジョブズがいないだけ

それは即戦力病で教育とか研究開発とか長期的な投資ができないのが原因なので別の話

まぁ最近は技術志向の人達にも年収1億円払う企業とか出てきてるし、ワンチャンGoogleが生まれる可能性もあるんじゃね

米研究拠点の採用に年収1億円提示も、NTT社長
https://r.nikkei.com/article/DGXMZO47118890Z00C19A7000000

ZOZO、最高年収1億円の「天才・逸材」採用していた
https://www.itmedia.co.jp/news/spv/1909/19/news030.html

求人を見るとエンジニアで1000万超える額はチラホラ出てきたから後はそいつら使って何をするかだな

言語スレ的に言うと、政府とズブズブっぽく見えるしZen言語が普及すればあの企業はワンチャンあるなと思うわ

F#のロゴ
めっちゃカッコいいな！

>>19
求人では1000万円超(年収1000万円とは言ってない)がある

>>18
給与の基準もおかしいんだよな
レベルの低いインド人にすら月600万出してたりしてるし中国人なら月200万出してる
どっちもプログラマーとしても満足にやれないクソみたいなコーディングだったりする
なお日本人には月50万も出したくないそうだ

日本人は辞めさせるの面倒だもん

エンジニアは使い捨ての奴隷じゃねえんだぞコラ

身分差別の罪の重さを理解できない人類が、たかが衒学趣味に罪悪感をもつわけがない

>>14
アホでも優秀でも同じようにだらだら書くしかないgo
が良いということか

日本でも会社通さず直で業務委託の仕事貰えば月100万円とか余裕だろ

ただ上限が150万円ぐらいで止まるから起業したり投資したりコンサルとかにならないと1億円も稼げないんよな

>>26
煽り抜きでそういうこと
「優秀」さは別のところで発揮するべき

Goが使われるのって主にバックエンドだろうけど、
今時のバックエンドはクラウドサービスを積極的に活用してシンプルに問題を解決するのが主流だよね
もはやコードレベルでアプリケーションアーキテクチャを語る時代は終わり、コードに対して求められるものが変わってきてるんだよ

どういうことなの…

>>28
戦力の逐次投入するやつはみんなそう言う
今ここで投入するより別のところで投入するべきだと

>>31
Scala導入するような間違った方面で熱量発揮するバカはお呼びじゃねえ
ってオブラートに包まずに言った方がわかりやすかったか？

自称優秀なやつほど愚直に書くことを病的に避けて
ScalaやらHaskellやらのコードゴルフみたいな難解な解決（）に走る

そういう難解な「優秀」さはかえって邪魔
それをScalaショックから学ばない「優秀」な奴は本当にバカ

今後はUiPathでアプリが作れて営業ができる人が生き残ります
コードの時代は終わった

馬鹿同士極論で無意味な議論して楽しいのかな

scala祭りの人がscalaから引退したのは衝撃だった

JavaとHaskellの対立が激しくなったら
Scalaが最も冷静な中立の言語になる予定だったんだろ

失敗の原因を選べ
・中立だから
・本当の中立なら成功するけど本当の中立ではなかったから

元々オブジェクト指向、動的型付け言語から
関数型、強い静的型付け言語に流れるブームがあって
Scalaはそこに乗っかる形でJava資産を使える関数型の強い静的型付け言語ってことで一時期流行った

でも型をおもちゃに無茶苦茶やる意識高い系がマウント取りはじめて
本当に物を作りたい人が離れていったり
互換性やビルドの遅さみたいな言語自体の欠陥もあいまって
「やっぱ強い静的型付け関数型言語は意識高い系のおもちゃでしかなかった。
プロダクト作るのには向いてないな」って雰囲気になって
一気に人がいなくなって焦土になった←いまここ

>>34
UIPathでAIできるのか？

Rustが主流になる
https://qiita.com/baby-degu/items/a311ca07d155037253c8

>>38
typescriptもそうなりそうな予感がしてる
react nativeで使ってみたけど
マジで苦痛の極みだった
もの作るってレベルじゃねえ
この手のでかいフレームワークで型推論ありの静的型付け言語使うのは無理がある

C++も結局autoだらけになっちゃったからな
実際いちいち型を細かく指定したくないわ

>>41
いやいやｗｗｗ

型推論ありの静的型付け言語は、高機能エディタやIDEの利用が必須だからな
リアルタイムな文法チェックが無いとやってられないし、省略した型指定をコンパイラがどう解釈するか簡単にチェックできる機能も必須だよ
そういうの使いこなせない奴には良さがわからない

rustは関数化しないでベタに書きまくる輩が多すぎる。
あれはあとあと問題になるだろう。

ScalaはScalazやCatsのようなモナドライブラリがあって、それに依存するライブラリも次々作られたのに対して
Typescriptやほかの言語で似たようなモナドライブラリがありながら、それに依存するライブラリがデファクトになっていない（意識高い組のおもちゃにされなかった）のは何故だろう

(´-`).oO(なんでだろう)

Juliaプログラミングクックブック ―言語仕様からデータ分析、機械学習、数値計算まで

おー
出るのか。

RDBをオブジェクトにマップするようにモナドをオブジェクトにマップするのがJava系
オブジェクト無視してHaskellそのまま全部再現するのがAltJS

>>46
Scalaは高階カインド多相が使えるからファンクタやモナドが普通に作れるがTypeScriptなどの他の言語はそうではない

高階カインド多層をTSに入れたら完全におもちゃにされるだろうね
今ですら型パズルがどうのっていってるし

難しそうな用語だと思ってググったけどC++のテンプレートと同じやつか

・・・入れない方が良い

出たよモナダー
そりゃ嫌われるわ

モナドという概念はややこしくてもひとつひとつのモナドはそれ自体のコードも使い方も別にふつうだし
使いやすいライブラリ設計してたら自然にモナドになっていることもある

開けモナドよ

モナド語ってる奴も別にマクレーンの圏論の基礎とか読んでるわけでもないし半端もんよ。

本当にマクレーン読んだ？

>>57
お前モナー
モナドだけに

今どき圏論やるのにCWMから始める方が半端もん

Zen言語なる言語がリリースされたらしい
https://zen-lang.org/ja-JP/

より宗教色の強い言語です

>>61
rust から次世代的な機能を全部取り除いた一見次世代っぽいけど全然次世代じゃない言語に見えるけど
何か良い所があるのだろうか？

もともとZigという言語があって、そこからforkした言語だからRustはあまり関係ない

お前らが大好きなScala情報貼っとくぞ😊


Scala研修テキストが株式会社ドワンゴ様から寄贈されました
https://blog.scalamatsuri.org/entry/2019/10/01/163533

ドワンゴがドヤって手を出す言語は地雷判定として結構機能する。

単にドワンゴが傾いてるだけだと思う

>>61
キャッチャーミットわろす

>>65
前から無料で読めたが？

>>66
RustとScalaだな

https://dwango.github.io/articles/frugalos/

>ドワンゴではniconicoの配信系サービスのバックエンドで利用するために、Frugalosという名前の分散オブジェクトストレージを開発しているのですが、この度OSSとして公開することとなりましたので、この場を借りて軽く紹介させて貰います。

>FrugalosはRustで実装されており、現時点では以下のリポジトリが公開されています


うおおおおおおお！！！！！！！！！

ジャップのプロダクトって名前が壊滅的にダサいよなｗｗ
ガイジン失笑ｗｗｗ

質素os

ドワンゴに所属してたことがあるエンジニアってだけで
こいつ仕事できねえんだろうなって思うは

蟻さんのことか

じゃあ逆にお前らが仕事できるって思う企業はなんなんだよ

>>75
アリさんマークの引っ越し社。

ドワンゴ一時期の大量退職の後に比較的優秀な人が入って立て直したかと思ったのに
また大量に辞めたんだな

どこが使ってるからダメだとか言ってるだけで
こいつ仕事できねぇんなろうなって思うは

>思うは

力抜けるからやめろｗｗｗ

Rustはモジラだからダメとか言ってる奴は前からいたな
GAFAに勝てるわけがないみたいな
順張り原理主義か

まあ実際のところrustはインデックスオーバーのエラー出したりしてんだよね。
あそこまで安全言うててそういうバグ出すとかしょーもねーなと思うわｗ

インデックスオーバーって何？

モジラには分散処理のノウハウが乏しいという意味なら批判は妥当
逆にそれがRustの差別化要因になったわけだが

バカはオールオアナッシングでしかモノを考えられない

Rustちゃんスタックに適度にでっかい構造体作るとオーバーフロー検出してくれるんだけど
それを越えたクッソでかい構造体だとオーバーフロー検出されずにsegfaultするのはしゃーないんやろか

Rust言語のメリットと課題、「Azure IoT Edge」の事例から分かること
https://www.atmarkit.co.jp/ait/articles/1910/02/news094.html

Microsoft Security Response Center(MSRC)は2019年9月30日(米国時間)、Microsoft社内におけるRust言語の採用事例を発表した。

ガベージコレクションのランタイムオーバーヘッドを避けたかったため、Go言語は選択肢から外れた。
加えて、デーモンに必要なセキュリティ関連の要件から、メモリや並行性(コンカレンシー)に由来するバグに対処する必要のない言語が必要だった。
こうした条件を踏まえ、Rustが最適だという結論に達した。

Azure IoT Edgeの一般提供を開始する前に外部のセキュリティベンダーと契約し、開発したソフトウェアに対するペネトレーションテストを実施した。その結果、コードベースのうち、Rustで作成した部分では、セキュリティ問題が見つからなかった。

開発時にはRustエコシステムが役立った。開発当初から、「rust-clippy」を使用し、Rustコンパイラがカバーしない範囲の細かい警告を出力させることにした。

加えて、継続的インテグレーション(CD)を実行する際、Rustコードの整形ツール「rustfmt」による処理を経ていないプルリクエストを却下する仕組みを採用したことで、コードベース全体で一貫したコードの整形が可能になった。

Rustコンパイラの更新プロセスとツール整備は順調に進んだ。コンパイラへのアップグレードは、ほぼ常にスムーズだった。

スレタイから却下されたエセ次世代言語の話をだらだらするのやめようぜ

じゃあV言語の話でもするか

V言語ってGoの人たちがやたらネガキャンしてたよな

集金詐欺だからな。

メモリリークしかしない言語なんて擁護しようがない

CIではなくCDと略されるようになったのか？

いまどきCDて
DVDだろ

Scalaってなんで最近聞かないんだ？

>>94
brulayだろおっさんｗｗｗ

メモリは1.5年ごとに倍になるし、

Scalaスレってもうないのな

集金詐欺という意味なら最近出てる新しい言語は皆該当する

P++はどう？

>>100
計画としてすら存在しない言語についてどうと言われても

ようこそここへ　（クックブック）

Perl6はどう？

TS界隈が燃えてるな
俺が予想した通りだ
型で遊びたいやつらがマウント取り始めた
もう終わりだ

https://www.npmjs.com/package/typescript
もう終わりだ

そういえば炎上して消滅したパッケージがあったな

次のスレタイは

次世代言語アンチスレ19 TypeScript Rust 他

に変更しないか？🤔

>>107
イイネ

>>104
https://speakerdeck.com/uhyo/an-quan-xing-falseji-bei-karajian-rutypescript
any型は嘘ってやつか
いかにも型合わせパズルばっかやってて
実際にモノ作ることには興味ない奴が言いそうなことだ

何が問題なんだ？
any型を使うことは型チェッカに嘘をつくことであるというのは完全に正しいが

型システム様のご機嫌伺いのためにコーも書いてる訳じゃないんで
作るべきモノがあるからコード書いてるんで

コードな。typo

そもそも炎上してるってどこ情報よ

VSやVSCodeとかならJavaScriptでも型推論してくれるし
型を明示したいならJSDocを書けばいいだけだから無理してTypeScript使う必要もないかな

>>104-105

始まってすらいない

結局JSDocで型書くならTypeScriptで静的チェック強制した方がいいんだよなあ

型合わせパズル型合わせパズルって言ってるけどC#程度の強度でもDynamic使わずにまともにプロダクト作られて運用されてるのにanyが型システム的に嘘って言われた程度で騒ぐ人って…

typescriptは構造的部分型だからそのDynamicに型を付けていくようなものなんだよ

どの言語使おうと堅牢に作ろうと思えばその分コストかかるってだけの話なんだよな。

>>119
メンテナンスコストを含めるとどうだろうね

メンテナンスコスト考えるならJava、PHP、jQueryだけ使うべき

既存のJSプロジェクトからの移行ならともかく最初からTSで書くプロダクトならパズル言うほど複雑にならんぞ

旧世代言語、現世代言語の総合スレも欲しい

>>118
C/C++だって生メモリに対して型を仮定してるだけだから似たようなもん

C++は例外安全パズルだったな
「CのコードはそのままC++のコードとして使える」が嘘八百だと割り切れば解ける
嘘八百だは言い過ぎだろなんて擁護してたら解けないパズル

>>118
前スレでは型がどうとか言ってたな
時間の経過とともにトーンダウンしてるのは気のせいか

>>118
漸進的型付けではなく構造的部分型なの？

次世代言語スレがアホばっかりになったな

>>127
構造的部分型を利用して漸進的型付けを実現している

型を指定すると何も作ってないことになるんだからすごい

プロダクトを作るって観点で言語を議論せず
やれ型パズルだのやれ安全パズルだのぐだぐだ言うバカばっかになった

>プロダクトを作るって観点で言語を議論せず

どうせ「俺はこれで作れるんだ」の応酬で議論にならない

>>125
元々互換性は完全では無いけど、例外安全と何か関係あったっけ？

>>129
構造的部分型の名を出した方向性は分かったがそこからどうanyの議論に発展するのか分からないな

例外はcatchしなければexitに似ているが
catchしたら、Cなら既に終了しているプログラムがまだ動いているようなもの

例外はCで対比するなら戻り値かerrnoで処理するものだから普通に動いているだろ

>>64
zigとの違いはナンでしょう

マネージャー「このままじゃ期限に間に合わないが……大丈夫か？」

型ガイさん「大丈夫です！！！メンテナンスのことを考えて型に拘っていますので、品質の良いものができるかと！！！！！」

マネージャー「型？そこは拘らなくていいから期限を……」

型ガイさん「僕に嘘つきになれって言うんですか！！？！！！！？？？？？？！！！！！！」ﾄﾞﾝｯ!！！！

型定義できるのにany使うのはただの手抜きでしょ
テスト書かない奴・ドキュメント書かない奴と同レベルの言い訳されてもね
程度が知れるわ

>>139
ほんとそれ
俺達真実の探求者からするとanyは許せないよな。嘘つきの言葉を許すな！w

>>138
マネージャ無能すぎるだろ
こわい現場だ

型書いたぐらいで期限に間に合わなくなるってことは、当然テストもロクにしてないわけで……

そりゃテストなんて書かないでしょ
作るべきもがあるからな！ﾄﾞﾝｯ

「型合わせ終わったからバグはありません！」
「どれどれ」
「バグだらけじゃねーか！ふざけんな！」
「型合わせ終わったのにどうして....」

型システムを過信し過ぎるのも型を軽視しすぎるのもよくないねという話なんだよな
型が合って出なくなるバグは型にエンコードした情報だけって事すら認識してない人間が型パズル型パズルって馬鹿にしてそう

>>144の思考だとvoid*を使わないC/C++にはバグがないということになるが？

このスレJuliaと銘打ってるのにJuliaの話題出てこない。

「any」というのはですね、嘘吐きの言葉なんです。中途半端に型を使うからanyになるんですよ。

TS信者はany推しでどでかい墓穴を掘ったな

最近の言語だとvar someClass = new SomeClass()みたいなnew演算子は排除するのがトレンドなのかな
C++だとnewのあるなしで確保先をスタックとヒープに分けるから意味あるけど
Java以降の言語でオブジェクト生成に毎回new打たせる意味は結局よく解らなかったな
特に意味もなくnew打たせる言語はもはやレガシー感漂う

Goに至ってはnewはゼロ初期化明示に残ってこそいるけれどスタックかヒープかは自動でコンパイラが割り振るしな

ハンガリアンかな
接頭辞newを見て補完候補を絞り込む

JavaScriptのnewの有無による差（言語仕様）が嫌い

dartはそこらへん緩かったような
a = [3,3,if (hoge) 4,for () i]
とかもできるようなったし。

>>154
中間のカンマ省略可能だと式書きたいときに困るでしょ

TSの型狂信者なんて関数型言語の狂信者に比べれば数も個体の狂暴性も大したことないじゃん

コードの書き方勉強するならもちろん外人が書いたコードを見た方が上達するんだろ？

そらネイティヴやからな

>>157
なにそのウンコよりゲロの方がマシ理論
これだから型パズル大好きマンは

型パズルってフレーズここで聞きすぎてむしろ静的型チェックのない強い型付けの言語の方が型パズルだと思うようになってしまったけど…

とりあえずテストコード書こうぜカスども。

部品の型を言えばオートでパズル解いてくれるのが静的型チェックで、
人間がこの部品がどこならちゃんとはめられるか考えないといけないのが動的型付けだから、
なるほど型パズルなのは動的付け型の方だな

付け型ってなんやねん

解いてはくれねえだろ
コンパイラが間違いだと思ったら指摘するだけでよ
コンパイラが仕様を理解して正解を提案してくれる訳でもあるまいし
結局人間がきっちり書くしかねえんだよ

型が合えば満足する奴はそこがわかってない

実際問題型に過剰な信頼を寄せている人間はおれどもTypescriptの中でわちゃわちゃしてるくらいなら別に良くない？
PureScript使えって言い出してる訳じゃないし
あっちはReactが上手く使えなかったり生DOM上手く使えなかったりで、静的型付け好きな私でも本末転倒感を感じる

逆なんだよなあ
最低限型が合ってるかどうかコンパイラがチェックしてくれる分だけ労力を他のことに割ける

動的型付け信者はまるで動的型付けだとロジックのバグが発生しないかのような物言いをする

型だけは立派だなw

動的型付けは不完全なコードも実行できるようにしてデプロイまでの工程を高速化するためのものであって、バグは当然増える

>>167
ジェネリクス使いだすとだんだん手に終えなくなってくるよ
ようは単純な型使ってるだけの間は害はない
メタプログラミングやりだしたらどうでもいいところに時間かけるようになる

OCamlは許された……？

>>170
ジェネリクスすら使えないとかｗｗｗ

本来動かないコードのエラー発生をランタイムまで
先送りするのがメリットなのか？

ジェネリクス使っただけで手に負えなくなるプロジェクトって静的型がなかったら実行時バグで死ぬだけでは

>>170
ジェネリクスとメタプログラミングは全然違うんだが
C++のテンプレートと勘違いしてる？

>>175
型の制限を加えるプログラミングと言えるのでメタプログラミングのひとつだよ
出来合いのコンテナ使ってるだけの人は気にしなくていい

>>176
型の制限を加えるとメタプログラミングになるというロジックが意味不明

メタプログラミングって何なの？

ggrks

>>138
マネージャー「このままじゃ期限に間に合わないが……大丈夫か？」

型なしガイさん「大丈夫です！！！期限を最優先に、JSDocも型も書かずに、コードだけを書いてます！！！！！」

ええんかおまいら・・・

生JSはそもそもまともにドキュメントを書けるような構造化されたコードを書ける時点で結構ハイスキルな方だし、
そのレベルならドキュメント書かなくても十分に可読性や保守性の高いコードだと思うよ

流石にドキュメントは書こうぜというか
最早型云々のレベルじゃない

↓これマジ？ルーストってまともなエディタも作れないの？？

686 デフォルトの名無しさん sage 2019/10/04(金) 22:07:43.17 ID:YLLg2aHe
AtomチームがやってたRust製エディタの実験プロジェクトも終了したんだからあきらめよう

char **argv の時点で既にパズルになってたよ
型レベルの構文木があるなら構文解析もあるので型レベルプログラミング不可避

>>183
Atom自体が死に体だから余裕が無くなったのだろ
まさかAtom用のフレームワークElectronを利用したVSCODEにシェア奪われるとは

>>182
第1引数は数字です
第2引数は文字です

って書くんか？
それじゃ「メンテナンスのことを考えて型書いてますんで！！！」ガイジと同じレベルやないかい

その情報無かったら他人はどうやって使うのさ
命名でカバーするの？

>>187
マネージャー「型？そこは拘らなくていいから期限を……」

型ガイさん「その情報無かったら他人はどうやって使うのさ命名でカバーするの？！！？！！！！？？？？？？！！！！！！」ﾄﾞﾝｯ!！！！

>>188
ほんでマネージャはなんで答えるのよ

>>189
なんでっておまえらドキュメントガイジがコードも書かずに遊んでるからだろ
給料泥棒

/**
* メソッドの盛り合わせでございます。
* データベースにお接続し、データを取得でございます。
* 第1引数は数字でございます。
* 第2引数は文字でございます。
* 第3引数はあるかもしれないしないかもしれないでございます。
* 返値はないかもしれないし数字かもしれないでございます。
*/

おまえら下請けのゴミどもはヨ？納品物は正しく敬語で書けよ

正直>>191はやりすぎだけど

型ガイさんみたいな意識高めの人ってコメント全く書かなそうだし>>191の方がメンテナンスしやすそう

ジェネリクスとメタプログラミングについてはとりまRust Part7 260をチェケラ

もはや次世代言語関係なしに型もドキュメントもテストもロクに書けないペチパーが暴れるだけのスレになったな

> 返値はないかもしれないし数字かもしれないでございます。
これが実際だったりしてもコメントにすら書かないでごまかす輩がいるんだよな。
型にこだわるやつに限って都合の悪いことはコメント書かん傾向にある。
逆にうまくいかんことをコメントにしろと思うのだが。

>>195
これもまったく逆だな
文字列か数値かnullが返る関数はそういう型を書かないとそもそもコンパイル通らないし、
そういう妙な型になってる関数はなんでそんな関数が出てくるのか、どんな用途なのかわからないようだとコードレビューに通らない

>そういう妙な型になってる関数はなんでそんな関数が出てくるのか、どんな用途なのかわからないようだとコードレビューに通らない
そんなレベルでコードレビューやってるなら問題ないだろね。

>>195
> 都合の悪いことは書かない
型に関しては全くそうは思わないが、話は変わるけどテストコードはまさに > 都合の悪いことは書かない が横行してるよね
ユーティリティ関数のようなテストしやすいところだけテスト書いて、本当にテストの必要なコア部分は誰もテストなんか書こうとしない
奇跡的に書かれたとしても頻繁に変更が入るからすぐに壊れて放棄される
この傾向は型の有無とは無関係だが、実際にはテストコードなんか無いのにその現実から目を背け
「テストがあれば型は不要」と抜かすのが動的型信者

>「テストがあれば型は不要」と抜かすのが動的型信者
こんなこと言い出す輩はruby使ってる奴以外見たことないがな。
逆ならたくさん見てきた。

>>199
まあそれはその通り
一方で、それなら静的型を使っているプロジェクトはそうでないプロジェクトに比べてテストが書かれないのかというと、
面白いことに実際にはたいてい逆なんだよなw
言語の性質とは無関係に、単に品質に対する意識の問題なんだよ

>>190
いや、命名でカバーすんの？

>>176
お前は何を言ってるんだ？

Haskellくらい型の表現力が豊かで状態を陽に扱う言語だと、コンパイルが通れば大体狙い通り動くってことが良くある
静的型付けでもオブジェクト！フィールド変数！ウオオオ！って副作用バリバリな言語だと、テストコード書かないと安心できないことの方が多い

テストを何だと思ってるんだ

別に「型なんてなくてもいいものができる」なんて流石に言わんでな
「型キチがモナドだのFreeだのEffectだのでパズルおもちゃにしてマウントとってくるくらいなら型なんていらねえ」って言ってるだけ
これは個人の感想じゃなくて、Scalaの大失敗からの教訓な

これをいうとすぐペチパー連呼発狂マンが飛んでくるのほんと図星なんだなとしか思わん

ホントに型の話してるのか不安になってきた

>>191
こういうコメントに謎の型書くくらいなら
普通に言語機能の型書いた方がよくない・・・？

> 第1引数は数字でございます。
が平気で null | string （ただし暗黙キャストで数字になる） とか使われてたりするのが、型無し言語の世界だぞ

お前らこれ読んでも、型よりコメントの方がいい、型はなくていいとか、本気で言ってるの？

おもちゃにするまではなんとなくわかるが個人の勝手だし、マウントとってくるってのはなんなのかわからんな。

個人の勝手で共同プロジェクトのソースコードぐちゃぐちゃにされたらたまらんわ
結局メンテできるのそいつ一人になって
仕事が集中したらケツまくって逃げるんだもんな

型にこだわるやつは地雷だし、そんな奴をホイホイする言語が地雷

Cのマクロをほぼほぼ封印できた成功体験が大きいと思うぜ
マクロをどう使おうが個人の自由、などという結論にはならなかった

ちなみにマクロを否定するなら代案が必要だったから俺達はtemplateで再帰とかしている

メンテナンスが～！って言われるけど作って最初の数ヶ月だけメンテされて

その後APIの仕様変更とかがない限りずっと放置されるんだよね……w

個人の勝手でコードぐちゃぐちゃになるってどういう組織なのよ
どんな体験からそんな保守的になったのか興味あるわ

個人の勝手うんぬんって、完全にマネジメントの問題じゃん
それが型のせいで～とか、思考回路ショート寸前すぎない？

>>211
新規で作るよりあるものに機能足そうって思想で魔改造されるパターンで
放置どころかメンテが続くパターン知らないんだな

TSってaltJSの中じゃ保守的な方ってイメージだったんだが
言語機能としてはC#やJavaと大差ない程度なのに1人抜けたらメンテ出来ないってヤバいでしょ

型キチが大暴れしてコードしっちゃかめっちゃかにするのを
型キチ本人のせいじゃなくてマネジメントのせいにするとか
まじで自分は悪くない正義なんだ思想でゲボ吐きそう

ScalaでScalaz使い倒した上にimplicit地獄で複雑怪奇に絡み合った製品コードを
「これがきれいでシンプルでバグもない！」って強弁した挙げ句
誰も触れないからメンテお前が一人でやれって言われた途端退職したキチと同類なんだろうなお前ら

今のScalaの惨状みてると、日本中といわず世界中で似たようなことあったんだろうなって思うは

そりゃちょっと勉強すれば誰でもメンテはできるだろうけど型ガイさんのために学習コストを払うのが前提だよね……😅

ここの人たちGAFAとかに勤めてなさそう

>>216
そいつがキチなのは本当なんだろうけど
それじゃそのキチにすら見限られるよ・・・

型アンチが型を嫌う理由が型に1ミリも関係ない私怨で草
動的型ならしっちゃかめっちゃかにならなかったわけじゃあるまいし

そいつ本人とコードレビューが機能してないのがダメなだけ
そいつがRubyやら生JS使ってても同じことが起こっただろう

キチに見限られるとか本望ど真ん中で草

とりあえず「コードしっちゃかめっちゃか」の例を見てみたい

型キチ推しがType Scriptでanyを推奨

だから型そのものが嫌いなんじゃなくて
型キチのおもちゃになるくらいならそんなもんいらないとしか言ってねえっての
型そのものの有用性くらいわかっとるわ

型キチの藁人形論法寒気するわ

まぁまぁ落ち着きなさい

型パズルでもして遊んできなさい(^_^)

そんなん勝手にしろとしか
私怨をこのスレで発散されても困るんだが

その理論ならコードレビューが機能してなかったらRubyやJSでもメタプロ厨のオモチャになって解読不能なコードが出てくるだけだろ
キチガイを排除できない態勢がクソなだけ

>>227
これでしかない

何が彼を憎悪に駆り立てるのか本当にわからない・・・
型が理解できてないだけなのかな？

レビュワー「こんな複雑怪奇なコード通せるかバカ。分かるように書け」
型キチ「これが一番シンプルで分かりやすい！！分からないお前らがバカ！！」
上「リリース日決まってるし作り直す時間ないしちゃんと動きはするんでしょ？通してやって」

型キチ擁護さんには画期的な腹案を持ちはっとるんどすなあ

完全にマネジメントの問題で草
そのロクに読めない複雑怪奇なコード出してくるヤツをプロジェクトの中心に据えたのは誰なんですかね

>>221
その結果、まともに引き継ぎも出来ず
誰も触れない製品コードが残っちゃったんでしょ？

問題が起きる前に排除も出来ず
問題が起きてからの対処にも利用出来なかった最悪の事例じゃん

キチガイが型無し言語で書いたコードより、型キチが静的型付け言語で書いたコードの方がマシだからな
静的型付けが理解出来ないから前者の方がいいというのはただの勉強不足

スクリプトとかいうゴミの話はやめてちゃんと機械語吐き出すまともな言語の話しようぜ

>>232
1000000000%そのとおり

TypeScriptを使うメリットを具体的に上げられる人いるの？

あまり語られないが、interfaceで設計できるのが最大のメリットだと思う
地味な使い道としては、JSON Schemaへの変換ツールとして非常に実用的。

最低限型の合ったコードを書くことを

プロジェクトの開発者全員に

強制できてレビュアーの負担が減ること

Go言語とか見ても分かるように、型ガチガチにやらないことが次世代のトレンドってことだな

必要ならTypeScriptでanyを使うしC#でdynamicを使う

それな
おまけに型推論で、自分で型書かなくても良い感じにしてくれるし
TS叩いてるやつって、PHPくらいしか触ったことないゴミだろ

>>235
なんだかんだ型は皆無よりはあった方がいいのは確か
ただし「anyは嘘吐きの言葉」とか言い始めるやつがプロジェクトに紛れ込むのがそれ以上の欠点

型は強制されない方が便利とかVB6の時代にタイムスリップしてきたみたい

旧Javaの冗長な型の反動で型無し言語が持て囃され、やっぱり型無し言語は糞、型推論でやってこうがトレンドだというのに
ここのおじいちゃんたちは「型は冗長！型はない方がいい！」

四半世紀前くらいからタイムスリップしてきたのかな？

極論で喚くだけのゴミ
booleanでしか物事を理解できず、バランスというものを知らないらしい

本当に型がそんなに大事ならGoは覇権を取れなかっただろうな
Scalaが死んでGoが覇権を取ったのは、>>243の過程からさらに揺り戻しで
「厳しすぎたり表現力ありすぎたりする、型ガイホイホイの言語じゃダメだ」って流れが来てるってことだろ

そのGoもGo2でジェネリクス入るけどな

char **argv の時点で既に難易度のバランス崩壊してるようなことは言われてた

>>207
Cはキャストでどうにでもなるけどそれが全ての型がない言語を代表してるとでも
旧ObjectWorksだと何も困ることはなかったな
任意のインスタンスに存在しないメッセージ投げようとしても警告が出てセーブできないし
無理やりevalで実行時解釈させようとしてもエラートラップするだけで原因はすぐわかるようになってる
引数はいわゆるanyだがどのクラスに限定するのか記述することもできる（そうしたいのなら）

型で縛ってる言語は労力かかるわりに仕上がり悪いことが多いね

そもそも型推論はコードの安全性を高めるのが目的というよりも
型が定まることにより最適化の恩恵を受けられるというのが本来の筋だと思うんだよな

型ガイとか型キチって表現は嫌いだけど、今は一般的なプロダクトでは型に持たせる表現力は控え目にしながらジェネリクスくらいは入るかって感じかなぁと思ってるよ

金融で型に持たせた機能で処理の妥当性をできる限り保証していきますって分野にだけ関数型言語でリッチな型を使うとか、Rustみたいに低レイヤーの捕捉しにくいバグ要因に対してだけある程度の機械的検査性だけ持たせるって使い分けの方針でさ

動的で強い型付けの言語も漸進的型付けやアノテーションの形で使えるものは使うって感じじゃん？

うーん何言ってるかわかんない

ScalaやRustみたいな型ガチガチにやる言語は今日日流行らないってことよ

理想のエンジニア「こういう機能があればユーザーは喜ぶだろうか？UXとかも考慮しないとな……」

現実のエンジニア「型が～！！モナドが～！！！動的wwwww」

俺悲しいよ……😭

コンテナ
スマポ
モナド
こいつらの目的は、ライブラリでできることを言語本体から分離すること
分離できなかった原因の一つがたまたま型システムだったから型の話をしてるだけ

コンパイラにできることは型が正しいか検査することだけであって
正しい処理をしたかどうかなんて担保できないんだよね

型の辻褄は合わせました、ロジックは間違ってて要求仕様を満たしてません
こういうのを何度も見てると本末転倒とさえ思える
型に振り回されすぎて実際のコードがゴミになってる
これはいかんね

新規に少人数でゴチャっと作るなら型無し言語が早いと思うが、
その後軌道に載って人数増やして機能追加を加速して行くとなったら、静的型付け言語の方に圧倒的なアドバンテージがあるぞ
そのへん疎かにしてるからバグだらけで機能追加もままならないとか糞サービスになる

>>253 みたいな下側の話をするためのしょーもない場所にわざわざやってきてまで煽りたいだけの人間が居る事の方が俺は悲しいよ

>>256
少人数でも大人数でも動的なほうが問題起こしにくいよ
コード量も少なくて労力がかからないというのは利点しかない

機能追加にしても動的だと合わせやすいけれども静的型付けだと
どうしても綿密にやらないといけない割に不具合起こしやすくなる
強い型付けは想定されていなかったことに対して非常に弱い側面あるね

それはさすがに嘘つきすぎ
人数や規模が増えるとバグは動的型付けの方が圧倒的に増える、加速度的に増える
動的型付けならバグってても実際にそこ通るまで検出されないだけ

今時の言語は型推論が強いから静的型付けでもそこまでコード量は増えない

個人的におかしいと思うのは
強い型付け言語の利点としてなぜかコードの安全性なるものが神話化してしまったことなんだね
それは全く担保できないことなんだけれども。

大きな利点があるとすればコンパイラがより最適化しやすくなる、ということだけだけど
HaskellなんかのUnboxed Valueがさっぱり早くないところを見ると疑問もある

>>259
通らないコードはテストもされていないってことなんだよ
そこを心配するのはそもそもおかしいのだ

動的なエラートラップはすぐに原因がわかるのと対処も早いので進捗は早めになる

>>261
無根拠に断言してるだけ、論点先手、詭弁の典型
静的だと動的型付けよりエラーの原因がわからないという根拠、データなし

なお現実は型レベルで整合性の取れないおかしなコードを書くゴミの方が多い

>>261
動的型付けで実引数に与えられる可能性のある型すべてに対してどうやってテストするの？

>>258
機能追加で動的だと合わせやすいとか全く異次元で信じられないよ
俺は今機能追加するときには、自分が作ったコードだろうが他人が作ったコードだろうが、まずは型を頼りに仕様を把握して、既にある型に沿って追加コードを書いていくよ
必要なら既存のコードの変更もするわけだけどその時も型を頼りにIDEの機能を使ってリファクタリングとか頻繁にする
自分の作った数年前のコードなんて、型無しで保守するとか恐怖だよ

HaskellとかScalaとかでそこそこの規模以上の開発したことあるなら
「静的で強い型付けしてるから開発とテストサイクルが速い」なんて口が裂けても言えないと思うが

一ヶ所変えるだけであらゆる関数の引数や返り値の型を全部変える必要が出てきて
それに伴って既存テストコードも全部動かなくなって
何が正しいのかから全部決め直しになるみたいな地獄を経験したことない奴が
「静的型の方が開発サイクル速い」とかフカしてるの見るのおぞましいわ

>>266
JetBrains の IDE とか使ったこと無さそう
そういう地獄は IDE でさくっと回避する時代だよ

ID:b9+wkgN8

動的型がどれだけ頭の悪い似非エンジニアに汚染されてるか、よくわかるレスですね

>>266
一ヶ所変えるだけであらゆる関数の引数や返り値の型を全部変える必要が出てきて
それに伴って既存テストコードも全部動かなくなって
何が正しいのかから全部人力Grepになるみたいな地獄を経験したことない奴が
「動的型の方が開発サイクル速い」とかフカしてるの見るのおぞましいわ

おまえらが馬鹿にしてる Java だって IntelljIDEA や AndroidStudio のリファクタリング機能でテストコードも含めて何の苦もなく引数の型変更とかできる
逆に型無かったらこれをサクッとやるのは難しい

マネージャーとの面談にて

マネージャー「最近の調子はどんな感じなんだ？」

型キチ「概ね大丈夫です……ただ、動的型付け言語が一部のプロダクトで使われてるのだけが不満で……」

マネージャー「か、型？それだけが問題なのか？」

型キチ「それだけ！？！？？？？？？？？！？型があるかないかだけでメンテナンス性と可読性が全然違うんですよ！？？？ｷﾞｬｵｵｵﾝ!!!」

悲しいね

ああ型無し言語は引数の型は無いんだったなｗメソッド名の変更をさくっとできるとかに読み替えてくれ

>一ヶ所変えるだけであらゆる関数の引数や返り値の型を全部変える必要が出てきて

これはわからんでもないが

>それに伴って既存テストコードも全部動かなくなって

なんでそうなるのか意味不明

>>269
それは現実離れした極論だね
修正が必要になるのはどの言語でも変わらないよ

テストコードが動かない場合、あるいはtest protocolが失敗するケースでは問題が起きてるから修正にはなるがそれだけだ
引数に全く違うオブジェクトが入ってきた場合の振る舞いはすぐにトラップするからわかるよ
全体修正なんてことにはならないしなったこともない

>>272
メソッド名の変更は全体に適用できるので問題ないね
命名変更程度なら用意されてる
呼び出す方も全て変わる

>>264
旧仕様のクラスのままで新仕様のクラスをテストする、ということが動的の場合はできるのだ
こう言ったことに限らずあらゆる局面で柔軟性が高いのは利点だよ
開発サイクルの速さはこういうことにもつながっている

モナドが難し過ぎてHaskellでmain関数書けないんだが
こんなもん普通の言語に導入するのは無理がある

>>264
重要なことを書くのを忘れた
「型を追わなくていい」んだな
そこに注力する必要がなく、適切なprotocolと定義があるかを見ることが重要になる
型付け言語と動的の場合それぞれアプローチが変わってくる

関数型言語は関数型を使ってる自分に酔ってシコるためだけに存在する言語だからね
シコScalaやシコHaskellは勉強しなくていいよ

F#のことも思い出してあげて

座標を扱う時に直交座標も極座標も数値型の組に過ぎないから型があってるだけでは不十分
みたいな話ならまだ分かるんだが

>>281
それは設計が悪いだろ
まともな頭してたら直交座標と極座標は別の型にする

CLOSなんかでも総称関数で想定外のオブジェクトが渡されたら大変なことになるなんて言う人いないと思うが
最終的に呼ばれるはずだったslotが存在しないオブジェクトを扱おうとしていたら直ちにトラップか
コンパイルする処理系だと事前に警告だから

どこをどうやっても全体修正なんてことにはならない
強い型付けをしても想定通りに動かないコードが出来上がってしまうのは
すなわち型だけで安全性を高めることはできない証左とも言える

その理由の一つに一般的に型とは振る舞いを定義しているものではないからだ
型が合わなければ通さない、合っていれば通す、ただそれだけのことであって
通した後の処理まで面倒見ているわけじゃあない
本末転倒になっているのはこの部分だね

こんなお花畑野郎とは絶対に一緒にコード書きたくねえな
型以前の問題だったわ

こいつの言ってる安全性ってなんなんだ
勝手に神話を作って勝手に信じたのか

マネージャーとの面談にて

マネージャー「最近の調子はどんな感じなんだ？」

型キチ「概ね大丈夫です……ただ、静的型付け言語が一部のプロダクトで使われてるのだけが不満で……」

マネージャー「か、型？それだけが問題なのか？」

型キチ「それだけ！？！？？？？？？？？！？型が理解できないし勉強できないメンテナンスできない人がいるんですよ！？？？ｷﾞｬｵｵｵﾝ!!!」

悲しいね

ここ型議論しかしてねーな

次スレは動的型付けvs静的型付けで

>>286
型キチさん、型チェック忘れてますよw

型ガイさんって正直Javaしか使ったことかいんでしょ？
怒らないから言ってみ？

型無しガイジはPHPスレに帰れ

型があれば処理が正しいなんて言ってるやついないじゃん
そんな神話聞いたことないわ

存在しない脅威について怯えるのは出来ないエンジニアにありがち

マジで無能はオールオアナッシングでしかものを考えられない

＞強い型付けをしても想定通りに動かないコードが出来上がってしまうのは
＞すなわち型だけで安全性を高めることはできない証左とも言える

JavaScriptは強い型付け言語ですけど
動的型付け/静的型付けと強い型付け弱い型付けの区別もついてないレベルで
こんなご高説垂れてたのか

型ガイさんって正直Java(8未満)しか使ったことかいんでしょ？
怒らないから言ってみ？

静的型付けネガる人って何でもStringとか何でもMapとか、あるいは配列の1番目はx座標で2番目はy座標を返すメソッド！
とかやっちゃう人なのでは？型が簡単に作れて使える世界を知らないだけでは？

>>293
ベターを知らないんだよな
ベストとワーストでしか話しが出来ない
能力があって責任ある立場にいればそんな発想にはならない

>>294
JavaScript は一般的には弱い型付け言語じゃないの？
今も "1" + 1 とかできるんだよね？

Scalaが次世代言語になれなかったのは事実
成功して現世代と言えるくらいになった次世代言語が型がゆるいGoくらいっていうのも事実

でもScalaが自滅したのは強い静的型付けだった「から」じゃないし
Goが流行ったのは型がゆるい「から」じゃないはずなんだけど
なんでそういう関係ないところで型の有用性について議論したがるかね

>>248
んで？今でもあんたはそのobjectworks使った仕事してるの？

>>283
誰一人として型だけで安全なコードができるなんて言ってないのにお前は誰に向かって書いてるんだ？

>>272
少なくともpythonに関しては、JetBrainsのIDEといえどtype hintingが無いと結構失敗する

>>298
それは暗黙の型変換が行われるだけで、その結果は言語仕様で定義されてるから、型システムとしては型安全性があると言える
型安全性があるのが強い型付けで、無いのが弱い型付け、とされる

でもそう定義する界隈があるってだけで、それが絶対的な定義ではないとは思うけどな

型キチってScala関連の書き込みには全くレスつけてくれないけど
そういうことなんだなって察してしまうわ

型の話が出るといつもコンプレックス丸出しの奴がギャーギャー騒ぎ始めるねえ
scalazで落ちこぼれたのは分かったけどもw

自分の脳内で作り上げた想像上の人間がScalaスレに書き込んでないことから何かを察するの、すげえな

型についてそこまでこだわっても品質なんてそこまで変わらんとも思うが、
しかし言語選択で今一番影響あるのは型の強さとかあるなしかもな。
まあperlとかphpレベルで暗黙変換しなけりゃ俺はいいかなと思うけど。
動的静的よりも暗黙変換をどれくらい許すかのが個人的には重要かな。

一般的型キチさんの開発環境
Java6、SVN、Eclipse、Windows、WinMerge、秀丸エディタ、オンプレミス、エクセル、社内Wiki、Outlook

一般的動的マンの開発環境
Ruby・Python・PHP、Git、IntelliJ、Mac、Docker、AWS・GCP、スプレッドシート、esa、Slack


悲しいなぁ……😭😭😭

本業C#だがMacがWindowsになる程度だしクソ企業と普通の企業の差では
あと表計算ソフトはスプレッドシートと名を変えようがダメ

>>308
そんなにMacが好きならSwiftやiWork使えよww

「俺Mac取ったー！おまえWindowsな！」
小学生かw

>>308
スレタイに出てるJuliaは空気だな？

Pythonのデータ系やJuliaはWindowsも多いよ
Rubyなんか挙げちゃった子には無縁の世界

v 更新しとるんだな。今ならてきとうにコミットするのはありかも。
https://github.com/vlang/v

このスレマジでMacにコンプ持ってるやつ多すぎて笑うわ

未だにWindows使ってるレガシー企業のくせに次世代言語てw

精神勝利法すげえな

型付しないと精神を保てない例だなw

むしろ未だにMacにこだわってる方が加齢臭すごい
LinuxとWindowsがあれば十分で、Macとかいう中途半端なゴミはいらない

TS, Go, Rustを使いたがるスタートアップ界隈はWSL2次第でWindowsに戻ってくる動きもあるんだがな

>>313
副業でRubyもたまにやっているがDockerが普及してWindowsユーザーも増えているぞ
Rubyの会社で今時Docker環境じゃないのは余裕がない証だと思って避けているわ

>>308
でたキチガイ

>>308
型キチだが
TypeScript・Python(Type HintingなしはNO)、VSCode、Ubuntu Desktop(Core i9) + Mac、AWS、Slack

モダーンで、すまんなすまんなw

自分の一存でScalazを採用させるだけの発言力があるのに
Java6 SVN Eclipse 使わされてるSIerって型キチの設定ガバガバすぎない？

>>319
rubyなんかはそこまで低レイヤーさわらんし、バージョン管理ツール使ってりゃいいんでないの？
docker だとやりすぎ感があるんでは？
c/c++系統の奴使ってるとか、kubernetes使うとかでもない限りそんなに必要と思わんのだけど。

>>314
サンプルやコンパイラがメモリリークするのは直ったんだろうかね

Goのように簡単に書けてRustのようにGC無しで自動解放すると言っていた
Go/Rustを超える詳細不明のメモリ管理が実装された話は聞かなかったが

✕　Windowsの方が良い。Macはいらない

○　Windowsしか使っていないレガシー企業に所属しているからMacに触れる機会が無い

AppleなんてMSが資金援助しなかったら潰れてたんだから
Apple信者はジョブズじゃなくてゲイツを崇めるべき

型付コンプマンとOSコンプマンは同一人物か
どうでもいいから言語の話をしろよ？

いい加減に型議論スレ立てれば？

PythonがRubyを倒した時にはこんな問題はなかっただろう
C#とTypeScriptあたりが潰し合えば問題ないのに
論点をそこに設定できない理由があるならそいつが元凶だ

>>329
何と戦ってるんだお前は

>>324
個人的には無理だろと思ってるけど、実際コミットしてみるのは面白そうかなと思う。
どっかでそれなりの妥協するか崩壊するかだろうけれど言語勉強にはいいんでないかな。

>>328
Juliaの話題が出ないから次スレからスレタイから外したら。

>>323
バージョン管理ツールがGitとかのVCSを指しているなら意味が分からんのだがどういう意味だ？
Docker DesktopとGitを入れて `docker-compose up` で開発ができ、CIから何からを半自動でやるのがインフラを整えるということでは

>>333
rubyで閉じるならrvm, rbenv使うなりしてりゃ環境合うだろって話。
それ以上低レイヤー依存が激しいならdockerもありだろうが、
使わんでもcloudでインスタンス利用するならdockerは無駄な冗長化だなと思う。
docker compose とかすげー半端感しか感じないんだが。
大してスケールするわけでもないし。

>>334
あー、xenv系の話か。すまん、俺がボケてた
言っていることは一理あるしそういう派閥がいるのも知っているが俺は完全に同一の環境で開発するのを是としている
ただ開発環境がDockerでデプロイ先はVPS直という現場はアホだと思うよ

>>332
出ないからこそだゾ >>3-6

>>332
そして誰もいなくなった

https://japan.zdnet.com/article/35139247/

MIT、「Julia」上で動作する初心者向け汎用AIプログラミングシステム「Gen」を発表
Liam Tung （ZDNet.com） 翻訳校正： 編集部 2019年07月01日 10時55

　マサチューセッツ工科大学（MIT）は米国時間6月26日、確率的プログラミングシステム「Gen」を開発したと発表した。
Genにより、初心者でもコンピュータービジョンやロボティクス、統計に関する処理を容易に手がけられるようになるという。

　Genは、「Julia」に組み込まれるかたちで実装されている。なお、JuliaはMITの研究者らによって2012年に公開された
動的プログラミング言語であり、世界的に高い人気を集めている。

　Genの開発者らは「カスタム化した複数のモデリング言語をJuliaに組み込む」ことで、ユーザーが「数式と格闘したり、
高効率なコードを手作業で記述したりせずとも」人工知能（AI）のモデルやアルゴリズムを開発できる
新たなAIプログラミングシステムを生み出したとMITは述べる。

　このシステムは予測などの複雑なタスクにも使用できるため、技術に造詣の深い研究者にも役立つだろう。

　MITの論文によると「Gen」という名称は、従来の確率的プログラミングでは考慮されていなかった、
「汎用目的」（General purpose）での使用を可能にすることを念頭に置いて付けられた。

　論文には「既存のシステムは汎用目的としては実用的ではない」と記されている。

　また、「特定の問題領域にのみ適した、制約の大きいモデリング言語を提供しているシステムがある。
その一方で、どのようなモデルでも表現できる『汎用の』モデリング言語を提供しているシステムもあるが、
そういったシステムは使いものにならないほど収束の遅い推論アルゴリズムしかサポートしていない」とも記されている。

　今回のシステムにより、例えば、人の姿勢といった立体的な形状の状態を推論し、
自動運転車やジェスチャーベースのコンピューティング、
拡張現実（AR）に用いられるコンピュータービジョンのタスクを簡素化するようなプログラムを作成できるようになる。

　Genは、MITが2013年に「DARPA AI」プログラムから獲得した資金によって2015年に開発した
確率的プログラミングシステムを強化するかたちで、グラフィックス描画やディープラーニング（DL）、
さまざまな確率シミュレーションを組み合わせている。

　MITで電子工学及びコンピューターサイエンスの博士課程を専攻しており、
この論文の主執筆者であるMarco Cusumano-Towner氏は、「自動化されたAIを、
コンピューターサイエンスや数学の専門知識をさほど必要とせずとも、
容易に扱えるようにするというのがこの研究の目的の1つとなっている」と述べている。

　「われわれはまた、生産性を向上させることで、専門家によるAIシステム開発時の試行錯誤や
プロトタイプ作成の迅速化を容易にしたいと考えている」（Cusumano-Towner氏)

　Microsoftが「AIの民主化」を旗印に掲げているように、
MITの研究者らもデータサイエンスをあらゆる人々のもとに送り届けようとしている。

　また、MITによるとこれは、Googleの「TensorFlow」の1歩先を行くものだという。

　MITは、TensorFlowが「DLモデルに的を絞っている」という点で、
AIの持っている潜在的能力を完全に解放していない可能性を指摘している。

また生産性を向上させてしまった・・・これは言ってみたい

生産or消費でしかものを考えられないんだな
これを言ってやろう

型キチや型無し不能者は正直どうでもいいから置いとくと、実際のところ俺の周り(当然狭い)で仕事で関わる可能性のありそうな次世代言語はある程度の静的型付け可能な言語かな(具体的にはGo, Rust)。

みんなの周りでは動的言語で仕事に関わりそうな次世代言語ってどんなのある？(純粋な興味)

型に関してはうまい落とし所のがあればいいな
ガチガチでもなくゆるゆりでもないみたいなの

そのひとつが漸進的型付けで、TypeScriptはかなりいいセンいってると思う。

>>342
そもそも次世代言語に動的型のやつあったっけか？

過ちを犯した者が仕様変更しなさい

仕様変更しているのは静的型だけになった

Haskellは安全性では一番だけど
モナドと遅延評価が難し過ぎて普通の人がコードを書くのは難しくて失敗
Cの型は単なるメモリレイアウトで実質型なしで
スタックオーバーフローなどの脆弱性を大量に生み出し失敗
Javaは割と堅牢な型システムだがnullを放置したせいで
ヌルポの山を築いて失敗
RustはCにまともな型システムを導入しようとしたが
所有権に誰もついていけず見事失敗
Goは動的言語と静的言語のいいとこどりをしようとして中途半端になって失敗
TypeScriptは漸進的型付けというありそうでなかった型システムだが
型定義が面倒すぎる上anyは嘘派と頑張らない派で対立して失敗

>型定義が面倒すぎる

面倒と思うのは既存のjsコードに型定義を付けるときくらいで、最初からtsで書いている分には
面倒と感じたことはないがなぁ。
他の静的型付け言語とかと比べてどういうところが面倒なんだろうか。

所有権はC++の頃からあるよ
Rustで新しく導入されたと言えるのは借用規則とライフタイム

「所有権」と呼ばれる概念は昔からあるけどそれが何を表しているかは結構バラバラなわけで、
そこは「rustの所有権システム」と解釈すべきなんだろう。

どうでもいいけど、今の40代って軒並み役に立たないな
オンプレのLinux操作は早いけど、それだけ
保守歴長すぎて、新規でコード書くことが一切できない
まさかRDBの設計すらろくにできないくせに、俺は35定年を乗り越えられたエンジニア、みたいにしてるのマジで笑えるわ
死んで欲しい

転職してえ

人には得意不得意があるのだから「出来ないことがある」で評価すべきではありませんよ。「出来ることがない」なら無能なので切りましょう

>>352
わかってるよ、保守で役に立つんだから、保守やっててくれりゃいい
オンプレマシンのお守りも重要な仕事だ

だけど「設計はベテランに任せておけ」とか40代のゴミ同士で乳繰りあって盛り上がってるの見ると
ホント寒気がするんだわ
試しにDBの論理設計やらせたら、正規化もまともにやってない、型は適当、NotNullも定義してないExcel出してきやがる
20件くらい指摘上げたら、「君こだわり強いねｗ」とか「業務は趣味じゃないんだから」とか言い出すんだぜ
目眩がしたわ

絶対ああはなりたくない

この手のやからは単に自分の得意分野でドヤってるだけ

で？お前には何ができるの？

>>355
バックエンドもフロントエンドもできるが
少なくともあの爺どもよりは

そのおじさんもミドルならできるんだろ

次世代言語に全く関係無い話は余所でやってくれ。

俺もおまえらも薄汚い無能オッサンになるんだよ
次世代言語どころか、現世代言語すら理解できないような悲しいオッサンにな

だから、有意義に過ごせよ、この何でもない毎日をよ

青春だねぇ

すでに完全にオッサンから初老に一歩足いれてるワシの観察によると
若い時分に「老害は新しいモノがわかってない!これからはこういう
新しい概念を理解してないとダメだ!」みたいなこと言って意固地に
なってたタイプほど、歳食ってから老害になるパターンが多い印象
逆に仕事で金もらえるならなんでもやりますよ、みたいなやつは
歳くっても頭が柔らかい。

>>348
とにかく型定義ファイルがだるいし
それがあってるのかという型そのものへの疑心暗鬼が生まれてしまいメンドクセとなる
あと結局型の設計がJSっぽさ満開のライブラリだと
頑張れば型付けできるがそもそもの型設計が
クソ過ぎるため型パズルを解くことになるのもだるい
TSそのものというよりそれ含めた環境が地獄なので
相当難しい

周りのレベルが今の自分のレベルだ
転職でもしてろ

>>361
これはガチ
金になるからって理由で流行りものに広く浅く手出してるやつの方が実践的な経験たくさん積んでるし長生きしてる

自動プログラミングの登場はいつ頃？

>>361
プログラミングなんて一つ覚えれば他は応用で何とでも出来るからな
言語は設計者の信念や価値観が反映されるし
最近はその傾向が非常に強く濃く出てるからな
最後はその価値観や信念を受け入れられるか否かになってるね

>>361
アラサーだけど完全同意
年齢というより本人の性格

若いうちにガッツリ開発した経験があればいつでもやり直せると思うが
ずっとマニュアル通りの保守運用してた人とかは厳しい

>>362
>とにかく型定義ファイルがだるいし

それ.d.tsの話だろ。
最近はnpmもかなりts対応が進んで、ここ1年以上自分でアンビエント宣言書いてないわ。

スレタイからTS消したのに結局TS・JSの話しかしてねーな

女子小学生の話でもする？

>>371
淫行で捕まるぞ。

プログラマーがJSと仲良くなる方法？
一緒にスイッチやろうぜ！これだけでいい

結局Scalaが世界中巻き込んだ大爆死して
型なんて適当でいいんだよ派のGoが覇権取ったのは
型キチにとって最高に都合が悪いから
露骨な話題反らししたり老害ペチパー連呼したりするんやろなあ

よきにはからえでそこそこ動くなら楽だしな

型煽りが来たしそろそろOS煽りの時間か？

むしろJSからTSへ、RubyやPHPからGoへ、で静的型への移行が進んでいるのでは

なるほどScalaからGoとみるかRubyやPHPからGoとみるかで確かに違うか

GoがScalaを意識してたとか初めて聞いたわ

意識してたかどうかはしらんが
最初にScalaとかの型ガチガチにやる言語と比べて
貧弱すぎて草生やされてたのはよく覚えてるわ

>>371
山梨でボランティアしてこい

遭難して迷惑かけるなよ

そもそも型付けがガチガチとかゆるゆるというのが何を指してるのか分からん
HaskellでさえunsafeCoerceとかあるんだからある意味ゆるゆるな言語であるとも言える

Goの型が貧弱とかゆるいとか言ってる奴馬鹿丸出しだぞ
あれガチガチの静的型付けだから

>>383
静的言語の中でも型システムがしょぼいという話なのだが

Goの特徴として前から言われていたのはAOTコンパイラ
そして案の定JITコンパイラ言語が一つ消えた

実装と文脈を無視して、仕様を切り取ってはいけない

>>384
型システムが貧弱というのと型付けがゆるいというのは違う

>>384
いや>>374や>>380みる限り明らかに型がゆるいと勘違いしてるアホだろ
GOがよく叩かれるのは機能の貧弱さであって型付けの強弱や静動とは別の問題だから

いい加減セミコロン排除してほしい
今時の言語にセミコロンは不要

フレームワークを作る側と、フレームワークに用意された関数を呼ぶだけのドカタが
同じように話し合っても意味ないだろ

RailsがRubyで生まれたのは動的型のメタプログラミングのやり易さによるものだが
ドカタにはメタプログラミングなんて想像もできないだろ？

セミコロンは必要

セミコロンはあっていいわ
それよりlispみたいな括弧だらけをどうにかしてほしい
dartのことなんだけど

>>389
型は辛うじて理解できるから型型言ってりゃ意識高く見えるんだろう

セミコロンないとウンコしたあとケツ拭かないみたいで気持ち悪いねん
屁しか出なかったから拭かなくて大丈夫でも一応拭いとかんと気持ち悪いんや

ごく稀に魔改造されたフレームワークを見かけるけど
今までどういう経緯でなったのか理解できなかったけど>>389みたいな発達障害の仕業だったんやな……

前スレではTSはJSに型を付けた安全な言語！って言ってたのにどうした？

TSはJSに型をつけた"JSよりは"安全な言語。
Rustも"C++よりは"安全な言語。

比較級と原級はまったく意味が異なるので混同しないように。
一般に、 old, older, oldest の実年齢は old が一番高いのだ。

盾の中で最上級になっても実戦でぶつかるのは盾と盾ではない
矛にあたるのはテストだよね

rustが安全ね。。ライフタイム、所有権を気にしすぎてベタに長い関数書きまくりの糞コードで本当に安全といえるのかね。

ライフタイムや所有件と関数の長さは関係ない
関数の長さと安全性も関係ない
まだ40行で疲弊してるの？

コードが長いから安全じゃないって意味わからんな
このスレの一部のヤツらは安全性の概念を勘違いしてるとしか思えんわ

だからメモリ安全性だけ主張しても意味ないつってんのに理解力ほんとないな。

まあRustならバカ避けになるから結果的には安全性に大きく寄与するだろう
Goなんかはキャズムを超えてしまってそろそろプログラマの品質が怪しくなってきたし

goの型付けで言えば、interface{}をreflectで解決する一種の動的型付けに
頼らなきゃならん場面が多いのが問題だなぁ。
genericsが来ればだいぶ違うんだろうが。

所有権やらライフタイムやらにうるさいせいで
本質的じゃないボイラープレートがぼこぼこ生えて
コードベース肥大化するせいで
本質的なロジックが簡単にバグ誘発する

くらい長々説明しないとわからない頭の持ち主なんだから仕方ないよ

実際にRust書いたこと全然なさそうなレスだな

馬鹿でも書けると書かされたPHPはどうなりました（ウィスパーヴォイス）

所有権とか参照のライフタイム自体は「メモリの解放責任が今どこにあるか」「参照先がいつまで生きてるか」ってだけでRustの固有概念じゃないよ
C++でもというかC++でこそ所有権と参照のライフタイムはそりゃあもうRust以上に意識しまくらなきゃいけないし
その分ボイラープレートも増える

感覚で語ってるからちゃんとした説明ができないんだよ
それを直視出来ずに他人の理解力不足にしてしまう残念さ

所有権やらライフタイムが本質的じゃないってあたり、お里が知れるな

そこはまぁ、所有権を管理することがプログラミングの目的じゃないから。

本来やらなくていいことだしな

あぁそうだな、型を宣言するは目的じゃないんだったな

本来の目的に近いのがテスト
ユーザーとテスターの見分けがつかないぐらい近い

Rustで借用チェッカうっせえってなるのほぼ可変参照の唯一性ルールだよな
これはロジック上安全でもいちゃもんつけてくるパターンが多い

ライフタイムで怒られるときはほぼ確実にこっちが間違ってる

スコープ、寿命はc/c++でメモリ配置を考えながら組んでた経験あれば
むつかしい部分ないからね

>>402
なんかやたら流行ってるよな
一時期のRubyみたいな感じになってきた
そんな簡単に使える言語じゃないと思うけど
Webアプリならフレームワークあるから似たようなもんなのかね

流行ってますぅ？
フレームワークといっても薄いのしかないからレールズ使いはDBと接続できなくて詰みそう

GOの定番フレームワークって存在するの？

プログラミングなんて誰でもできる単純作業になるのがベストなのにすぐマウント取ろうとするやついるよね

ゴチャゴチャ言ってるけどCRUDアプリしか作れないんだろ？

CRUDを笑う者はCRUDに泣く

誰でもできる単純作業と言われても
世の中にはforループすら理解できない人がいるらしいし

また初心者にプログラミングを教える機会があった
https://cpplover.blogspot.com/2019/10/blog-post.html

江添亮
自由ソフトウェア主義者
C++ Evangelist
C++標準化委員会の委員
ドワンゴ社員
C++11本を執筆した。
株式会社ドワンゴで働いている。

あっ…（冊子

>>422
俺より頭良さそう

察しもクソもC++界隈だとかなり有名な人だよ

何の言語の経験もなくてforループって習った直後は理解出来んかったわ
あとで自宅でゆっくり考えて数日で判った中学生の頃

アセンブラでループはそれから1年くらいかかった

信者キメェ

ぼくはC言語やり始めてif文の理解に2週間ぐらいかかったなあ

>>426
もしかして俺に言ってんの？
別に誰も支持してるなんて言ってないんだけど
1bit脳だとそういう認識しかできないのか？

警察の職質にキレた挙げ句国賠起こして返り討ちにあったやべえ人じゃん

江添さん最初に会った時ガリガリだったのに
ひさびさに写真見てムキムキになってて笑う

>>428
そうだよテメーに言ってんだよｗ

信　者　キ　メ　ェ　ぞ

信者ってかアンチの人だと思うんだけど

江添がC++界隈で有名なのはただの客観的事実だぞ
いい意味で有名とは一言も言われてないのに信者認定とか顔真っ赤すぎる

信者日和っててワロタ

どんな下らない事でも無知を指摘されると発狂するやついるよな

信者ですが何かくらい言ったレよ

公開してるコードみれば江添、まったくコード書けないんだなってのはよくわかるよ。
めちゃくちゃ短いコードであれかよと思う。

>>431
知能も沸点も低そう

goroutine乱用しなけりゃgoは酷いことにはならんだろ。
まあバカは乱用するんだが。

goroutineは乱用してこそ華。

「ポインタ乱用しなければCは酷いことにはならんだろ」ぐらい無意味な意見

>>439
でもGo民たち、goroutineが書きやすいって言ってたじゃん・・・

>>441
ポインタとgoroutineを同等にとらえるという極論言い出すバカ。
goroutineが必要な場面って実はそこまでない。

乱用して酷いことになった実例がないと話がピンとこないなぁ。

何やて！って1000くらいgoroutine作るようなコード書いたら遅くなる

goroutineが必要な場面というか並列処理が必要な場面はそこまでない、とは思うんだけど、
並列処理が不要な場面でGo使うのが良いとも思えないんだよなあ

1台に閉じる程度かつ多少複雑な並列処理を扱うならGoは有力な選択肢ではあるとは思うんだけど

ツアーやってるんだけど
やたらスライスばっかつづいてツライス

変数の宣言方法が3つくらいありまあす！　：＝）

僕はツアーをそっと閉じた

Goとかいう知恵遅れ言語もてはやしてる奴って
だいたい元を辿るとペチパーなんだよな
今のところ例外はない

プログラミングなんてただの作業は知恵遅れでもできるようになるべきだしGoはもっと普及すべき

君たち知恵遅れGo！Go！♪

>>449
Goに例外は無い、と掛けてるのか
うまいね

>>450
自動プログラミング。

知恵遅れってそれ自衛隊員に同じこと言えるの？

>>454
なんで自衛隊が出てくんの？

自衛隊員はともかくそれを統べる奴は漢字が読めない点で
充分条件を満たしているよな。

漢字が読めない奴は士官になれないよ

良くて土管

総理にはなれるのか…

田布施システムが生きてる限りしゃーない

goでも難しい言い出す奴いるってのがやべぇな。

レールズのおかげて知恵遅れにプログラミングができないことが分かったから、これからは賢者の仕事になるだろう

>>462
PHPのおかげでもあるな

PHPは知恵遅れでも動かせるじゃん？
安全かどうかはともかく

例の見下しフローチャートの画像だれか貼ってあげて

このスレって単純作業にプライド持ってる奴隷がたくさんいるよなぁ
コンビニのバイト達がレジ打ちの速さを競ってるようにしか見えない

ていうか契約プログラミングの次に来るものは
願望プログラミングだろうＪＫ
知恵遅れでも安全にプログラムができうる

実際は単純作業もまともにできないカスばっかだけどな。

ある程度以上できる側の人なら

・単純作業ではない比較的高度な研究開発をしている
・単純作業もロクにできない大多数のゴミどもの作るスクラップをリペアして組み直して回ってまともに動くプロダクトにしている

のどちらかになるから、コンビニのバイトに例えるということは……

その後者はできる人に分類していいのか…？

スクラップアンドスクラップですわ

軍事にたとえるのやめた時点でもう
「やるなら軍師」理論は終わコン

>>456
外人はどうやねん。

【悲報】TypeScriptの型システムだけで4bit VMを実装してコンパイル時にFizzBuzzを解くバカが現れる
https://gist.github.com/acutmore/9d2ce837f019608f26ff54e0b1c23d6e

次世代言語やんけw

バカすぎるだろ…

c++のテンプレートがチューリング完全と似たような話か

Haskellやってるとき同じ悩みにあった記憶
先に式変形で解くのがいいのか計算で解くのがいいのか
ごっちゃになってプログラムが崩壊した

gitがあれば崩壊しなくてすんだパターンかな

プログラマを実力巡にABCと分けるとして
Aを揃えるというのは殆どの経営者にとって現実的じゃないから選択肢から外れるわけ
悩んでいるとCでも扱えるものがあると聞いてPHPやRoR を使えるCを安く雇って作らせてたわけ
けどCが作るものは持続不能なゴミだと気付いたわけ
そんで今はBにGoなりVなり使わせて前進してるわけ
そんなわけでいまBの市場価値が上がりまくって苦しいわけ

ちょっと違うかな
地頭はAだけどプログラミングの小手先の技術や経験に乏しい人ってのは世の中に沢山いるんだ
彼らは往々にして、自分をAだと思っているBに小手先のテクニックでマウントを取られて本来のパフォーマンスを発揮できずにいる
そこで小手先のテクニックの要らない言語を強制してマウンティングを封じることで、全体的にはパフォーマンスが向上するというわけ

ヘイトスピーチのように犯罪として裁くことでパフォーマンスを向上させるやり方も
あると思うのだが
やはり、犯罪はないものとする前提なんだな

Ａ；俺はやればできる子！

＞Bに小手先のテクニックでマウントを取られて本来のパフォーマンスを発揮できずにいる

草
どんな妄想だ

そもそも仕事のプログラミングに高度なスキルなんて求められてないがな

高度なものを実装したところで誰もメンテナンスできない聖域が増えるだけでデメリットでしかない

つまり首切られないってことじゃんｗｗｗ

>>486
こういう属人化させる=クビにならない=優秀
って考えてる地雷キチガイは採用段階で見極めないとあかん

職業プログラマーとして優秀なのは

レベルの低い人でもわかりやすい命名や設計をして、シンプルなコードを書いて、教育もできる人な

高度なことがしたいなら個人でアプリ作るか、基礎研究所にでも転職しろ！

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

COBOL最高まで読んだ

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

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

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

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

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

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

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

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

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

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

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

それがまさにTypeScriptでは？

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

any使えば良いじゃん？

全部anyつければ解決

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

つ noImplicitAny: false

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cしか勝たん、

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

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

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

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

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

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

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

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

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

とりあえず名前がださい

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

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

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

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

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

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

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

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