次世代言語25 TypeScript Swift Go Kotlin Rust Nim
■ このスレッドは過去ログ倉庫に格納されています
スレタイ(順番はRedMonk準拠)以外の言語もok 前スレ 次世代言語24 Go Nim Rust Swift Kotlin TypeScript https://mevius.5ch.net/test/read.cgi/tech/1647887021/ >>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>はヒープを使う型の一つに過ぎない それ以降の記述は全く意味不明 ベアメタル等OSなしでも動作しないといけないため Rustはヒープを前提とせずに動くよう設計されている >>444 本当はスレ民のことが気になって仕方ないだろ? 隠しても無駄www なぜせっかくRustで作られたブラウザを除外するかね? 「NHKプラス」、「Firefox」での視聴が不可能に 5月23日から推奨ブラウザを「Microsoft Edge」「Google Chrome」「Safari」に限定 [孤高の旅人★] https://asahi.5ch.net/test/read.cgi/newsplus/1651490664/ >>448 そのどれかのブラウザがインストールされてない端末って何がある? Linuxと組み込みくらい? >>448 もし本当に視聴不可となったら技術力が無さすぎる 昔ならともかく今の時代にブラウザ依存なコードを書くのはダメなプログラマーの典型 視聴不可ではなく動作確認するブラウザの数を絞るなら理解できる > 「Firefox」など、上記3ブラウザ以外での動作はもともと確認しておらず、推奨ブラウザには加えていなかったという。 > 「5月23日以降に予定している設備更新に伴い、Firefoxでは動画が完全に再生できなくなる どういう設備更新なんだろうな・・・ WebKit系じゃないと使えない仕組みがあるのか 今どきはブラウザ依存な書き方する方が面倒だろう。普通にテストしてないだけでは。 chromiumにしか実装されていない独自拡張機能に依存したAPIに手を出したとか?? でもSafariで動くなら違うか Firefoxでだけ動かないコードなんて可能なのか?? そういえばchromeにrust使う話ってどうなったんだ? たしかFirefoxもまだ全部はRustに治せてないんだろ >>461 君は何らかの大きなシステム開発に関わったことがないのかね? どんな言語と言語の場合でも一気にやることは不可能かつムダ 新規部分や改修部分に絞って手を付けていく >>462 なるほど だからよそと違ってバグまみれとか言われるんやなw 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のほうがローリングリリース・ローリングアップデートの期間が短い(現在は4週間)2021/3頃から6週間から変更された。 以前はFirefoxはローリングリリースを採用していないかった。またChormeの使用者がFirefoxより10倍なので脆弱性も発見されやすい。 何かと問題なSafariの脆弱性がこれだけのはずが無く、脆弱性報告数=危険なブラウザとははっきり言えない 途中まで数字で語ってるのに最後だけ願望になっててワロタ 木を見て森を見ずという言葉を考えた昔の人はいいセンスしてる Appleって莫大な利益を何に消費しているのだろうね >>448 そもそもNHKは見ないのでどうでも良い。 >>472 ウィグル弾圧に使われてる可能性が高い。 いまどきウェブ見てて落ちるブラウザなんてファイアフォックスくらいだし、そこらへんは忠実にネスケ以来の伝統を受け継いでて驚く。 トリビア:Firefoxユーザーはレベルが高いの致命的なバグがあっても自分で治して使っている >>475 ここ数年間の常用者だがFirefoxが落ちたことがない もしデマカセを言っているのでないのならばどういう状況で落ちたのか語ってほしい >>475 Chromeは週一ぐらいで落ちる IME変換中に間違えてファンクションキーを押すと落ちる >>477 数か月前に頻繁にメモリ不足で落ちてた。タブがクラッシュする >>481 それメモリが少なすぎたとか メモリを超える巨大なデータを読み込んだとか 無数にタブを開いたとかそういうオチだろ 逆に100兆個のタブを開いて落ちないブラウザってどれ? メモリ不足を、クラッシュせずに通知くらい【余裕】にできないと。 当たり前のこともできない。所詮現世人類の我々の技術力はそこまでということだ―― >>477 Windowsでタブレットモードにしてると頻繁に落ちるな。 落ちるというか、無限ループしてるっぽいんだよな。 入力を受け付けず、タスクマネージャで見るとCPUをぶん回してる。 頻繁に落ちるのに、落ちないとか信者が言い張るのも、ネスケ以来の伝統だよな。 英語設定のLinuxだけど落ちないよ? バグってるのはサイトかホストなのでは? Windowsでここ何年か使ってるけれど、 特に気になる動作は無いけれどな。 Edgeの印刷で返ってこない方が辛い。 FireFoxで微妙に表示が崩れるとChromeだとちゃんと表示されるのか気になる 表示させてみて同じだとホッとして違ってたらがっかり Rustが、Goの最大の競合相手であることが明らかになったってよw プログラミング言語「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で書いている どこでもそうだよ 理想の家族 父 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を気をつけて使い分けないといけないのとか面倒だと思うけどな Goの一番の面倒さはnilとエラーハンドリングかな Option/Result型だけでも特別に用意されてれば、もっとGo使ってたかもしれん >>506 Rcは出てこないプログラムも多い Arenaはほぼ完全に出てこない つまりそれらレアケースを元に語るのは現実的ではない Rustで引っかからずコードを書き上げるのはかなりの猛者だと思うよ 本当の意味での言語仕様部分は何とかなるかもしれないけどそこから先がつらい 入門4冊目の「コンセプトから理解するRus」tを読んで途中で投げ捨てた 本自体は良書なんだけどtrait境界がもう人間の理解を超えてる Cだと時間をかければ書き終えれるけどバグが入ってる可能性がある 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!(); } 実際にトレイト境界の条件の実装部分を読んでみた シンプルなマクロで書かれてる部分もあれば複雑な部分もある そこで書いてある実装が本当に確実の条件を満たしうるのかは分からないし ドキュメントを読んでも厳格な意味が書いてあるわけでもない どこかで漏れがあってもわからない 例えば条件の一つがよくよく考えてみればさらに二つに分離して考えないといけないものだと 後で判明するともう既存のコードがみんな死んでしまう 使用してる所を全部さかのぼって修正しないといけない それかRust自体の仕様変更で死んでしまったりいろいろ死にそうな要因がたくさんある マクロでやりすぎてる >>518 そんなこと起きたことがない 聞いたこともない机上の空論 Rustの標準ライブラリの設計がそもそも間違ってて、その修正のために破壊的な変更がいきなりきたら大変だ、って話? そんな馬鹿な、と笑っちゃうね サプライチェーン問題は批判理由が見つからない人が持ち出しがち。 マクロがない言語だと、同じ機能をコンパイラやらランタイムが持ったりするわけだが、不思議に誰もそれらの機構を疑わなかったりする。 中身が可視化されたのに逆に疑わしく感じた場合は、まずは自分の知識が足りなかったことに気づきましょう。 実装の問題は重要だろ。 そもそも実装と独立に仕様だけ語れるような作りにrustはなってない。 何を問題視してるのかもうちょっとわかりやすく書いてくれないと議論にならん コーダー風情にはどこら辺に問題があるかすらわからないんだ ほっとけばいい >>522 依存型理論原理主義過激派かな?ちょっと面白い >>527 Π型はないけど、const genericsなら… >>521 ランタイムが持ってる言語ならランタイムをアップデートしたら終わり マクロの言語は該当箇所を探し出して修正して丸ごと再コンパイルが必要 工数考えたらどちらが有利なのかすぐ分かる 知識が足りないのはどちらなんだろうか? >>529 現実には起きない架空の話だから両者ともにバカげている ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる