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

**デフォルトの名無しさん** · 2022/08/05(金) 08:26:38.87

スレタイ以外の言語もok

前スレ
https://mevius.5ch.net/test/read.cgi/tech/1655771266/

**デフォルトの名無しさん** · 2022/08/27(土) 23:38:25.67

安全なメモリ管理ってｗ
単に関数でnewしたものを保存してスコープが切れたら解放するだけでしょｗ
それC++でFile file;のように宣言したのと概ね同じなんじゃね？ｗ

**デフォルトの名無しさん** · 2022/08/27(土) 23:43:33.94

Rustはオワコンだからあんま使いたくないな

**デフォルトの名無しさん** · 2022/08/27(土) 23:45:55.57

>>882
まずC++がメモリ管理バグを生産し続けている仕組みを学習すべきだな
それまでこのスレに出入り禁止

**デフォルトの名無しさん** · 2022/08/28(日) 00:56:35.98

C++にはtemplate反対派もいるから
バッファ<T>の代わりにtemplateを使わないやつを再発明することで
オーバーランも再発し続ける

**デフォルトの名無しさん** · 2022/08/28(日) 05:26:11.72

>>881
Rustの解説にもある通りRAIIがベースで、自動変数の応用例だけどな。

C++は元々cをコンパイルできるという大原則があって、その原則からスマートポインタ強制とかは行っていない。Rustはそのあたりのしがらみを捨てているんだからああなるだろ。
RustもC++の複雑さに加えてHaskellの難しさも取り込んでいるから、絶壁の学習曲線問題は悪化している。置き換えが進むのはc/c++の一部の領域のみで、Javaの領域とか食えないと思うわ。

**デフォルトの名無しさん** · 2022/08/28(日) 06:06:08.65

>>886
その件でRAIIや自動変数と言い出してる時点で把握不足
それは以下の非常に大雑把に分けた3段階のうちの最初の(1)の部分でしかない

(1) RAIIとデストラクタ
(2) 所有権とその移動
(3) 借用とライフタイム

>>882も(1)止まり
>>880は(2)止まり
(1)と(2)だけではダングリングポインタの発生を防げない

**デフォルトの名無しさん** · 2022/08/28(日) 07:28:26.48

>>886
Rustの難しさがC++の難しさを引き継いでいるのかは疑問に少し疑問だし、Haskellの難しさに至っては全く受け継いでないと思うぞ
型に対する要求は小さいし、関数が純粋であることも求めてないし、遅延評価をベースにしてもいない

**デフォルトの名無しさん** · 2022/08/28(日) 10:48:45.36

サブスクやリボ払いじゃないんだから
よく似た難しさに10回出くわしたら1回あたりのコストは1/10になるんだよ

まあそうなると「コスト」とは何かを定義するのが極めて困難になるんだけど

**デフォルトの名無しさん** · 2022/08/28(日) 12:11:47.01

RustやC++やHaskellの難しいポイントってそれぞれ具体的にどういうところを指してるの？
単に難しさと言われても人によってイメージするもの違うのでは

**デフォルトの名無しさん** · 2022/08/28(日) 12:52:57.69

Haskellの難しさは対象ドメインの一般的理解よりも一段二段高い抽象度を意識したプログラミングが必要なところ

**デフォルトの名無しさん** · 2022/08/28(日) 13:12:40.64

Lisp世代とErlang世代の間に暗黒時代がある
モナドと型推論のプロトタイプもその時代にある
検索しても多分辿り着けないのは検索エンジンが原因でしょ

**デフォルトの名無しさん** · 2022/08/28(日) 13:38:45.23

トレイトとライフタイムが難しい

**デフォルトの名無しさん** · 2022/08/28(日) 14:28:30.61

>>893
トレイトはシンプルで分かりやすいけど
クラスが非常に難しい

例えば複数の型に共通する機能性質とメソッド群を用意したいことはプログラミングでよく発生する場合
トレイトだと複数の型々に関係なく独立してそのまま用意して各型に実装するだけだけでいいけど

クラスだと継承でやるにはその型自身に継承しなきゃいけなくて多重継承になったり継承ピラミッドが複雑化
あるいは継承は破綻するからメソッドを増やす別の方法を拡張して使い何のためにクラスを使っているのか本末転倒になる
結局クラスと型が分離できていないことにも問題が多い

Rustでは型とトレイトという二つの直交した概念だけで全てが済むからシンプルで分かりやすい
クラスも継承もないのはRustだけでなくGoでもそうだけど今までクラスと継承で遠回りしてきたプログラミング言語の到達点かなと思う

**デフォルトの名無しさん** · 2022/08/28(日) 15:06:53.82

>>894
インターフェースも知らんのか？

**デフォルトの名無しさん** · 2022/08/28(日) 15:17:26.17

トレイトも型なのに何言ってんだこいつw

**デフォルトの名無しさん** · 2022/08/28(日) 15:26:53.46

>>895
Linusを怒らせたのはそういう所だな
C++を知っていても使わない自由があると言いながら
実際に使わない者が現れれば「知らんのか？」とミスリードしてくる

**デフォルトの名無しさん** · 2022/08/28(日) 15:34:27.90

>>897
C++にはインターフェースが無いことも知らんのか？
そりゃリーナスも怒るわw

**デフォルトの名無しさん** · 2022/08/28(日) 15:39:21.95

C++も素のままならまだいいのだが
やっぱり癌はSTLなどのライブラリや例外だな
内部で勝手に動的にメモリ確保したりとかするなよってｗ

**デフォルトの名無しさん** · 2022/08/28(日) 15:57:21.77

>>895
そのインターフェース等を批判してることを読み取れないのか？
クラスとインターフェースの2種類が必要となってしまっている
トレイトだけで済むRustがシンプルで分かりやすいことを認めたわけだな

**デフォルトの名無しさん** · 2022/08/28(日) 16:07:51.94

分かってなさそう

**デフォルトの名無しさん** · 2022/08/28(日) 16:15:35.13

>>896
トレイトは型ではない
例えばCopyトレイトやDisplayトレイトなどの既存のものから自作のものまで自由にトレイトを作れるが
それらトレイトはもちろん型ではなく機能や性質を示すだけである
ある型を作ったときにそれら任意のトレイトを実装するか否かは自由であり
あるトレイトを作ったときにどの型に対して実装するか否かも自由である

**デフォルトの名無しさん** · 2022/08/28(日) 16:21:02.87

スパゲティーは苦手だからCarbonに期待

**デフォルトの名無しさん** · 2022/08/28(日) 16:22:01.22

Rustでは型とトレイトという二つの直交した概念だけで全てが済むからシンプルで分かりやすい

クラスとインターフェースの2種類が必要となってしまっている

ほーん

**デフォルトの名無しさん** · 2022/08/28(日) 16:33:32.30

つまりクラスとか継承とかそんな複雑なものは要らないよな
型とインターフェースだけがあればいい
Goは実際にそうなっている

**デフォルトの名無しさん** · 2022/08/28(日) 16:33:43.64

>>893
ライフタイム以前よりはかなり簡単になったけどまだ引っかかりどころは残ってる感じ？

**デフォルトの名無しさん** · 2022/08/28(日) 16:44:44.59

>>900
Rustの公式リファレンスにもトレイトはインターフェースって書いてあるんですがww

**デフォルトの名無しさん** · 2022/08/28(日) 16:48:30.90

>>900
Rustはstructとimplとtraitの3種類が必要としまってますねwww

**デフォルトの名無しさん** · 2022/08/28(日) 16:52:01.49

>>907
そうだよ
インターフェース自体を問題にはしていない
クラスに加えて結局インターフェース等も必要としている状態を批判している
それならばGoやRustのように最初からクラスは無い方がシンプル

**デフォルトの名無しさん** · 2022/08/28(日) 17:01:29.35

C++20でconceptというのがあるんだな
これは知らんかったわ
C++も大変だねー

**デフォルトの名無しさん** · 2022/08/28(日) 17:27:57.92

rust は使ったことないがエラーメッセージが c++ より親切と聞いておる。

**デフォルトの名無しさん** · 2022/08/28(日) 17:42:22.67

ここに書き込んでるヤツのせいで本当にrustが嫌いになったわ

**デフォルトの名無しさん** · 2022/08/28(日) 17:47:23.10

>>912
他人の意見ばかり気にしてないで、自分で判断したらいいのに

**デフォルトの名無しさん** · 2022/08/28(日) 18:01:38.50

>>897
別にリーナス怒ってはないやろ
mallocで失敗したくらいで強制終了するしかないポンコツは流石に使えんわって言っただけで

**デフォルトの名無しさん** · 2022/08/28(日) 18:04:31.62

>>911
C++と言うより原理的にテンプレート絡みのエラーメッセージはわかりにくいわな
まあそこは言語組込のrustに軍配上げるしかない

**デフォルトの名無しさん** · 2022/08/28(日) 18:12:18.75

> クラスとインターフェースの2種類が必要となってしまっている

class に加えて interface があるのは救いなんだがｗ
実装ではなくてインタフェースに対してプログラミングせよ
ってのを実践するのに丁度いい潔い言語機能なんだが

**デフォルトの名無しさん** · 2022/08/28(日) 18:24:29.65

interfaceでできることは (多重継承禁止しなければ) classでもできる
この客観的事実を、鬼滅棒みたいに振り回す人
と仲良くなるところまでがC++の難易度です

**デフォルトの名無しさん** · 2022/08/28(日) 18:31:25.88

個人的にはC++でIFooとか涙ぐましいことやってんのも受け入れられるよ
問題は、言語ユーザが実装とインタフェースを分離したいという発想を持ってるかどうかだから

もちろんそうなったとき、よりスッキリすんのは言語として interface があるほうだよねって話

**デフォルトの名無しさん** · 2022/08/28(日) 18:34:20.72

そもそもC++はオブジェクト指向言語ではないのでインターフェースは必要ない。

**デフォルトの名無しさん** · 2022/08/28(日) 18:36:05.49

>>903
Rustを使えば避けられるよ

>>908
implは単なる接着剤だよ
Goのように接着剤なしで書く方式もあるように
接着剤であるimplはそこで言う種類じゃないよ

**デフォルトの名無しさん** · 2022/08/28(日) 18:39:21.55

そもそもRustは仕事がないのでimplは必要ない。

**デフォルトの名無しさん** · 2022/08/28(日) 18:40:17.57

>>918
うん
インタフェースは必要でむしろクラスが要らないよね
そのわかりやすい道を選んだのがGoとRust

**デフォルトの名無しさん** · 2022/08/28(日) 18:44:55.39

Rustは仕事がない。
Goは仕事がある。
この差は大きい。

**デフォルトの名無しさん** · 2022/08/28(日) 18:45:28.11

雇われ仕事はな

**デフォルトの名無しさん** · 2022/08/28(日) 18:46:02.45

>>913
自分の判断ではrustはスパゲッティだから

**デフォルトの名無しさん** · 2022/08/28(日) 18:47:05.71

ていうか、Rustって使ってる人少なすぎじゃね？

**デフォルトの名無しさん** · 2022/08/28(日) 18:48:13.72

メソッドが無いってんならともかく、クラスが無いと言っても明示的なクラス定義に比べてソースコードの物理的レイアウトの自由度が高いというくらいの話でしかないでしょ
そんなドヤ顔で語るほどのことでもない

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

>>925
少なくとも他の言語と比べたらスパゲティになりにくいね

>>927
メソッド自体はクラスと関係なくてクラスベースのプログラミング言語でなくても存在するものだよ
クラスを特徴付けるものはクラスの親子関係を示す継承だね
GoとRustに継承はないからクラスとは明確に異なるよ

**デフォルトの名無しさん** · 2022/08/28(日) 19:06:04.35

クラスに継承は必須ではないよ
VBAのクラスに継承は無いぞ？

**デフォルトの名無しさん** · 2022/08/28(日) 19:06:48.27

Rust、Haskellは仕事がない。

**デフォルトの名無しさん** · 2022/08/28(日) 19:07:23.94

>>920
implは操作の定義
structはデータの定義

この2つを分けたことの意味が分からないようならRust辞めたほうがいいよ

**デフォルトの名無しさん** · 2022/08/28(日) 19:08:15.18

始めても居ないだろ。

**デフォルトの名無しさん** · 2022/08/28(日) 19:16:42.43

Goのimplicitなインターフェース実装よりも
Rustのexplicitなトレイト実装のほうが断然いい

ただJavaと違ってC#やSwiftならExtensionで後からクラスにインターフェース実装追加できるからGoやRustの方式が特に優れてるわけでも無いと思うけどね

**デフォルトの名無しさん** · 2022/08/28(日) 19:25:12.79

>>929
VBAは他にもできないことや制限されることが色々とあるから置いときましょ

>>931
違うよ
implは『実装』の定義だよ
structは(構造体の)『型』の定義だよ

**デフォルトの名無しさん** · 2022/08/28(日) 19:32:34.36

>>933
優れてるかどうかは誰も言っていなくて
元々の話はRustはトレイトがあるから複雑で難しいとかいう批判に対して始まった議論やろ
実際にはクラスとそれに纏わる諸々がないからGoもRustもクラスのある言語より簡単でわかりやすくなってる

**デフォルトの名無しさん** · 2022/08/28(日) 19:39:33.75

importしないと使えないメソッドがあるのが理解できない

**デフォルトの名無しさん** · 2022/08/28(日) 19:45:44.96

問題はクラスではなく副作用だよ
勘違いするなよ
クラスのメンバーが途中で書き換えられたりしなければ問題はないのよ

**デフォルトの名無しさん** · 2022/08/28(日) 19:49:05.31

rustはstructのフィールドごとにmut設定できないので欠陥言語

**デフォルトの名無しさん** · 2022/08/28(日) 19:53:38.21

次スレのタイトルは

次世代言語28 Rust

にしとこうか？

**デフォルトの名無しさん** · 2022/08/28(日) 19:55:42.04

仕事がない言語に未来はない。

**デフォルトの名無しさん** · 2022/08/28(日) 20:11:14.04

仕事があっても未来がない言語の方が多い件

**デフォルトの名無しさん** · 2022/08/28(日) 20:17:59.03

RustはPHPより優れているんだ！！といくら主張しようとも。
Rustは仕事が無くてPHPは仕事があるんだから仕方がない。

**デフォルトの名無しさん** · 2022/08/28(日) 20:18:38.81

>>941
具体的にどういう言語に未来がないの？

**デフォルトの名無しさん** · 2022/08/28(日) 20:25:11.67

>>943
COBOL Fortran Ruby Perl VB.NET VBScript Delphi

**デフォルトの名無しさん** · 2022/08/28(日) 20:25:27.41

コボラーの人たちは逃げ切ったと思う
くいっぱぐれなかったコボラー

**デフォルトの名無しさん** · 2022/08/28(日) 20:30:40.83

Objective-Cもまだ仕事はあるだろうけど未来はないな

**デフォルトの名無しさん** · 2022/08/28(日) 20:35:31.36

全部、一時代を築いた言語たちじゃないか。

**デフォルトの名無しさん** · 2022/08/28(日) 20:36:35.22

だから仕事と過去はあるけど未来がないと言われてるんだろ

**デフォルトの名無しさん** · 2022/08/28(日) 20:38:56.54

Elmとかいうの一時期Qiitaで流行ってたけどもう下火だな

**デフォルトの名無しさん** · 2022/08/28(日) 20:48:08.93

世界で見捨てられたころに日本で流行らせようとする人たちが出てくるのは何故なんだろうな。

**デフォルトの名無しさん** · 2022/08/28(日) 20:51:32.52

流行らせよう・・・そんな未来形は使う必要がねえんだ

**デフォルトの名無しさん** · 2022/08/28(日) 20:52:32.31

PHPとRoRのプロの人は今後も食いっぱぐれないと思う

**デフォルトの名無しさん** · 2022/08/28(日) 20:57:10.97

COBOLみたいに進化が止まればね
PHPはアグレッシブに言語仕様変えてるから往年のぺちぱーにとっては厳しくなりつつあるんじゃないか？

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

>>935
トレードオフなんだよ
得たものもあれば失ったものもある
ある状況において簡単になってるように見えるだけ

**デフォルトの名無しさん** · 2022/08/28(日) 21:09:02.48

おれRoR得意だけどRails使ってるとこはフットワーク軽いとこ多いし、みんなどんどんGoに置き換えてるよ
Railsにフロントもやらせるとゴチャっとしてメンテしづらくなりやすいし、APIだけやらせるんならRailsである必要性もないし・・・

**デフォルトの名無しさん** · 2022/08/28(日) 21:25:19.61

>>955
APIだけの場合でもモデルの作りやすさとか考えると全然あり
まぁLambdaとかでコスト削減したいなら無し

**デフォルトの名無しさん** · 2022/08/28(日) 21:31:52.80

スレタイは次世代言語じゃなく新世代言語にしとけば？
それならスレタイにある現世代の言語でも違和感ないから

**デフォルトの名無しさん** · 2022/08/28(日) 21:41:34.26

>>955
Goにする理由がわからないなあ
Web APIだけならRailsで十分でしょうよ

**デフォルトの名無しさん** · 2022/08/28(日) 22:08:57.12

>>944
C, C++, C#, Python, JavaScript/TypeScript, Go,

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

>>959
未来のある言語ばかりだな

**デフォルトの名無しさん** · 2022/08/28(日) 22:12:52.50

>>944
途中で書き込んでしまった
あとFORTRANはスパコンとかの数値演算系ではまだまだ現役で未来がないわけじゃないよ

**デフォルトの名無しさん** · 2022/08/28(日) 22:16:33.25

>>961
Formura「いつのスーパーコンピュータの話をしてるんだ」

**デフォルトの名無しさん** · 2022/08/28(日) 22:41:58.53

YouTube で有名な雑食系エンジニア・KENTA が勧めるキャリアパスは、
Ruby on Rails → Go のみ

さらに彼は、PHP, Scala をオワコン認定した。
要するに、この2つはRailsに勝てる要素がない

時価総額1兆円のGitLab は、Railsで続けることを宣言している

**デフォルトの名無しさん** · 2022/08/28(日) 22:54:34.17

ああ、ごめんなさい、ガイジを召喚しちゃった・・・

**デフォルトの名無しさん** · 2022/08/28(日) 22:58:49.50

>>962
富岳とかの利用方法見たらわかるけど、最初に載せてる
なんだかんだ言って言語仕様的に最適化し易いのとライブラリに1日の長がある

[コンパイラ/インタプリタ]
富士通コンパイラ(Fortran2008 & Fortran2018サブセット, C11 & GNU拡張仕様・Clang拡張仕様, C++14 & C++17サブセット & GNU拡張仕様・Clang拡張仕様, OpenMP 4.5 & OpenMP 5.0サブセット), GNUコンパイラ, Julia, OpenJDK (Java), Python, Ruby, XcalableMP, LLVM
https://www.hpci-office.jp/pages/r-ccs_riken_2022-2

**デフォルトの名無しさん** · 2022/08/28(日) 23:01:39.48

>>965
それ今はまだ使われてるってだけで未来の話はしてないよね

**デフォルトの名無しさん** · 2022/08/28(日) 23:11:01.40

Fortranは過去の資産が大量にあるからなあ
しかもバリバリ現役のが
普通にCOBOL以上だよ

**デフォルトの名無しさん** · 2022/08/28(日) 23:15:53.85

>>966
新規案件もあるしコンパイラの改善も進んでるけど？
あんたの未来の定義はなに？

**デフォルトの名無しさん** · 2022/08/28(日) 23:23:42.78

>>968
話の流れくらい把握してから聞いてくれよ

**デフォルトの名無しさん** · 2022/08/28(日) 23:27:23.09

>>969
把握できてないのは貴方では？

**デフォルトの名無しさん** · 2022/08/28(日) 23:52:33.65

次の土方言語

**デフォルトの名無しさん** · 2022/08/29(月) 00:01:26.37

機能を追加しつつげてるC#辺りの方が、次世代って言わないだろけれど、時代に合わせて進化続けてる感じするよ。

**デフォルトの名無しさん** · 2022/08/29(月) 00:13:24.90

C#は一つの言語にアグレッシブに手を入れ続けるという点では現在進行系で最も成功している言語だろうね
単純な言語仕様の量で言えばもはやC++を超えてるんじゃないか

**デフォルトの名無しさん** · 2022/08/29(月) 00:15:09.28

C#に一番類似してるやつとさっさと決着つければいいのに
PythonとRubyがとうの昔にやったことを未だにできてない

**デフォルトの名無しさん** · 2022/08/29(月) 00:24:30.02

Javaと言いたいのかもしれないが、C#の方が別物になりすぎて今や全然類似していない
今だと一番類似してるのはKotlinあたりだろうが、シェアではそもそも全く勝負になってないな

**デフォルトの名無しさん** · 2022/08/29(月) 00:38:48.50

科学計算系の現役のライブラリの中覗くとFortranのコードベタ移植してたりするよね

**デフォルトの名無しさん** · 2022/08/29(月) 01:40:27.72

>>953
PHPは太古のコードも割と動くからな…

**デフォルトの名無しさん** · 2022/08/29(月) 06:56:36.80

>>970
IEの新規案件もまだあるんだがそれでもJScriptに未来があると言うのか

**デフォルトの名無しさん** · 2022/08/29(月) 07:04:39.97

>>978
> IEの新規案件もまだあるんだが
それ一般的なのか？

**デフォルトの名無しさん** · 2022/08/29(月) 07:10:46.62

>>979
新規案件があるくらいじゃ未来があるとは言えんという話だぞ
話の流れずっと理解してないな

**デフォルトの名無しさん** · 2022/08/29(月) 07:32:15.58

>>980
詭弁のガイドライン
2. ごくまれな反例をとりあげる