次世代言語24 Go Nim Rust Swift Kotlin TypeScript

**デフォルトの名無しさん** · 2022/03/22(火) 03:23:41.60

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2022/04/10(日) 13:30:51.71

>>804
ほんまこれ
このスレの一部のRust信者がRustこそ至高みたいなノリだけど、このノリについていけないRust推し結構いると思う

**デフォルトの名無しさん** · 2022/04/10(日) 13:55:42.06

いつでも最初から型が要るのは足枷というのは確かに思うわ
そうなると漸進的型付けってやつかねえ
TS以外のaltJSは死んだとかだれかが言っていたが、Haxeの再興もあるか？

**デフォルトの名無しさん** · 2022/04/10(日) 14:04:03.83

>>805
というよりRustは好きだけど別に推してはないという
誰も使わなくていいよ
俺と一部のお前らが使うだけでいい
みんなに使ってもらう必要なんて一切ない

**デフォルトの名無しさん** · 2022/04/10(日) 14:14:16.90

>>807
そう思ってるなら言わなきゃ良いんじゃないですか？そういう他の言語を使ってる人を小馬鹿にした態度がRust推しそのものでしょ、しかも良い印象は全く受けない

**デフォルトの名無しさん** · 2022/04/10(日) 14:16:40.89

アンタにレスしてないから気にしないでね
人を小馬鹿になんかしてないし
Rust以外の言語も好きだし
そもそもどの言語も馬鹿にしたりしない

**デフォルトの名無しさん** · 2022/04/10(日) 14:23:28.49

こういう屈折した性格の勘違い野郎ばっかで本当に近づきたくない。扱いにくいのに能力なんてないし言語触ってれば最先端だと勘違いしてる、とんでもねえバカ

**デフォルトの名無しさん** · 2022/04/10(日) 14:40:08.25

RustはMozillaのステマでfirefoxのRust導入は
不可能と叩きが暴れてた頃が懐かしいなあ～

**デフォルトの名無しさん** · 2022/04/10(日) 14:57:34.06

>>810
まあ勘違い馬鹿は必ず存在するのである程度致し方ない。
連中は基本的に「難しい言語使ってる僕すごい」であり、
プログラミング言語の優劣を自己で判断する能力はないので、
何か新しく「凄いけど難しい！！！」とされる言語が出てきたら勝手に移住する。
だから、対策としては、何でもいいから新しい言語を作って適当に吹聴する事だね。
そうすればRust界隈も浄化される。

なお一時期はC++の連中の選民思想が超絶にウザかったが、これが今はRustになってるだけ。
ならC++スレはどうなったかと思って見てみたら、完全にお馬鹿の溜まり場になってたわ…。
まあ○○言語を使ってれば賢いって事にはならないので、当然でもあるのだが。

**デフォルトの名無しさん** · 2022/04/10(日) 15:13:47.07

ちんちんシュッ！シュッ！シュッ！

**デフォルトの名無しさん** · 2022/04/10(日) 15:18:10.17

完結に喋れない病気直ってないの？

**デフォルトの名無しさん** · 2022/04/10(日) 15:22:51.62

>>783
はっきり言えば、誰も「新言語」なんて必要としてないだろ。
欲しがってるのは、各自が気に入った言語での、
・バグを自動的に検出してくれるゴリゴリのリンター
・Cと同速で動く爆速環境
であって。

はっきり言ってRust信者の「Rustは書きやすい！！！」すら方便で、連中は
・リントが強く、データ競合が起きない
・寿命管理ががっちりしてるので、GCなくてもメモリリークが発生しにくい
事がRustの買いだと言ってるわけだが、
Rust信者すら、信者になる前に使ってた言語でこれらを満たす状況になってたら、そのままその言語を使い続けてるだろ。

寿命管理はGCが爆速なら（リアルタイム系以外は）誰も文句言わないのでこれで決まり。
データ競合バグは言う程問題でもないが、
これをどうしても避けたいのなら、JSのように基本シングルスレッドにしてしまえば根本解決する。
だからこの2点が必要とされてるのなら、JSの爆速環境があれば済む話。

JSにおいて速度の枷は動的型であり、だからこそTSでアノテートだが、JSに変換して実行してる現在では速度メリットはない。
だからV8(JSエンジン）がTSをそのまま食うようになれば、解決する。期待値としては多分現行の倍速程度にはなる。
あるいはBlazor(WebAsembly)がこれに近い状況。

ただし世界が望んでるのは、Python/RubyがとりあえずJS並に高速化する事だね。
ただ俺はPython/Ruby連中が高速化についてあまり真剣に取り組んでない（ように見える）のは意味が分からないのだが。
Matzも新言語作るんだーとか言ってたと思ったが、あんたがやるべきなのはRubyの高速化でしょうが、と。

**デフォルトの名無しさん** · 2022/04/10(日) 15:22:54.24

>>811
なんか最初の頃はMozillaの印象強かったよねえ

**デフォルトの名無しさん** · 2022/04/10(日) 15:24:50.68

>>805
そもそも5ch以外で信者っぽい人見たことないけどな
リアルでもTwitterあたりでもみんな複数言語使ってる中の一つにRustもあるってだけ

**デフォルトの名無しさん** · 2022/04/10(日) 15:33:46.76

>>815
ruby3はruby2の3倍高速化というお題目でそれなりの成果を出した訳だけどそれでもまだまだ足りないと言うのね

スクリプト言語で高速化するためにはボトルネック箇所をCなりで置き換えるのが普通
JSはブラウザで動かさなければならないという制約上言語自体を高速化する必要があり
ブラウザベンダー大資本がつぎ込まれた結果高速化した
前提がかなり異なるから同じことがruby/pythonに起こることはないのではないか

**デフォルトの名無しさん** · 2022/04/10(日) 15:56:47.79

>>818
> ruby3はruby2の3倍高速化というお題目でそれなりの成果を出した訳だけど
それよく勘違いされてるが、
3倍になった『部分がある』だけで、全体が3倍になったわけではないよ。
(これは公式でもこう『追加』アナウンスされてたはず）

俺が思う割と正当な比較はこれだが、
> https://1.bp.blogspot.com/-rfuoTnmJM5Q/X41w-eFt9QI/AAAAAAAAJcc/nFNdlKqfs6sRKna-85JxpmzrAe1bw0tGQCLcBGAsYHQ/s0/3730357d-results-energy-time-and-memory-usage-screenshot-from-research-paper.png
> https://okuranagaimo.blogspot.com/2020/10/blog-post_19.html
「Pythonは100倍以上遅いぞ」なんて言われる事も多く、
C比だとJSで5-6、Python/Rubyは80-100程度だと思ってる。
だからまずはJS並にするだけで16倍程度は高速化するわけであり、CやCythonは嫌だ…な連中には十分だと思うんだよ。
Rubyも16倍のクライアントを捌けるようになれば鯖代も半分以下に出来るだろうし。
(そもそもコードが汚れるのは無理に速度チューニングしたコードにするからであり、
馬鹿みたいなコードでも速く動くのならコードも綺麗に保てるし）

> 前提がかなり異なるから同じことがruby/pythonに起こることはないのではないか
逆に言えば、金さえつぎ込めば改善出来るわけで、
改善項目とそれに要する金額をずらっと羅列して、クラファンで資金が付いたところから実行、
十分な結果で採り入れられたらそいつがその資金を給料として獲得、とかいう方式にすれば、
割とすぐにでも行けるんじゃないかと思うんだけどな。

**デフォルトの名無しさん** · 2022/04/10(日) 15:58:01.34

>>815
> JSにおいて速度の枷は動的型であり、だからこそTSでアノテートだが

違うよ
ブラウザがTSをそのまま食えるようにするというのは開発者側でトランスパイルする必要性を無くすだけで実行速度の改善を目的としたものではないよ
ていうかその方向性はasm.jsとかPNaClみたいな先駆者がいて彼らの現状の到達点がWASMという経緯があるよ

**デフォルトの名無しさん** · 2022/04/10(日) 16:21:05.00

>>820
> 実行速度の改善を目的としたものではないよ
それは知ってるが、JSの速度改善には型の固定（静的型)が必要だから、「『Any無しの』TSを食わせる」必要があるんだよ。
その前段階として「TSを食わせる」が必要なわけ。
（実際やろうとしてるかは知らん)

asm.jsはお世辞にもいいものとは思えない。
あれもJSエンジン内で型を固定出来てるわけではないし。（ただJITだとあれでも行けるのかな？)

PNaClは知らない。けど削除されちゃったよね。
ただwiki見る限りWebAssemblyでいいから削除、みたいな感じのようだが。

「Any無しのTSを食わせる」位ならBlazorでWebAssemblyしろってのはその通りだが。
だからWASIも方向性としては有ってて、最高に上手く行けばJVMを置き換える事になるかもしれんけど。
(Java言語そのものは死なず、JavaからWebAssemblyを吐くようになるだけだが）

**デフォルトの名無しさん** · 2022/04/10(日) 16:49:31.19

知らなかったくせに

**デフォルトの名無しさん** · 2022/04/10(日) 16:53:31.25

毎日Rust攻撃してる人、暇なんかな。
別の事に時間使えはいいのに、と他人事ながら思うよ。

**デフォルトの名無しさん** · 2022/04/10(日) 16:57:09.68

AssemblyScript や Static TypeScript の話をどこかで聞きかじったのが混ざってるんだと思う

**デフォルトの名無しさん** · 2022/04/10(日) 17:16:31.79

Ruby はJIT で、C コードをコンパイルするけど、
1万ぐらいコンパイルしても、Rails みたいにすべての関数が平均的に呼ばれるアプリでは、
1割ぐらいしか速くならない

行列・ベクトル演算みたいに、CPU セントリックな処理では速くなるから、
Python, Julia では、JITの効果は大きいかも

I/O を使わずに、少ない数値を何回も使って、組合せ演算するようなたぐい

YouTube で有名な、雑食系エンジニア・KENTA が言ってたけど、

Scala が滅んだのは、
食えないから、コミュニティーに居座る無職のベテが、新規を叩きまくるから。
食えない所には、変な香具師しか残らない

Scala, PHP は、KENTAがオワコン認定したから、一気に滅んだ

結局、Laravel, Django, Node.js などは、競争でRails に勝てなかったから。
だから、未経験者のキャリアパスは、Rails → Go だけと宣言した

**デフォルトの名無しさん** · 2022/04/10(日) 17:19:51.97

>>794
ライナスは理論家じゃなくて実務家

ライナスはUNIXクローンが動かないと意味がないからとりあえずソースを書いて動かそう派で
タネンバウムは理論上マイクロカーネルが有利だからマイクロにしろと言って噛みついて来た理論家

**デフォルトの名無しさん** · 2022/04/10(日) 17:37:12.48

Blitz.js は、React 版・Ruby on Rails。
Cake PHP みたいなものか？

Type Script なら、Rubyよりも型安全だけど、
モデルが、RailsのActive Record よりも弱いらしい

**デフォルトの名無しさん** · 2022/04/10(日) 17:53:45.64

>>819
"それなりの成果" ってわざわざ書いた意図をくみ取って欲しかったな

クラファンとかアイディア出すのは良いんだけど
具体的にどういう課題があって改善したがってるのかが分かんないんだよね
Cで書いたモジュールと置き換えるのじゃだめなの？

**デフォルトの名無しさん** · 2022/04/10(日) 18:07:58.32

定期的にKENTAさんを引用している人、もしリスナーさんだったらやめたほうが良いですよ？

分析は正しいかもしれないが、イメージを悪くして迷惑をかける可能性だってあるし、
本人が見ていないところに、荒らしにも見える行為はマナー上良くないですからね？

**デフォルトの名無しさん** · 2022/04/10(日) 18:20:31.55

Youtubeで有名な、とかいう主観に満ちた枕詞をつけてるあたり権威付けして威を借りようとでも思ってるんでしょ

たかがYouTuberに言語の勢いを減らせるほどの影響力ないでしょ

**デフォルトの名無しさん** · 2022/04/10(日) 18:27:03.03

YouTuberの名前を出されても中学生が書いてるのかなとしか思わんしマジでそんなやつどうでもいい
偉そうに技術を語るなら、超有名OSSプロダクトをいくつも作ってるとか、GAFAでアーキテクトをやってるとかぐらいの実績がほしい

**825** · 2022/04/10(日) 18:58:00.76

KENTA の有料のRuby on Rails サロンは、日本6位の3千人。
日本1位は、キングコング西野の数万人

vue.js 日本ユーザーグループが、3千人

単独のフレームワークの有料サロンで3千人は、あり得ない！
世界的にも断トツじゃないか？

実際に、外人から驚嘆されている。
転職で未経験者が、こんなすごいポートフォリオを持ってくるのは、あり得ないって

これが日本人が発明した塾・予備校。虎の穴

でも、これほどすごくても、日本人の年収が先進国の1/3 なのも、あり得ないけどw
失われた30年。
財務省のせいで、世界中で唯一、GDP が伸びなかった国

**デフォルトの名無しさん** · 2022/04/10(日) 19:10:26.93

KENTAガイジNGしてないひとまだいたんだ

**デフォルトの名無しさん** · 2022/04/10(日) 19:35:37.31

>>821
GC対応は悲観的
様々な言語で効率化が異なる手法のGCのためにWebAssemblyに共通仕様のGCを作るのは不可能という結論になった
だから当面はWebAssemblyにGCは載らずいずれGC対応しても各GC言語はそのまま動かず特別仕様に制限される

**デフォルトの名無しさん** · 2022/04/10(日) 19:50:06.06

>>834
JVM on WASMみたいなアプローチならどうじゃろ？

**デフォルトの名無しさん** · 2022/04/10(日) 20:10:14.95

>ただ、今となってはマイクロカーネルにすべきだし、徐々にでも変更していくべきだと思うよ。
>今でもモノリシックの利点を説いているのは、後付のように思える。
そう思ってるなら思ってる奴がフォークするなりしてやればいいんじゃね？
そのためのフリーソフトなんだから。でも結局やらんだろうがな。

**デフォルトの名無しさん** · 2022/04/10(日) 20:30:35.41

オンラインサロンの会員数を出したり、外人から驚嘆されてるとかいう眉唾情報を出したり、教祖が教祖なら信者も信者だな

**デフォルトの名無しさん** · 2022/04/10(日) 20:49:57.25

>>828
> 具体的にどういう課題があって改善したがってるのかが分かんないんだよね
> Cで書いたモジュールと置き換えるのじゃだめなの？
この主語がRubyではなく、Rubyランタイムだと仮定すると、以下。

Rubyについて文句言われてるのは速度だけだろ。
エコシステムはPythonには劣るが、基本的には「それ、Rubyでも出来るよ」程度にはなってるんだろ。
なら後は人数だけで、新規を呼び込むにはPythonよりも圧倒的に速い速度だよ。
手法は速くなるのなら何でもいい。

改善箇所は、まずはプロファイラ付きのランタイムを配ってデータを集めて、
使用頻度の高さ＊コード見ての改善見積もり＝高速化効果見積もりと、その費用の一覧を作って、
ついでにそのプロファイラー付きランタイムでの使用実績も掛けて各社向けに
「御社のRubyプログラムは○○円で△%高速化」の一覧に差し替えて、クレクレ君するしかないね。
長期的に見れば自前でゴリゴリチューニングするよりランタイムが速くなってくれた方が楽だから、
10社くらい束ねればわりと行けるのではないかと。
あくまで、各社が「ここを速くしてくれ」として費用を出してきた場所を改善だ。
ユーザー無視して高速化しても外れるだろうし。

**デフォルトの名無しさん** · 2022/04/10(日) 20:50:32.86

>>828
> 具体的にどういう課題があって改善したがってるのかが分かんないんだよね
> Cで書いたモジュールと置き換えるのじゃだめなの？
主語がRubyだと仮定して、
Rubyのどこが不味いのか、速度が欲しければCでdllを用意しろ、という意味なら、死ねと言われるだろうよ。

Rubyは根本の戦略が間違ってる。
Pythonとダダ被りなので、このままだと、シェア的に見て死ぬのはRubyだと確定してる。
なら、Pythonと正面からやり合うのではなく、違う道を模索しないといけない。
具体的には互換性無視での先行だね。そして「学生が学ぶならRuby」という地位を確立してしまう事だ。
2012位にRubyカンファレンスでMatzが「互換性を重視しました！」
と言って沸いたという記事があったはずだが、あれが完全なる間違い。
互換性重視と言うと聞こえはいいが、これは「新規のコードよりも既存のコードを優遇する」という事であり、
これからコードを書く/学ぶ連中にとっては全く意味無い。それよりは、最新の書き方を試せる方がいい。

どの言語も段々と互換性を重視するしかなくなるので、仕様改訂出来ず、段々と古くさくなっていく。
Pythonなんて既にそうなってるだろ。
なら、「常に最新の書き方が出来ます！」をキープして、新規学習者の登竜門的な地位を確立するしかない。
これには、
・バージョン管理で仕様を年に一度は大幅改訂。新しい記法を貪欲に採り入れ、古い記法はばっさり捨てる。
・古いバーションの記述でも動きはするように、関数単位でのパースバージョン指定が出来るようにする。
・学生にとって入社～3年目程度に必要な概念は全て学習出来るよう、
　他言語でのプロポーザルの有力案は全て採り入れる。（高速である必要はなく、動けばいい）
とかで、とにかく「プログラミングの学習にはRuby!」という地位を確立しないと、
Pythonに食われて死ぬ未来しかないだろ。

で、RoRは仕様を改訂/捨てまくりだと聞いてるけど、
あれが正しいよ。というか、何かしらPython(や他言語)と差別化しないと死ぬだけ。

**デフォルトの名無しさん** · 2022/04/10(日) 20:57:15.28

学生にRuby…？
専門学校ならそれでいいかもしれんけど

**デフォルトの名無しさん** · 2022/04/10(日) 20:58:47.74

>>834
> 様々な言語で効率化が異なる手法のGCのためにWebAssemblyに共通仕様のGCを作るのは不可能という結論になった
そりゃそうかもしれんが、これはWebAssemblyの連中が真面目すぎるだけ。

Python/Ruby/JS/TSを使ってる連中が、GC方式なんて気にしてるわけねえだろ。
GC出来てれば何でもいいんだよ。（循環参照でもGC出来るのは必須で）

やりたくないから理由を適当にでっち上げたようにしか見えないね。
（オープンソースならそんなもんだが）

**デフォルトの名無しさん** · 2022/04/10(日) 21:10:10.44

>>836
wikiによるとArchとDebianでやってみた奴はいるらしい。
> 2012年現在、Machベースの GNU Hurd も機能しており、それを採用した Arch Linux と Debian のテスト版も進行中である。
> https://ja.wikipedia.org/wiki/%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB

ただまあ、マイクロカーネルにしても、
ドライバ周りのコードを（カーネル開発人員が）自前で書かないといけないので、
最終的に書かなければならない合計コードサイズ自体は大して変わらず、
カーネルで落ちるかユーザーモードでバグるかの違いで、大して意味はないのかも？
ならわざわざやろうと思わないのも道理だ。

**デフォルトの名無しさん** · 2022/04/10(日) 21:15:37.68

GNU Hurd ダメなやつだから。

**デフォルトの名無しさん** · 2022/04/10(日) 21:24:19.23

この聞きかじりで広く明後日の知識を披露してる人は
前暴れてた人と同じなのか違うのか

**デフォルトの名無しさん** · 2022/04/10(日) 21:28:26.61

循環参照とか参照カウント・世代別GC とか、
動的言語で、そんな事を知っている香具師はいない

唯一、Ruby には「Rubyのしくみ」と言う、
Ruby1.9の仮想マシンの本があるから、

Cookpad の笹田耕一が、どういうようにRuby VM を作ったかと言うのは、
日本人だけは知っている

**デフォルトの名無しさん** · 2022/04/10(日) 21:44:41.86

香具師→やつ
訂正しとくわ

**デフォルトの名無しさん** · 2022/04/10(日) 21:54:26.09

>>832
すまん、コレ見るとやっぱジャップランド土人ってガイジの集団じゃないか？
中国に併合してもらって考えを悔い改めた方がいいのでは？

**デフォルトの名無しさん** · 2022/04/10(日) 21:55:02.28

V8高速化するのは兆円越えるような凄まじい金銭が投入されてるが、pythonの組織など億から10億程度、rubyはその1/5行くかどうかなんだから張り合える訳がない。

**デフォルトの名無しさん** · 2022/04/10(日) 22:10:35.68

他言語のエンジンをrustで作り出したら本格的

今のところjs/tsのエンジンであるdenoのみか

**デフォルトの名無しさん** · 2022/04/10(日) 22:50:17.14

GOとか早くも終わりそうな感じだけど実際どうなの？
API作るには良いかと思った事もあったけどわざわざ採用する程でもないんだよねぇ

**デフォルトの名無しさん** · 2022/04/10(日) 22:54:33.39

>>849
RustによるPython実装のver0.1が公開
https://egg.5ch.net/test/read.cgi/river/1627101447/

Rython（ライソン）は、Rust言語によりPythonを実装することを目的として開発されたプログラミング言語である。

**デフォルトの名無しさん** · 2022/04/10(日) 22:54:54.30

サーバー用途以外だったらワークフローエンジンとかCIツール周りなんかは向いてそうな気はする。

**デフォルトの名無しさん** · 2022/04/10(日) 22:55:50.40

>>848
いくらなんでもそんなに金かけてるわけないだろ
V8の開発をする専門エンジニアをフルタイム数万人規模で働かせるっていうの？
ちなみに任天堂やソフトバンクの時価総額が7兆円ぐらいな

**デフォルトの名無しさん** · 2022/04/10(日) 23:46:53.01

>>850
Goはある範囲内なら簡潔に分かりやすく書けていいよ
今はRustでもGoと同様のプログラミング方法で簡潔に分かりやすく書けるようになったため私はRustへ移った
理由はRustの方が速くて他にも広く適用できるため

**デフォルトの名無しさん** · 2022/04/10(日) 23:58:13.16

>>835
もちろんそれでも他でも動く
C#によるBlazorも重くて遅くてデカいけど動いている
焦点は効率の問題

**デフォルトの名無しさん** · 2022/04/11(月) 00:50:05.90

>>838
いや、だから一般論じゃなくてあなたは何に困ってるのかを聞いてるの
ただ漠然と速度が遅いと言われるだけでは分からんのよ

**デフォルトの名無しさん** · 2022/04/11(月) 01:12:00.13

使ってないので何も困ってませんというオチ

**デフォルトの名無しさん** · 2022/04/11(月) 07:03:18.35

抽象論で済ませたいという輩はそもそもプログラム向いてないよ。

**デフォルトの名無しさん** · 2022/04/11(月) 07:06:48.33

だってプログラム書けないだもん

**デフォルトの名無しさん** · 2022/04/12(火) 13:44:31.10

速度に不満があるならJulia使おうぜ
ちなみに俺はプロット表示出来なくて、すぐ必要なわけでもないし面倒になって環境構築の段階で挫折した

**デフォルトの名無しさん** · 2022/04/12(火) 20:19:42.59

所詮道具は道具だ
個人的に深掘りしたいライブラリ整備したい言語と
働くために使う言語は別だと割り切ればだいたい幸せだよ

まあそれで何個も使ってるとしんどいんだけどな

**デフォルトの名無しさん** · 2022/04/12(火) 20:24:08.33

>851 さすがにむせた

**デフォルトの名無しさん** · 2022/04/13(水) 02:09:35.75

流れに身を任せれば良い。幸福感が得られる。
重要な決定に関与しないので、責任感に追われることは無い。
それも生き方。何の間違いもない。

**デフォルトの名無しさん** · 2022/04/13(水) 09:38:49.99

このようにして奴隷は誕生するのである。

**デフォルトの名無しさん** · 2022/04/13(水) 14:31:42.18

プログラミング言語の人気ランキング、順位変動は縮小傾向にある――RedMonkが調査
https://atmarkit.itmedia.co.jp/ait/articles/2204/13/news040.html

**デフォルトの名無しさん** · 2022/04/13(水) 16:28:48.93

Nimだけトップ20圏外か

**デフォルトの名無しさん** · 2022/04/13(水) 17:49:20.83

うぅ、、Nimさん（；；）

**デフォルトの名無しさん** · 2022/04/13(水) 19:36:47.36

考えてみたらnimなんてQitaか5chでしか聞かなかったもんな。
声の大きい人のおかげでGoやRustと同格っぽく錯覚してたけど、実際は>>865のように
Crystalあたりが比較対象になるマイナー言語だったんだよな。

**デフォルトの名無しさん** · 2022/04/13(水) 19:42:01.28

メジャーかどうかがキミらの関心事なん？

**デフォルトの名無しさん** · 2022/04/13(水) 19:49:54.89

>>865
16.Go
17.Powershell
と並べられるとGoが急にしょぼく見えてきた

**デフォルトの名無しさん** · 2022/04/13(水) 20:39:44.52

Zigがグラフに入ってない気がするけどなんでだろ？
Vでも入ってるのに

**デフォルトの名無しさん** · 2022/04/13(水) 20:55:30.92

Zは今は駄目だ

**デフォルトの名無しさん** · 2022/04/13(水) 20:59:16.38

型無し糞言語を勧めてくる屑どもは市中引き回しの上打ち首に処せ

**デフォルトの名無しさん** · 2022/04/13(水) 21:55:10.23

>>865(整理)
1 JavaScript
2 Python
3 Java
4 PHP
5 CSS
5 C#
7 C++
8 TypeScript
9 Ruby
10 C
11 Swift
12 R
13 Objective-C
14 Shell
14 Scala
16 Go
17 PowerShell
18 Kotlin
19 Rust
19 Dart

**デフォルトの名無しさん** · 2022/04/13(水) 21:56:44.53

Rが意外と高ランクなのはなぜだろう
Stack Overflowの質問数が多いから学生が課題で使うなどしてるのかな

**デフォルトの名無しさん** · 2022/04/13(水) 22:04:41.58

>>874
このスレにとっての整理というのはこういうことだろ
8 TypeScript
11 Swift
16 Go
18 Kotlin
19 Rust

**デフォルトの名無しさん** · 2022/04/13(水) 22:07:12.36

>>865
この相関表だとJuliaがここにスレタイに入ってないのはおかしい、Nimも外してJVMで動いてる競合が全くしないKotlinも外せよ。
入れるならコンパイルできるHaskell、Erlang、Dあたりだろう。TypeScriptは残しても良いけど、ここの人たちがGCだのなんだの
ムーブセマンティックがどうの言うてる次世代言語のような先進性なんてほとんど無いぜ？
このスレにNimがあるのはえらい迷惑、RustやC++をまじめにやってる人も迷惑だと思うけど、あんたら好きそうだから隔離としては
ええんちゃうか？

**デフォルトの名無しさん** · 2022/04/13(水) 22:10:18.46

こないだここで話題に出てたFlixはいいセンいってると思うんだけどな

**デフォルトの名無しさん** · 2022/04/13(水) 22:11:15.80

そもそもHaskellが入ってないのがおかしい

**デフォルトの名無しさん** · 2022/04/13(水) 22:20:19.72

「次世代言語」ってどういう意味よ
ちなみにHaskellはJavaやPythonなんかよりも古い言語だ

**デフォルトの名無しさん** · 2022/04/13(水) 22:35:07.15

現世代じゃなくて次世代ってことは流行ってる言語はだめか
Nim以外スレタイから消した方が良い？

**デフォルトの名無しさん** · 2022/04/13(水) 22:48:55.23

実用プロダクトがバンバン出て
求人も当たり前に見つかるのは
次世代感はあまり無いかも

**デフォルトの名無しさん** · 2022/04/13(水) 23:05:23.43

>>880
Haskellは98とか2010とかいろいろ修正機能追加してるので、C11とかC++20とかそういう立場でしょ。次世代ってことは現世代で
問題があるか書き難いか、表現しずらい、誤解を生むような記述が解消されてたり、コンピューターサイエンス屋が無理やり入れたに
機能なんかを削除したり。あとは実行上のメモリー管理や分散処理が簡単になるとか

**デフォルトの名無しさん** · 2022/04/13(水) 23:07:38.62

それはNimが現世代言語になれなかっただけでは？

**デフォルトの名無しさん** · 2022/04/13(水) 23:26:59.24

>>880
無駄が少なく記述できる（冗長・簡潔）とか、新しい概念が追加されている（Structured programming→OOPS)なんかもそう。
今まではアセンブラや行番号記述の言語（例えばN88BASIC）などから構造化プログラミングが可能になり、C++やJavaでOOPSが唱えられていたけどRustで言えば多態はクレートになるが、クレートより先の進化が無いとは限らない。
またErlangやHaskellにあるガード構文もパラダイムを変えるようなものではなく、あくまでも制限なので構文上で次世代というには、多くの言語が似たような構文を導入し始めてる。
例えばasync/awaitなど非同期構文などはまさにそれ

**デフォルトの名無しさん** · 2022/04/13(水) 23:42:53.90

>>883
メモリー管理というか、どんどん複雑大規模化するソフトに対するメモリーに起因するバグが統計的に少なく記述できる「次世代言語」

**デフォルトの名無しさん** · 2022/04/14(木) 11:35:33.89

Haskelｌはメインの言語としては狭すぎる　　　　　　　　　　　　　　　　　
特殊な分野向け

というがCSSがランキングにあがってるんだよね

**デフォルトの名無しさん** · 2022/04/14(木) 12:22:45.14

ScalaがGoやKotlin,Rustより上なのか
Scala3になっていろいろ改善されてるみたいだし、まだ復活の目ある？

**デフォルトの名無しさん** · 2022/04/14(木) 12:46:43.91

ない
Scalaはビッグデータ分野のOSSでの採用が多かったから既存コードベースだけは無駄にデカい
そんな状況で非互換メジャーアップデートしたらどうなるかわかるだろ？

**デフォルトの名無しさん** · 2022/04/14(木) 17:49:33.35

なるほどPython3

**デフォルトの名無しさん** · 2022/04/14(木) 18:41:17.09

本当の意味での次世代って存在するのかな？

ロシアが威嚇のために日本海に向けてミサイル撃ってるけど
他の国にも威嚇してエスカレートして核戦争始まって文明が滅ぶかもしれないｗ

**デフォルトの名無しさん** · 2022/04/14(木) 20:30:53.20

人類がそこまでの存在だったってだけの話よ

**デフォルトの名無しさん** · 2022/04/14(木) 21:31:28.88

次世代言語って、今流行してる言語を置き換えうる別の言語ってことじゃないの？
新しい概念やらが採用されてるかどうかは関係なく、政治的な理由で決まることもある気がする
まあそういうのよりは、新しい概念が採り入れられてる言語について語ったほうが楽しいだろうけど

**デフォルトの名無しさん** · 2022/04/14(木) 21:39:45.95

Rustは次世代を担う方の素養はないと思う。C->C++->Rustと進んでこないとRustの目指している世界観が理解できないと思うのに、コードは命名規則に_を使うのか思えば大文字小文字でFn/fnで意味付けをしてたり、’staticみたいなコメント？と思える雑な定義が多い。理解してない子が勢いで作ったの？って感じがするので広める前に整理が必要だよね。ISOをとったらどうかな？

**デフォルトの名無しさん** · 2022/04/14(木) 21:50:00.79

rust嫌いなのはよくわかったけど理由付けがしょーもなさすぎる

**デフォルトの名無しさん** · 2022/04/14(木) 21:52:41.11

>>894
JavaScript→TypeScript→Rust と普通にステップアップしたよ
とても使いやすいよ

**デフォルトの名無しさん** · 2022/04/14(木) 23:13:24.53

Cすっ飛ばしてRust来たけど気に入ってるよ

**デフォルトの名無しさん** · 2022/04/14(木) 23:45:37.43

Rustは十分に抽象化されているため
Cの生ポインタの知識なく効率よく使える
むしろ生ポインタは安全でないため足を引っ張る知識

**デフォルトの名無しさん** · 2022/04/15(金) 00:26:17.76

なにいってんだこいつ

**デフォルトの名無しさん** · 2022/04/15(金) 01:12:09.01

バカが安易に生ポインタ書き込みしないようにunsafeしないと使えないようになってるので大丈夫
99%以上の用途ではそんな低レベルなものは必要とせずとも大丈夫なようにRustはできている
ほとんどの人は実験目的以外で用いることがないだろう

**デフォルトの名無しさん** · 2022/04/15(金) 05:59:27.92

unsafeがあるから安心安全

**デフォルトの名無しさん** · 2022/04/15(金) 07:12:23.73

生ポインタが分からぬのに使えてるとか笑

**デフォルトの名無しさん** · 2022/04/15(金) 08:32:18.47

CもC++もRustも使えるが
確かにRustでは他の多くの言語と同じく生ポインタを使って読み書きすることはないしその概念も不要だな
普通の言語ならばそのような抽象度の低いものを持ち出さずともプログラミングできるべきなのだろう

**デフォルトの名無しさん** · 2022/04/15(金) 08:48:44.24

生ポインタとかエッチ