次世代言語25 TypeScript Swift Go Kotlin Rust Nim YouTube動画>4本 ->画像>2枚

スレタイ（順番はRedMonk準拠）以外の言語もok

前スレ
次世代言語24 Go Nim Rust Swift Kotlin TypeScript
http://2chb.net/r/tech/1647887021/

セックスも男女関係を円滑にする一つの言語なんですよ。

プログラミング言語は以下の3つに分類される
CとC++　←省メモリ高速だが、メモリ解放でミスると危険
GC言語　←省メモリ高速ではないが、メモリ解放は自動で気にしなくていい
Rust　←省メモリ高速だが、メモリ解放は自動で気にしなくていい

「省メモリ高速ではない」はNANDなのかNORなのか
プログラミングの才能無さそうな日本語

このスレは実質「Go vs Rust」のスレです。

僕は生前、同業・Googleの言語センス同調圧力に抗うも努力は虚しく、無残な敗北を余生噛みしめる結果となった。

君たちには底辺職言語オタクの僕の分まで、強く自由に生きてほしいデス。

ＰＨＰの”勝ち”やね・・・

"1000" 名前：デフォルトの名無しさん[sage] 投稿日：2022/04/17(日) 22:31:30.13 ID:xE2XgYmS [6/6]
１０００ならPHP大復活時代でルースターズを蹂躙レイプする

>>7
PHPもタイプヒンティングちゃんと使っていったら悪くないんじゃないかね。
結局日本国内のWeb系じゃ一番使われてるし。

PHPはドル記号がダサいから駄目

C++使っててもコンテナクラス使うかスマートポインタを普通に使っていればメモリリークすることは殆どないでしょ。
手動でnewとdeleteしなくてはいけない時ってある？

go とrust が合体した言語があったらいいのに

>>11
vlang

絵に描いた餅を出されても

>>10
リークというかダングリングだけど、人が書いたメソッド中身見ないで使ってると参照切れてたり日常茶判事だよ

>>10
そういう問題じゃないんだよ
スマートポインタ使わないで実装できてしまうことでこれまでどれたけの脆弱性をうんだか、という問題

>>10
・スマートポインタを使い忘れてもコンパイルが通ってしまう
・スマートポインタを間違って使ってもコンパイルが通ってしまう
後者はC++ベテランでも複雑化するとうっかりミスがある
・そもそも毎回unique_ptr指定が面倒かつ無駄なのでデフォルト適用にして欲しい

新しいプロダクトできました。メモリーリークはないです。
なんでいいきれるの？
Rustで、実装してるからです。
ああ、納得。

こんな感じで会話できるかどうかの差はものすごく大きい。

>>11
go要素いらねえだろあんな糞文法
なんどGoogle潰してやろうと思ったか

やはりRustが最強

JavaScript/TypeScriptの高速フォーマッター「Rome Formatter」リリース。Rust製でPrettierより約10倍高速と
https://www.publickey1.jp/blog/22/javascripttypescriptrome_formatterrustprettier10.html

Rustの文法すごい好きだから、c#ぐらいのノリでかけて文法がRustっぽい式指向な言語が欲しい

なんでもその言語はC#のノリで書けるらしい

Goやないかい！

GoはC#のノリで書けるんやから！

俺はなんでもオミトオシやねんから！

Goやそんなもんは！

>>20
Rustの構文や標準メソッド等ほぼそのままに
所有権と借用ルールとライフタイムだけを削除というか無視して処理するGC言語『GC-Rust』を作るとよいかもね
プログラミング初心者入門用にもなるし速さ省メモリを必要としない場でも使えるような
多少遅くてもいいのだからインタプリタ型でも十分かもね
あとは所有権参照借用lifetimeだけ学べば本物のRustへすぐに進める

>>19
ツール系はいくつかrust製があるね。
ripgrepもなかなか良いよ。

>>22
あーそんな感じだな
GC付きのRust欲しいわ

Rcじゃだめなの？

もう調べてるかもしれないけどもっと現実的な話で式志向がいいならF#どうっすか

>>14,15,16
スマートポインタを使い忘れるってことはmake_sharedかmake_unique使わないでnew使ってるってことだからgrepすれば簡単に見つけられる。全ての関数の引数の型とクラスメンバの型に生ポインタが無いようにすれば間違った使い方をして生ポインタがでてきてもコンパイルエラーなる。（もしそれらに生ポインタがあっても正規表現使えば見つけられるだろうし）

>>27
そんな面倒なことをせずとも無指定でunique_ptr相当になるRustを使った方が楽でいいな
Rustなら他にも忘れたり間違えたりすればコンパイラがエラーとして詳しく指摘してくれるし

>>18
アリが象を潰すつもりですか？

>>27
ある瞬間自分の書いたコードだけチェックできればいいってならその通りだとは思う
ただ実際には依存ライブラリや他の人が入れてくるコード全てを常時チェックし続けないといけなくなるし
もし依存ライブラリがnew使ってたとして毎回フォークして書き直すのか？という問題もある

巷に出没するRust信者自分でRustまともに書いてない説を提唱したい

そうなるとRustを広めたい勢力に雇われてる工作員の可能性出てきちゃう

>>28
引数渡しがデフォルトmoveじゃなければよかったんだかな。
デフォルトconst 参照で組まれていたらずいぶん学習しやすくなったと思う。

所有権のmoveセマンティクスらへんがRustの最大の文法的特徴なのに、そこがいらんとな
最初からKotlinとか使ってればええやんか

>>34
C++以外のユーザーがRustを学習するときの一番の難所でもあるけどな。

実際、不変借用は頻出しそうな気がするけど、性能ペナルティーとかあるのかね？

rustはインストール先がユーザーホームディレクトリの下なのが何だかな。
マルチユーザーで使う場合が手間かかる。

>>33
それはおかしい
一般的に参照を引き渡すということは様々な問題を生じさせるということ
競合の種も産むし参照切れの種も産む
だから参照を引き渡す方が記述コストを増やすことこそ道理
次に
C言語でもポインタ参照渡しは＆を付けて表記する
したがって無印よりも＆前置こそ参照渡しに相応しい

>>30
これ。
見つけたからってどう住んだよ？って話だよな
他社のコードを修正できないし、そもそもそんなチェックを未来永劫担当者に引き継いでいけるのか？ってこと
個人でできることと、組織やプロダクト関係者全体としてできることは違う

>>30,38
そんなこと言ったら、Rustでも他人の書いたコードにunsafeが入ってる可能性もあるでしょ。

>>33
Nim言語だとデフォルトで不変コピー渡しだけど引数のサイズが一定サイズ以上（確かポインタサイズの3か4倍以上）だとポインタで渡すようなコードを生成するんだよね。

>>37
Rustは参照を使ったときの問題が起きないようにコンパイル時にチェックしているんだからデフォルトがconst参照渡しでも問題ないんじゃないの?

Rustって借用したり借用を参照するときに&や*をつけないといけないけどその結果コードの見た目が生ポインタを使ってるCのコードに似てるんだよね。暗黙に借用したり参照しちゃダメって考えでそうなってるんだと思うけど。

>>17
メモリリークは防げないでしょ

>>39
＞Nim言語だとデフォルトで不変コピー渡しだけど
＞引数のサイズが一定サイズ以上だとポインタで渡すようなコードを生成するんだよね。

この議論でそんな話を持ち出す時点であなたは以下の理解が足りない
一般的にプログラミング言語によるセマンティクスと最終的に生成されるコードは全く無関係でありそこに関連があってはいけない独立のものである
完全に独立したものであるが故に最終コード生成オプティマイズを十分にすることが可能となる

>>40
そうですね。スミマセン

やべーアスペおるな

プログラミングを勉強しようと思って
なにを勉強すればいいか先生に聞いたらパイソンっていうから
検索したら大きな蛇の画像とかがでてきたのでやめたわｗ

生成されるコードがプログラミング言語のセマンティクスと無関係じゃだめでしょ。
コード生成はプログラミング言語のセマンティクスと矛盾しない範囲内で生成しないといけない。コンパイラはその中で最適なコードを生成しようとするわけでしょ。
Nimではデフォルトで引数はプロシージャ内で変更不可(変更しようとしたらコンパイルエラー)だから引数の型のサイズに併せて生成するコードをコピー渡しにしたりポインタ渡しにできるわけで。
もし引数が可変参照渡しだと引数の型が1バイトでもコピー渡しでは無くポインタ渡しにしないといけない。関数がインライン展開されると話が違ってくるけど。

>>44
あ、すまん。これ誤爆しました。スミマセン〜。

「プログラミング言語によるセマンティクスと最終的に生成されるコードは全く無関係」そんな訳ない、RustはLLVMのIRを前提に
コードが吐かれるし、コードのリンケージをアトリビュート指定できる。C言語だって同様だし、むしろ、ハードウェアよりの低レベルな
システムプログラミングが可能な言語であれば、生成されるバイナリが厳密に言語の「セマンティック」を決める。
例えば今どきのCPUには分岐予測命令があるが、これに対応するstd::intrinsics::likelyのような分岐予測にヒントを与える、
セマンティクスはCPUがサポートされていれば100%生成されるバイナリがそうなる事を望む。無関係などありえない

>>47
Rustをgccと組み合わせて動かす試みあるから
LLVM前提ではないのでは？

>>45
その言語のセマンティクスとしてimmutableで渡すケースでも
値をポインタで渡すか値自体を渡すかはどちらでも構わないから言語のセマンティクスとは別問題

もっと顕著にわかりやすい例
構造体を一つ返す関数があったとする
小さい構造体なら値を返すだろうが
大きな構造体なら領域を用意してそこに書き込んでそのポインタを返すかもしれない
あるいは関数を呼ぶ側が領域を用意してそのポインタを裏引数として渡してそこへ返す値を書き込むかもしれない
このように3種類考えられるが呼ぶ側と呼ばれる側で一貫していれば目的を果たす
プログラマーはその生成コードが3種類のどれになるかを把握する必要はない
つまりそこで明白にレイヤーが分離される

>>33
もし文字列のベクタに文字列を追加する関数があったとき文字列が参照渡しでその関数が実行された後もその文字列が読まれていると、その関数は文字列をmoveすることができずコピーしなくてはならなくなるからじゃないかな。
メモリコピーは遅いから絶対に許さない人にはデフォルトがmoveのほうがいいのかも。

>>48
現状はIR前提でしょ、完成してない未来のものを持ち出すのであれば何とでもいえる。というか上で言ってる本題とはずれる
そんなところに食いついて来てしょーもないわ

>>47
Rustでもセマンティクスと生成コードは独立だよ
例えば>>49の関数が構造体を返す例
生成コードは言語仕様で定められていないしあなたも方法を答えられないでしょう
実際にRustで大きな構造体を返すと所有権を活用して驚きの最適化したコードを生成するよ

>>51
開発中で完成してないとは言っても実行バイナリの
生成もできないという状態ではないから
あなたの話とは違うというか
あなたの主張は間違ってるという例になってますよね

>>52
「生成コードは言語仕様で定められていないしあなたも方法を答えられないでしょう」
え？RustにもちゃんとFFIなどextern "C" {}ブロックがあるでしょ？生成コードは言語仕様で定められているし、このようなデータの受け渡しは
参照や可変参照の制限、ボローチェックなどがOFFになる。C言語やD言語やNimも同様でしょ、これが出来ない言語はシステムプランニングが
できる言語とは言えない。
「Rustで大きな構造体を返すと所有権を活用して驚きの最適化したコード」
どのような驚きのバイナリを生成しようと、例えばゲームエンジンのUnityなどでデータを渡す場合に所有権をRust側で保持したままのような
コードではUnityなどでメモリー管理されるので問題が出る。だから呼び出し間でどのようにデータを受け渡すか当然指定できる

>>53
何を言いたいのか1つも分かりません。。。あなたの勝ちでゴリラのようにマウンティングをしてください、どうぞ

>>54
FFIを理解していないアホですか？
例えばそのextern "C"した時のみC言語の受け渡しインタフェースに従うだけ
どの言語でもFFI使わなければ各言語が自由自在の方法を取る

>>39
引数のサイズが一定サイズ以上だとポインタで渡す

それはそれで他者が変更したときの挙動が変わるから怖いよね。
特に並列作業時。

>>50
const参照をデフォルトにしたら、そのあたりは引き渡し時にmoveを明記するんだろうね。あるいはCOWで実装するか。

もしかしたらRustに「権利を持つオーナーは極力少なく・小さくする」というポリシーでもあるのかな？

>>56
さっきからID変えて絡んでこなくてよいですよ、「extern "C"した時のみC言語の受け渡しインタフェースに従う」セマンティクスと生成コードが決まりますよね。
アホと言えば誰もしもが感情的になるわけではないです。FFI使わなければなんて話をしていませんし、「プログラミング言語によるセマンティクスと最終的に
生成されるコードは全く無関係」という理想論のような現実を知らないコンピューターサイエンス学科の学生のような言葉を否定してるだけです。

>>57
デフォルトで引数は不変が前提なので引数の型の定義を変更してポインタ渡しになったとしても基本的には挙動は変化しない。
引数のアドレスをとってれば挙動が変化するかもしれないけど、Nim言語は明示的に変数のアドレスをとることは危険な行為で自己責任でやれってことになってるから。

>>58
普通のプログラムでC言語FFIなんて使わないです、そして、その特殊ケースはどうでもよい話です
一般的に言語が定めるセマンティクスと生成コードは別階層なので独立しています

>>57
静的型付けで型サイズが定まる普通の言語ならば大丈夫
引数や返り値がポインタ渡しになるか値直接渡しになるか
型サイズ次第で変化しても一貫していれば構わない

>>57
> それはそれで他者が変更したときの挙動が変わるから怖いよね。
> 特に並列作業時。
横レスだけど、明らかにそういう話じゃない

普通にカーネルのシステムコールするだけでC言語のFFI使ってますよ、DBアクセスするにもSQLiteでもMySQLでもPostgresqlでも使用してますし
TCP/IPスタックにアクセスするにもFFI使ってます、もしや特殊なのはあなたなのでは？ガン無視されて独立しているのは、そんな詰まらないことで
言い張るあなたなのでは？

Kotlinみたいな出力先がjvmとjsとネイティブがあるのは
このひとの中でどう解釈するんだろ

>>63
そんなことは誰でも知っているがこの流れとは無関係な話
各FFIはそのFFIの指定に従う
逆に言えば各言語の普通のコードではFFIなんて関係ないので各言語で完全に自由
だから引き数や戻り値のサイズに拠ってポインタ渡しか否か変わる言語もある

プログラマーはそれらを知らなくてもプログラミングできる
各言語が定めるセマンティクスだけ理解すればプログラミングできる
つまりセマンティクスと生成コードは完全に独立した別階層であり無関係

この話の終着点どこ？
「お前はアホだから黙れ」が立証できれば満足するの？

>>33
変数の代入がmoveなのに関数引数の時だけ参照になるのは紛らわしくない？

>>59
あ、不変前提ね。勘違いしてました。

>>67
変数もデフォルトで不変借用にする、とか。戻り値の受けが面倒臭くなりそうだけど。

>>68
Cの(ポインタ)参照が前置＆だから
Rustの(借用)参照も前置＆にした現状仕様がわかりやすいと思うけど、なぜ変えたいの？

>>68
変数の代入をデフォルトで参照にするとmutが絡んできたときにborrow checker周りでとてつもなく面倒になりそうな気がする

rustはライフタイム周りが途方もなく汚く見える
ウンコに触れたくない

Rust「エラーには回復可能なエラーと回復不可能なエラーがあってResult<T, E>を使って~(長文)」
エンジニア「TとEって何だよ」「"?"って何?」「Box<dyn Error>って何?」

Golang「ほぼ
if err != nil {
panic(err)
}
でいい」
エンジニア「そうだったのか！」「やっと理解できた！」「Goって美しい」



何も言い返せんかったは・・・

twitterでイキってるバカをそんなに晒すなよ。

なおイキッテルのはRUSTERのもよう
ＧＯに完全敗北してどんな気持ち？

null安全じゃない言語とかこのご時世にあるんですね

スレタイの言語でも
Goとかnilチェックするコードを書き忘れてもコンパイルエラー出ないね
安全じゃない言語多すぎ

GOはポイント使わなければ安全だぞ
ただし初期値に０と””が入る

>>77
このif文を書き忘れたらコンパイルエラーになるの？

>>72
> if err != nil {

>>74
これってgoありがたがる人を馬鹿にしたツイートじゃないの？

Goはnil安全ではない
if err != nil {を書き忘れたり
return nil, nilしちゃっていると死ぬ

nil以外にも存在しない時の値で死ぬ
例えばstring.Index()は未発見時に-1を返す
返り値が-1かどうかチェック忘れてもコンパイルエラーとならない
そのまま-1を使ってしまい実行時に死ぬ

いずれのケースもRustではコンパイルエラーとなるため安全
Goは危険だらけ

分かりにくい人「円周率は3.141592...と無限に続く数字で、よく近似の3.14が使われます。」
視聴者「何で3桁なの？」「2の後は何なんだよ」「近似って何？」

分かりやすい人「円周率って色々言われてるけど、実は3なんです！」
視聴者「そうだったのか！」「やっと理解できた！」「数学って美しい」

https://twitter.com/zugaaanzubababa/status/1506569845693100035
https://twitter.com/5chan_nel (5ch newer account)

Goでは「値が存在しないこと」を安全に表す方法がないことが敗因
RustではOption<T>型のNoneで安全に表せるところ

なおシェアはＧＯが圧勝したもよう
ＲＵＳＴボーイズは一生夢見て低賃金でこき使われる童貞野郎

goはCがシンプルで使いやすいと思う人向けの言語じゃないかと思う

言語機能をモリモリにしたい誘惑に抗ってランタイムを充実させるという判断できる自制心はすごいと思う

Ruby 3.0 のJIT は、MJIT で、
Ruby VM のバイト(中間)コードを、C コードに変換してから、
Cコンパイラでネイティブコードに変換していた

Ruby 3.1 のJIT は、YJIT で、
バイトコードから直接ネイティブコードに変換する。
ただし、x86_64 のみに対応

条件分岐があっても、10回実行した分岐だけを変換する。
実行されない分岐は変換しない

遅延変換・Lazy Basic Block Versioning（LBBV）

これで、Rails のプロジェクトが、20% ほど速くなったらしい

ゴミが20%早くなかったからってどうしたってゆうね

>>81
今さらゆとり

>>87
でもRuby on railsってまだまだ使われてるよね？
有名どころでも、クックパッド、Airbnb、Gunosy、クラウドワークス、
食べログ、価格.com、Twitter、 Hulu、 GitHub

>>81
偽物を「実は」という詐欺師。

>>89
大規模railsを別言語で書き直しましたという
ニュースは時々出てくるけど逆は聞かないからなあ…

>>89
業界や会社によってはCOBOLだって使われてる。
いったんそれでシステム組んじまったら中々移行は出来んもんだよ。

>>80 >>82
Goはなぜそんな危険な言語仕様にしたの？

R○byは業界のSPA移行とPythonブームによって思いのほか綺麗に消えてくれたのは良かった
まあPHPなんかに比べたらまだ「恥を知る」人間が多かったんだろうね

>>94
PHPユーザに失礼なやつだな

お前あれだろ？
刺し身に直接わさびを付けるタイプだろ。醤油でわさびをとかさないで刺し身につけて食べてね？どうよ？

>>94
言語マニアならpythonよりRubyの方がマシだろ。Pythonみたいにメソッドと関数が混在するのは書いててキモい。
python4でNim方式を採用してほしいわ。

もちろんプログラム記述方式としてはPythonは最悪
あれが普及するのは害悪しかない

>>95
直接わさびを口に運び刺身を投入して咀嚼した後に醤油を飲むタイプです

PHPユーザに対し失礼な発言は謝罪して撤回させていただきます。この度は申し訳ございませんでした。

インデントでスコープ区切るのあんまり好きじゃない

Haskellもインデントでスコープを区切ってた気がするけど一応ブレースでくくることもできるんだっけ

>>98
人類最底辺のゴミPHPoorに謝罪など必要ない
奴らに必要なのは死あるのみ

PHP使う人ってなんであんなアヘアヘ君ばかりなの？昔からああなの？

>>96
けっこう同意。

>>102
障害者手帳持ちでも書けるとガイジを集めたから
ガイジが作ってガイジが保守して、真人間は近寄らないか万一深淵を覗いてもすぐに逃げるから
ガイジだけが残った
それがPoopHPoor

言語の良し悪しと普及率はあんまり関係ないってことだな

良し悪しは文法だけでは決まらないしね
全部作り直すとかできないから、まず既存資産との互換性とかがめちゃくちゃ重要だしなあ

Haskellはとてもいい言語だと思うけど、まあ今後も広くは普及しないだろうね

Java(8以前)とPHPとVB.NETは案件も人材もロクなのにあたったことないし関わりたくない

障害者雇用枠だししゃーない

小一時間でゲームをつくる──7つの定番ゲームのプログラミングを体験 (WEB+DB PRESS plus)
https://www.あmazon.co.jp/dp/4297127458

この本面白いね。
コンソールに出すアスキーアートだけでゲームを作るところと最小限の工程ごとに動作確認するところがユニークだ。

誰かこのなかのどれかのゲームをGoやRustに移植してgithubあたりにアップしてくれないか？
その出来栄えでその言語の優劣を競うというのはどうだろうか？

コード書けない奴が何の優劣を語るんだ？
LOC？

>>110
urlミスってるよ

コードが書けないやつだからこそnull安全なんてほとんど誰もありがたかってない事を上のように一生懸命言い出す

>>113
これだからGo信者は… 本当に現代人？

>>93
Goは言わば並列対応スクリプトC言語だからだよ
だから今どきの言語と異なりC言語のように地道に記述量が増えるとともに安全軽視で自己責任

男の人って気持ち悪い…
どうして少女をそんなに汚したがるの？
お母さんに悪いとわおもわないの？

そらごらんなさいRustの悪影響を

アイGoー

Rustならシンプルに分かりやすく書きやすい上に
うっかりミスもコンパイルエラーで検出されるから良いよな

Rustの話は専用の隔離部屋でお願いします

Rust part14
http://2chb.net/r/tech/1644596656/

次スレタイトルからRustの文字を削除してください

比較の話だからここでいいんじゃね
そもそもアンチ側が悪影響とか言い出してきっかけ作っているし
アンチを各言語本スレへ誘導するのはダメだろ

比較の話も含めて >>121 の専用スレでやって下さい

言語同士の比較はここでやる
Rust単独の話は向こうでやる
それだけだ

以上

むしろここが隔離スレだと思ってた

ここは次世代言語スレ
次世代言語の話題や機能や比較に議論まで何でもOK
各言語の本スレに迷惑がかからないようここで行なうこと推奨

>>114
このように誰もGoのことなど挙げてないのに、Rustの超ビギナーの信者は異様に敵視を行う。

例えば、代表的なNull安全言語は、RustがまさにそうだがOptionを使うからNullなんて無いのだが、matchを書いたとしてもNoneで
異常を処理しないような事を書いてしまえば、Nullで落ちたりするプログラムと大して変わらない。unwrapを連打するようなプログラムは
論外だとしても、それはNullをチェックしないプログラムと何ら変わりない。
Qitaの有害記事、「null安全でない言語は、もはやレガシー言語だ」のせいで、このような思想を植え付けられている人があまりに多い。
大切なことは異常系をきちんと処理できているかということで、言い訳では「ちゃんとやるのを忘れているかもしれないのでは」という指摘に
コンパイルが通らないだの、Rustでしかそうならない事を都合が悪いのか、短い考察だけで反論しています。
コンパイルが通ろうと通らななかろうと、”ちゃんとやるのを忘れて”いれば同じです。

また、たしかにNull安全は、Java/KotlinのようなNullが奥深くに根ずく言語であれば恩恵は大きいでしょう。しかしGoのような言語は
扱うデータはstructであり、Nullが無い訳ではないが、奥深くに潜む”参照”データー構造を設計思想から良しとはしていない言語である。
一部の言語設計者ではリンクリストのような、非効率で何も考えてないデーター構造を逆にレガシーと呼びます。
もちろん、if err != nil { }が古臭く邪魔で嫌、あちこちに現れるので受け付けないという意見は分かるし、これを簡略化するために
Null条件演算子やNull合体演算子が欲しいという要望もわかる。しかし、それが導入された、もしくはされていないからといって
それはNull安全言語とは厳密には関係ない。

>>127
> このように誰もGoのことなど挙げてないのに
>>72,74,80,82

>>127
＞このように誰もGoのことなど挙げてないのに、Rustの超ビギナーの信者は異様に敵視を行う。

このように誰もRustのことなど挙げてないのに、Goの超ビギナーの信者は異様に敵視を行う。

以下略

>>127
それは君の主張が間違っている
Rustではある型Tの変数に対してnull相当(nilやundefined等含む)を代入出来ない
そのため君の主張する処理し忘れがあってもnull相当を扱ってしまう危険性は起きない

ほらまたTとか言い出したこれだからRusterは

Goだって最近Tって書けるようになったでしょ
スレタイの言語皆Tって書くのでは

・Rustにはnullという概念のものが存在しない
・存在するかしないかを示したいならば代数的データ型であるenum Optionを用いる
・扱う型をT型とするとOption<T>型となるため型が異なり処理を忘れてミスすることも起きようがない

Nim, Zig, Rust, C++でコンパイル時に実行されるコードを比較した記事。
https://castillodel.github.io/compile-time-evaluation/

>>133
糞バカ中世ジャップランド土人どもはOption.get()するだけだぞ

>>135
Optionにget()メソッドはありません

ほぼOptionのNoneと言ってるのに、null相当(nilやundefined等含む)を代入とか、Option<T>型となるため型が異なりとか
もう誤魔化して言いくるめる気にしか見えない。。。
どれだけNull安全で助かってるか、なんてコードを書いてればそんなに無いでしょ。確かにNullが無いのだから、Nullのような状態で
クラッシュ/panicする事態は減るでしょう。コンパイルが通った時点でNull安全性が保障されるなんてのも、今どきの多くの言語は
外付けながらLint系の警告をしてくれます。もちろん言語に統合されてない後付けで「美しくない」とかそういうのはあるでしょうが。
そして手続き型プログラミングを初めて数年の初心者なら沢山のミスを犯すのかもしれんけどさ、そもそも宣言と同時に初期化を
する重要性は、関数型プログラミングでも少しでもしていれば分かるはずでそんな経験もなく、旧Java系なんかからRustへ移ったら
感嘆するように見えるのかもしれんが、そんなしつこく言うほど便利な場面って具体的にどういう時よ？逆にさ？
次はNan安全言語とか、-+Inf安全言語とかやるのかい？

Rustのアドバンテージを認めざるを得ないから認めつつ
それでも批判したいから言い掛かり長文
みっともない

>>137 その通りだからきみはJavaとかHaskellとか使えばいいと思うよ


Rustの良いところを教えてほしいなら普通に指導を乞えばいいのに

null安全をlinterが警告してくれる言語なんてあったっけ？

>>140
未初期化変数へのアクセスのことを言ってそうな気がする
それ以外のケースでnullの問題踏んだことない人なのかもしれない

>>134
Goが無いのはGoでは不可能なの？

Rustにいいところなんてないよ
面倒なだけ

色々とプログラミングが楽で快適だからRust使ってるわ

普通に煽りじゃない反論ができない時点でRustニワカのキモさが良くわかる。Null安全を全否定してないのに
「指導を乞え」とか「JavaとかHaskellとか使え」とか「それ以外のケースでnullの問題踏んだことない」とか
Nullのような状態で クラッシュ/panicする事態は減るって書いてるのに文字も読めもしない。
”それほど強調して、気持ち悪く粘着してNull安全言語なんて宣伝してることがRustのために良くない”って話だよ
言語の悪口を言ってるんじゃない、おまえのようなキモくて何も答えられないで煽りだけクズを論ってんの

自分でこれが煽りじゃない反論だと思ってるならヤバい

Rustより良い言語が出現したらそれを検討する予定
今のところそういう言語がないためメイン言語はRustのまま

煽ってるだけの書き込みにまともな返答がくるわけないじゃん

まだスレタイに出てないけど注目してる言語とかありますか？

flixかな
scala亜種といった感じで流行るようには見えないけどね

この根源的な差が決定的かな

＞ プログラミング言語は以下の3つに分類される
＞ CとC++　←『省メモリ高速』だが、「メモリ解放でミスると危険」
＞ GC言語　←『省メモリ高速』ではないが、「メモリ解放は自動で気にしなくていい」
＞ Rust　←『省メモリ高速』だが、「メモリ解放は自動で気にしなくていい」

言語じゃないけどWASMってどうよ

>>149
Pony
Rustよりも安全。データ競合だけでなく、デッドロック、実行時例外が起きないことも保証されてる
actorモデルを採用している

>>150
これですかね
ありがとうございます

The Flix Programming Language
https://flix.dev/
https://github.com/flix/flix

プログラミング言語Flixに関するMagnus Madsen氏へのインタビュー
https://www.infoq.com/jp/news/2022/03/flix-programming-language/

Flixは多くのプログラミング言語にインスパイアされたオープンソースのプログラミング言語であり、開発者は関数型、命令型、論理型のスタイルでコードを書くことが可能である。FlixはScalaに似ており、Hindley-Milnerに基づく型システムとGoにインスパイアされた並行処理モデルを採用している。JVM言語はポリモーフィックエフェクトシステムやDatalog制約などのユニークな機能をサポートしている。

>>153
どもです

https://www.ponylang.io/

フィンテックでアクターモデルのプログラミング言語Ponyを使う
https://www.infoq.com/jp/news/2016/05/pony-fintech/

Ponyはアクターモデルを使ったネイティブ言語であり、LLVMを使う。アクターモデルはErlangやAkkaで有名であり、1973年のCarl Hewitt氏他の論文から生まれた。アクターは状態管理と非同期メソッドを組み合わせる。フィールドに加え、アクターはひとつのメッセージキューとヒープを持つ。Clebsch氏によれば、Ponyのアクターは独立してガベージコレクションがされ、ErlangやAkkaとは違い、アクターそのものもガベージコレクションされるので、アクターを殺すためのメッセージのようなものは必要ない。手動でのメモリ管理は不要なのだ。

アクターは自分のヒープのガベージコレクションをmark-and-don’t-sweepアルゴリズムを使って他のアクターとは独立して行う。つまり、Ponyは到達可能なグラフに対してはnのオーダーだ。到達不可能なメモリは影響を与えない。アクターのヒープのGCにはsafepointがなく、読み込み、書き込みのバリアも、カードテーブルマーキングもコンパクト化もない。コンパクト化が必要ないので、ポインタのフィクスアップも必要ない。

erlang系で何かしら伸びてこないのか

>>156
Erlang系でElixirの次に来そうなのはGleamかな？
まだまだ新しすぎて未成熟だけど、着実にコミュニティが大きくなってる気がする

あとは他に33個ほどリストアップされてるから、なんか伸びそうなのあったら教えて
https://github.com/llaisdy/beam_languages

>>152
Wasm自体は十分に実用的でブラウザ上からクラウドエッジ上に至るまで様々な環境での環境非依存言語の地位確立
ただしWasm仕様へのGC導入は未来の話へと先送り
したがって実用的なWasm記述言語としてはC/C++/RustのままとなりRustがベストチョイス

>>158
LLVMが噛めばほぼ全てWasm対応になりうるので利点でもなんでもない
オレオレ言語でもWasmに対応できるというかすでに作った

>>159
GC言語だと明確に不利なだけでもちろん動くよ
GCなし自作言語で良いものが作れたならばシェア取りに行くといいね
現状Rustの天下を崩すチャンス

WEB+DB Press 127号で、
Elixir のPhoenix が、28ページの特集

Ruby on Rails 7, Phoenix 1.6 から、脱Webpack でesbuild へ

RailsのHotwire, PhoenixのLiveView で、websocket によるリアルタイム通信。
ここ数年、SPA でReact に奪われたシェアを回復すべき戦略

他には、Bootstrap よりも、Tailwind が多くなってきた

128号は、Terraform 特集。
Software Design 2022/1月号も、Terraform特集だった

YouTube で有名な、雑食系エンジニア・KENTA のRuby on Rails サロンでも、
Terraformで転職を差別化できると言ったから、すべての雑誌・学校も動いた

1つのサロンが転職に有効な技術を持ってしまうと、
他者が合格できなくなるので、対抗上、勉強しないといけなくなる

Terraformが何なのかも理解せずにここプログラミング言語のスレに書き込んでいるのか

リスナーさんだか受講生だか知りませんが、KENTAさんの主張を引用するなら本人から許可を取って、
情報の許可範囲とガイドラインを守って書き込みしたほうが絶対良いと思いますね。

匿名掲示板ならアレな発言も、多少は仕方ないかもしれませんが、
他人の名を語ってそれだとさすがにまずいです。倫理とルールを守りましょう。

え本人が書き込んでるんじゃないのか

KENTA

2021年のWeb系エンジニア転職を成功させる3つの技術要素、2021/4



Web系エンジニアを目指す人のためのプログラミング学習ロードマップ、2021/2



上の動画で、Terraform で転職を差別化しましょうと言っている。
それで、すべての雑誌・学校も動いた。
Terraformが出来ないと、転職に負けてしまうから

米国人からすると、日本のRuby on Rails は異次元の戦い。
10年以上のプロでも、1年ぐらいの初心者に負けてしまう

日本では解雇できないから、資格などの事前審査制。
米国では国民全員がフリーランスだから、ひとまず雇っても、すぐに首にできる

>>164
えまじで？

KENTAさんは全エンジニアの輝きの星

讃えよー敬えー

>>165
相変わらずのゴミ動画

>>151
RustがメモリをGC並みに雑に扱えたら、最高だったな。

RcもWeakも無くなればね
裏で勝手にやってくれるとかして？
プログラマ側が一切ケアしなくて良いんならスゴイよね

Goはコンパイル言語なのにスクリプト言語のように扱える軽量さが最大の魅力だろ
Go並にエディタの補完が軽量でコンパイル爆速のコンパイル言語を俺は知らない

Rustはライフタイムが全然わからなかったし、コンパイル遅すぎて無理だったね
GCはあった方がいいに決まってるわ
開発時の生産性が圧倒的に違ってくる

GoはCGo何とかしてくれればもっと使う気になれるんだけどな

とにかくGoは頭の悪い人でもすぐにプロジェクトに参加できるぐらいに機能がシンプルに削ぎ落とされていてコンパイル爆速ってのがポイントな言語
それに対して〇〇の機能がないーって言っても仕方ないだろ

頭の悪い人でも使いこなせる言語じゃないと企業ではなかなか普及しないと思うよ

https://without.boats/blog/notes-on-a-smaller-rust/
だれかここで言われてる言語作ってくれ

>>174
本当にその通りなんだけど、これだけは欲しかったみたいな機能も一緒に削られてるところが少しモヤモヤする
ジェネリクス(ようやく追加されたけど)とか代数的データ型とか

>>172
ライフタイムがわからなかった、って、かなり知能が低い人じゃないとありえないと思うよ
そしてそのくらい低い人はプログラミングに向いていないと思う

ライフタイムはわかるけどこれがリージョン推論とかいった厳密な理論とどう対応しているのかがわからん
一般的なプログラマーはここまで理解しなくてもいいんやろうけど
なんでこんな単純なわかりやすい原則の背後にそんな謎な人口に膾炙されていない理論を導入しないといけないのかがわからんわ

荒らしなし規制無し

3ch
NEXT2ch
45ch

ふたばちゃんねる
明和水産

>>178
ブロックスコープというあまりにも大雑把な大きな枠で扱うのではなくて
実際に使われている有効な範囲(リージョン)で細かく扱いましょう、というだけだよ
生存単位は前者で、借用単位は後者で細かく区切る
具体的コード例を含めた解説ページの例

Non-Lexical Lifetimes って？
https://qiita.com/_EnumHack/items/8b6ecdeb52e69a4ff384

プログラミング言語「Erlang」を生んだジョー・アームストロング氏死去
なお、アームストロング氏は「なぜオブジェクト指向はクソなのか」という名文を残しています。

>>177
プログラマーって言ってもOS作ったりドライバ作ったりする低レイヤーやってるのと、バックエンドやWeb系の高レイヤーやってるのはいるわけで
Rustは前者の人たちが使えばいいのでは？後者の人たちがRustがーとかイキってるの見ると笑ってしまう

後者の分野ではRustはGoに勝てないでしょう

>>182
むしろGoは対象が狭くて短命に終わる言語
言語の機能不足で書きにくい上に速いわけではない
唯一のメリット(?)が仕様が簡素なこと

>>182
勝ち負けの定義次第だけど後者でもrustの方が有利な場合はあるんじゃないの
discordのバックエンドの例とかあるよね

だいたいのケースでgoが適しているって主張なら分かるけど
特定の分野で常にgoの方が適しているというのは言い過ぎかと

これだからRust信者は嫌なんだ...12年続いて厳格に互換性を保ってる言語が短命だって？
速いわけではないって、そりゃGCが裏で動いてメモリー解放をほとんど気にしなくて良い言語と比べれば、極限の速度では有利になるのは当たり前でしょ？
それでもC99やRustなどと比べても2倍も時間が掛かるわけではない、これを速いわけではないと表現するのは、自身でも気づいていないのか隠された悪意と偏見を持ちすぎてる。
むしろRustこそ後方互換を保つためなどと言いつつEditionなどという仕組みや、ボローチェックの強化なんて短命のコンパイルが通らないような事をして、短命で終わっている
今書いてるRustが10年後コンパイルが通るのかエラーになるのか全く見えない。普通の用途ではGoで十分という話に噛みついてくる
言語の表層的な機能をどんどん導入して直行性が無く、どんどん書きにくくなっていくのに苦労に見合う速度はC99以下。唯一のメリット(?)は意識高い系がたった1つの言語をやってればマウントできる事

>>182
でも現実にWeb分野でもRustがじわじわと広まりつつあるよね
サーバ側はGoよりRustが高速で省メモリでGC負荷なしで有利
ブラウザ側は実用的となったWebAssemblyでRustが最適

>>185
不勉強でよく知らないんだけどeditionやborrow checkerの強化でコンパイル通らなくなったcrateってどういうものがあるの？

長文に構うなよ

>>176
同感
必須機能が足りな過ぎてGoはプログラミングが修行のように辛い
C言語で何でも書けるというのと同じで書けるけど辛い

>>186
コンビニに行くのにF1とかソーラーカーは要らない定期。どれだけ早かろうが省エネだろうが。
JavaやC#はセダン〜バスみたいな感じかな。
Goは原付2種みたいなもんでしょ。
まず主戦場も違えばドライバーも違う。

>>186
それでお前は使ってるの？
Reference Types使ってもパフォーマンスがjsに比較してカスな件どうなった？

>>191
え？
JSとは誤差
そして何か処理するコード次第で圧勝

もう一回貼っておきますね

https://zenn.dev/igrep/articles/2021-11-wasm-reference-types

PythonにおけるCFFIみたいな用途で使う分にはきっと問題無いんだろうね
特定の目的に対してはぴったりはまるんでしょうが
それを何の前提も付けず単に「実用的」と呼ぶのは誇大広告ではないんですかね

最小限で考えると
Cにあとひとつ何かを加えたものでやっていけそう
Cに関数のオーバーロードがあればやっていけそう
コンテナクラスもほしいけどOOPを持ち込んでしまうので今回はパス
あくまで
void add(struct vector_int *v, int value)
void add(struct vector_float *v, float value)
というふうに関数と構造体だけで頑張っていけそう

Cに拘ってる奴は本気でCが使いやすいと思ってるのか冗談で言ってるのか

go よりはcのが好きかな

>>195
下手な増改築だらけのC++よりCが良い
LinuxのLinusも同じ意見

C言語にオーバーロード？
結局C++みたいにABI建て増ししてマングリングしないといけないやつじゃん

Cは_Genericで頑張れば

個人的いはCにがんばってほしい

>>199
> _Generic

（´･∀･`）ﾍｰそんなのあるんだ勉強になりました
これあったら十分やわ

ジェネリックってプログラミング言語によって指すものが異なってるよな
異なるといってもレベルの低いもの高いもの玉石混交という意味で

IoT, AI でも、Elixir もある

Nerves は、最小のLinux, Erlang を含む、組み込み向けOS

Nx はテンソル用。
TensorFlow, PyTorch のフロントエンド

Erlang VM のFFI で、他言語のモジュールも使える

Cは文字列が弱点だった
ちゃんとした文字列の型があればもっと便利だったとおもう

nimはもっと広まって欲しいかな。できればpython置き換えるくらいに。

>>197
てかLinusはそんなにその言語がいいと思ってるならそれでお前がなんか作ればいいだろって話をしてるな。
ここの連中なんかはまさにそんな感じだが。

これはなかなか面白い記事だった
原点回帰というか、ここのスレでの議論にも参考になると思う
お前らの感想を聞きたい

How the C programming language has grown
https://opensource.com/article/22/3/how-c-programming-language-has-grown

結局言語は道具。結局は何を作るかなんだよ

ネイティブ言語に変換できるビジュアルプログラミング言語とかいいと思う
オブジェクト指向とかわかりやすいだろうし。
唯一問題なのはマウスとキーボードをせわしなく行き来することかな
以前Blockly使ってそんなの作ったけどソースコードどっかやっちゃった

なんだァ？てめェ……

そうです、わたすが変なおじさんです

Rustのスレ複製おじさんが暴れまわってるから怖くなっちゃって見てないわ
あんなスレ見てたら気がおかしくなりそう
ここはまだまし

頭おかしなるで

>>181
「なぜオブジェクト指向はクソなのか」
１データ構造と機能は一緒にすべきではない
２すべてがオブジェクトである必要があります。
３データタイプ定義はあちこちに散らばってしまう
４オブジェクトはプライベートな状態を持っている

最近はモジュールがまた流行ってるよね
rustもGoも自分から見るとモジュール指向に見える

自分はモジュール型からOOPに進化した過程を知ってるから正直モジュール型は好きじゃない

＞すべてがオブジェクトである必要があります

C++やJavaみたいにすべてがオブジェクトじゃないオブジェクト指向言語なんていくらでもあるじゃん

>>216
そういう意味じゃないよ
https://gist.github.com/posaunehm/4087971

真のオブジェクトっていうのは、一つのスレッドみたいなもので他のスレッドとの通信をメッセージパシングでやりとりするものと言っていたような
一方、普通にいわれているオブジェクト指向というのは単なるプログラミングの書き方の効率化の手法にすぎないって話
つまり、継承という方法で差分だけ書いていけるようにすることによる効率化だけの話だってこと。

差分プログラミングならまあクソでしょうね

今のオブジェクト指向継承あんま使わなくね？

むしろ継承はクソすぎて足を引っ張る
そのためGoやRustなどの言語ではclassを廃止というか最初から採用しなかった

>>216
一言でいえば、プリミティブ型のことを言ってるんじゃなく（オブジェクトに）メソッドがぶら下がる粘着性を言っている。

いまどきの言語はRustやGoならstructで、Goならダックタイピング、Rustならクレートによるimplでそのデータを扱う機能実装を行うが
さらに考えを推し進め、D言語などでは(Pythonのself引数のように)データを引数に取るUFCと呼ばれる使い方も出来る。
関数が第一級の言語要素という考え（第一級関数）は、関数型言語には必要不可欠とされmap/reduceなどの高階関数でも
常用され、クロージャ・関数オブジェクト・無名関数と幅広く展開される。
OOPLとの明確な違いは、Classに対するオブジェクトにmethodという関数が束縛をされていないことである。もちろん上記の言語は
OOPSをサポートするが、それは多態を表現できるだけの意味しかない。

以上、D言語の宣伝です。

>>222
> Rustならクレートによるimplで

ちょっと惜しい
『トレイトによるimpl』が正しい
その後にD言語は更に進んでいるとの宣伝と書いてあるようだが
Rustにも当てはまることばかりなので違いがよくわからない

DのUFCSは任意の関数に適用できるけど
Rustは第一引数がselfなassociated functionだけだよね

typescriptでclassを使わないでやったときに無限にf(g(h(x)))みたいに書いたなあ
tsにもほしいわ

どうしてDって今のgoやrustみたいにならなかったの？

DのUFCSもメンバ関数やネスト関数などには適用できない制限がある

UFCSなんかなくても最初の引数の型に対してメソッド定義するだけで目的達成可能
グローバル名関数を増やして名前空間を汚さずともその型のメソッド定義がベター

>>225
GoやRustはclassなんか無くても各型に対してメソッドを定義できるのでそういうことを招かずに済むのよ
UFCSのメリットはメソッドチェーン記法が可能になることだから最初からメソッドを定義すればいいものね

>>229
structかenumは定義する必要あるじゃん
tsのtypeがどういうものか分かったうえでレスしてる？

>>230
structやenumは単なるtypeだよ
C言語でもstructと(enumの代わりにタグ無しの)unionがあるよね(ただしメソッド定義はできないけど)

Nim言語にもUFCSがあって関数だけじゃなくtemplateやmacroも関数と同じ文法で呼び出せるのでUFCSが使える。ただし第一引数がuntypedだとmethod call syntaxが使えない。
UFCSのメリットは標準ライブラリとか他人の書いたコードにある型とプロシージャの組に対してもmethod call syntaxが使えることだと思う。
第一引数が組み込み型のプロシージャを定義すれば組み込み型に対してmethod call syntaxが使える。
ライブラリAで定義されている型Xのオブジェクトに対してまったく別に書かれたライブラリBで定義されているgenericsなプロシージャをmethod call syntaxで呼ぶ出すことができる。

>>230
structやenum以外でもOK
任意の型にメソッドを定義可能

>>228
オーバーロードがある言語なら引数が一つ以上あるグローバル関数を追加しても引数さえ異なれば同名の関数をグローバルに追加できる。
UFCSとオーバーロードがある言語では第一引数がFoo型の関数を定義するのはFoo型にメソッドを定義することとほぼ同じとみなせる。

つまりUFCSは汚染でありリスク要因
定義していないメソッドが使えることになってしまう
UFCSがなくとも明確にその型に対して定義されたメソッドのみ対象で実用上困ることはない

モジュールがあるなら関数のimport有無でどの関数が呼び出されるか制御できたりしないの？
Rustのtraitのuseみたいに

>>235
UFCSのあるNim言語をよく使っているけど特に問題無く使えてるよ。
ライブラリAで定義された型を第一引数に持つ関数をライブラリAの外で定義してもgenerics/template/macroなど使わない限りライブラリAから呼び出せないし、ライブラリA内で使われている関数を外から勝手に上書きできない。
メソッド呼び出ししているように見えてもライブラリA内のプライベートな変数/関数はライブラリの外からアクセスできない。
method call syntaxってa.fooMethod(b)って書いてあるのを
コンパイラがfooMethod(a, b)という関数呼び出しとして解釈しているだけでなんのリスクもないよ。
第一引数にFoo型のオブジェクトをとる関数を定義してもオーバーロードがあるのでFoo型を使わない人には何の影響も与えない

D言語のプロジェクト見て半笑いになるのやめてさしあげろ

>>236
Nim言語だとimportするときにfrom std/strutils import `%`みたいに特定の型/関数だけをインポートすることができるよ。
もし同じ名前で同じ引数の関数が複数定義されている場合は関数名の前に"モジュルー名."をつけないとコンパイルエラーになる。

結局UFCSは不要だよな
メソッド的に使いたいならば最初からその型にメソッドを生やせばよいだけ
必要ならばジェネリックに定義すれば複数の型に同時にメソッドを生やせる
わざわざグローバル関数にしておいてからメソッド的に使えます！とかメリットを一切感じない

>>240
標準ライブラリにある型とか他人のgithubリポジトリにあるライブラリにも自由にメソッド追加できるの？
ジェネリックにする必要が無いときでもジェネリックにしないとメソッドはやせないの？

Nim言語にはそもそもC++のメンバ関数みたいなのが無くて、第一引数がFoo型の関数がFoo型のメソッドの代わりみたいになっている。

>>241
ジェネリックである必要なし
もちろん同じ機能を複数の型に適用ならジェネリックで1回で済むのが普通

>>241
うん
標準ライブラリや第三者ライブラリにある型にもメソッドを増やすことができるよ
だからUFCSが無くても困らないよ

UFCSがあれば引数が一個以上持つ関数であればa.f(b)ともf(a, b)とも書ける。
a.f(b)とf(a, b)の両方で書きたい場合があったらどうするの?
UFCSがなければa.f(b)で呼べるメソッドがあるときジェネリックな関数の中でf(a, b)の形式で呼ばれていたら、わざわざ新しくa.f(b)を中で呼ぶf(a, b)を定義しないといけない。
逆にf(a, b)な関数があったときに新しくメソッドを定義しなくてもa.f(b)と書ける。
それとNimだとcommand invocation syntaxがってf a, bという文法でも関数を呼べる。括弧がないので引数が複雑な式にならなければ書きやすくて読みやすいよ。

>>244
Rustでも可能
例えばu64型のxに対して
xのn乗はu64::pow(x, n)という関数が標準であるけど
これはx.pow(n)と呼び出すことができる

>>225
js/tsなら言語仕様拡張せんでも関数合成だろう。

>>231
>>233
tsではどうやるの？

>>241
既存の型にもメソッド追加できるよ
例えばJavaScriptならこんな感じ

// 文字列にhello()を追加
String.prototype.hello = function() {
console.log(`Hello ${this}!`);
};

// 数値にhello()を追加
Number.prototype.hello = function() {
console.log(`Hello ${this}!`);
};

"abc".hello();
// 123.hello(); // 文法エラー
let num = 123;
num.hello();

Rustではジェネリックにメソッド追加することも可能

// メソッドhello()を持つトレイトHelloを宣言
trait Hello {
fn hello(&self);
}

use std::fmt::Display;
// 表示可能トレイトDisplayを満たす全ての型に対してhello()を実装
impl<T: Display> Hello for T {
fn hello(&self) {
println!("Hello {self}!");
}
}

fn main() {
"abc".hello();
123.hello();
}

既存の型へのメソッド追加はプロトタイプ汚染とか言われて忌避されてるよね
他モジュールへの影響の出ない形でメソッド追加する手法が望ましい

>>250
JavaScriptはプロトタイプがグローバルに書き換わり全てのモジュールに適用されるためだな
一方でRustはメソッドを追加するにはトレイトを用意することが必要、そしてトレイトが宣言/useされている空間のみ有効、なので汚染が生じず安全

>>251
型を定義した以外のcrateでメソッドを追加するためにはtraitが必要、が正しいかな
メソッドを追加するためにはtraitなしのimplを書く方法もあるが、これをできるのは型を定義したcrateだけに制限されているので他crateで定義を追加して汚染することはない

とまあRustの事情は知ってるんだけど、他の言語ではどうなってるのかが知りたかった

知ってるけど今そんな話してるんじゃないんだわ

JavaScriptで脆弱性を生みまくってさんざん問題視されたんだから、いまどきそんな汚染が起こる新しい言語は一つもないよ

他の言語でもメソッド追加方法を教えて
今のところ
JavaScript　>>248
Rust　>>249

発端になったD言語のUFCSハブられてるのなんで？

>>256
UFCSはメリット無いからでしょ
メソッド追加できるなら関数よりメソッドの方が名前空間を汚さないし

>>256
nimには採用されてるし、調べてみるとC++にも導入の提案がされてるみたいだから、それほどハブられてないのでは？

Bjarne Stroustrupの提案: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4174.pdf
Herb Sutterの提案: https://isocpp.org/files/papers/N4165.pdf

UFCSはメソッド名空間の汚染
だから採用しないのが正解

結局メソッド生やしたいんじゃなくてプライベートメンバにアクセスしたいだけなんだよな

>>259
汚染言うならRustのtrailと同レベルじゃない？

関数をincludeしなければ影響無いんだし、言語次第だけど名前空間に閉じ込めることもできるだろ。

>>261
Rustは一切汚染しません
何を誤解しているのですか？

いやトレイトで似たようなメソッドがたくさんぶら下がって汚染されてますよね？それが更にハードルが上がる一因になってる

>>263
Rustでは明示的にuse Traitしない限り
そのトレイトのメソッドが有効になることはないよ
汚染は起きず安全に設計されている

>>264
当然、D言語でもnimでも、importしたシンボルは、importされたスコープでしか有効にならないし、メソッド形式の呼び出しもできない
Rustと何が違うんだよ

UFCSは強制汚染
関数として必要なだけなのにメソッド名空間を汚染
メソッドとして必要なだけなのに関数名空間を汚染
だから採用する言語がほとんどない

>>264
イヤイヤ、そんなのほとんどの言語でimportやincludeと同じで更に言えば、use std::io::prelude::*;みたいにRustでもPythonでも
誤ったやり方とされてるワイルドカードだって使えるんだから一緒でしょ。明確に言うなら”汚染は起きず”ではなく、汚染は当然ながら
useするのだから起きている。無意味にuseしない*を使わないというのは言語仕様や特性じゃなく規約だよ

スコープやシンボルが限定されてるのに汚染と呼ぶのはおかしい

>>267
Rustでは追加メソッドを使う場合
必要な機能のTraitだけを
use TraitName as _; する
そのため汚染は起きない

>>264
ほんとRustニワカ嫌いだわ、「明示的にuse Traitしない限り」なんて良くそんな詭弁が言えるわ。どう考えても一緒でしょう
だからPythonだってas構文使えますし、D言語だってimport std.stdio : writeln, writefln;で選択的インポートできるでしょｗ

Rust聖戦士がワラワラ
他の言語のスタイルはすべてアンチパターン

>>269
Underscore importなんてRustがトレイトのシンボルが別のシンボルと競合する可能性がある場合、つまりRustが破綻しないように
特別にあるだけで、汚染の低下のための機能ではないぜ。ここで汚染といってるのは無暗にメソッドが追加される事。
（回避策が仮に無ければ）衝突することはもはや、言語的な欠陥だ

使われる空間に名前が載ることを汚染とは言わない
使わない空間に名前が載ることを汚染と言う

UFCSが汚染と言われる理由は
関数として使いメソッドとして使わなくてもメソッド名空間に載り
メソッドとして使い関数として使わなくても関数名空間に載るためだと考えられる

>>273
Rustだって、fn中にuse出来るわけでそれはほかの言語でも同じ。そう言う事はあまりしないけども、多くの言語で同じように”使われる空間”だけに載る

RustがUFCSを採用しないのは単に、パーサーをオブジェクトを先して作り直すと（C言語にわざと似せてる）見た目が変わってしまうし
パーサーに手を入れるということは苦労してきたコンパイル速度が低下してしまう恐れがあるという事だけ

>>273
その程度で汚染とか言うの聞いたことねえよ
ESModuleとかが導入される前のJSのグローバル汚染なんかと比較してみ？
Rust上げしたいがためだけのただのイチャモンだよお前の主張は

>>272
Rustでは汚染は起きないですよ

>>274
そうです　
だからRustでは>>273の汚染という状況は発生しないですね

そもそもUFCSは汚染だなんてここ以外で聞いたことがないんだけど

>>273
UFCSとやらはムダに汚染しまくるクソな機能だな

Rustの宣伝はこんな匿名掲示板じゃなくQiitaとかに書いてほしいな
その反応で実際に正論なのか暴論なのか明らかになるだろう

UFCSという汚染機能をサポートしているプログラミング言語はDとNim
埋もれた言語となったのも当然の結果

汚染だとか書いてるのは全部ガイジだな

ほとんど全ての言語がUFCSを採用していない理由はメリットが無いからだと思う
そして無条件に二つの名前空間に登録されてしまうことを汚染と呼ぶかどうかは置いておくとしても本末転倒の方法かなとは感じる

>>275
さらにRustは実装としてUFCSを別の意味で誤って使っていた過去がある、::パス構文で混乱を引き起こして曖昧性が起きた。2017年頃でそんなに優れた開発者がおらずなんとなく実装していた時期だな、いつもはRustは論文がしっかりしてると嘯くのに

やっぱりUFCSは悪だな

次スレはもうRust消そう
話にならん

>>286
Rustは関係ないんじゃね？
むしろRustのアンチ側がなぜかRust叩きしていて巻き込まれ被害側にみえる

どっちでもいいよ
信者だろうがアンチだろうがあらゆる話題がRustとの比較になって宗教戦争化するのが馬鹿馬鹿しすぎる

Rustの話題はスレ違いなのでRust叩きもスレ違いとする、問題解決

ほぼ全ての言語がUFCSを採用していない
しかしUFCSが叩かれるとなぜか必死にRustを攻撃してくれる
一石二鳥と言えるだろう

C++委員会での議論でもメンバ関数と非メンバ関数で衝突したときにどう解決するかで割れて否決されたみたいだし、なかなか難しそうだね

考えてみたがUFCSは完全に不要っぽい
まずメソッドとして使いたいものは最初からメソッドとして書けばよい
次に外部の関数をどうしてもメソッドとして使いたいならばその外部関数を呼び出すメソッドを追加すればよい

衝突が問題ならUFCSの使用は記号などを使って明示したらいいんじゃないかな？

「Rustを攻撃」ってどっちも同じでしょって言ってるだけなのに、このように攻撃を受けたと勘違いするんだから、正常な議論なんて出来ない。
UFCSについて難癖付けてるだけじゃん、個人的には別に必要ないと思うし、仮にあったら便利だとも思うが。コンパイル時間が増えるのは許容できない
「Rustのアンチ側」なんて言い出すクズどもとまともな話なんて出来るわけない。
こんな奴らばっかり増やしてもRustの普及を妨げてると思うんだけど？

スレ読んだけど
汚染でも何でもなくRust特有の問題でもないことをRustは汚染だと延々と叩いてるのは異常に感じた

今のところUFCSがある言語と外部のデータ型に対してメソッドを追加できない言語、メソッドを追加できる言語とできない言語のそれぞれは前者が勝手で勝るけど、前者同士では好みとか実現手法の違い程度の話のように感じてる
UFCSも結局モジュール単位で環境が分離されている事が殆どのようだし、どちらかじゃないとできない事も、どちらかだと発生する致命的な不都合も見えてこない
一見機能が不要に見えても、その採用理由が他の要素に起因してたりもするだろうし、その辺私はUFCS採用言語のことを詳しく知らないのでなんとも言えないな

>>292
C++での議論では当然そういう案含めていろいろ提案されたけど、結局どれも一長一短で委員会での合意には至らなかったみたい
一人で作ってる言語なら作者の好みでサクッと入れられちゃうんだろうけどね

汚染と言わなくても、Rustがuseで似たようなメソッドがたくさん出てくるのは本当でしょ、UFCSにしてもそれはイコールで何ら変わらんわ
なんでこいつらマトモに話すら出来ないの？コーディング能力を持ってるんだろうけど、コミュニケーション能力はゼロに近い

メソッドが動詞ならUFCSでは関係が逆になるんだよね
英語圏の人はどう思ってるんだろ

>>298
OSV言語の自然言語に近くなるから、オブジェクトが先に来るのは利点として受け止められてる。でも所詮はシンタックスシュガーの何者でもない

>>297
> 似たようなメソッドがたくさん出てくる

そこ意味がわからない
似たようなメソッドがたくさんとは何？

C#にも拡張メソッドと言う名前でほぼ同じ機能が使えるけどそっちは拡張メソッドオンリーで使う前提で作られてる

似たような機能はいろんな言語にあるよね

>>299
英語はOSVじゃなくSVOな？OSVになることもあるけど、そして世界の自然言語の主流は日本語と同じくSOVが40%
参考としてスター・ウォーズのジェダイ・マスター：ヨーダは、このOSV語順で話す。

var s=copy(section);
paste(s);
みたいなのがあって

これを
paste(copy(section)):
とするより
section.copy().paste();
のほうが受け入れ易いってことだよね？

>>304
最初からメソッドとして書けば済む

Methods! You will be written first, but many are not.

>>305
ところがどっこい var sのsはメソッドを生やせないstring型だ

常にメソッドを生やせるとは限らないし、元のクラスに必要以上の仕事を増やさないためにから拡張メソッドという概念があるんだよ

スコープでuse出来て局所ごとにsection.print()の意味が変わる場合も便利だと感じる？

メソッドじゃなくて関数や変数でも、スコープごとに意味が変わりうるのは当然のこと

拡張メソッドが欲しいのはまぁ分かるんだけど
UFCSまでいくと普通の関数のつもりが意図せずメソッド呼び出しできてしまう、みたいなデメリットの方が大きくなる気がするなぁ

なぜRustが叩かれていたのかようやく理解できた
Rustでは基本の型にも外部の型にもメソッドを追加できるわけか
そのためメソッドを自由に追加できない言語の人が逆恨みで叩いていたと

"test".print();が局所ごとに意味が変わると気持ち悪い

>>266
Nimだと「メソッド名空間」自体が無いから、そんな議論をするのは無駄だね。

>>312
え？logging.rsに"test".print();と書いてあるのと、printer.rsに"test".print();で意味が変わるのはなんも関係無くねえ？
つーか普通に関数でprint("test")だのsaveだの、getだの散々やってるじゃん。気持ち（悪い）の問題なんだろうけどさ

>>311
それはNimも同様。
むしろNimの方がメソッドと関数を統一しているから(記法が違うだけ)、より自然に拡張できる。

>ぜRustが叩かれていたのかようやく理解できた
>逆恨みで叩いていたと

こういうアホなことを言う狂信者ばかりだからだよ。

RustのメソッドとかC++のメンバ関数のような特定の型だったりトレイトに束縛された関数のようなものがNimにはなくて、自由関数だけがある。
だからNimからUFCSをとったらC言語のように全ての関数をfoo(x, y, z)って書かないといけなくなっちゃう。
UFCSがあるおかげでどんな関数もx.f(y,z)だったりf(x, y, z)とか自由に書ける。
UFCSで関数がメソッドになるとプライベート変数/メソッドにアクセスできちゃうって勘違いしている人がいるかもしれないけどNimではそれは起きない。
C++のメンバ変数に相当するものや関数のアクセス権はモジュール外にそれを公開するかしないかのどちらかしかない。

>>315
Nimでも自由にメソッドを追加できるならばUFCS必要なくね？？

>>314
逆にprint_to_printer()とか print_to_consoleとか書いてあったら発狂するかもしれんわ
一番使うdebug_assert_eqとかヤメテほしい・・・、あと帰ってくる正式な型名が異様に長くなるのもC++の悪いところを引き継い出るような感じがする

>>316
自由関数しかないNimは関数名空間が常に汚染されてしまうのね
普通のプログラミング言語ならばメソッド名として名前空間が分離されるのよ

std::iter::emptyは名前空間を汚染するので使ってはいけません

アホか

>>319
1つも調べもせんのな、自由関数だけじゃなくmethodもある。つーかおまえRust使うの止めてJavaやってろ、まじ迷惑

グローバル関数じゃなくて？

>>317
>>316にまとまっているよ。
メソッドが無くて、ただの記法の違いでしか無いからこそUFCSのメリットを最大限享受できる。

>>319
メソッド名を関数名から「常に」分離するメリットは？
関数自体をモジュールとかで分離して管理できればいいんじゃないのかね。

やはり逆恨みで無関係なRust叩きやってる説が正しいかもしれん
Rustが無関係な状況でも>>321のように唐突にRustを出してくる

逆恨みだの、攻撃だの、ずーーとこんな事言ってる奴いるけど完全なびょーきだと思う。名前空間が汚染されないという言語はお前の中で具体的に何？

もうケンカしてる人らが最強次世代言語作れば

逆恨みとか、自我と言語が密結合していない限り出ない言葉だよな
用途目的に応じて言語を使い分ければ良いのに

つまりそういうことだ

おそらくNimの人がずっとRustを仮想敵にでもしてるのかもな
だからNimに不利っぽい書き込みがあるとRustの話がどこにもなくても無意識にRustを叩いてしまってるのかもな

ローカルのスコープしか影響しないのに、わざわさわ汚染とか言うの意味わからん
紛らわしいからやめろ

> わざわさわ汚染
タイポしてた
わざわざ汚染

例えば新しい言語が出来て人気を博したら、RustにもNimにもDにもSwiftなどにも存在しない機能や、シンタックスシュガーになるわけで
それを指摘したら、逆恨みだの、攻撃だの、アンチだの言いだしたらこのスレはマジ必要ない。
なんで無いのか考察を言ったり、コンパイル時間への影響とか、現行の構文が大きく変わってしまうとかそういうのを述べるならまだしも
UFCSが汚染だとキチガイのように書いてる。マジこんなやつ迷惑だろｗ

このスレを「汚染」で検索してそれら書き込みを見るとプログラミング言語名の最多登場がRust
なぜRustを汚染と叩く書き込みが多いのか不思議

>>228とか>>235みたいな、主観と思い込みによる断定から荒れ始めたんだよな
そこからおそらく自己正当化のために独自の「汚染」を定義
誰にも賛同されないと逆恨みだの攻撃だの仮想敵だの

>>333
それはもちろん同感だが
同時に発生しているRust汚染叩きは何なのだろう？

rustは錆なんだから汚染ぐらいでどうこう言うのもちょっと

Rustに対してとにかく言いがかりつけてるアレな人が前からおるやん
今回もそれだろ
有名人が叩かれる有名税みたいなもんや

いーや一番言いがかりで汚染されてるのはこんスレとロシアだと思いますわ。反枠＆陰謀論！病院池

有名税か
逆恨みやストレス発散でバッシングする連中多いもんな

>>332 >>334
事実に基づかない嘘で被害者面するのやめるべきだな。
このスレで「汚染している」と難癖つけられているのはUFCSだろ。次点でNim。Rustはあったっけ？

ケンカはやめて＞＜

ふたりを　とめて〜

有名税とか言う前にまずDとNimとUFCSを無理筋でこき下ろした件に対するごめんなさいは？

あと無関係な争いに巻き込まれたRustも可哀想

調べたところRustにもUFCSがあるようだけど。
https://doc.rust-lang.org/1.30.0/book/first-edition/ufcs.html

それ古い版のthe bookだし>>224の条件付きだからUFCSってあるってだけだよ

途中送信した
条件付きだからこれをUFCSと呼ぶのは誤用ってことで今は使ってないよ（>>284）

>>344
もちろんRustにもあるけど微妙に違うので今はUFCSとは呼ばなくなった
その微妙な差というのは既に>>245で書いたように

> 例えばu64型のxに対して
> xのn乗はu64::pow(x, n)という関数が標準であるけど
> これはx.pow(n)と呼び出すことができる

とメソッド形式でなく関数形式の時に型名等の前置パスで常に制限される

ほんのわずかだけ違うとはいえ
D、Nim、RustといったUFCS対応言語は2通りの記述方法が出来て便利で良いですよね

Goってマジで終わりかけてる？
使う価値あんまり感じなかったのは事実だけどｗ

バカヤロー、まだ始まっちゃいねぇよ

Goジェネリクスの実装とパフォーマンスについて
https://www.infoq.com/jp/news/2022/04/go-generics-performance/

>>260
ちげーよ。
記法の問題。

>>295
これが正しい

>>295
これが正しい

>>295
(UFCS方式を含めて)メソッドを追加できない次世代言語が存在するのですか？

頭痛くて寒気すると思ったら熱あったわ。

>>355
Rust、Kotlin、Swift、C#は拡張できるし、メソッド形式呼び出しがあるモダン言語なら必須機能っぽいけどね

最後にGoの悪口に収束するのは、おまいらの悪い癖だと思う

>>356
現代日本の片づけのキモはゴミ在庫の管理だ。 これはコンマリも言ってない..
pptppc2 「キモ」「ゴミ」とかいうワードが真っ先に出てくると身構えてしまう。

>>357
スレタイにある言語だと
TypeScriptもJavaScriptだからメソッド追加可能
残るGoは？

nimググってみたけどけっこう良さそうな言語じゃん。

Go開発者の92％が「Go言語に満足」
https://mag.osdn.jp/22/04/27/135700

>>360
自演乙

>>361
ガイジの中のガイジ煮詰めたデータに何か意味あるんか？

なんかの統計でphpも満足度が高かったような

Nimは100%ですよ

>>362
何いちゃもんつけてんだ。
nimは使ったことすらねーわ。ググっただけだ。
一応このスレタイトルのtypescriptとgoは使ってる。

サーチフレンドリな名前ではある

生存者バイアスとしか…

phpは障害者雇用枠だから

前にも書いたけど学校のサイトとかをワードプレスで運用してるところ結構あるんだよね
他の言語では先生達に書き換えて運用とか無理だと思う

PHPはそういう用途に向いてる
絶対そこはRustとかGoにはならない

言語と人を比較して言うのだが
PHPを批判するような子は
たいていPHP以下の存在
そして必ずPHPの作者以下の技量

たぶんPHPが存在してなければ、また誰かが気軽にwebサイトをさらっとかけるスクリプト言語をRustのようなシステムプログラミング言語で開発していただろう
そしてそれはPHPのようなものになるのだろうね

たしかにPHPが障害者を吸ってくれたおかげで助かってるところはあるかも
ITの汚物入れ、人類最底辺のクズ、エタヒニン・罪人
それがPHPoor

Reasonってどうですか？

https://reasonml.github.io/

こんスレってなぜかJuliaの話、完全スルーするよな。Go？Rust？Zig？Nim？時代遅れのローエンド言語や

>>370
GoとPHP、どっちも使わない人からしたら大して変わらない説。

>>373
よっぽど根に持ってるんだな。
ちょっと病的な感じ。

ローエンド言語なんて言葉ある？
ローレベル言語ならわかるけど

>>375
単に知られてないから話題に反応できないだけだと思う
良いところ教えてよ

Julia、せっかく新規言語で型付けと動的性のバランスを取れる立ち位置にあったのに、抽象-具象の継承ベースの型を採用した部分が個人的にジェネリクスと噛み合いが悪いと思っていて悲しい
1-originとかは正直瑣末事だと思ってる分そこだけが本当に合わない

一応最新バージョンだとパラメトリックな抽象型とそのパラメータに抽象型を使えるし、その部分型をパラメータにも抽象型コンストラクタ（？）にも適用できるから実用上十分なんだと思うが

JuliaのユーザーってPythonは当然として、他にはMATLABやRが競合になるようなコミュニティだから、
このスレとはまるで層が違うんじゃないかな
MATLABやRの話も全く出ないし

Juliaって計算科学や数値解析に特化した、R言語みたいなものでしょ？

Julia厨はクソみたいな押し付けするくらいなら
自分で他言語のライブラリの移植でもした方がよっぽど使ってもらえるという当たり前のことすら理解してないからな。

>>380
その継承が中途半端なことしかできないし
継承を採用したことも失敗してるし
Juliaはあかんね

継承は基底クラスと派生クラスの役割（責務）の分担が非常に難しいです。
よほど上手く設計しないと、すぐに「スパゲッティ・オブジェクト・プログラム」ができあがります。
継承は実装の再利用という面があるので、得てしてコピペの代わりに使われがちでもあります。
既存のあるクラスの振る舞いをちょっとだけ変えたいから継承を使おうってやってしまうと、
派生クラスのソースを見ただけでは何をやってるのか全くわからない最悪のコードになります。
まだコピペのほうがマシなことも。

最初はちゃんとクラス階層の設計がされていたとしても、だんだん皆が使う共通ルーチンを基底クラスに持たせよう、としてしまうとか、
基底クラスは、すぐに、巨大かつ影響範囲が広すぎてイジれない「神クラス」になるでしょう。
この場合の基底クラスの役割は、グローバル変数そのものと言ってよいですね。

とにかく、継承を使うと、コピペ、グローバル変数の使用、といった「禁じ手」と実質的に同じことが簡単にできてしまいかねません。
もし継承を使うのであれば、かなり注意が必要です。

その一方で、継承でないと絶対にダメという用途もあんまりないのです。
継承を一律禁止してしまってもそんなに困らないところがあります。
そのため最近ではGoやRustなど言語の仕様として継承（インタフェースではない実装を持つクラスの継承）を禁止している言語が増えているという有り様です。

今北産業

長い。そして間違っている。
Rustは代わりにtraitで継承を表現できるが、Goは表現する方法はなく、似たことをするとデータ構造を弄くることになる。
そもそも継承においてはデータ構造と実装の併合が問題なので、あとは察してください。

じゃあ継承使わないでプラグイン機構使いたいときはどうすんの？

プラグイン機構とだけ言われても意味が一意じゃないと思うけど
mixinのことかいな？

Composition over inheritanceは30年近くも前のGoFですでに広まってるのになぜ次世代言語スレで話題になるんだろう

ていうかJuliaの型システム知らなかったから簡単に調べたけど具象型はsupertypeになれないとか書いてあるんですが
Juliaでもいわゆる継承の問題点はちゃんと回避されているんではないですかね

>>391
継承とジェネリクスとの相性の悪さが問題なのではないかな

>>390
その後に継承のデメリットの方が多いと分かってきたため
そのデメリットをどう回避するかが各言語の主題となっている

>>390
知った気になって語りやすい話題だからだろう。

実装の拡張を肯定しつつデータ構造を直接拡張しないところが重要。
それを字面だけ解釈して、結局は妥協でデータ構造が暗黙に継承するような、先進言語の形だけ真似した言語もあるくらいだからね。

>>387
Goだけがどの話題でも機能不足との結論になっていて悲しいです

クラス継承しか知らないプログラマーは何でも継承で表現しようとするために失敗しているわけだから
継承のないプログラミング言語で修行させればそこは学習できるはずだ

実際言うほど継承使わないからなぁ
共通的な部分を継承で済ます場合はあるけど
データもその共通部分がはっきりしているなら親クラスで定義するけど
ただフレームワークを使ってたらコントローラはControllerから継承みたいなのはどうしてもあるが

>>397
そこは移譲ではダメなの？

typescriptは不要だな。jscript .netといっしょで空虚だ。

マイクロソフト、JavaScriptに型宣言を追加しつつトランスパイラ不要の「Types as Comments」をJavaScript仕様策定会議のTC39に提案へ
https://www.publickey1.jp/blog/22/javascripttypes_as_commentsjavascripttc39.html

継承自体は悪くなくて設計が悪い
実際継承使わないパターンが多くなったのでそれもどうでもいい

クラスに当たるものに委譲で継承的なことをすると状態が問題になる
そしたら状態を持つのが悪いと言うまた不思議な話になる

そしてどんどん学習時間取られてみんな疲弊していく

委譲元のクラスが単体では問題なく動くのに組み合わせるとテストを通らない

よく見ると以上元のクラスの内部状態が必要になってるけど公開されていない
完全な設計ミス

interfaceに必要な要素を追加…などできずデフォルト実装を追加
こうしてゴミが出来上がる

継承はそのオブジェクトの内に閉じた処理、オブジェクトの外の処理でもリスコフ置換原則が成立する範囲ではスマートでいいと思うよ
ただ現実的な話、ビジネスルール自体がそうなってないケースが多い
オブジェクトの外の処理は多くの場合、処理対象の子クラスの型で分岐を求められる
これにオブジェクト指向で対処しようとすると、めんどくさいデザインパターンの洪水に呑まれる

オブジェクトの内側のことは継承でエレガントに実現しておｋ（嫌いなら使わなくてもおｋ）
外側のことは地道にpattern matchingで泥臭く頑張る
これでいいと思うね

キチガイ隔離すれの本領発揮

RustもJuliaやGoみたいに廃れて消えていく気がしている。
https://qiita.com/AKKYM/items/78c04840bc72d9db834d

ポエムすぎ。

このRustと同じ分類となる、更に便利な言語が登場しないと、Rustを置き換えることが出来ないだろう

＞ プログラミング言語は以下の3つに分類される
＞ CとC++　←『省メモリ高速』だが、「メモリ解放でミスると危険」
＞ GC言語　←『省メモリ高速』ではないが、「メモリ解放は自動で気にしなくていい」
＞ Rust　←『省メモリ高速』だが、「メモリ解放は自動で気にしなくていい」

>>405
妄想でつか？

JuliaはFORTRANを駆逐できましたか？

https://mun-lang.org/
Mun触ったことのある人いる？
ぱっと見GCつきのrustみたいに見える

>>410
文法や基本型はRustと同じっぽいね
ドキュメントを見る限りでは非常に小さいサブセットで開発途上なのかよくわからない

>>407
その分類、そもそもニーズが大きくない気がするし、
このまま競合は現れずに行きそうだよね。

>>410

Dlang: C++風のGC言語
Crystal: Ruby風のGC言語
nim: Python風のGC言語
Vlang: Go風のGC言語
Mun: Rust風のGC言語 ← New!

こういうこと？

VlangはGC無かったと思った

>>414
ほんとだ、ありがとう

>>412
重視されているからこそ
C/C++からRustへの移行(安全化)だけでなく
各種GC言語からRustへの移行(高速化)が起きている現実

>>416
ないわ～
pythonからRustってありえないよ

NumPy, SciPyのライブラリの実装FORTRANをCにベタ移植して更にC++でラップしたような物ばかりだったけどRsutへの移行は順調に進んでいますか？ｗ

それらPythonの使い方は単なる皮言語だからな
次世代言語スレで皮言語を持ち出す時点で頭おかしい

>>418
どの分野でもどの言語でも同じだけど
他の言語に移行するのは新たな物(仕組み・システム)を作る時だよ
そのまま移植は非常にレアケース
例えば古すぎるたり性能面で難があるけどアルゴリズムだけだから再設計せずそのまま他言語へ移植など

>>416
GCあり言語では、データ構造は気にしても、
メモリ操作を意識している人は、少数じゃない？
だから置き換えは、結構ハードル高いと思うけれど。

>>417
Pythonは、グルー言語でもあるから、
単純な置き換えは、そうそう進まなさそうだよね。

>>421
メモリ操作とは具体的になあに？
めったにない特殊なケースは除くとしてハードルが高いことなんて無いんじゃないかしら

>>422
低レイヤー言語だとメモリ読む前にキャッシュしたりアライメント揃えたりするでしょ

>>423
何それ？
よほど特殊なことをしない限りそんなコードを書くことはないよ
C言語でもアライメント気にせずに変数に値が入るし変数そのものがキャッシュだし

>>424
ｗ

>>424
他人のこさえたライブラリと構造体を受渡するときなんかは意識せざるを得んよな。
コレはレアケース？

>>426
それはFFIと言って低レイヤー言語だけの問題ではない
PythonでもJavaScriptでもある

元の話題
>>423
> 低レイヤー言語だとメモリ読む前にキャッシュしたりアライメント揃えたりするでしょ

例えばSIMD命令使うのが "よほど特殊なこと" に該当するかどうかという話？

この流れでFFIもSIMDも関係ないと思います
GCあり言語の普通のプログラムをGCなし言語へ置き換える話をしています

>>421
> GCあり言語では、データ構造は気にしても、
> メモリ操作を意識している人は、少数じゃない？
> だから置き換えは、結構ハードル高いと思うけれど。

>>422
> メモリ操作とは具体的になあに？
> めったにない特殊なケースは除くとしてハードルが高いことなんて無いんじゃないかしら

メモリ操作って言い方が曖昧なら、スタックとヒープを意識するかしないかって言い方ならどう？

GCあり言語でスタックとヒープを意識するような事ってあまり無いと思うんどけど。

>>430
GCなし言語でどうしてもスタックとヒープを意識しないとプログラミングできないことってある？？

>>431
ありなしで言ったらあるでしょ
性能意識するコードとか

>>432
それは性能をよっぽど気にする特殊な場合だけでしかもその中の一部のコードだけやろ
それ以外は関係ないやん

言うほど低レイヤーコード書いてるやつはここにはおらん。
だから話がおかしな方向に行く。

>>434
GCあり言語のコードをGCなし言語にする話だから
低レイヤーコードなんて一切関係ない

スタックは普通に意識するでしょう、末尾最適化されてないナンチャッテ意識高い系の再帰呼び出しとか直すけど・・・
GCアリ言語でも無しでも、スタックサイズは普通に意識する。
ヒープは言うほどRustは組み込みに使わないし、トヨタが使うというてもそれはメモリコンパクションのあるようなOSが載ってる場合だから
本当の組み込みじゃないし、でもアロケーターが64byte-4kでもVec::with_capacity(size);とか普通にIO系の処理では意識するでしょ

>>436
Rustはヒープ無しでも動作するからヒープを意識しなくていいのはその通りだが
ヒープが有る場合でもVec::with_capacity(size);等は動作最適化を手動でする時のみ必要であって、
プログラマーは何もしなくても全自動でcapacity拡張してくれるから意識しなくてもよい

>>433
そもそもの質問が「ヒープ意識しないとプログラムできないことってある？」だから、反論になってないよ
頻度は問題にしてなくて有無の話だから

>>438
それは君の方がおかしい
今回のこの文脈ではそこは意識する必要がない

＞GCあり言語の普通のプログラムをGCなし言語へ置き換える話をしています

ベクタの使用領域の大きさはどちらの言語でも自動的に拡張してくれるのに任せればよいから意識しなくてよい

GCありの言語で循環参照するようなデータの持ち方をしまくってるようなコードだったりすると、
そのまま移植できないだろうし面倒かな？
場合によってはRustでいうArenaみたいなのまで持ち出して再設計しないといけなそう

移植なんてしたことないしあくまでも想像だけど

>>437
”Rustはヒープ無しでも動作する”、不正確でダウトといっても良い。”Box<T>を使わない場合、Rustは最小のメモリで動作する”
一般的に最小のメモリとはプログラムをメインメモリにロードした領域であり、それ以外にも、ヒープ解析すればRustの場合は、
Config structなどが多数メモリにロードされていることが分かります。後半の文は意味不明。

GCあり言語って一絡げにできるほど似通ってるんだっけ

>>441
知識が浅すぎる
Rustはヒープ無しでも動作する、で正しい
そのためRustの標準コアライブラリcore::はヒープ無しで動作するように作られている
std::のうちcore::以外の部分はヒープを用いており明確に両者は区別されている

>> ”Box<T>を使わない場合、Rustは最小のメモリで動作する”

意味不明
Box<T>はヒープを使う型の一つに過ぎない
それ以降の記述は全く意味不明

まじきち隔離所、顔真っ赤になってｗｗ

まーたRust信者がスレハイジャックしてる

ベアメタル等OSなしでも動作しないといけないため
Rustはヒープを前提とせずに動くよう設計されている

>>444
本当はスレ民のことが気になって仕方ないだろ？
隠しても無駄ｗｗｗ

なぜせっかくRustで作られたブラウザを除外するかね？

「NHKプラス」、「Firefox」での視聴が不可能に　5月23日から推奨ブラウザを「Microsoft Edge」「Google Chrome」「Safari」に限定 [孤高の旅人★]
http://2chb.net/r/newsplus/1651490664/

>>448
そのどれかのブラウザがインストールされてない端末って何がある？
Linuxと組み込みくらい？

「Firefoxはバグ

訂正：firefoxはバグが多いの？

Chromeより軽くてFirefoxオススメ

>>448
もし本当に視聴不可となったら技術力が無さすぎる
昔ならともかく今の時代にブラウザ依存なコードを書くのはダメなプログラマーの典型
視聴不可ではなく動作確認するブラウザの数を絞るなら理解できる

> 「Firefox」など、上記3ブラウザ以外での動作はもともと確認しておらず、推奨ブラウザには加えていなかったという。
> 「5月23日以降に予定している設備更新に伴い、Firefoxでは動画が完全に再生できなくなる

どういう設備更新なんだろうな・・・
WebKit系じゃないと使えない仕組みがあるのか

今どきはブラウザ依存な書き方する方が面倒だろう。普通にテストしてないだけでは。

>>454
あ、本当に動かなくなるのか。

chromiumにしか実装されていない独自拡張機能に依存したAPIに手を出したとか？？
でもSafariで動くなら違うか
Firefoxでだけ動かないコードなんて可能なのか？？

Chromiumは現代のIE6ですから

そういえばchromeにrust使う話ってどうなったんだ？

>>459
ああ、ごめん。さぼってたわｗ

たしかFirefoxもまだ全部はRustに治せてないんだろ

>>461
君は何らかの大きなシステム開発に関わったことがないのかね？
どんな言語と言語の場合でも一気にやることは不可能かつムダ
新規部分や改修部分に絞って手を付けていく

>>462
なるほど
だからよそと違ってバグまみれとか言われるんやなｗ

Chromeの方がセキュリティバグ多いよな
頻繁にバージョンアップしろと言ってくる

>>464
JVN iPedia - 脆弱性対策情報データベース。https://jvndb.jvn.jp/
期間指定なし
・safari 884件
・edge 1054件
・firefox 1989件
・chrome 3464件
期間指定2018/01から
・safari 48件
・edge 391件
・firefox 492件
・chrome 937件

とはいえ、Chromeのほうがローリングリリース・ローリングアップデートの期間が短い（現在は４週間)2021/3頃から6週間から変更された。
以前はFirefoxはローリングリリースを採用していないかった。またChormeの使用者がFirefoxより10倍なので脆弱性も発見されやすい。
何かと問題なSafariの脆弱性がこれだけのはずが無く、脆弱性報告数＝危険なブラウザとははっきり言えない

途中まで数字で語ってるのに最後だけ願望になっててワロタ

go-tour-ko.appspot
.com

>>466
Appleに報告した脆弱性、数カ月放置の後に「現在、調査中です」の返答
https://appleinsider.com/articles/21/09/27/apple-still-investigating-unpatched-security-flaws-in-ios-15

木を見て森を見ずという言葉を考えた昔の人はいいセンスしてる

Appleって莫大な利益を何に消費しているのだろうね

>>448
そもそもNHKは見ないのでどうでも良い。

>>470
そんなこと気にして何になるの？

>>472
ウィグル弾圧に使われてる可能性が高い。

Rust厨がウザいからだろ。

いまどきウェブ見てて落ちるブラウザなんてファイアフォックスくらいだし、そこらへんは忠実にネスケ以来の伝統を受け継いでて驚く。

トリビア：Firefoxユーザーはレベルが高いの致命的なバグがあっても自分で治して使っている

>>475
ここ数年間の常用者だがFirefoxが落ちたことがない
もしデマカセを言っているのでないのならばどういう状況で落ちたのか語ってほしい

かまちょかまちょ

>>475
Chromeは週一ぐらいで落ちる
IME変換中に間違えてファンクションキーを押すと落ちる

落ちるOSってありそう

>>477
数か月前に頻繁にメモリ不足で落ちてた。タブがクラッシュする

>>481
それメモリが少なすぎたとか
メモリを超える巨大なデータを読み込んだとか
無数にタブを開いたとかそういうオチだろ

逆に100兆個のタブを開いて落ちないブラウザってどれ？

メモリ不足で落ちないブラウザもないと思います

メモリ不足を、クラッシュせずに通知くらい【余裕】にできないと。

当たり前のこともできない。所詮現世人類の我々の技術力はそこまでということだ――

>>477
Windowsでタブレットモードにしてると頻繁に落ちるな。

落ちるというか、無限ループしてるっぽいんだよな。
入力を受け付けず、タスクマネージャで見るとCPUをぶん回してる。

Linuxでは落ちないよ

頻繁に落ちるのに、落ちないとか信者が言い張るのも、ネスケ以来の伝統だよな。

英語設定のLinuxだけど落ちないよ？
バグってるのはサイトかホストなのでは？

Windowsでここ何年か使ってるけれど、
特に気になる動作は無いけれどな。

Edgeの印刷で返ってこない方が辛い。

FireFoxで微妙に表示が崩れるとChromeだとちゃんと表示されるのか気になる
表示させてみて同じだとホッとして違ってたらがっかり

Safariが恨めしそうにこちらを見ている

Rustが、Goの最大の競合相手であることが明らかになったってよｗ

プログラミング言語「Go」、開発者の満足度やニーズは？
https://japan.zdnet.com/article/35187065/
また調査では、Goの主なライバル言語が「Rust」「Python」「Java」「TypeScript」であることも明らかになった。RustとGoは、どちらもシステムプログラミング言語であり、開発者には広く評価されているが、「JavaScript」や「Python」ほどの人気はないようだ。

　しかしこの調査では、Amazon Web Services（AWS）、Google、Microsoftの支持を受けているRustが、Goの最大の競合相手であることが明らかになった。Goの代わりに選ぶとしたらどの言語を選ぶかという設問では、回答者の25％がRustを選ぶと述べており、17％がPython、12％がJava、8％がTypeScript、8％がC#と回答していた。

　「最もよく選ばれているのは、Rust、Python、Javaだ。RustとGoの機能セットは補完的な関係にあるため、あるプロジェクトに必要とされる機能がGoにない場合、Rustは優れた選択肢になるかもしれない」とMerrick氏は述べている。

>>494
競合なのは事実だろうけどGoやってるような人はRustも必要になれば普通に使えるでしょ
エンジニア目線では特に対立関係にないから煽っても無意味だぞ

競合ではなく両方利用
Goで不十分なところはRustで書いている
どこでもそうだよ

それができるんならCでいいじゃん

理想の家族

父 40歳 海外へ単身赴任(死ぬまで)
母 35歳 息子に甘い
姉 17歳 弟に甘い
俺 44歳
妹 15歳 多感な時期 俺に反発しながらも。。？
猫 ウンチしない 抜け毛ない 俺の声かけに無視しない

>>495
そうだぞ。
競合なのは事実だろうけどGoやってるような人はRustも必要になれば普通に使える、という体で話さないと嫌われるぞ。
それに、裁量権のない作業者の間では対立関係にないから煽っても無意味だぞ。

低レイヤーはRust
高レイヤーはGo

この使い分けじゃいかんの？同じシステムプログラミング言語でも毛色が違うだろ

GoogleとMicrosoftがRustに注目しているのもOS開発の目的であってGoでOS開発作ろうとはならんでしょ

主張はわかるが、これはもしや片思いみたいなものではと見ている。

仮にGoユーザーの多くが低レイヤーにRustを使いたい結論だったとしても、
Rustユーザーの多くが高レイヤーにGoに使いたいという結論にはならない。
よってカップル不成立。

例えばウェブサーバーサイドもRustで書いたほうが早い速いしな

低レイヤーのことは低レイヤーガールに聞けよ

Goは良くも悪くもCっぽくって人間が気をつけて書かないといけない部分が多いんだよな
一度Rustに慣れてしまうと、Goで隅々まで気を使うのが面倒くさくなってしまう
もちろん既存のGoプロジェクトはGoのまま書くけど、新規ならなるべくRustにしたくはなるな

LinusはgitをC+シェルスクリプトで書いてた
書こうと思えば書ける

でも普通に記述に時間がかかるので今は他の言語も役割分担してる

Rustはデータ競合らへんは起きないけど、Box、Rc、Arenaを気をつけて使い分けないといけないのとか面倒だと思うけどな