◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ:次世代言語25 TypeScript Swift Go Kotlin Rust Nim YouTube動画>4本 ->画像>2枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1650185555/ ヒント： http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
スレタイ（順番はRedMonk準拠）以外の言語もok
前スレ
次世代言語24 Go Nim Rust Swift Kotlin TypeScript
http://2chb.net/r/tech/1647887021/ セックスも男女関係を円滑にする一つの言語なんですよ。
プログラミング言語は以下の3つに分類される
「省メモリ高速ではない」はNANDなのかNORなのか
このスレは実質「Go vs Rust」のスレです。
僕は生前、同業・Googleの言語センス同調圧力に抗うも努力は虚しく、無残な敗北を余生噛みしめる結果となった。
ＰＨＰの”勝ち”やね・・・
>>7 PHPもタイプヒンティングちゃんと使っていったら悪くないんじゃないかね。
結局日本国内のWeb系じゃ一番使われてるし。
C++使っててもコンテナクラス使うかスマートポインタを普通に使っていればメモリリークすることは殆どないでしょ。
go とrust が合体した言語があったらいいのに
>>10 リークというかダングリングだけど、人が書いたメソッド中身見ないで使ってると参照切れてたり日常茶判事だよ
>>10 そういう問題じゃないんだよ
スマートポインタ使わないで実装できてしまうことでこれまでどれたけの脆弱性をうんだか、という問題
>>10 ・スマートポインタを使い忘れてもコンパイルが通ってしまう
・スマートポインタを間違って使ってもコンパイルが通ってしまう
後者はC++ベテランでも複雑化するとうっかりミスがある
・そもそも毎回unique_ptr指定が面倒かつ無駄なのでデフォルト適用にして欲しい
新しいプロダクトできました。メモリーリークはないです。
>>11 go要素いらねえだろあんな糞文法
なんどGoogle潰してやろうと思ったか
やはりRustが最強
JavaScript/TypeScriptの高速フォーマッター「Rome Formatter」リリース。Rust製でPrettierより約10倍高速と
https://www.publickey1.jp/blog/22/javascripttypescriptrome_formatterrustprettier10.html Rustの文法すごい好きだから、c#ぐらいのノリでかけて文法がRustっぽい式指向な言語が欲しい
なんでもその言語はC#のノリで書けるらしい
>>20 Rustの構文や標準メソッド等ほぼそのままに
所有権と借用ルールとライフタイムだけを削除というか無視して処理するGC言語『GC-Rust』を作るとよいかもね
プログラミング初心者入門用にもなるし速さ省メモリを必要としない場でも使えるような
多少遅くてもいいのだからインタプリタ型でも十分かもね
あとは所有権参照借用lifetimeだけ学べば本物のRustへすぐに進める
>>19 ツール系はいくつかrust製があるね。
ripgrepもなかなか良いよ。
>>22 あーそんな感じだな
GC付きのRust欲しいわ
もう調べてるかもしれないけどもっと現実的な話で式志向がいいならF#どうっすか
>>14 ,15,16
スマートポインタを使い忘れるってことはmake_sharedかmake_unique使わないでnew使ってるってことだからgrepすれば簡単に見つけられる。全ての関数の引数の型とクラスメンバの型に生ポインタが無いようにすれば間違った使い方をして生ポインタがでてきてもコンパイルエラーなる。（もしそれらに生ポインタがあっても正規表現使えば見つけられるだろうし）
>>27 そんな面倒なことをせずとも無指定でunique_ptr相当になるRustを使った方が楽でいいな
Rustなら他にも忘れたり間違えたりすればコンパイラがエラーとして詳しく指摘してくれるし
>>27 ある瞬間自分の書いたコードだけチェックできればいいってならその通りだとは思う
ただ実際には依存ライブラリや他の人が入れてくるコード全てを常時チェックし続けないといけなくなるし
もし依存ライブラリがnew使ってたとして毎回フォークして書き直すのか？という問題もある
巷に出没するRust信者自分でRustまともに書いてない説を提唱したい
そうなるとRustを広めたい勢力に雇われてる工作員の可能性出てきちゃう
>>28 引数渡しがデフォルトmoveじゃなければよかったんだかな。
デフォルトconst 参照で組まれていたらずいぶん学習しやすくなったと思う。
所有権のmoveセマンティクスらへんがRustの最大の文法的特徴なのに、そこがいらんとな
>>34 C++以外のユーザーがRustを学習するときの一番の難所でもあるけどな。
実際、不変借用は頻出しそうな気がするけど、性能ペナルティーとかあるのかね？
rustはインストール先がユーザーホームディレクトリの下なのが何だかな。
>>33 それはおかしい
一般的に参照を引き渡すということは様々な問題を生じさせるということ
競合の種も産むし参照切れの種も産む
だから参照を引き渡す方が記述コストを増やすことこそ道理
次に
C言語でもポインタ参照渡しは＆を付けて表記する
したがって無印よりも＆前置こそ参照渡しに相応しい
>>30 これ。
見つけたからってどう住んだよ？って話だよな
他社のコードを修正できないし、そもそもそんなチェックを未来永劫担当者に引き継いでいけるのか？ってこと
個人でできることと、組織やプロダクト関係者全体としてできることは違う
>>30 ,38
そんなこと言ったら、Rustでも他人の書いたコードにunsafeが入ってる可能性もあるでしょ。
>>33 Nim言語だとデフォルトで不変コピー渡しだけど引数のサイズが一定サイズ以上（確かポインタサイズの3か4倍以上）だとポインタで渡すようなコードを生成するんだよね。
>>37 Rustは参照を使ったときの問題が起きないようにコンパイル時にチェックしているんだからデフォルトがconst参照渡しでも問題ないんじゃないの?
Rustって借用したり借用を参照するときに&や*をつけないといけないけどその結果コードの見た目が生ポインタを使ってるCのコードに似てるんだよね。暗黙に借用したり参照しちゃダメって考えでそうなってるんだと思うけど。
>>39 ＞Nim言語だとデフォルトで不変コピー渡しだけど
＞引数のサイズが一定サイズ以上だとポインタで渡すようなコードを生成するんだよね。
この議論でそんな話を持ち出す時点であなたは以下の理解が足りない
一般的にプログラミング言語によるセマンティクスと最終的に生成されるコードは全く無関係でありそこに関連があってはいけない独立のものである
完全に独立したものであるが故に最終コード生成オプティマイズを十分にすることが可能となる
プログラミングを勉強しようと思って
生成されるコードがプログラミング言語のセマンティクスと無関係じゃだめでしょ。
>>44 あ、すまん。これ誤爆しました。スミマセン〜。
「プログラミング言語によるセマンティクスと最終的に生成されるコードは全く無関係」そんな訳ない、RustはLLVMのIRを前提に
>>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でも使用してますし
Kotlinみたいな出力先がjvmとjsとネイティブがあるのは
>>63 そんなことは誰でも知っているがこの流れとは無関係な話
各FFIはそのFFIの指定に従う
逆に言えば各言語の普通のコードではFFIなんて関係ないので各言語で完全に自由
だから引き数や戻り値のサイズに拠ってポインタ渡しか否か変わる言語もある
プログラマーはそれらを知らなくてもプログラミングできる
各言語が定めるセマンティクスだけ理解すればプログラミングできる
つまりセマンティクスと生成コードは完全に独立した別階層であり無関係
この話の終着点どこ？
>>33 変数の代入がmoveなのに関数引数の時だけ参照になるのは紛らわしくない？
>>59 あ、不変前提ね。勘違いしてました。
>>67 変数もデフォルトで不変借用にする、とか。戻り値の受けが面倒臭くなりそうだけど。
>>68 Cの(ポインタ)参照が前置＆だから
Rustの(借用)参照も前置＆にした現状仕様がわかりやすいと思うけど、なぜ変えたいの？
>>68 変数の代入をデフォルトで参照にするとmutが絡んできたときにborrow checker周りでとてつもなく面倒になりそうな気がする
rustはライフタイム周りが途方もなく汚く見える
Rust「エラーには回復可能なエラーと回復不可能なエラーがあってResult<T, E>を使って~(長文)」
twitterでイキってるバカをそんなに晒すなよ。
なおイキッテルのはRUSTERのもよう
null安全じゃない言語とかこのご時世にあるんですね
スレタイの言語でも
GOはポイント使わなければ安全だぞ
>>77 このif文を書き忘れたらコンパイルエラーになるの？
>>72 > if err != nil {
>>74 これってgoありがたがる人を馬鹿にしたツイートじゃないの？
Goはnil安全ではない
分かりにくい人「円周率は3.141592...と無限に続く数字で、よく近似の3.14が使われます。」
視聴者「何で3桁なの？」「2の後は何なんだよ」「近似って何？」
分かりやすい人「円周率って色々言われてるけど、実は3なんです！」
視聴者「そうだったのか！」「やっと理解できた！」「数学って美しい」
https://twitter.com/zugaaanzubababa/status/1506569845693100035 https://twitter.com/5chan_nel (5ch newer account)
Goでは「値が存在しないこと」を安全に表す方法がないことが敗因
なおシェアはＧＯが圧勝したもよう
goはCがシンプルで使いやすいと思う人向けの言語じゃないかと思う
言語機能をモリモリにしたい誘惑に抗ってランタイムを充実させるという判断できる自制心はすごいと思う
Ruby 3.0 のJIT は、MJIT で、
ゴミが20%早くなかったからってどうしたってゆうね
>>87 でもRuby on railsってまだまだ使われてるよね？
有名どころでも、クックパッド、Airbnb、Gunosy、クラウドワークス、
食べログ、価格.com、Twitter、 Hulu、 GitHub
>>89 大規模railsを別言語で書き直しましたという
ニュースは時々出てくるけど逆は聞かないからなあ…
>>89 業界や会社によってはCOBOLだって使われてる。
いったんそれでシステム組んじまったら中々移行は出来んもんだよ。
>>80 >>82 Goはなぜそんな危険な言語仕様にしたの？
R○byは業界のSPA移行とPythonブームによって思いのほか綺麗に消えてくれたのは良かった
>>94 PHPユーザに失礼なやつだな
お前あれだろ？
刺し身に直接わさびを付けるタイプだろ。醤油でわさびをとかさないで刺し身につけて食べてね？どうよ？
>>94 言語マニアならpythonよりRubyの方がマシだろ。Pythonみたいにメソッドと関数が混在するのは書いててキモい。
python4でNim方式を採用してほしいわ。
もちろんプログラム記述方式としてはPythonは最悪
>>95 直接わさびを口に運び刺身を投入して咀嚼した後に醤油を飲むタイプです
PHPユーザに対し失礼な発言は謝罪して撤回させていただきます。この度は申し訳ございませんでした。
Haskellもインデントでスコープを区切ってた気がするけど一応ブレースでくくることもできるんだっけ
>>98 人類最底辺のゴミPHPoorに謝罪など必要ない
奴らに必要なのは死あるのみ
PHP使う人ってなんであんなアヘアヘ君ばかりなの？昔からああなの？
>>102 障害者手帳持ちでも書けるとガイジを集めたから
ガイジが作ってガイジが保守して、真人間は近寄らないか万一深淵を覗いてもすぐに逃げるから
ガイジだけが残った
それがPoopHPoor
言語の良し悪しと普及率はあんまり関係ないってことだな
良し悪しは文法だけでは決まらないしね
Haskellはとてもいい言語だと思うけど、まあ今後も広くは普及しないだろうね
Java(8以前)とPHPとVB.NETは案件も人材もロクなのにあたったことないし関わりたくない
小一時間でゲームをつくる──7つの定番ゲームのプログラミングを体験 (WEB+DB PRESS plus)
https://www. あmazon.co.jp/dp/4297127458
この本面白いね。
コンソールに出すアスキーアートだけでゲームを作るところと最小限の工程ごとに動作確認するところがユニークだ。
誰かこのなかのどれかのゲームをGoやRustに移植してgithubあたりにアップしてくれないか？
その出来栄えでその言語の優劣を競うというのはどうだろうか？
コードが書けないやつだからこそnull安全なんてほとんど誰もありがたかってない事を上のように一生懸命言い出す
>>113 これだからGo信者は… 本当に現代人？
／:|. ／:|
>>93 Goは言わば並列対応スクリプトC言語だからだよ
だから今どきの言語と異なりC言語のように地道に記述量が増えるとともに安全軽視で自己責任
男の人って気持ち悪い…
Rustならシンプルに分かりやすく書きやすい上に
Rustの話は専用の隔離部屋でお願いします
Rust part14
http://2chb.net/r/tech/1644596656/ 次スレタイトルからRustの文字を削除してください
比較の話だからここでいいんじゃね
比較の話も含めて
>>121 の専用スレでやって下さい
言語同士の比較はここでやる
ここは次世代言語スレ
>>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相当を扱ってしまう危険性は起きない
Goだって最近Tって書けるようになったでしょ
・Rustにはnullという概念のものが存在しない
>>133 糞バカ中世ジャップランド土人どもはOption.get()するだけだぞ
>>135 Optionにget()メソッドはありません
ほぼOptionのNoneと言ってるのに、null相当(nilやundefined等含む)を代入とか、Option<T>型となるため型が異なりとか
Rustのアドバンテージを認めざるを得ないから認めつつ
>>137 その通りだからきみはJavaとかHaskellとか使えばいいと思うよ
Rustの良いところを教えてほしいなら普通に指導を乞えばいいのに
null安全をlinterが警告してくれる言語なんてあったっけ？
>>140 未初期化変数へのアクセスのことを言ってそうな気がする
それ以外のケースでnullの問題踏んだことない人なのかもしれない
色々とプログラミングが楽で快適だからRust使ってるわ
普通に煽りじゃない反論ができない時点でRustニワカのキモさが良くわかる。Null安全を全否定してないのに
自分でこれが煽りじゃない反論だと思ってるならヤバい
Rustより良い言語が出現したらそれを検討する予定
煽ってるだけの書き込みにまともな返答がくるわけないじゃん
まだスレタイに出てないけど注目してる言語とかありますか？
flixかな
この根源的な差が決定的かな
>>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がなく、読み込み、書き込みのバリアも、カードテーブルマーキングもコンパクト化もない。コンパクト化が必要ないので、ポインタのフィクスアップも必要ない。
>>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号で、
Terraformが何なのかも理解せずにここプログラミング言語のスレに書き込んでいるのか
リスナーさんだか受講生だか知りませんが、KENTAさんの主張を引用するなら本人から許可を取って、
KENTA
2021年のWeb系エンジニア転職を成功させる3つの技術要素、2021/4
VIDEO Web系エンジニアを目指す人のためのプログラミング学習ロードマップ、2021/2
VIDEO 上の動画で、Terraform で転職を差別化しましょうと言っている。
それで、すべての雑誌・学校も動いた。
Terraformが出来ないと、転職に負けてしまうから
米国人からすると、日本のRuby on Rails は異次元の戦い。
10年以上のプロでも、1年ぐらいの初心者に負けてしまう
日本では解雇できないから、資格などの事前審査制。
米国では国民全員がフリーランスだから、ひとまず雇っても、すぐに首にできる
>>151 RustがメモリをGC並みに雑に扱えたら、最高だったな。
RcもWeakも無くなればね
Goはコンパイル言語なのにスクリプト言語のように扱える軽量さが最大の魅力だろ
GoはCGo何とかしてくれればもっと使う気になれるんだけどな
とにかくGoは頭の悪い人でもすぐにプロジェクトに参加できるぐらいに機能がシンプルに削ぎ落とされていてコンパイル爆速ってのがポイントな言語
>>174 本当にその通りなんだけど、これだけは欲しかったみたいな機能も一緒に削られてるところが少しモヤモヤする
ジェネリクス(ようやく追加されたけど)とか代数的データ型とか
>>172 ライフタイムがわからなかった、って、かなり知能が低い人じゃないとありえないと思うよ
そしてそのくらい低い人はプログラミングに向いていないと思う
ライフタイムはわかるけどこれがリージョン推論とかいった厳密な理論とどう対応しているのかがわからん
荒らしなし規制無し
>>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年続いて厳格に互換性を保ってる言語が短命だって？
>>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が使いやすいと思ってるのか冗談で言ってるのか
>>195 下手な増改築だらけのC++よりCが良い
LinuxのLinusも同じ意見
C言語にオーバーロード？
>>199 > _Generic
（´･∀･`）ﾍｰそんなのあるんだ勉強になりました
これあったら十分やわ
ジェネリックってプログラミング言語によって指すものが異なってるよな
IoT, AI でも、Elixir もある
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 「なぜオブジェクト指向はクソなのか」
１データ構造と機能は一緒にすべきではない
２すべてがオブジェクトである必要があります。
３データタイプ定義はあちこちに散らばってしまう
４オブジェクトはプライベートな状態を持っている
最近はモジュールがまた流行ってるよね
＞すべてがオブジェクトである必要があります
真のオブジェクトっていうのは、一つのスレッドみたいなもので他のスレッドとの通信をメッセージパシングでやりとりするものと言っていたような
むしろ継承はクソすぎて足を引っ張る
>>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は任意の関数に適用できるけど
typescriptでclassを使わないでやったときに無限にf(g(h(x)))みたいに書いたなあ
どうして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が使えない。
>>230 structやenum以外でもOK
任意の型にメソッドを定義可能
>>228 オーバーロードがある言語なら引数が一つ以上あるグローバル関数を追加しても引数さえ異なれば同名の関数をグローバルに追加できる。
UFCSとオーバーロードがある言語では第一引数がFoo型の関数を定義するのはFoo型にメソッドを定義することとほぼ同じとみなせる。
つまりUFCSは汚染でありリスク要因
モジュールがあるなら関数のimport有無でどの関数が呼び出されるか制御できたりしないの？
>>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)とも書ける。
>>244 Rustでも可能
例えばu64型のxに対して
xのn乗はu64::pow(x, n)という関数が標準であるけど
これはx.pow(n)と呼び出すことができる
>>225 js/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ではジェネリックにメソッド追加することも可能
既存の型へのメソッド追加はプロトタイプ汚染とか言われて忌避されてるよね
>>250 JavaScriptはプロトタイプがグローバルに書き換わり全てのモジュールに適用されるためだな
一方でRustはメソッドを追加するにはトレイトを用意することが必要、そしてトレイトが宣言/useされている空間のみ有効、なので汚染が生じず安全
>>251 型を定義した以外のcrateでメソッドを追加するためにはtraitが必要、が正しいかな
メソッドを追加するためにはtraitなしのimplを書く方法もあるが、これをできるのは型を定義したcrateだけに制限されているので他crateで定義を追加して汚染することはない
とまあRustの事情は知ってるんだけど、他の言語ではどうなってるのかが知りたかった
JavaScriptで脆弱性を生みまくってさんざん問題視されたんだから、いまどきそんな汚染が起こる新しい言語は一つもないよ
他の言語でもメソッド追加方法を教えて
今のところ
JavaScript
>>248 Rust
>>249 発端になったD言語のUFCSハブられてるのなんで？
>>256 UFCSはメリット無いからでしょ
メソッド追加できるなら関数よりメソッドの方が名前空間を汚さないし
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が破綻しないように
特別にあるだけで、汚染の低下のための機能ではないぜ。ここで汚染といってるのは無暗にメソッドが追加される事。
（回避策が仮に無ければ）衝突することはもはや、言語的な欠陥だ
使われる空間に名前が載ることを汚染とは言わない
>>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は論文がしっかりしてると嘯くのに
>>286 Rustは関係ないんじゃね？
むしろRustのアンチ側がなぜかRust叩きしていて巻き込まれ被害側にみえる
どっちでもいいよ
ほぼ全ての言語がUFCSを採用していない
C++委員会での議論でもメンバ関数と非メンバ関数で衝突したときにどう解決するかで割れて否決されたみたいだし、なかなか難しそうだね
考えてみたがUFCSは完全に不要っぽい
衝突が問題ならUFCSの使用は記号などを使って明示したらいいんじゃないかな？
「Rustを攻撃」ってどっちも同じでしょって言ってるだけなのに、このように攻撃を受けたと勘違いするんだから、正常な議論なんて出来ない。
スレ読んだけど
今のところUFCSがある言語と外部のデータ型に対してメソッドを追加できない言語、メソッドを追加できる言語とできない言語のそれぞれは前者が勝手で勝るけど、前者同士では好みとか実現手法の違い程度の話のように感じてる
>>292 C++での議論では当然そういう案含めていろいろ提案されたけど、結局どれも一長一短で委員会での合意には至らなかったみたい
一人で作ってる言語なら作者の好みでサクッと入れられちゃうんだろうけどね
汚染と言わなくても、Rustがuseで似たようなメソッドがたくさん出てくるのは本当でしょ、UFCSにしてもそれはイコールで何ら変わらんわ
メソッドが動詞ならUFCSでは関係が逆になるんだよね
>>298 OSV言語の自然言語に近くなるから、オブジェクトが先に来るのは利点として受け止められてる。でも所詮はシンタックスシュガーの何者でもない
>>297 > 似たようなメソッドがたくさん出てくる
そこ意味がわからない
似たようなメソッドがたくさんとは何？
C#にも拡張メソッドと言う名前でほぼ同じ機能が使えるけどそっちは拡張メソッドオンリーで使う前提で作られてる
>>299 英語はOSVじゃなくSVOな？OSVになることもあるけど、そして世界の自然言語の主流は日本語と同じくSOVが40%
参考としてスター・ウォーズのジェダイ・マスター：ヨーダは、このOSV語順で話す。
var s=copy(section);
Methods! You will be written first, but many are not.
>>305 ところがどっこい var sのsはメソッドを生やせないstring型だ
常にメソッドを生やせるとは限らないし、元のクラスに必要以上の仕事を増やさないためにから拡張メソッドという概念があるんだよ
スコープでuse出来て局所ごとにsection.print()の意味が変わる場合も便利だと感じる？
メソッドじゃなくて関数や変数でも、スコープごとに意味が変わりうるのは当然のこと
拡張メソッドが欲しいのはまぁ分かるんだけど
なぜ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にはなくて、自由関数だけがある。
>>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を仮想敵にでもしてるのかもな
ローカルのスコープしか影響しないのに、わざわさわ汚染とか言うの意味わからん
例えば新しい言語が出来て人気を博したら、RustにもNimにもDにもSwiftなどにも存在しない機能や、シンタックスシュガーになるわけで
このスレを「汚染」で検索してそれら書き込みを見るとプログラミング言語名の最多登場がRust
>>228 とか
>>235 みたいな、主観と思い込みによる断定から荒れ始めたんだよな
そこからおそらく自己正当化のために独自の「汚染」を定義
誰にも賛同されないと逆恨みだの攻撃だの仮想敵だの
>>333 それはもちろん同感だが
同時に発生しているRust汚染叩きは何なのだろう？
rustは錆なんだから汚染ぐらいでどうこう言うのもちょっと
Rustに対してとにかく言いがかりつけてるアレな人が前からおるやん
いーや一番言いがかりで汚染されてるのはこんスレとロシアだと思いますわ。反枠＆陰謀論！病院池
有名税か
>>332 >>334 事実に基づかない嘘で被害者面するのやめるべきだな。
このスレで「汚染している」と難癖つけられているのはUFCSだろ。次点でNim。Rustはあったっけ？
有名税とか言う前にまずDとNimとUFCSを無理筋でこき下ろした件に対するごめんなさいは？
それ古い版のthe bookだし
>>224 の条件付きだからUFCSってあるってだけだよ
途中送信した
条件付きだからこれをUFCSと呼ぶのは誤用ってことで今は使ってないよ（
>>284 ）
>>344 もちろんRustにもあるけど微妙に違うので今はUFCSとは呼ばなくなった
その微妙な差というのは既に
>>245 で書いたように
> 例えばu64型のxに対して
> xのn乗はu64::pow(x, n)という関数が標準であるけど
> これはx.pow(n)と呼び出すことができる
とメソッド形式でなく関数形式の時に型名等の前置パスで常に制限される
ほんのわずかだけ違うとはいえ
Goってマジで終わりかけてる？
>>295 (UFCS方式を含めて)メソッドを追加できない次世代言語が存在するのですか？
>>355 Rust、Kotlin、Swift、C#は拡張できるし、メソッド形式呼び出しがあるモダン言語なら必須機能っぽいけどね
最後にGoの悪口に収束するのは、おまいらの悪い癖だと思う
>>356 現代日本の片づけのキモはゴミ在庫の管理だ。 これはコンマリも言ってない..
pptppc2 「キモ」「ゴミ」とかいうワードが真っ先に出てくると身構えてしまう。
>>357 スレタイにある言語だと
TypeScriptもJavaScriptだからメソッド追加可能
残るGoは？
nimググってみたけどけっこう良さそうな言語じゃん。
>>361 ガイジの中のガイジ煮詰めたデータに何か意味あるんか？
>>362 何いちゃもんつけてんだ。
nimは使ったことすらねーわ。ググっただけだ。
一応このスレタイトルのtypescriptとgoは使ってる。
前にも書いたけど学校のサイトとかをワードプレスで運用してるところ結構あるんだよね
言語と人を比較して言うのだが
たぶんPHPが存在してなければ、また誰かが気軽にwebサイトをさらっとかけるスクリプト言語をRustのようなシステムプログラミング言語で開発していただろう
たしかにPHPが障害者を吸ってくれたおかげで助かってるところはあるかも
こんスレってなぜかJuliaの話、完全スルーするよな。Go？Rust？Zig？Nim？時代遅れのローエンド言語や
>>370 GoとPHP、どっちも使わない人からしたら大して変わらない説。
>>373 よっぽど根に持ってるんだな。
ちょっと病的な感じ。
ローエンド言語なんて言葉ある？
>>375 単に知られてないから話題に反応できないだけだと思う
良いところ教えてよ
Julia、せっかく新規言語で型付けと動的性のバランスを取れる立ち位置にあったのに、抽象-具象の継承ベースの型を採用した部分が個人的にジェネリクスと噛み合いが悪いと思っていて悲しい
JuliaのユーザーってPythonは当然として、他にはMATLABやRが競合になるようなコミュニティだから、
Juliaって計算科学や数値解析に特化した、R言語みたいなものでしょ？
Julia厨はクソみたいな押し付けするくらいなら
>>380 その継承が中途半端なことしかできないし
継承を採用したことも失敗してるし
Juliaはあかんね
継承は基底クラスと派生クラスの役割（責務）の分担が非常に難しいです。
長い。そして間違っている。
じゃあ継承使わないでプラグイン機構使いたいときはどうすんの？
プラグイン機構とだけ言われても意味が一意じゃないと思うけど
Composition over inheritanceは30年近くも前のGoFですでに広まってるのになぜ次世代言語スレで話題になるんだろう
ていうかJuliaの型システム知らなかったから簡単に調べたけど具象型はsupertypeになれないとか書いてあるんですが
>>391 継承とジェネリクスとの相性の悪さが問題なのではないかな
>>390 その後に継承のデメリットの方が多いと分かってきたため
そのデメリットをどう回避するかが各言語の主題となっている
>>390 知った気になって語りやすい話題だからだろう。
実装の拡張を肯定しつつデータ構造を直接拡張しないところが重要。
それを字面だけ解釈して、結局は妥協でデータ構造が暗黙に継承するような、先進言語の形だけ真似した言語もあるくらいだからね。
>>387 Goだけがどの話題でも機能不足との結論になっていて悲しいです
クラス継承しか知らないプログラマーは何でも継承で表現しようとするために失敗しているわけだから
実際言うほど継承使わないからなぁ
typescriptは不要だな。jscript .netといっしょで空虚だ。
マイクロソフト、JavaScriptに型宣言を追加しつつトランスパイラ不要の「Types as Comments」をJavaScript仕様策定会議のTC39に提案へ
https://www.publickey1.jp/blog/22/javascripttypes_as_commentsjavascripttc39.html 継承自体は悪くなくて設計が悪い
委譲元のクラスが単体では問題なく動くのに組み合わせるとテストを通らない
継承はそのオブジェクトの内に閉じた処理、オブジェクトの外の処理でもリスコフ置換原則が成立する範囲ではスマートでいいと思うよ
このRustと同じ分類となる、更に便利な言語が登場しないと、Rustを置き換えることが出来ないだろう
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!
こういうこと？
>>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 他人のこさえたライブラリと構造体を受渡するときなんかは意識せざるを得んよな。
コレはレアケース？
>>426 それはFFIと言って低レイヤー言語だけの問題ではない
PythonでもJavaScriptでもある
元の話題
>>423 > 低レイヤー言語だとメモリ読む前にキャッシュしたりアライメント揃えたりするでしょ
例えばSIMD命令使うのが "よほど特殊なこと" に該当するかどうかという話？
この流れでFFIもSIMDも関係ないと思います
GCあり言語の普通のプログラムをGCなし言語へ置き換える話をしています
>>421 > GCあり言語では、データ構造は気にしても、
> メモリ操作を意識している人は、少数じゃない？
> だから置き換えは、結構ハードル高いと思うけれど。
>>422 > メモリ操作とは具体的になあに？
> めったにない特殊なケースは除くとしてハードルが高いことなんて無いんじゃないかしら
メモリ操作って言い方が曖昧なら、スタックとヒープを意識するかしないかって言い方ならどう？
>>430 GCなし言語でどうしてもスタックとヒープを意識しないとプログラミングできないことってある？？
>>431 ありなしで言ったらあるでしょ
性能意識するコードとか
>>432 それは性能をよっぽど気にする特殊な場合だけでしかもその中の一部のコードだけやろ
それ以外は関係ないやん
言うほど低レイヤーコード書いてるやつはここにはおらん。
>>434 GCあり言語のコードをGCなし言語にする話だから
低レイヤーコードなんて一切関係ない
スタックは普通に意識するでしょう、末尾最適化されてないナンチャッテ意識高い系の再帰呼び出しとか直すけど・・・
>>436 Rustはヒープ無しでも動作するからヒープを意識しなくていいのはその通りだが
ヒープが有る場合でもVec::with_capacity(size);等は動作最適化を手動でする時のみ必要であって、
プログラマーは何もしなくても全自動でcapacity拡張してくれるから意識しなくてもよい
>>433 そもそもの質問が「ヒープ意識しないとプログラムできないことってある？」だから、反論になってないよ
頻度は問題にしてなくて有無の話だから
>>438 それは君の方がおかしい
今回のこの文脈ではそこは意識する必要がない
＞GCあり言語の普通のプログラムをGCなし言語へ置き換える話をしています
ベクタの使用領域の大きさはどちらの言語でも自動的に拡張してくれるのに任せればよいから意識しなくてよい
GCありの言語で循環参照するようなデータの持ち方をしまくってるようなコードだったりすると、
>>437 ”Rustはヒープ無しでも動作する”、不正確でダウトといっても良い。”Box<T>を使わない場合、Rustは最小のメモリで動作する”
一般的に最小のメモリとはプログラムをメインメモリにロードした領域であり、それ以外にも、ヒープ解析すればRustの場合は、
Config structなどが多数メモリにロードされていることが分かります。後半の文は意味不明。
GCあり言語って一絡げにできるほど似通ってるんだっけ
>>441 知識が浅すぎる
Rustはヒープ無しでも動作する、で正しい
そのためRustの標準コアライブラリcore::はヒープ無しで動作するように作られている
std::のうちcore::以外の部分はヒープを用いており明確に両者は区別されている
>> ”Box<T>を使わない場合、Rustは最小のメモリで動作する”
意味不明
Box<T>はヒープを使う型の一つに過ぎない
それ以降の記述は全く意味不明
ベアメタル等OSなしでも動作しないといけないため
>>444 本当はスレ民のことが気になって仕方ないだろ？
隠しても無駄ｗｗｗ
なぜせっかくRustで作られたブラウザを除外するかね？
「NHKプラス」、「Firefox」での視聴が不可能に 5月23日から推奨ブラウザを「Microsoft Edge」「Google Chrome」「Safari」に限定 [孤高の旅人★]
http://2chb.net/r/newsplus/1651490664/ >>448 そのどれかのブラウザがインストールされてない端末って何がある？
Linuxと組み込みくらい？
>>448 もし本当に視聴不可となったら技術力が無さすぎる
昔ならともかく今の時代にブラウザ依存なコードを書くのはダメなプログラマーの典型
視聴不可ではなく動作確認するブラウザの数を絞るなら理解できる
> 「Firefox」など、上記3ブラウザ以外での動作はもともと確認しておらず、推奨ブラウザには加えていなかったという。
今どきはブラウザ依存な書き方する方が面倒だろう。普通にテストしてないだけでは。
chromiumにしか実装されていない独自拡張機能に依存したAPIに手を出したとか？？
そういえばchromeにrust使う話ってどうなったんだ？
たしか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の脆弱性がこれだけのはずが無く、脆弱性報告数＝危険なブラウザとははっきり言えない
途中まで数字で語ってるのに最後だけ願望になっててワロタ
木を見て森を見ずという言葉を考えた昔の人はいいセンスしてる
Appleって莫大な利益を何に消費しているのだろうね
>>448 そもそもNHKは見ないのでどうでも良い。
>>472 ウィグル弾圧に使われてる可能性が高い。
いまどきウェブ見てて落ちるブラウザなんてファイアフォックスくらいだし、そこらへんは忠実にネスケ以来の伝統を受け継いでて驚く。
トリビア：Firefoxユーザーはレベルが高いの致命的なバグがあっても自分で治して使っている
>>475 ここ数年間の常用者だがFirefoxが落ちたことがない
もしデマカセを言っているのでないのならばどういう状況で落ちたのか語ってほしい
>>475 Chromeは週一ぐらいで落ちる
IME変換中に間違えてファンクションキーを押すと落ちる
>>477 数か月前に頻繁にメモリ不足で落ちてた。タブがクラッシュする
>>481 それメモリが少なすぎたとか
メモリを超える巨大なデータを読み込んだとか
無数にタブを開いたとかそういうオチだろ
逆に100兆個のタブを開いて落ちないブラウザってどれ？
メモリ不足を、クラッシュせずに通知くらい【余裕】にできないと。
>>477 Windowsでタブレットモードにしてると頻繁に落ちるな。
落ちるというか、無限ループしてるっぽいんだよな。
頻繁に落ちるのに、落ちないとか信者が言い張るのも、ネスケ以来の伝統だよな。
英語設定のLinuxだけど落ちないよ？
Windowsでここ何年か使ってるけれど、
FireFoxで微妙に表示が崩れるとChromeだとちゃんと表示されるのか気になる
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も必要になれば普通に使えるでしょ
エンジニア目線では特に対立関係にないから煽っても無意味だぞ
競合ではなく両方利用
理想の家族
>>495 そうだぞ。
競合なのは事実だろうけどGoやってるような人はRustも必要になれば普通に使える、という体で話さないと嫌われるぞ。
それに、裁量権のない作業者の間では対立関係にないから煽っても無意味だぞ。
低レイヤーはRust
主張はわかるが、これはもしや片思いみたいなものではと見ている。
例えばウェブサーバーサイドもRustで書いたほうが早い速いしな
Goは良くも悪くもCっぽくって人間が気をつけて書かないといけない部分が多いんだよな
LinusはgitをC+シェルスクリプトで書いてた
Rustはデータ競合らへんは起きないけど、Box、Rc、Arenaを気をつけて使い分けないといけないのとか面倒だと思うけどな
Goの一番の面倒さはnilとエラーハンドリングかな
>>506 Rcは出てこないプログラムも多い
Arenaはほぼ完全に出てこない
つまりそれらレアケースを元に語るのは現実的ではない
Rustで引っかからずコードを書き上げるのはかなりの猛者だと思うよ
Rustはある程度から人間の理解を超えて来るので一定程度以上勉強しても無駄かなと
>>509 その辺はScalaで学んだからRustでは苦労しなかったけど
最初訳わからんってなるのは分かる
プログラミングはは知的生産だと思ってたけどこれはもう違う別の何か
多くの人に知ってもらいたい
実装に必要なtraitを境界として追加しただけで煩雑だけど難しくはないよね
>>509 そのtrait境界は意外に理解が簡単だった
ジェネリックにプログラムを書く時にそのジェネリックな型には何が来てもいいわけではなくて
書くプログラムの中で使っている機能(というかインタフェースというかメソッド)を持つ保証する(というか限定するというか制約条件を並べる)こと
例えば本スレからコピペだけど以下のフィボナッチ数列イテレータ
型へのtrait境界がwhereのところにあるClone(複製できること)とTryFrom<usize>(数値から変換できること)とnum::CheckedAdd(オーバーフロー検知付き足し算ができること)の3つを満たしてればどんな型でも適用可能
fn fibonacci<T>() -> impl Iterator<Item=T>
where T: Clone + TryFrom<usize> + num::CheckedAdd,
{
let [zero, one] = [0, 1].map(|n| T::try_from(n).ok().unwrap());
itertools::unfold((zero, one), |(m, n)|
m.checked_add(&*n).map(|f| {
*m = n.clone();
*n = f.clone();
f
})
)
}
pub fn main() {
for f in fibonacci::<i8>() {
print!("{f} ");
}
println!();
}
実際にトレイト境界の条件の実装部分を読んでみた
例えば条件の一つがよくよく考えてみればさらに二つに分離して考えないといけないものだと
>>518 そんなこと起きたことがない
聞いたこともない机上の空論
Rustの標準ライブラリの設計がそもそも間違ってて、その修正のために破壊的な変更がいきなりきたら大変だ、って話？
サプライチェーン問題は批判理由が見つからない人が持ち出しがち。
実装の問題は重要だろ。
何を問題視してるのかもうちょっとわかりやすく書いてくれないと議論にならん
コーダー風情にはどこら辺に問題があるかすらわからないんだ
>>522 依存型理論原理主義過激派かな？ちょっと面白い
>>527 Π型はないけど、const genericsなら…
>>521 ランタイムが持ってる言語ならランタイムをアップデートしたら終わり
マクロの言語は該当箇所を探し出して修正して丸ごと再コンパイルが必要
工数考えたらどちらが有利なのかすぐ分かる
知識が足りないのはどちらなんだろうか？
>>529 現実には起きない架空の話だから両者ともにバカげている
>>529 ランタイムだけ差し替えられることに気づくとは…
Juliaの今ひとつなところはswitch/case文がないところ
Juliaではマルチディスパッチしろという方針なのかもしれんが、マルチディスパッチの方が他言語に普及してないのは機能として過剰な割に効率性に劣るからなんだろうかね
まつもとゆきひろ氏が考える、プログラミング言語の未来
https://logmi.jp/tech/articles/326541 楓：「今Ruby、Cの次に好きな言語はなんですか」。
まつもと：そうだな。Elixir、Go、Rustは気になるっちゃ気になるんですね。ただ、正直に言うとRustは僕の好みではない(笑)。
楓：おおー。気になるポイントと好みじゃないポイントはどのあたりなんですか。
まつもと：やはりCを一番よく書くので、システムプログラミングの領域が、私がよくプログラムする領域なんですけど。そこに出てくる言語の中で今一番メジャーなのは、GoとRustであるというのが気になるところですね。
だけど、Rustが型でいろいろなことを言ってくれるのはうれしいところとうれしくないところがあって。つまりコンパイラに怒られるんですね。僕はコンパイラに怒られるのがすごく嫌いなので(笑)。なんかストレスがたまるんですよね。
楓：(笑)。
まつもと：どちらかというと、技術的なことではないところで一緒にがんばれるものがいいなって思っていて(笑)。
どの言語でも間違えればコンパイラに怒られる
コンパイラに怒られずにランタイムに怒られる方が
ランタイムに怒られてもうまく問題点を見つけ出せる方が頭良い気がする
自分がすごくプログラミングが出来る自負があるから、コンパイラに怒られるとプライドが傷つくから嫌だって言ってるようにも見える
ひろゆきは賢いからコンパイラは余計なことを小うるさく言わんでいいって感じ？
自意識過剰で被害妄想だな
The compiler is your friend
Rustのコンパイラに怒られるってことは所有権のシステムとかが全然理解できてないんだと思う
人間の理解を超えたところから怒られるのは違うかなと
囲碁や将棋はもうAIの方がかなり上に行っちゃって誰もAIに勝てない
デバッグ含めた開発効率の良さを考えると可能な限りコンパイル時に怒って欲しいかな
プログラムを書いてエラーが出ると「自分が否定された」「尊厳を奪われた」と感じる人もいる、という話
https://togetter.com/li/1698737 ランタイムは運良くバグを踏まなければずっと怒られずに済むのに対してコンパイラは必ず怒られるから
コンパイルが通って、いざ実行してみたら
>>545 そうゆう浅はかな考えは恥をかく元。常に所有権を意識しなきゃならないので、言うなら、呼び出される上のほうでロックしてても
複数スレッドでアクセスして安全なのに、所有権をいちいち意識しなきゃならないという事だ。
Rustはスクリプト言語の作者からすれば、面倒な記述が多すぎると感じて当たり前
強いて言えば、こういう浅い奴がマウントとってる現状のRustコミュニティは反吐が出る、Rubyコミュニティも好きでもないけど
そろそろ指摘するんじゃ無くて、勝手に直したり、良きに計らって欲しい。
>>545 実はそういうは人を排除するためだけにRustのプロジェクトを立ち上げたりしてる組織もある
今のコンパイラはエラーが起きた行を指摘するけど
松本が所有権を理解してないんじゃないと思うがｗ
なんか最近開発に興味なくなってきた
最近のげんこはprintをpirntとか書くと、
>>556 一部のコンパイルエラーは修正コード提案してくれるしIDEからボタンぽちで修正できるから、
それ発展させて意図が不明確なコードでも何種類か修正候補出してくれるようにならないかな
>>565 Qiitaに投稿された「TypoScriptを作った」を思い出した
レーベンシュタイン距離が近ければOKっていうネタ言語
英語圏のフォーラム見に行くくらいモチベあったのにな
>>545 Rustはマナー講師みたいなものだろ。
Rustが望ましいと考えるスタイルを強制して他のやり方を許さない。「なんで？」と理由を聞いても「それがルールだから」とか理解しがたいことしか言わない。
せめて「スタックにデータを保存するため」とか「Cleanみたいに参照透過性と性能を両立させるため」とか言えばいいのに、そういった思想的な背景を説明しないからマナー講師が跋扈する。
>>570 それはどのプログラミング言語でも同じ。
いずれの言語も独特のスタイルを押し付けてくる。
もしそれを感じ取れないならば、それは特定のスタイルに慣れてしまっているだけに過ぎない。
例えばわかりやすい例を持ち出せば、リアクティブな言語や宣言的な言語では、
a ＝ b ＋ 100
と記述しておけば、aが変わればそれに応じてbが変わるし、bが変わればそれに応じてaが変わる。
ところがそうでない不便な言語に出会ったときに、
双方向に自動的に変わってくれないために苛立つかもしれない。
>>571 「それは特定のスタイルに慣れてしまっているだけに過ぎない。」と切り捨てているところに排他的思想＆知識マウントを感じるね。
a ＝ b ＋ 100の例は代入演算に対して ("="から一般的に連想される) 「等しい」の意味を適用することにより生じる誤謬。
原理や技術的決定を理解せずに相手にルールを押し付けようとするマナー講師の話とは関係無いな。
>>570 むしろスタイルを強制しないプログラミング言語なんて存在するのか？
松本がRust好きじゃないのはまあそうだろうなとは思う。
>>570 マナー講師はフォーマットみたいな個人の好みレベルの話で
コンパイラが指摘する構文とかセマンティクスはその言語の世界における自然法則みたいなものでは
>>575 エラーメッセージの問題じゃなくてドキュメントの問題かもしれないけど、エラーの形で否定するなら納得のいく理由を教えてほしいものだわ。
自然法則みたいな原理があるなら、その原理からどう推論したらそのルールになるのかの考え方も欲しいところ。
まぁ、それ以前のエラーメッセージしかしないクソ言語も多いけど。C++とか。
>>576 rustのlifetimeとかborrowing周りのエラーはそんな感じでエラーになった理由は教えてくれるよ
例えばどんなエラーの原因を分かると嬉しいと思う？
美人女教師のイラストでも添えたら
>>577 原因じゃなくて原理ね。
エラーメッセージとしてはとりあえずは原因と解決策で十分だけど、verboseの時とかは技術的背景とかポリシーとかを説明した解説へのリンクがあると嬉しい。特に制約の厳しいライフタイムとか借用とか。
まぁ、そうなるとrust版D&Eを書くようなものだから大変か。
>>580 現状でもエラーによってはGitHubのissueへのリンクが付いてるから、具体的にこのエラーでこのページへのリンクを付けるべきって提案があれば受け入れられる可能性は高いと思うよ
カンマとピリオドの間違いとか
コンパイラ「Did you mean ',' instead of '.' ?」
>>580 例えば、↓のコードをコンパイルすると
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0bd550e905a2263a33895815c4430436 error[E0499]: cannot borrow `x` as mutable more than once at a time
てな感じでエラーコードが表示されて、以下の解説ページへのリンクが貼られている
https://doc.rust-lang.org/stable/error-index.html#E0499 この中から関連するリファレンスへのリンクが貼られている
現状のドキュメントで十分ではないという問題はあるかもしれないけど、
>>580 で言われているような方向性にはなっているよ
>>582 上のコードのセミコロンを全角にしてみたらまさにそんな感じのメッセージが出た
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=118aa7e31d9c6c786d222f34a66623c3 error: unknown start of token: \u{ff1b}
help: Unicode character '；' (Fullwidth Semicolon) looks like ';' (Semicolon), but it is not
コンパイラのエラーメッセージに外部サービスのリンクって、もしそのサービス終わったらどうすんの？
>>585 rustのことなら公式サイトへのリンクだよ
さすがに言語のメンテナンスが続く限りは大丈夫でしょう
最も重要なマナーは
Rustちゃんは生活のすべてを管理されたトップアスリートでヘソ出しユニに胸はぺったんこでショートヘアのすっぴんだけど最高の記録を出す
なおGoちゃんは無限に二股をかけられるという特技もある
レベルが低すぎてRustスレで書けないRustの話しかしない駄スレ
＿＿＿_
Rustスレはフィボナッチ数列で無駄に盛り上がってる
>>594 行列演算とかじゃなくてフィボナッチ数列かぁ……
純粋アルゴリズムにrustは不向きだとなぜ気づかんのかな。。
>>595 なかなかゴミみたいな様相だよ
フィボナッチ数列の第n項はメモ化しなくても線形オーダー、あるいは対数オーダーで計算できるのに、メモ化にこだわりのある人が「そのやり方はmainのループと合わせて計算量はn^2だ」とか言い出して散々
>>596 個人的にはむしろ抽象化と両立が難しいところに新しい道ができたように思えた
（過剰なメモ化なら言語関係なくやられがちな気がする）
フィボナッチ数列計算するのにあそこまでする必要はないわ
スレ見てないけどベクトル演算した方が速いんじゃないの知らんけど
Rustのスレなんだし、アルゴリズムで計算量を改善したりする話じゃなくて、Rustのベストプラクティスについて話してほしい
数値計算はやっぱりJuliaかFORTRANが実行速度最速なのかしらん。
>>597 nが与えられた時に
『フィボナッチ数 F_n』を求めるのは単純にO(n)あるいは工夫してO(log n)で合っている
ところがその『F_n』を求める関数を「ループでn回」用いて
『フィボナッチ数列 F_0, F_1, F_2, ..., F_n』を求めると当然n倍でO(n^2)またはO(n・log n)となってしまう
それが後半の「そのやり方はmainのループと合わせて計算量はn^2だ」という話だと思うのでそれも合っている
ところが『フィボナッチ数列 F_0, F_1, F_2, ..., F_n』を生成するイテレータを作ると全体がlog(n)で済む
つまり計算量を大きく節約できる
この二つの区別を出来ているかどうかが重要なポイントかな
ごめん1箇所だけ記述ミスを訂正
>>604 × ところが『フィボナッチ数列 F_0, F_1, F_2, ..., F_n』を生成するイテレータを作ると全体がlog(n)で済む
○ ところが『フィボナッチ数列 F_0, F_1, F_2, ..., F_n』を生成するイテレータを作ると全体がO(n)で済む
頭おかしくなっちゃった！
>>604 そうそう、こんな感じで論点をどんどん変えてくんだよね
フィボナッチ数列のはずがフィボナッチ数列の1~n項の計算にすり替えられちゃう
『フィボナッチ数 F_n』を求めるアルゴリズム・計算量と
スレの流れとしては前者なのに一人だけ「数列だから初項からn項までの計算量を考えろ」とか頓珍漢なこと言ってるのよね
スレ見たけど最初から全員がフィボナッチ数列を列挙させているから
>>609 で言うところの後者だな
そして今日書かれた2種類のコード共に後者のイテレーター
>>610 たぶん君だけが勘違いしている可能性が高いｗ
フィボナッチ数列自体はただの例題なのに異様な執着心見せる人が居るよね
>>610 フィボナッチ数列といったら F_0, F_1, F_2, ..., F_n, ... だよ
それはともかく前者と後者でベストなアルゴリズムが異なるから前者だけの話をすることはありえないと思う
そして後者のイテレータはそのまま前者をO(n)で求めることが出来るから
どちらもO(n)で十分とするならばイテレータをプログラミングするのが自然じゃないかな
職業マは生暖かい目で見守ってるよ
フィボナッチってO(1)では？（ビネ並感）
各項のオーダーはO(1)可能だが複素数(行列)でムダに計算量多いだろw
>>616 複素数じゃないよ、実数の範囲で計算できるよ
Qitaベンチマークで、フィボナッチとかドヤァってるドアホ見るけど、片方の言語がoverflowチェックなどが入ってる演算を
標準的なコンパイル方法・プログラムの書き方をした場合の比較になっているのなら意味はあるのでは
確かにCheckedAddとかで書いてるQita記事のフィボナッチベンチなんて見たこと無いね、逆に言うとそれしか意味がない。ベンチとは名ばかりのフワッとした自己満足オナニーだ、100mハードルと100m走くらべてるようなもんさ
>>619 Rust本スレのフィボナッチはoverflowチェック入っているぜ
http://2chb.net/r/tech/1652347700/181 >>622 それはその個人の問題点であってプログラミング言語の問題ではない
顔真っ赤でコピペして来てるｗ
フィボナッチが居ついちまったじゃないかよ。
フィボナッチ呼ばわりはフィボナッチさんへの風評被害になるからやめな
>>625 口だけ番長定期
これだから世界から糞バカ中世ジャップランド土人とか呼ばれるんだよ
>>624 それはあまりにも無知な発言
RustではC/C++やCPUでの同じ動作となっているにすぎない
例えばC/C++では (正確には未定義だが通常動作)
int main() {
char x = 127;
x = x + 1;
printf("%d\n", x); // 出力結果: -128
}
Rustでは (普通にrelease modeの場合)
fn main() {
let mut x: i8 = 127;
x = x + 1;
println!("{x}"); // 出力結果: -128
}
ちなみにdebug modeではpanicで知らせる
release modeでもコンパイラに指定でpanicで知らせることも可能
>>629 に加えてRustでは
let n: i8 = 126;
の時、
println!("{:?}", n.wrapping_add(1)); // 出力結果: 127 // 溢れていないならその値
println!("{:?}", n.wrapping_add(2)); // 出力結果: -128 // 溢れたらラッピング(一周して)その値
println!("{:?}", n.overflowing_add(1)); // 出力結果: (127, false) // 溢れていないならばオーバフローフラグfalseが返る
println!("{:?}", n.overflowing_add(2)); // 出力結果: (-128, true) // 溢れたらオーバフローフラグtrueが返る
println!("{:?}", n.checked_add(1)); // 出力結果: Some(127) // 溢れていないならばOption型のSome(値)が返る
println!("{:?}", n.checked_add(2)); // 出力結果: None // 溢れたらOption型のNoneが返る
println!("{:?}", n.saturating_add(1)); // 出力結果: 127 // 溢れていないならその値
println!("{:?}", n.saturating_add(2)); // 出力結果: 127 // 溢れたらその型の上限の値
といったようにRustでは求められている状況に応じて容易に多様な対応を取ることが可能
Rustよりも用意周到なプログラミング言語があればその動作を教えて欲しい
ここ2週間くらいRustスレずっとこんな調子だったんですよ
何が用意周到なんだか。言語のことを言ってるんじゃなく、「あくまでそれでベンチマーク比較すんなよド素人」という話だけなのに、ムキになって言語機能の紹介書いちゃうオジサン
>>625 Rustスレでも満場一致で同じ意見だからご心配なく
CPU・C・C++・C#・Rust全てにおいてオーバフロー時は一周回った結果になるってことか
>>634 演算子オーバーロードできる言語なら a + b が Option<T> 返すような型を実装できるから言語組み込みでキーワード用意する必要もないのでは
例えばRustだとそういうライブラリもある
https://docs.rs/checked/latest/checked/ >>636 Goもそれらの言語と同じ
int8(127)に1を足すと-128となる
標準でオーバフローチェックしなくてズルい！と発狂している人はどんな言語を使っているのだろう
実装が処理速度に与える影響を論じるのなら浮動小数点数の話で語り始めるべきだったなｗ
Pythonなどは(無限にではないが)演算で型拡張が行われるから、それらと同列でベンチマークすべきではないのは同意
Rustでの標準挙動は
>>636 や
>>638 により他の主要なプログラミング言語と同じ
その上で
>>637 など演算毎にチェックも可能
このような状況でとなおRust叩きをしている人は頭がおかしいのかそれとも
Rustスレ過疎ってル訳でもないのにどこでもRustの話始めるのなんでなん?
言語は一つに統一したらええに。
Swiftってわかりにくいね
それでも Swift >>> 越えられない壁 >>> Go、つまり 林檎 >>>>>> Google
>>645 > Objective-Cもクソ
具体的にはなにがどうクソなの？
まずxcodeが糞
1 + 1 = 2 レベルの内容すら理解できんとかガイジ？ホイ卒？
Swiftやってると某こんスレにいるアホ言語初心者のような参照カウントの悪辣性に気付くんだわ。その言語の機能解説ずーとしてるバカたち
>>650 1 + 1 = 2は定義上そうなっているだけなので理解できるかどうかという話じゃないんだぞ（クソリプ）
「Swiftになってよかったこと」で調べればobjective-cの駄目なところはいくらでも出てこない？
Swiftは言語だけみれば結構いいけどね
>>653 ビチグソが固形ウンコになったくらいのレベルでよかったとかいうxcodersは頭がおかしい定期
ごめん、うんこに失礼だった
匿名掲示板でうんこレスしこたま投稿するの楽しいにゃん♪
Xcodeが嫌ならVS CodeかAppCode使えば良くね？何が問題なの？
kotlinのチュートリアル的なのみたらif式は変数に代入してコールできるとかあったけどいつ実行されるの？コールしたとき？それとも代入された変数には既にif式の実行結果が入ってる？
・フリーエンジニアが年間3,600万円の売上を上げた方法を解説する
>>668 君は年収３００でRustで組み込みでもしてるのが実力だからねｗ
>>671 こういうの鵜呑みにしちゃうんだ
変な壺とか買ってそう
>>663 このようにマジキモRust信者が24時間張り付いて、他言語の悪口を言うスレです
（自演して）クソクソ言っとけば悪口になると思ってそう
>>671 高収入になるほどRustを好む傾向がはっきりデータに出ているな
この状況でRustを叩いてる連中はどういう人たちなのだろう？
あからさまにRustを叩いている人はごく一部を除いていない
>>678 叩きもなにも、もはや誰も言語仕様の話はしていない。汚物連呼程度の煽りならスルーするのが賢明だ
Rustは素晴らしい言語ではあるが
>>683 そう考えるRust狂信者は多そうだな。
Haskellの二の舞だわ。
むしろ駄目プログラマーを上手く排除できるからありがたい
駄目プログラムがRustに置き換わるだけで何の解決にもなっていないのでは？
一番排除できてありがたいのは、癖のあるC++プログラマーw
例えば駄目プログラムの典型として
>>688 データ構造がスパゲッティでも、Rustのルールに則っていれば、動いてしまうんじゃないの？
Rustだって、設計の良し悪しまで判断できないと思うんだが。
何でもRcで囲めば簡単にスパゲッティデータ構造作れそう
>>685 まぁ確かに
Ruby募集すればスクール卒が集まるし、PHP募集すれば障害者雇用枠が集まるしな
そういうこと
>>692 そういうのはRuby募集するときにRustスキル必須にすればいいけど、そんなことをしたらコスト上がるだろ。
コスト以上の売上を上げられるのかね？
>>693 何当たり前のこと言ってるんだ？
便所掃除に大卒雇うわけないだろ？
そういうこと
>>687 C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:
- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)
- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。
言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
型無し糞言語ユーザーはその場で○していいよ
>>690 Rustでデータ構造がスパゲッティだと
参照や競合を解決するためにそれ用のを使わざるを得ないから
その使われている部分が無理やりなのか必要なのかをチェックするだけで判別できる点は良いね
そもそもスパゲッティデータ構造って定義はなに
>>690 0か100で判断すんな。
他の言語よりマシって言ってるんだろ。
ちょっと待て
昔のレベルの低い状況だったらよかったのかもしれんが、抽象バカはこれからはプログラマーとしてはやっていけないよ。
まだスパゲッティデータ構造とかいう話をしているんかよ。新しいバズワードでも作りたいんかね。
>>688 Rustにも進出してそれを体感するようになった
Rustはデータ競合もコンパイラがチェックするから他の言語では気付かなかったことを把握して組めるようになった
>>711 実環境と同じで開発する Docker っていうんだぜ 最新の開発手法なんだが 逆に知らないのか？ＲＵＳＴとか言ってるバヤイじゃないだらｗ
>>711 受入側がテストケースを作るという話なら理解できるけど、そういう話じゃ無いんだろうなぁ。
>>713 それはOpsDevの話だから、ちょっと違う気がする。
> スパゲッティデータ構造
データと環境の区別がつかないやつとか
底辺というか単にアマチュアと思う
YouTube で有名な、雑食系エンジニア・KENTA の動画 VIDEO
>>718 いやEKSのワーカーノードってEC2のインフラに乗っかってるやん
何言ってんだコイツ
普通の荒らしならNGでも良いけど、これは広告黙認になっちゃう…
ECS(Elastic Container Service)・EKS(Elastic Kubernetes Service) については、
>>722 さすがです
些末な言語でケンカしてる土方ＰＧとはレイヤーも知識の深さも違いますね・・・
それだけ昔も今もタイトルの読めない人が蔓延ってることだよ。
次も脈絡なくdockerとか言い出されたらちゃんと無視しようね
なんかあの動画原稿読んでる感が強いんだけどゴーストライターが原稿書いてるなんて事ないよな
やーいおまえらの年収、ケンタ氏の月収レベルｗ
スクラッチのPHP並にWEB開発が楽な次世代言語が欲しいんですよ
某スレで気持ち悪いオナニーコード書いて一生懸命しょーもないフィボナッチの話してるふりしながらダメ人間批判のアホどもへ
> TypeScriptはJavaScriptの改良版と見なされることもありますが、実際はそうではない。
時間掛かるから型チェックやめまーす
テスト書くから必要ないって事だろ
wasmにコンパイルされる専用言語が待たれるという説
TSにはインクリメンタルビルドの仕組みがなくてファイル変更のたび毎回フルビルドが必要なの？
>>748 制約を明示したり強制したりするのにリーズナブルだから型が使われているんだと思うが
何で代替しようとしているの？
>>749 型は制約じゃないぞ
階層理論の産物さ
制約とはtrait systemのことさ
>>742 コンパイル時間でGoに勝てる言語ってある？
>>752 出来上がったバイナリ(deno本体)の実効速度の話ね
>>745 例えばある関数がnumberだけ返すことをテストで網羅できんの？
正直言ってD言語とかの存在価値がわからないんだが使っている人いるの？
>>753 何言ってんだこいつ
Denoはコンパイル時間って言ってるんだが
>>758 Go→RustもTS→JS
どっちも一貫してDeno自体の実行速度を最優先してるわけよ
Denoのjsってそんなに大規模か？
>>761 その時間ってもろホットリロードのタイムラグなわけじゃん
Rustのようにかなり強力にコンパイル時エラーでほとんどの問題を排除してくれる堅さとは異なり
確かにRustのコンパイルが遅いのが嫌だという意見はわかる。”C++より早いだろ？”とか”嘘つき！Rust速い！”とかコメントしなくてあ、結構です
>>765 学歴コンプのある人はすーぐ学歴の問題にする
>>768 ハーバードでMBA持ってるけどな
F欄は口くせーから喋んなゴミ
プログラミングにも理解があって英語ぺらっぺらな海外トップ学歴の経営人材なのに
Javascriptに対するTypescriptってCに対するC++みたいなもんだろ？
結局地がjsな以上互換性を保ちながら完全に型で覆うのは難しいよねって
JVMバイトコードに対するScalaみたいなもん
さすがにそこまでじゃない
denoてどのくらいnodeからの移行が進んでるんだろ？
serialportとかちゃんと使えるならラズパイとかで使ってみたいな
>>778 進まないから今現在必死に最適化してるんだろう
少なくともそのQiitaには、Denoの実行速度が遅いからJavaScriptに移行した、とまでは書いてないと思うんだけど、なんか誤読してる人多い？
いやそこ誤読してる文盲はおらんやろ・・・おらんやら？
typescriptのコンパイラはtypescriptで書かれてJavascriptにして実行されてるから遅いんだろう
マシン語にしてるわけでもないし、処理としてはコンパイラとしては軽い方だから
Kotlinとか確か開発者がロシアじゃなかったっけ？もうオープンソースだから米国的にはOKなの？
いち早くロシアの侵攻を批難する声明を出したから許されてるんだろう
>>786 いち早く出してねーよ
ロシア政府なみの嘘つくな
最初のツイートはロシアのプロパガンダと同じ巧妙な内容で反感買いまくってから追加で声明出したんだろ
JetBrainsのサンクトペテルブルクのオフィスとブラハのオフィス(本社)の写真みたけどすげぇ格差だったわ
tsの変換や型チェック処理する機能はgoやrustで書き直すプロジェクト進行中だから
PHP+味付け程度にJSでシステム作ってる化石野郎でも応用効く言語教えやがれください
PHPに勝ったところで次世代PHPにしかならないのに？
PHPってマジで話聞かなくなったよな
Goにオプショナル型とスプレッド構文とmap,reduce,filterのコネクション系操作が入ったら最高なんだけど
Typescriptの糞なところ
GoのMap糞過ぎて全く読めない
構造体作ってマッピングするのじゃ何がダメなの？必要なのだけ定義すればいいんだが？
>>797 ＞サードパーティーのライブラリに向かってコードジャンプしても型定義ファイルに飛ぶせいでコードが読めない、ゆえにGithubを見に行く必要がある
「Atom」を開発終了に追いやった「Visual Studio Code」、月例更新でさらに強力に
https://forest.watch.impress.co.jp/docs/news/1416263.html TypeScript開発では「TypeScript 4.7」が導入されたほか、待望の［ソース定義への移動］がサポートされた。100％の確度ではないが、型定義ファイル(*.d.ts)ではなく、JavaScriptによる実装部分へ直接ジャンプできる。
https://twitter.com/mattbierner/status/1517182624917340162 https://twitter.com/5chan_nel (5ch newer account)
>>800 おーこんなのあったんだ、ありがとー
適当に試してみたけどできないのも結構あるね
標準ライブラリ大きいのと小さいのどっちが良いのかね
大きくて、APIが安定していて、ゴミが少ないやつが良い
goはpackageの命名が糞杉
Effective Goでは、パッケージ名は1単語にしよう、って書かれてるけど、アンダースコアや大文字小文字が使えないわけではないよ
いまだにgenrandom, gen_raondom, genRandom, GenRandomのどれがいいかわからん
CSSならlong-name-propertyだし、JSONならLong_Name_Property、SQLならLONG_NAME_PROPERTYまたは
言語内で閉じるなら慣習に従うだけだけど言語またがる時は迷うよね
標準ライブラリは名前が綺麗なのに、自分で命名しようとすると難しくて悲しい
そうでもないぞ
>>810 なおGoはlongnameproperty
ガイジか？
>>815 Goは後発の分際であの体たらく
どんな頭弱が作ったのか顔が見てみてーわ
Goのstrconv::atoi()って
>>804 _ "github.com/mattn/go-sqlite3"
>>806 だね、触ったこともない人が騒いでるだけ。とんでもねえアホ
>>818 std::num::strconv::float_to_str_bytes_common
(´；ω；`)ｗ
golang入門したころにファイルの読み書きや文字の扱いのライブラリを見て愕然としたな
>>819 golintでエラーだぞ
おまえこそエアプだろカス
PHPでも書いてろ
goの作者の一人は有名人過ぎるけどもう後進に道を譲れよよ思う
>>821 file, err := os.OpenFile("foo.txt", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0777)
これがキレイだとは決して思わんが....
let mut file = File::options().read(true).write(true).open("foo.txt")?;
これもどうかと思うぞ？何故、直感的ではないoptionsでopenに繋げるチェーンなのか..確かにオプションの設定はpanicが起こらないから
言語的な理由（言い訳）は分かる。でもRustってオプション扱いを第二引数にしない思想があるんだろうか...
>>822 デニス・リッチーとかC言語の作者とかだからC言語のライブラリと似た名前になるはある意味当たり前だよなあ
>>825 Rustの標準ライブラリが汚い理由はオーバーロードがない、デフォルト引数がないから
デニス・リッチーが直接に関わったという話は聞いたことないけど、ケン・トンプソンと勘違いしているのだろうか
>>822 有名と有能は違うぞ
どこぞの通貨危機衰退先進国のゲリ首相は有名だが有能か？
>>829 画像あるから普通に顔見てみたいなら見ればいいでちゅよ？
>>829 有名人だから顔なんてネットに溢れてるんだからとっとと見て好きなだけ罵倒してきなよ
Goのモジュールシステムシンプルでわかりやすいと思うけどな
>>825 メソッドチェーンでオプション書くの大嫌い
単なるデータは普通にデータとして書かせてくれ
>>825 君その話前にもRustスレでしてなかった？
ケン・トンプソンなんかおまえ
> ile, err := os.OpenFile( os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0777)
>>837 The 老害やな
長いものに巻かれろ、年長者は無条件に敬え、右に倣え、出る杭は打て、死なば諸共
これが衰退先進国糞バカ中世ジャップランド土人村の末路
Rustは通常の言語仕様で欠落してる部分がある
>>826 デフォルト引数やキーワード引数が欲しいのは分かるけどオーバーロードが欲しいのはなぜ？
デフォルト引数が必要だと思うならそれはもう関数オーバーロードが必要だとおもっていることと同義だろ
>>825 C：f= open(out, O_WRONLY|O_CREAT|O_TRUNC, 0777);
D：auto to = File("output.txt", "wb");
Erlang：{ok, Contents} = file:read_file( "input.txt" ),
Fortran(2003)：open(in, file="input.txt", status="old", action="read", access="stream", iostat=err)
Basic(Free Basic/VB)：Open "input.txt" For Input As #1
Nim：var f = open "output.txt", fmWrite
Objective-C：NSData *data = [NSData dataWithContentsOfFile:@"input.txt"];
Perl：open my $fh_in, '<', 'input.txt' or die "$!";
Python：infile = open('input.txt', 'r')
Tcl：set infile [open "input.txt" r]
Rustは異質、ド変態はFortranとObjective-C。Swiftは知らん
>>848 こう見るとPythonが一番美しいな
例外あるからエラー処理省略できるし
これが良いかどうかはまた別の話として
一般的にデータを初期化する際にいくつもの数のオプション値指定が存在するものが多い
>>849 Rustは例外機構がないからもっとエラー処理がシンプル
「?」一文字付加するだけで(必要ならエラー自動変換しつつ)上位関数にエラー処理委任できる
そのため例外機構がなくても記述がシンプルかつ同様のことが出来るだけでなくエラー処理忘れなどもコンパイル時に指摘してくれて安全
こんだけ色々な言語が乱立するってコンピュータの世界はバベルの塔だわ
twitterの「スタバでMacを開くエンジニア」って奴ほんと嫌い
その大したことない記事に助けられてるからバカにされてるんだろアスペｗ
コピペしてすぐ使えるコードが出ている
qiitaもワイもアカウント持ってて投稿したりしてるぐらいだから別に否定しているわけではないんだが
qiitaがクソだと言っている分けではなくてただこいつがqiitaに載せている記事すべてが糞だっていう意味を言っている
気になるんなら見とけよ内容もtwitter上を跋扈するいわゆる情報商材系サイトのそれに近くて技術的な要素を一切含んでいない
https://qiita.com/SMAC ここはお前の日記帳かよ
>>862 Ｔｗｉｔｔｅｒ一生懸命見て彼の成長に嫉妬してる時点で、君の”負け”やで
>>864 「エンジニア1年生必見おすすめ入門書！」「【20XY年度最新】無料プログラミング学習サービス」「基本情報技術者試験のための戦略的方法」みたいなしょうもない記事しか書いていない奴のどこに技術的成長を感じればいいのか疑問なんやけど
お前はまさかこういった記事を見て勉強してんのか？（笑）
お前が勝ち負け判断すんの？（笑）
少なくともSNSで頻繁に目障りな投稿をしている人が他の媒体でどのような活動をしているのか確認する行為自体を一生懸命にならないとするの達成できない時点でお前がこの一連の流れのどんな登場人物よりも劣ってること明白じゃんｗｗｗｗｗｗｗｗｗ
きっと自分の電話にかかってきた電話番号を迷惑電話だったのかどうかネットで調べて確認すると言った最低限な行為すらも日常生活の中でするのには精一杯になってるんやろなｗこの低脳（笑）ｗｗｗｗｗｗｗｗｗｗｗ
デジタル人材の副業・複業採用決定数をプログラミング言語・スキル別で分析
~副業・複業人材の登録が、前年度比3倍に。 調査レポートを公開~
https://prtimes.jp/main/html/rd/p/000000040.000053307.html >>868 レスバ判定員です
言い返せなくなってる時点でお前の負けやでｗｗｗｗｗｗ
>>872 Qiitaの若者の成長に難癖付けて２ｃｈ陰口で悦に浸ってるオッサンとか
キモすぎにもほどがあるでんで
もうちょっと客観的に自分を見つめ直した方がええで
>>825 rustが汚く感じるのはビルダーパターンが気持ち悪いのか、ファイルのopenにビルダーパターン使うのが気持ち悪いのか、どちら？
>>878 どちらでもない
optionをopenするのが気持ち悪いだけ
let mut stream = FileStream::builder().read(true).write(true).build("foo.txt")?;
Rustにはなんでデフォルト引数ないの？
でもパス名が最後に来るの確かに思考の順序と一致しなくてウザいな
>>878 ソフトエンジニアはビルダーパターンは気持ちよすぎになるが
一方、ドカタは気持ち悪いになるってだけだろ
言語としては主ターゲットユーザーがソフトエンジニアかドカタって重要だからな
Rustはソフトエンジニアがターゲットで、そうじゃない奴はRustじゃなくドカタ用言語使え
ってこと。
そうでなくて最後にopen()でビルダーが終了して実行そしてエラーが返る
あと余談だが >>884 のO_NOFOLLOW指定はUNIXのC言語プログラマーなら馴染みでも一般的にわかりくいという時 ビルダーパターンはオプション引数のある言語でも簡単に実現できるんだが
Rustは代数的データ型のOption型があるから特に困らないんじゃない？
欲しいのはオプション引数というかキーワード引数？
デフォルト引数のことか
デフォルト引数はあったほうがいい
>>891 あのゴミみたいなsyntaxで目指してるとか鼻で笑うで
>>891 Goには当然デフォルト引数は無い
あと、GoはPythonとは真逆の思想
RustもGoも標準ライブラリが良くない
>>889 欠陥言語なんてものはそもそもほとんどない
デフォルト引数は新言語に人気が出てくると確実に要望が出てくる
いつかは実装される
実装できる余地がある言語はいいけど言語仕様上実装不可な場合はどうしようもない
>>889 ある言語が他の言語に比べて劣っている部分があるということと
その言語が欠陥言語かどうかは全く別の問題
もう少し論理的に物事を考えよう
Rsutは意味不明なんだよな
Rustはソースコード上の情報多くしたい感じだからデフォルト引数は入らなさそう
デフォルト引数もなく関数オーバーロードがないから謎の関数がぼこぼこ増えるんだろうな
言語を作った人間がデフォルト引数絶対に入れない！って言ってても
Rustはすでに作った人は居なくなってるし
Rustは複雑な引数はstructで渡しなさいという考えだから
..Default::default() にシンタックスシュガーあって短く書ければいいんだけど
引数爆発の解決のアプローチはいろいろあるわな
>>899 デフォルトは作ればあるよ
オプション引数の代替策の一つとしても使える
>>903 >>902 Rustでは不可欠な機能が着実に次々と実現されていっており
それら全て状況も議論も全てオープンに行われている
互換性、安全性、関連する影響がないことなど全て満たす必要があるためどの案件も時間がかかるが信頼できて安心できる
関数の引数の諸々の件も長くオープンに議論され続けているが様々な諸問題がでておりそれらを解決しうる仕様がまだ出来上がらずかなり先になるだろう
そして色々な代替手段があるためこれを必須として現実に困っている人がいない問題でもある
>>903 なんや、既に崩壊してる言語なのか
ざまあねえな
>>912 創始者が抜けたのはバーンアウトしたかららしい
>>912 修復不可能なデザインバグを見つけてしまったから逃げたんだろう
Mozilla関係の組織っておんも歩けないような人が多いよね
燃え尽きて去ったRustの創造者はいまはどこで何をしているんだ？
>>910 Rustコミュニティがオープンだとは全然思えない。async-stdとtokioなんか正にそう
>>917 やっぱゴミはゴミに惹かれるんやね
XウンコードとかいうゴミゴミのゴミIDEバンドルのゴミに惹かれるなんて
やっぱゴミ
>>910 apple信者の人たちと大して変わらんなｗ
androidにしかない機能があっても必要ない、問題ない、困ってないと言い放つが実装されると大騒ぎして喜び
誇らしげに自慢する
何週遅れてんだよと
全て状況も議論も全てオープンに行われていればまあこんな事になるわけがないよなww
「The entire moderation team resigns, effective immediately. This resignation is
done in protest of the Core Team placing themselves unaccountable to anyone but
themselves.」
https://github.com/rust-lang/team/pull/671 >>921 気持ち悪いRust信者はこの板に1人いるだけだぞ
通称複オジこと、はちみつオジ
>>917 おいおい、ほんとなのか。
優秀な奴だろうからどっかが雇っているだろうと思っていたが。
appleならMozillaより激好待遇だろうな
>>923 Qiitaで若者に嫉妬したりエアプRust信者したり大変だな
コミュニティの意見に向き合うのは難しい問題で、どの言語でも同じ
そして批判の声が見当たらないコミュニティは逆に危険
>>926 なんちゃらファウンデーションなんてそれはコミュニティに向き合うとか組織体制がちゃんとする努力をしているとは違う。後ろにスポンサーがいるかどうかが違うだけ
得てしてプラス面もあるが多くは大企業の意見がよく通る
>>929 どの言語のコミュニティが理想だと思う？
ジャップは10年遅れでPython受け入れだしたからな
Julia流行の隆盛とともに死すﾅﾑｰ（-人-）
１０年後にジャップランド土人村が残ってるかも疑わしい
>>934 ってどこの国の人なんやろな
なんかウンコのにおいしてるけどｗ
今の日本の体たらくはジャップランド土人村と呼ぶにふさわしいよ
声の大きいクソユーザーのせいで言語がどんどん変わっていくC#
>>938 具体的にはどういうとこ？
俺は最初からC#ダサいと思ってたけど
>>939 具体的にダサいところあげてくれ
ついでにダサくない言語も教えてくれ
単純にMicrosoftのソフトウェア開発能力がめちゃくちゃ高いからどんどん変わっていけてるだけだぞ
言語仕様が使いもしないパターンマッチよりにどんどん変わってる
x is { Name.Length: 1 }
MicrosoftはTeamsのアップデートしすぎ、ほぼ毎日バージョンが変わる。マジで勘弁してほしい
C#は場当たり的に糖衣構文追加するもんだから
さすがに C++ Perl Ruby には敵わないだろ
>>944 具体的に他の言語で書くとどういう記述に相当するもの？
>>951 シンプルでなくイージー
型無し糞言語代表だろ
他の言語の定型文をそのまま日本語に持ってくるからそうなる
Rubyはスクリプト言語にしてはPythonに比べ型は厳格だが、なんにでもなれるメソッドなかったっけ？
シェルスクリプトにも変数の型はあるしアセンブリもレジストリの種類は意識しないといけない
型なし言語って、誤用でしか用例を聞いた覚えがないけど、型なし言語とかいう用語はあるの？
値に型がない言語のことを型なし言語、って呼ぶのは正しいの？
型無し言語じゃない
>>961 https://ja.wikipedia.org/wiki/%E5%9E%8B%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0#%E5%9E%8B%E3%81%AA%E3%81%97 型付けを更に厳密に定義した区分として型なし（英: untyped）という区分が存在する。
代表的な言語としてはSmalltalk[7]、BCPL、B言語、アセンブリ言語などがある。
Smalltalkでは高速化のため処理系依存で実行時に型検査することがあるものの言語的には型検査がなく、
動的型付け言語のように文字列に割り算をするといった不正な操作をしても処理系が型検査して停止する事は無い。
BCPL、B言語、アセンブリ言語などオブジェクト指向とは関係なく型を持たない言語では、
ハードウェアのワード長に依存した1種類の型のみを持つか、
言語を使う側でデータを参照するときにデータ幅や種類の解釈を決定することとなる。
>>960 bashのdeclareについては一旦忘れていただく方向でお願いします
>>964 ほんまや
Brainfuckとかみたいな難解言語もだいたいuntypedかな
>>963 が言っている型無し言語とは、一つの変数がいろいろな型の値を束縛できるってこと？
untypedは基本的にdynamically typedのこと
>>968 > untypedは基本的にdynamically typedのこと
出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。
型付けなんてプログラマにとっては基本の基本で
次スレ（リニューアル）
http://2chb.net/r/tech/1655719441/l50 ↑次スレのリンクです。もし興味があればどうぞ。
（一定数いる最強言語決定戦を続けたい層には不向きかもしれないので、
棲み分けなどに、もし良いアイデアがあればどうぞご自由になさいませ。）
>>972 今どきの言語ならそんなことは起きないんじゃないかな
例えばRustの標準ライブラリには同名のreplace()という関数が10個もあるけど
(1) まず名前空間が分かれている
例えば str::replace() や Option::replace() など
(2) 次にメソッドの場合は名前空間を明示する必要がない
例えば let s = "価格: 123円"; という文字列に対してはstr::を付けずに
s.replace("価格", "値段"); // → "値段: 123円"
(3) 更にジェネリックな引数も取れる
例えば文字列""ではなく文字''も指定可能
s.replace('円', "万円"); // → "価格: 123万円",
文字判定関数を指定することも可能
s.replace(char::is_numeric, "*"); // → "価格: ***円"
このように様々な対象に対して様々な引数で用いられていても
同名のreplace()で曖昧になることもなくそれぞれを使うことができる
昔のように長い関数名を付けずに済むようになっている
>>977 3つともオーバーロードやデフォルト引数はほぼ関係ない話じゃん
3つめがかろうじてオーバーロードに引っかかってはいるが論点が違う
シャドーイングがOKで関数オーバーロードがNGって普通は逆じゃね？
>>982 その2つがどう関係あるのか説明してくれ
シャドーイング 同じ変数名で実際は完全に別物
引数の型が違うだけならジェネリクスでいいし、ジェネリクスで表現できないような
せいぜい意味不明なワードがくっついた似たり寄ったりの関数を大量に作ってくれよ
>>984 なるほどそういう意味か
イミュータブルとムーブがデフォルトだとシャドーイングNGだと命名負荷が高くなりすぎるのよ
オーバーロードやデフォルト引数/オプション引数ないとメソッドの命名負荷が高くなるのと似てる
>>982 C++/Java/C#書いてる脳だとまあすんなり同意するけど
OCamlだのHaskellだの書いてる脳で読むと「お前の普通なんか知らねーよ」って感じだな
>>982 効果が真逆という結論のようです
> シャドーイングは同時に存在できるのが一つだけで曖昧さがなくプログラミングにおいてプラス効果
> オーバーロードは同時に異なるものが存在できるため可読性を下げたりミスを起こす機会を生じさせてマイナス効果
確かにシャドーイングが出来ない言語では例えば
price_str = "398"
price_int = int(price_str)
とするかミスを生みやすい動的型付けで同じ変数名priceに入れるようです
シャドーイングがいかに優れているかよくわかりますね
書き込みする前に読み返したか？
Rsutは関数オーバーロードがないから
>>991 そういう時にメソッドではない不要なグローバル関数を設けるプログラミング言語は時代遅れ
もしstrに対してintに変換する関数int()を用意するならばstrのメソッドとして用意する
君には
>>977 を読み直すことを勧める
Rustは同様に abs(ｘ)ができない
>>991 Rustではintが多数あるため
let s = "98765";
let a: i32 = s.parse()?;
let b: u64 = s.parse()?;
となります
どちらも同じメソッドparse()で大丈夫です
あなたが使っている言語では多数のint毎に別々の変換用の関数があるのですか？
>>993 >int(price_str)できない
>Rustは同様に abs(ｘ)ができない
それはどっちもできるよ
parseは多分ジェネリック実装されてて戻り値の推定からジェネリック型決めてるんだろ？
>>985 ジェネリクスはまた別物だろ。
ライブラリ無いからシステムコール利用する機能を提供しようとする。
例えば socket(2)でいいわ。
第3引数なんて使うことないからと第2引数までを取るAPIとして公開、後になって第3引数必要になった(例えばSCTP利用)ってなった場合、オーバーロードできないとAPI変える必要あるじゃん。
>>996-997 それは実質fabs()と変わらない
ID:nghM89d8のレス一覧： >>825 メソッドチェーンでオプション書くの大嫌い
単なるデータは普通にデータとして書かせてくれ
>>825 君その話前にもRustスレでしてなかった？
ケン・トンプソンなんかおまえ
> ile, err := os.OpenFile( os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0777)
>>837 The 老害やな
長いものに巻かれろ、年長者は無条件に敬え、右に倣え、出る杭は打て、死なば諸共
これが衰退先進国糞バカ中世ジャップランド土人村の末路
Rustは通常の言語仕様で欠落してる部分がある
>>826 デフォルト引数やキーワード引数が欲しいのは分かるけどオーバーロードが欲しいのはなぜ？
デフォルト引数が必要だと思うならそれはもう関数オーバーロードが必要だとおもっていることと同義だろ
>>825 C：f= open(out, O_WRONLY|O_CREAT|O_TRUNC, 0777);
D：auto to = File("output.txt", "wb");
Erlang：{ok, Contents} = file:read_file( "input.txt" ),
Fortran(2003)：open(in, file="input.txt", status="old", action="read", access="stream", iostat=err)
Basic(Free Basic/VB)：Open "input.txt" For Input As #1
Nim：var f = open "output.txt", fmWrite
Objective-C：NSData *data = [NSData dataWithContentsOfFile:@"input.txt"];
Perl：open my $fh_in, '<', 'input.txt' or die "$!";
Python：infile = open('input.txt', 'r')
Tcl：set infile [open "input.txt" r]
Rustは異質、ド変態はFortranとObjective-C。Swiftは知らん
>>848 こう見るとPythonが一番美しいな
例外あるからエラー処理省略できるし
これが良いかどうかはまた別の話として
一般的にデータを初期化する際にいくつもの数のオプション値指定が存在するものが多い
>>849 Rustは例外機構がないからもっとエラー処理がシンプル
「?」一文字付加するだけで(必要ならエラー自動変換しつつ)上位関数にエラー処理委任できる
そのため例外機構がなくても記述がシンプルかつ同様のことが出来るだけでなくエラー処理忘れなどもコンパイル時に指摘してくれて安全
こんだけ色々な言語が乱立するってコンピュータの世界はバベルの塔だわ
twitterの「スタバでMacを開くエンジニア」って奴ほんと嫌い
その大したことない記事に助けられてるからバカにされてるんだろアスペｗ
コピペしてすぐ使えるコードが出ている
qiitaもワイもアカウント持ってて投稿したりしてるぐらいだから別に否定しているわけではないんだが
qiitaがクソだと言っている分けではなくてただこいつがqiitaに載せている記事すべてが糞だっていう意味を言っている
気になるんなら見とけよ内容もtwitter上を跋扈するいわゆる情報商材系サイトのそれに近くて技術的な要素を一切含んでいない
https://qiita.com/SMAC ここはお前の日記帳かよ
>>862 Ｔｗｉｔｔｅｒ一生懸命見て彼の成長に嫉妬してる時点で、君の”負け”やで
>>864 「エンジニア1年生必見おすすめ入門書！」「【20XY年度最新】無料プログラミング学習サービス」「基本情報技術者試験のための戦略的方法」みたいなしょうもない記事しか書いていない奴のどこに技術的成長を感じればいいのか疑問なんやけど
お前はまさかこういった記事を見て勉強してんのか？（笑）
お前が勝ち負け判断すんの？（笑）
少なくともSNSで頻繁に目障りな投稿をしている人が他の媒体でどのような活動をしているのか確認する行為自体を一生懸命にならないとするの達成できない時点でお前がこの一連の流れのどんな登場人物よりも劣ってること明白じゃんｗｗｗｗｗｗｗｗｗ
きっと自分の電話にかかってきた電話番号を迷惑電話だったのかどうかネットで調べて確認すると言った最低限な行為すらも日常生活の中でするのには精一杯になってるんやろなｗこの低脳（笑）ｗｗｗｗｗｗｗｗｗｗｗ
デジタル人材の副業・複業採用決定数をプログラミング言語・スキル別で分析
~副業・複業人材の登録が、前年度比3倍に。 調査レポートを公開~
https://prtimes.jp/main/html/rd/p/000000040.000053307.html >>868 レスバ判定員です
言い返せなくなってる時点でお前の負けやでｗｗｗｗｗｗ
>>872 Qiitaの若者の成長に難癖付けて２ｃｈ陰口で悦に浸ってるオッサンとか
キモすぎにもほどがあるでんで
もうちょっと客観的に自分を見つめ直した方がええで
>>825 rustが汚く感じるのはビルダーパターンが気持ち悪いのか、ファイルのopenにビルダーパターン使うのが気持ち悪いのか、どちら？
>>878 どちらでもない
optionをopenするのが気持ち悪いだけ
let mut stream = FileStream::builder().read(true).write(true).build("foo.txt")?;
Rustにはなんでデフォルト引数ないの？
でもパス名が最後に来るの確かに思考の順序と一致しなくてウザいな
>>878 ソフトエンジニアはビルダーパターンは気持ちよすぎになるが
一方、ドカタは気持ち悪いになるってだけだろ
言語としては主ターゲットユーザーがソフトエンジニアかドカタって重要だからな
Rustはソフトエンジニアがターゲットで、そうじゃない奴はRustじゃなくドカタ用言語使え
ってこと。
そうでなくて最後にopen()でビルダーが終了して実行そしてエラーが返る
あと余談だが >>884 のO_NOFOLLOW指定はUNIXのC言語プログラマーなら馴染みでも一般的にわかりくいという時 レス：1-200 201-400 401-600 601-800 801-1000 ALL
このスレへの固定リンク： http://5chb.net/r/tech/1650185555/ ヒント： http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「次世代言語25 TypeScript Swift Go Kotlin Rust Nim YouTube動画>4本 ->画像>2枚 」 を見た人も見ています：・次世代言語24 Go Nim Rust Swift Kotlin TypeScript 次世代言語17 Go Rust Kotlin TypeScript Julia 【悲報】iPhone 17, Google Pixel 10, Galaxy S26 シリーズなど次世代スマホ、トランプ関税で15％以上の大幅値上げへ ありがとうおやびん 次世代ゲーム機テクノロジースレ【Pro/Switch/Scorpio】 【正規スレ】【PS5】RDNA2X SIE次世代機予想スレ HWRT 高速SSD アンチ出禁 82世代目 【PS5PRO】 gamestopとマイクロソフトが業務提携 これって次世代機の勝負になんか影響ある？ 【apple】次世代iPod touchが開発中？ 次世代switchのスペック 次世代iPhone 294 次世代iPhone part1 次世代iPhone Part268 次世代iPhone Part264 次世代iPhone Part254 次世代iPhone Part271 次世代iPhone Part253 【スマホ】iPhoneが次世代モデルで「液晶」を全廃、OLEDディスプレイのみを採用 日本メーカーに打撃 〓〓〓いつまでも次世代 IMAP その２〓〓〓 【PS5Pro】次世代機予想スレ128世代目 【PS6】 【PS5Pro】次世代機予想スレ124世代目 【PS6】 【PS5Pro】次世代機予想スレ 101-8世代目 【PS6】 【PS5Pro】次世代機予想雑談総合スレ 115世代目 【PS6】 【PS5】SIE次世代機予想スレ 【携帯機&PSVR2】 13代目 【PS5Pro(Trinity)】次世代機予想スレ 105世代目 【PS6】 【PS5】SIE次世代機予想スレ 【携帯機&PSVR2】 17世代目 【PS5】SIE次世代機予想スレ 【携帯機&PSVR2】 21世代目 【PS5】お披露目間近 SIE次世代機予想スレ【携帯機&PSVR2】 53世代目 【PS5】爆速2.23GHz RDNA2 SIE次世代機予想スレ 光速SSD アンチ出禁 75世代目 【PS5PRO&PSP3】 「Star Wars ジェダイ：フォールン・オーダー | 次世代機版の最適化アップデート」でまた差がつく 次世代の哲学を育むスレ Part 15 次世代Nintendo Switch総合スレ ★41 【次世代ナビ】グーグルマップ、ＡＲ（拡張現実）使ったナビ機能の試験運用開始 【xbox】『ELDEN RING』をプレイしたXboxのヘッド、本作は宮崎英高の「最も野心的な作品」【次世代】 次世代機が年末のSwitchに勝つために必要なソフトって何？ Switchの次世代機が出るなら当然名前は「Switch U」だよな…？ よく次世代switchの話になるとバッテリー問題の話になるけど何とかならんの？ Switchの次世代機はサイバーパンクとかRDR2とか移植されそうじゃね？ 次世代Switch、サムスン製の第5世代V-NAND採用でゲーム読み込みを高速化か 【悲報】X民「Switch2のどこが次世代機なの？任天堂至高の人気持ち悪すぎ。」 Switch2が成功したとして、ソニーとMSは次世代機をどういうコンセプトにするのか 【速報】任天堂新型Switch用のVR/AR特許が公開。有名リーカー「次世代SwitchはVRハイブリッドになる」 【クルマ】日産 次世代EVの新型リーフ 2017年9月正式デビューへ！米テスラへ対抗か DF「NBA 2K21次世代版は解像度は同じでXbox series Xだけフレームドロップする」 「XboxSeriesSは4テラフロップスなので次世代マルチプラットホームの足を引っ張る」←これ 【ID無し】次世代ガールズグループ総合スレ 2【NiziU、aespa、IVE、Kep1er、NMIXX】 Z世代が選ぶ「次世代SNS TOP10」にmixi（ミクシィ）がランクイン 【NEO】【NX】 次世代ゲーム機テクノロジースレ No.10 【Scorpio】 【NEO】【NX】 次世代ゲーム機テクノロジースレ No.13 【Scorpio】 PS5期待の新作『Rise of the Ronin』ゲームプレイ公開！圧巻の次世代グラフィック！【神ゲー】 任天堂の次世代ゲーム機 Nintendo Smart、「すでに量産開始されている」とWSJが報道 次世代エモスク掲示板？ 次世代ディスプレイ MEMS46 次世代MacBook Airに望むこと Drico 次世代楽譜作成ソフト 東京マルイ次世代電動ガン85 AMDの次世代GPUについて語ろう 2世代 Intelの次世代技術について語ろう 130 AMDの次世代コアについて語ろう 245世代 正直、任天堂の次世代機て詰んでるよね？ SONY 次世代Xperia 総合本スレ 296 SONY 次世代Xperia 総合本スレ 298 【次世代国2】2020年代の覇権を予想するか Sony Mobile 次世代Xperia 総合125 NMBだけ次世代メンが全く育ってない問題 Sony Mobile 次世代Xperia 総合276 Sony Mobile 次世代Xperia 総合189
19:03:06 up 3 days, 9:25, 1 user, load average: 6.40, 7.21, 7.48
in 1.4956049919128 sec
@[email protected] on 102608
ブックマークへ