プログラミング言語 Rust 4
レス数が1000を超えています。これ以上書き込みはできません。
仕事で使ってるけど、小さな会社なので、皆さんのご期待には沿えない。 >>97
せめてモジラの提灯持ち以外にまともにプロダクションで使ってる企業を出してから言えよ クローズドソースのときって、どういうスタイルなの?
crateのパスを相対で書きまくるのか、巨大ctateをつくるのか https://www.rust-lang.org/en-US/friends.html
公式サイトのこのページくらいは見たことあるだろ?無いのか?無さそうだな。
まともな耳目がついててこのページ見てるならそんなレスできねえもんな >>106
まさかソースといってモジラの大本営発表持ち出してくるとは思わんかったわ
そんなもんただの提灯で何の意味もない。使ってる根拠にはならない
せめてそういう企業がGithubで公開してるものがあるとかなら認めるがそうじゃねえだろ ちょっと前までのfirefoxをRust使って書けるわけない失敗すると言い張ってからの
この流れは笑える >>108
失敗してるやん
Rustなんかで書き直したせいでアドオン全滅してる >>107
昔と比べるとだいぶオープンソースな時代にはなったが、
全てがオープンソースで開発されるような時代ではない。
公式の発表を信じずに何を信じろと?
「俺を信じろ」とでも言うつもりか?
「公式」と「お前」どちらのほうが信用度が高いのかまさか君にはわからないのか? まぁ、けど確かにここに載っているのは社内の一部の物好きな社員が
メンテの必要もないくらい簡単な社内ツールとかを作るのに
利用しているだけのような気はしているんだが、実際はどうなんだろうな? 少なくともブラウザから得た個人情報の横流しとステマで生計を立ててる非営利()組織の大本営発表は信じるに値しない >>109
それは設計の段階で従来のアドオンとの互換性の一部を捨てるように仕様変更したからだよ。
firefoxのアドオンは自由度が高すぎるが故に、セキュリティに問題を抱えやすかったし、
アドオン同士が衝突して落ちるとかも結構あったから、そこら辺をChromeと同レベルくらいに制限して、
セキュリティと安定性を取る方向に方針転換した。
仕様が変わってるんだから、Rustで書こうが他の言語で書こうがどっちにしろ従来のアドオンの一部は動かないよ。 >>113
あ、これネタだったの?
気づかずにマジレスしてしまったわ。すまん。 こっちとしちゃ糖質クンに「自分は視野狭窄している馬鹿なんだ」って気付いてもらうんじゃなく
ただどっちが妥当な話をしているのか周りに伝わればいいんだわ。乙。
Redditで、自社の既存のシステムをRustで書き直したよって言う投稿をよく見かける
自分で触った感じでも、プロトタイピングや全く新しいシステム作るときは他の言語でやった方が楽な気がするけど、
試行錯誤もRustでやった方がはやいわってなるのかね? >>112
どちらが信用度が高いのか本当に分からなかったようだ。。。
君には呆れを通り越して憐れみを覚えるよ。 そういう大きな話じゃなくて、もっと身近な感じでrust使ってるかどうかを聞きたかったんだけど、ここまで>>101しか出てこないな rustでチェスの対戦サイト(サーバー)作りましたとかないわけ?
goとかscalaではいくつかあるけど(もちろんphpも) 今まで「担当者の趣味でなんとなく」C, Go, Python, Rubyで書かれていたツールをRustで書いて
おー速いやんとニヤニヤしてる段階
>>105
crateのパスは相対 >>121
やっぱ細かく分けてるの?
っていうほど巨大なプロジェクトじゃないかな? Rustでコード書くのって意外と楽しいよね
クロージャもスッキリしてるし
そもそもあと実は俺はスネークケース文化が好き
map_or ←この時面がすき
mapOr ←こんな言語は(あるとしたら)嫌い スクリプト言語を趣味でやってる俺ですが
firefoxの軽さに感動してrustに興味を持ちました
現在ネットでrustについて調べてる最中なんですが
c++の置き換えだとかっていう情報はよく書かれてますけど
実際c++を書いたことの無い自分にはいまいち掴めません
なんか他に特徴的なとこはあるんでしょうか?
マルチプラットフォームのguiアプリとか作ってみたいです >>125
>なんか他に特徴的なとこはあるんでしょうか?
自分でガシガシ書く向けだよ。C++より綺麗に。JITなんざ頼らねぇ(れねぇ)、GC邪魔(やる余裕がない)って
領域向けに抽象度をある程度保ったまま書ける。メモリ管理にリージョン使うから解放タイミングが予測できるし、
組み込みもベアメタルもいける。nightlyは書式統一されたインラインアセンブラもある。
低レベル全部rustで書いてもいいし、ライブラリだけrustで書いてCから呼び出せばC++不要。
>firefoxの軽さに感動してrustに興味を持ちました
前にも言ったがfx57の速さにrustは関係ない。設計が根本的に変わった影響。
Servoにあるhtmlの並列トークナイズがfxに移植されたらさらに速くなる。
そんで、言語自体は遅いよ。コンパイラもまだ改善途中だし。
標準ライブラリのコードは速度のためにunsafeだらけで、
JIT/GCがある環境みたいにド直球で素直なコード書くもんじゃなくて、
速くなる部分はLLVMの部分だからコンパイラのバックエンドの違いでしかない。
tracing gcないから開放できないメモリがあるのは他と同じ。 >>119
会社で使うコマンドラインツールはほとんどRustで書いてる。
昔はPythonで書いたりしてたけど、使ってるうちにパフォーマンスが問題になったりすることが多くて
後で書き直したりするくらいなら最初からRustでいいや、と。 >>125
コマンドラインツールをRustでってのはときどき聞くんだけど、
GUIのアプリをRustでってのは聞いたことないな。
そもそもRust製のマルチプラットフォーム対応GUIフレームワークってのを聞いたことない。
Rust製のまともなGUIフレームワークとか存在してるの? なるほど、コマンドラインツールか。
rust に合ってる領域かもって初めて納得した。 >>128
gnomeは積極的にRustに寄っていってたはず
他は知らん >>129
pecoとか見てるとコマンドラインツールをカジュアルに作るならgoのが向いてる気もするが……
rustにもrgあるし一概にどっちが優れてるとは言えんが gnomeってrustで置き換えていくの?
rustの実用的なGUIってgtkぐらいだと思うけどqtもそろそろ実用段階だったりするのかね rustで書いてるosってrudoxだっけ?
あれってlinuxカーネルののrustによるリファクタリングって事でいいの?
l >>134
完全な新しいos?
じゃあlinuxにかなうわけねーじゃん。ただの自己満プロジェクトかぁ >>135
OSとしての実用は自己満レベルでも、コードベース資産としては価値あるんじゃねーの?知らんけど
世の中にはいくらでも自己満OSプロジェクトあるんだからそこは許してやれ
あのGNUですらHurdってOSを自己満で書いてんだ Rust Essentials - Second Edition
がPacktから出版されましたね linixこそ個人のお遊びプロジェクトだったんじゃないのか >>139
少なくとも自分はKonozamaくらってる >>136
LZ4圧縮とか、シェルとか、Redox OSはサブプロジェクトに結構見るべきものがある
Pijulプロジェクトで開発されたSSHライブラリとかもそうで、副産物がいい味出してる urxvtをrustで書き直して🙏
alacrittyはなしで🙅 >>138
そうね。その頃にはオープンソースなunix osが無かったからみんな喜んだ。でも今はlinuxがあるわけで。
まぁでもマイクロカーネルらしいし
ドライバはlinuxのが使えるとかすれば、化けるのかな? >>144
歴史の知識もOSの知識も無いなら変なこと言わないほうが良い BSDは訴訟がなければな。
あとminixも最初からライセンスが修正BSDだったらな。 linuxは未だにcで書かれてるわけだけど、
それがrustで書き直されたとしたらどうなるの?予想として。
メモリ使用量は減る?
バグは減るよね。 恐らくバグば減る、メモリ使用量は増える
C言語がサイズ減に全振りしているのをrustは安全側に振ってるからな
だがその前にLinusがブチ切れるだろ間違いない let foo = Foo {
c: f1(),
a: f2(),
b: f3(),
};
let bar = (f1(), f2(), f3());
構造体やタプル構築の時って、式の評価順序はソースに記述されてる順序で確定してるんだっけ?
ここでいうと f1 -> f2 -> f3 で そもそもgnuの成果物でもなんでもない不自由なコンパイラであるrustcでコード書くことを御大がよしとするわけねーだろっていう
GPLでrustc書き直してから出直してこい >>131
確かに go でもいいのかもしれんが、rust で作るとしたら、
規模とかランタイム速度要求とか
良いところなんじゃないの?って気はしたよ。
少なくともOSやブラウザをこれで作るって話よりかよっぽど現実的な感じがする。 rustは明らかに大物を矛盾なく作り上げるの向きと思うんだけれどもな
小物なら正直メモリの心配なんかせずに「mallocの後にfree不要と(以下略)」式にOS任せにしても構わんし 見解の相違としか言いようがないな。
大物をGCなしで作るとか、よっぽどのプロジェクトじゃないとありえん気がするよ。 linuxをrustで書くとか
rustがcに勝る安全性の部分ではcではバグになりうる部分がrustではバグにならないということはあるだろうけど
移植にしろゼロから書き直すにしろ、これら以外のバグが新たに大量に発生するわけで(現行のcで書かれたものは長い間かけてそれらのバグを1つ1つ潰してきた結果であり) >>158
そもそもブラウザこそGC使いたくない大物の代表みたいなもんで、rustはそのために作られたわけで >>159
そのうちAIを駆使してcからrustに理想的にTranslateする技術ができるよきっと AIは置いといて c2rust は同じく妄想した
ふと思ってググったら関数定義を rust で使えるようにするツールが引っ掛かった
c2rust.py
唐突な Python ワロタ bindgenというのはある
が、c->rustのトランスパイラは無理だろう。ValidなCでもvalidなRustには自明には移せない libcクレート使えば、見た目が半分CっぽいRustプログラムが書ける。 勉強中だが業務で初めてRust使う事になった
1000行程度のプログラムだけどこれを機会にスキルアップしないとだ Rustを業務で使った結果、毎週の報告で「コンパイル通らないので修正中です」を繰り返し
全然進捗が出せずに左遷減給からの自主退社コンボをくらう>>167
モジラのステマなんて信じたばっかりにかわいそうにwwwwww コンパイル通らない、って聞くけど、ソースジェネレーターって無いの? 新興言語を業務に採用して爆死するパターンはSwiftで既に学んだから、
Rustの業務採用は考えられない。 Cで書いたコードがgccやclangできっちりコンパイル通るのに
rustに移植して通らないのはrustc(というかRustという言語)が腐ってるからだろ 多言語にベタに移植してコンパイル通らないって喚くって、アホそのもののコメント乙 バグがコンパイル時と実行時のどちらで見つかるかというだけの話なんだがなぁ
CのデバッグよりRustのコンパイル通す方が楽だわ… >>174
何処から突っ込んでいいのかよく分からないのだが。
まず、君の言い方では「C(gcc or clang)でコンパイルが通ったものをそのまま他言語に
移植したらそれもコンパイルが通るはず(通らない言語は欠陥品)」と言っているように聞こえるんだが、
Cは「弱い静的型付け」の言語なので、Rustどころか「強い静的型付け」のJavaやC#
にさえCをそのまま移植するんじゃコンパイルは通らないぞ。
Java,C#の場合はジェネリックやインターフェースや(出来るだけ使いたくないが)キャストを
使用してコンパイラに対してしっかりと型安全を保証してやらなければコンパイルは通らない。
対して、Cは「弱い静的型付け」なのでコンパイルを通すだけなら場合によってはキャストすら必要なかったりする。
まさか、そのレベルから分かっていないのか?
だとしたらRustの所有権云々以前の問題なのだが。 そのレベルは移植の段階で調整しとるわドアホ
やっぱモジラ信者はRustのコンパイラこそ至高で、それを通せないプログラマの方がクソって論調か
相変わらず判で突いたような理論だな 俺が言ってるのは、別にマルチスレッドで動かすわけでもないプログラムを所有権どうこうで弾いて、
本来正しく動くはずのプログラムがコンパイルエラーになり、つまりプログラミング言語としてはご法度の、
書けないプログラムが存在するってことについて異議を唱えてる このスレでも何回も言ってるのに未だに理解しないの
本当に工作員って感じだな >>181
無理だと思うよ。
信者ガーとか言ってるのが居るけど、Codeで示せるなら最初から出してるだろうし。 mozillaが工作してるならこんなところじゃなくてtwitterなどでやるだろうし
工作員連呼してるのは自分自身が他言語の工作員だからでは C/C++から移植して動かない例か。メンバー間参照(self-borrowing)がある構造体くらいしか思いつかんが、
Vec<T>に対する&T -> インデックス使う
Stringに対する&str -> インデックス使う
Map<K,V>に対する&V -> Entry<K,V>使う
異なるメンバーTに対応する&T -> enum使う
で大体対応できるような気がする 業務で速度重視でrustとgoの選択肢がある時にどっちを選ぶべきか悩んでしまう
個人的にはrustの方が好きだしパフォーマンスも出るんだろうけど、今後のメンテ(教育コスト含む)とか考えたらgoにすべきなのかなって
今更null安全でも無くmapやfilterも無い言語は…って感じではあるんだけど
グリーンスレッドは嬉しいが 目的による
外向きサーバ作るならGoのが学習コスト抑えられて楽にスケールする
Rustとの速度差はネットワーク帯域でつぶれて有意に出ないことが多い
長期間メンテするcmdツールやデータ管理ツール作るならRustの方がかっちりかけるから負債になりにくい
Goは気を抜くと容易にサクラダファミリア化する >>186
なるほど
言語としてはrustなんだが、他の人達がついてこれるかが心配だ >>187 がRustを導入した結果、コンパイルが通らずにチームの生産性がだだ下がり
連帯責任で左遷、給与減、恨みを持った部下に夜道で襲われる未来がみえるぅー↑ Goはよく知らんけどnull安全もジェネリックもない言語使うくらいならC++でよくね?としか思わない >>189
いやGCあるかないかは重要な要素でしょう。 Goは標準ライブラリが本当に標準だし、それ故にクロスコンパイルが楽ってのもあるな。
libcを選ぶなんて、しなくて良い。 つまりbetterc的な感じでかな。
goはrustよりはちょっとした気持ちでつかえる。
sshクライアントライブラリまで標準で、しかもopensshとかに頼らず全部自前であるとか、
どんだけ再発明しまくってんのとか。 次スレからワッチョイ有効にしようぜ
同一人物だと思うけどいい加減ウザい ワッチョイしたらそんな変わる?
あんまり変わらん気もするが。 アカヒを遮断したら、差別書き込みが激減してたからね。 発言者が区別つくし、自演も面倒臭くなるからいいんじゃない? ちょっと違う
「あらゆる」書き込みが減る
ワッチョイだとそもそも書き込まないという人はそれなりにいる
都合よく自分の嫌なものだけが減るわけではない
そこは認識して受け入れないといかんよ
あとワッチョイを途中でやめることは実質不可能なのでそれも覚悟すること ワッチョイは自演にはそんなに効果はないと思う
日替わりのIDに代わって日をまたいで同一IPアドレスの奴をNGしやすくなるだけだと思う そういや前にも書いたけど、2ch関連のクレート有るね >>204
カジュアルな書き込みが全部減るんだよ
普通の雑談、普通の質問、普通の回答、普通の自演、普通の荒らし、普通の無自覚アスペ、全部だいたい均等に減る
残るのはワッチョイ出ても構わないような本気の雑談、本気の質問、本気の回答、本気の自演、そして本気の荒らしと本気の無自覚アスペ
だからご利益的には各自手元でどうにかする分類タグとしての>>202だね、これ以外を喧伝してるのはなんもわかってねえ
で、わかったうえでの導入はご自由に 仮に過疎ったりうまくいかなくなったりして「ワッチョイやめよう」という話になったとしても>>206のように言われて元に戻せない
不可逆なので覚悟だけはしておいておくれ ワッチョイ&IPアドレス表示で問題ないと思うよ
IPアドレス表示されて困ることは特に無いし
自演対策には効果ないだろうけどIPアドレス代わらない奴でウザい奴はアボーンできるし ボローチェッカさんに怒られてばっかりでめげそう(´・ω・`) メンターがおればなあとよく思う
Option::as_mutとOption::as_refの存在に長いこと気付かないでいたせいで、自分の設計が悪いのか随分悩んだ IP表示は抵抗ある
ワッチョイ導入はして欲しいけど >>210
君に期待してるから叱るんだよ
本当に君を諦めたら適当にOK出して実行時に事故らせるよ >>210
一般論だけど
最初のうちは小さく作ってみるといいよ
一挙にいっぱいやろうとすると大変よ カジュアルな書き込みって漠然としてるな。
「このスレは○○だから書き込み辞めよう」って時点で既にカジュアルではない気がするけど。
そんな程度で書き込みを辞める奴の情報なんてしれてるだろ。
本気の質問・雑談で良いじゃないの。 >>215
いやーほんとRustプログラマの選民思想ここに極まれりって感じだな
Rustのコンパイラは選ばれし者しか通せない
通せない奴はプログラマとして失格、発言権など無い
モジラらしいわ 「選民思想だ! 自分は排斥されてるんだ!」って完全に病人だなコイツ >>216
どういう事?
コンパイルに関して言えば、コンパイラが文句言うように直せばコンパイルできるし、何より安全じゃん。
どっちかと言うと、選ばれしものしかまとまなソースが書けないCよりも一般寄りなくらいかと。
別にコンパイル通せなくても書き込みゃいいじゃん。これはゴミだ、って。主義主張は自由かと。
通せないやつには書き込む権利はない、と俺が言ってるように聞こえるならば、
つまり自分が「書き込む権利がないと言われてると思い込んでる、通せない奴」だって事? >>219
何度もこれは言語未満のゴミだって根拠と共に書き込んでるのに
コンパイラ通せない奴の僻みだのなんだのいってキチガイ扱いしたのはてめえらじゃねえか むしろ守ってりゃ他はどうでもいいみたいな馬鹿が増える印象
こういう看板みて、禁止されてなければやっていいんだと勘違いするバカみたいに。
https://www.google.co.jp/search?q=%E5%85%AC%E5%9C%92+%E9%81%8E%E5%89%B0%E3%81%AA%E6%B3%A8%E6%84%8F%E6%9B%B8%E3%81%8D&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjmyoeF4s_XAhXCnpQKHdoiCEIQ_AUICigB&biw=1822&bih=903#imgrc=WVv8avT_bPk8NM: >>220
どういう事?つまりコンパイル通せないって事? イミフなdisリって単なる背乗りだから役立たずなんだがなあ。
じゃあどういう言語なら良いの?って聞くとダンマリw
シャドーとか所有権で挫折したのかな?
GC無しとか、動的っぽい使い方が出来るようにする為のもんだって分かってれば、あーこういうアプローチも有りなんだなと思えるけどね。 >>220
キチガイ扱いしたのは事実だが、「僻み」といったことは一度もないぞ。
暇だったし、過去レス検索して確認したから間違いない。
被害妄想甚だしいぞ。
第一、どこがコンパイル通せないかを具体的に書いてくれたら指摘してやるって言ってるだろ。
お前「Cを移植したらコンパイルが通らん」としか言わねえんだもん。
そんな漠然とした情報じゃ指摘しようがねぇよ。 僻みでも何でもなく、そこがいいところなのになぁ、だと思うけどね。俺も。
コンパイルできてたCも、多分misra案件だとまず静的解析ではねられるか上司にしこたま怒られる類だと思うよ。 rustってASTにアクセスできる仕組みってあったりするの? >>226
何がしたいの?
nightly なら syntax クレートとか使えばできると思う。
使ったことないからよく分からんけど。
stableじゃ出来ないんじゃないかな?たぶん。。。
誰かもっと詳しい人いる? >>220
で、どういう言語なら良いの?
またダンマリか、話題逸し?w 一般に普及した言語の仕事でクソ仕様にひどい目にあって
アンチになるというのなら理解できるが普及すらかまだわからない
新興言語でここまでアンチ活動する情熱の根源はどこだろう リアルで実害を被ると言及することすら嫌になるよ
粘着ができるのも個人的に気に食わないの範囲に留まってるからさ >>231
キチガイ扱いされてでもかまってもらいたいとか、とんだドMだな。
それはむしろキチガイ扱いされていることを喜んでいるという認識でよろしいか? 一つの構造体の中にVecの実態とそのスライスを持たせるような事って出来ないのかな
バイト列を解析して、元データの実態と意味毎に分けたスライスを持たせたいなって思ったんだけど構造体作る時に同時に渡そうとしたら怒られる
とりあえず実態だけ持たせて特定の場所のスライスを返却するメソッドを持たせたけど設計的にこれでいいのかな? >>229
普及した言語disると反論も大きいからねぇ。
かと言って余りにマイナー言語じやあ、disる場さえない。
なので自然に、中間の位置に有る言語に擦り寄ってくる。
昆虫の走光性みたいな知能。 >>234
じゃあ、Goのほうに行ってくれればいいのに。 この言語やっぱ参照をもつのは愚策だな
Lifetimeでインタフェース複雑になるし、ボローチェッカーが無理ゲーになる
この言語用の設計しないと >>233 スライスも参照だからself-referential structになっちゃうからRustで素直には書けんよね。インデックスが今んところベストだと思うよ
その例だとバイト列に直接アクセスしない想定だと思うけど、個人的には解析結果は元データに従属したものと考えた方がスッキリするような気がする
&strに従属するCharIndices<'a>みたいな 言語をdisる意味ってマジでわかんないよな。
素直に自分の好みの言語スレでマンセー言ってるほうが建設的。 >>237
ありがと
やっぱり素直には出来ないよね
>>236 も書いてるけど、rustに適した設計をする必要がある感じだね
元々vm系言語やスクリプトばかりだったけど、rust始めてからスタックやヒープ、メモリコピーの発生とか意識するようになって今後の自分の為にもなってそうだ Announcing Rust 1.22 (and 1.22.1)
https://blog.rust-lang.org/2017/11/22/Rust-1.22.html
try演算子がOptionにも対応したのが目玉か。
マイナーアップデートは mac の High Sierra 用。 1.RustからHTMLレンダリングエンジンを使いたい
HTML&CSS等をレンダリングしてビットマップを得たい
2.HTMLレンダリングエンジンの動作をカスタマイズしたい
不要な機能 JavaScript、ネットワークアクセス、audio or videoタグなど
改変する機能 CSS等にプロパティを追加して任意の動作をさせる、画像等へ任意のフィルタを適用など
候補はBlink、Gecko、Servoあたりを考えていますがRustから使うならやはりServo?
いずれにしろ組み込んだ上でさらにカスタマイズするような資料は見つけられない・・・ >>242
カスタマイズできるラスタライザーが欲しい
日本語が使えて画像を挿入できて線を引いたり出来るもの
入力はHTML以外にPDFやPostScriptなども考えたけどジェネレートや
レンダリング、デバッグを考えるとHTMLがお手軽かなと・・・
今考えているフローはこんな感じ
別ツール→言語(出力結果を制御するメタデータ付き)→ラスタライザー→ビットマップ+α ノベルゲームだったらスクリプトやマルチメディア系のタグを殺す意味が判らない >>243 librsvgでSVGをいじくり回すんじゃダメ?
・Rustバインディング(rsvg-rs)あり
・CSS,XSLT,DOM操作で加工可能 >>246
ありがとう。SVGって文字を扱えるんだっけ・・・って調べてみたら扱えるみたいですね
行けそうな気がしますがGPL/LGPL系のライセンスは使えるライブラリを制限するので避けたいです
C++だけどsvgrenとか?情報少なすぎてちゃんと動くのかすら不明。日本語フォントとか大丈夫なのだろうか
CでラップしてさらにRustでラップするようなのかな Javaも最初の頃はマトモに書いてもコンパイル通らなかったこといくらでもあったもんな。 >>215
本気の荒らしと本気の自演と本気の無自覚アスペはいいのか…?
自分に都合がよいものだけが都合よく残るって都合よく考えるなって言われてるんだろ RustでGUIってイケてる?っていうか、GUIライブラリ多すぎるだろ・・、
GtkとQtメインでやってるけど、JavaFXもいいし、Pythonなんてバインディング沢山あるし、
Rustなんてやりだしたら、もうキリがないよ・・・ もうどれか一つでGUI決めてくれねえかな・・。スゲエ、面倒。 おじいちゃん、GUIはブラウザってきまったでしょ? GUIはElectronみたいな方向に行ったほうがいいのかね Blink を Servo で置き換えた Selectron 来い >>238
バカが調子に乗って新しい言語使って書き散らしたコードをメンテする経験をすればわかるようになるよ。 個人的に検討するGUIフレームワーク
簡単な奴→MS HTAやElectronなど。Webで使われている技術で実装できる
凝った奴→wxWidgets。高機能かつ高速、大抵の物は作れるが罠もある。もしくはAPI直叩き
昔結構悩んだけど結局上記あたりに落ち着いた。当時検討した物
GTK→LGPLウザイ。パフォーマンスが良くない(最近は良くなった?)
Tk→低機能で作れない物がある。パフォーマンスが良くない
Qt→LGPLウザイ。パフォーマンスが良くない
JavaFX→パフォーマンスは悪くないがJREの初期化(≒起動)に時間がかかる
>>256
バカに無計画にコードを書かせているバカが問題なのであって言語が悪いわけではないだろう >>249
良いだろ。というか、それらを止めるのは現実的な方法では不可能。イエスマンを集めて楽しくワイワイ()になるぞ。
記名制のフォーラムでも本気の荒らしや本気のアスペや本気の無自覚は幾らでも居たんだから。 hyperってシングルスレッドなんなね
ベンチマークも結果がバラバラでよう分からん >>258
まあそうなんだが、
言語によって弾けるとする linus の意見には賛同するところはある。 >>256
そういうやつって言語関係なく台無しにしてるんじゃね? >>262
確かに、そういう奴ってどの言語使っても大体はクソコードを書くだろうな。
ただし、ベストプラクティスを教えてくれるやつがいるかどうかで差はあると思う。
新興言語はベストプラクティスを教えてくれる奴が極端に少ないから、余計にひどくなる。
対して、普及している言語は周りにベストプラクティスを教えてくれる人がいれば
バカでもある程度はマシなコードを書く(書くことを強制される)んじゃないかな。 >>262
関係ないんだが
「関係ない」ということを理解せずに無駄に新しい言語推しで
現場嵐してくることが問題。まずはてめーのコードを直せと。 そのバカと言語disに走るID:OgtFvRibは同レベルだよ。 >>265
単語の断片に反応してるだけの思い付き厨だろうな。 >>264
それって人事が無能なだけじゃあ。まぁ日本にそういう会社は多いんだけどな いうほど言語disに走ってる訳ではないけどね。
ただ言語disに走る気持ちは理解できるってこと。
他の言語disパターンとしては単純に自分があんまり知らんから
理解する時間の節約のための dis かな。 rustは組み込み向けの新言語になると思ったけど、全然流行らんな
早くC++から脱したいのに 昔の一部の組み込み系では製品の安定を求めるために
コンパイラのバージョンアップすら信用しない(=古いバージョンを使用し続ける)ことがあったなー 『"(Rustが売りにしてるような部分に関して)良いコード"を書きたいと思っているh人』にとっては素晴らしい言語となる可能性の高い言語がRust
『"良いコード"の定義が違う人』にとっては
『"良いコード"を書きたいと思っているわけではない人』にとっては >>269
目的より手段を優先する日本じゃ無理だろw
どうしてもやりたいなら自分で立ち上がるしかないんじゃないか >>273
rustが使いたいからその仕事を立ち上げるって明らかに手段と目的が入れ替わってますよね >>272
世界中のプログラマ
モジラのクソ提灯で言語未満の自称言語がひとつ減る訳だから >>276
執着というより単に語彙力がないだけかと。
コイツいつも大体同じようなことしか言ってないよ。 >>263
ガウディ本とかで計算モデルを理解してれば、慣れてるという理由で合わない用途に無理矢理押し込もうとしないんだろうけどね。 少なくともswiftに採用しようとしてる機能を先行実装しているだけでも価値ある Rustが成功したから真似されたんじゃw
Apple信者さすがの言い草 Swift の仕様変更と比べると、Rust のアップデートはかなり大人しいよな。 >>282
Rustのメモリ管理の仕組みが破綻してないことを証明しただろ!
しかも実務にも耐えてる
これが成功でないわけがない >>284
循環グラフとか動的計画法とか書けない言語のどこが破綻がないのかいってみろ工作員 簡単にwasmコンパイルできる環境が整ってきたな
https://twitter.com/badboy_/status/934742946754244613
今、試したけど、Windowsでも動いた。
cargo-wa は動かんかったけど。 このエラーメッセージ、表示されるときと(当該箇所の修正をしていないのに)も関わらず表示されないときがある
Why?
error[E0605]: non-primitive cast: `{integer}` as `f64`
= note: an `as` expression can only be used to convert between primitive typ
es. Consider using the `From` trait
このエラーメッセージが表示されるのは
このエラーメッセージの示す箇所と全然無縁な箇所でコンパイルエラーが出たときに同時に表示される
そしてその他所であるコンパイルエラーを解消するとこのエラーメッセージも同時に消える >>270
実際、g++ なんかはバージョン違うと相当挙動違うけどね。 >>289 エラー時には情報足りなくてusize等に推論してるから、かなあ
構文チェック -> 型推論&チェック -> ボローチェッカーって順番でエラー出してる感じだけど、
関係無い場所でのエラーのせいでas f64してるローカル変数の型推論が不十分な可能性がある
型推論は重い処理だから何らかの最適化のせいでエラー時の挙動が分からないのではないか Rustでイミュータブルに拘る人は何なの?ミュータブル使えよ ミュータブルにする必要のない箇所をイミュータブルにする
基本はミュータブルで使え、ミュータブルしてなかったらコンパイラが教えてくれる、そのときイミュータブルに変更すればいい Rustでイミュータブルに拘るのは、TypeScriptで型付けることに拘るようなもん 最近勉強し始めたんだけど、デフォでイミュータブルなのに思いのほかmutキーワード使う局面が多くて面食らってる。 イミュータブルに拘ると、Scalaとかでもそうだが、コピーだらけになる
コピーを恐れてるとイミュータブルを徹底できないよ あ、そういうこと。むりやりイミュータブルにする人たちがいるのか 静的型付け初めてなんだけどいきなりRustは敷居高いだろうか >>300
> イミュータブルに拘ると、コピーだらけになる
> コピーを恐れてるとイミュータブルを徹底できない
例出してみ イミュータブルとかメモリを富豪的に使うだけで性能はなんら上がらない、いかにもお偉いさんが机の上だけで考えたクソ手法だろ
なんでFortranやCが現役なのか考えたこともないやつがイミュータブルをもてはやす それは言い過ぎだろ
なんでもイミュータブルにするべきとは思ってないが、
並列性が必要なプログラムではイミュータブルは重要視しているよ
並列性が性能に直結しない(難しい)のは残念な話だけど…… >>306
値変えないならコピーするしかないだろ。それが富豪的でなくてなんなんだ?
>>307
並列計算で必要なのはイミュータビリティじゃなくて、変数スコープ分離と外部依存性の無いアルゴリズムだ
大方MPIすら使ったことないんだろうが、
共有リソースにアクセスしなきゃいけない並列プログラム組んでる時点で
設計が破綻してるとみなせると思うがそこんとこどう考える? このバカ、コンパイラが良きに計らうってことを知らんのか? >>292
thx
なるほど、コンパイル途中でエラーすると一部の推論に失敗してしまうのか const に異常にこだわるくせに異常に長い関数書く馬鹿は見たことあるな。
その前に関数切り出せと。
たぶん Rust が一般に広まるとボローイングルールをまともに理解できなくて
コンパイルできないから関数に切り出さないバカが増えると思われる。 イミュータブルにすることでコンパイラによる最適化の余地が増えるんでないの?
ミュータブル派とイミュータブル派の宗教戦争勃発なの? コンパイラが善きに計らうって、
つまりconstついてた(mut非指定の)変数がレジスタ割り当ての結果変更され得る最適化が起こるってことか?
さすかにそんな最適化は聞いたこと無いがソースあるのか?
即値展開ならわからんでもないが、それと並列は関係ないし アマゾンでオライリーのProgramming Rust出てるのな
アーリー版じゃ無い完全版かな?
どうでも良いけど蟹座の俺が心惹かれる表紙 >>308
「使ったことない」って人を判断したがるのは使ったことを自慢したいから?
ある数学上の問題を高速に解くために 2000年ぐらいにMPI を数ヶ月触ったことある程度で
以降は関わってないけど、それはなんか関係あるのか?
設計が破綻しているかどうかは問題によるだろ
どんなに考えても共有リソースにアクセスしなきゃいけない並列プログラムなんて山ほどある
共有リソースへのアクセス削減なんてみんな取り組んでる
そのための一ツールとしてイミュータビリティは重要な概念だろJK
> 並列計算で必要なのはイミュータビリティじゃなくて、変数スコープ分離と外部依存性の無いアルゴリズムだ
「重要視」と言ってるのに「必要」と解釈するのか……
変数スコープ分離という用語は知らん >>314
kindle版の話か
紙版を注文しちゃってるんだが ガーガー言うほど文句が出るもんでも、全力擁護すべきもんでもないと思うがね>デフォルトでimmutable
Haskellほどやり方が変わるわけでもない、C/C++のconstより明快、letとvarで分けるほど使い心地が違うものにはならない、
https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/box-syntax-and-patterns.html
↑にあるようなBoxを使って大きい構造体を関数に渡すのはRustじゃ悪手ってとこだけ知ってればいい >>315
MPIは不変性は並列化に必ずしも必要じゃないって話の例に出しただけだから、
さわった上で不変性が必要って主張するならまあそうなんだろう
データを不変にして触るノードの分だけコピーすりゃそりゃデータ競合は起きないだろうが、
その分ノードへの転送量だってかかるし、メモリも食う
だから富豪的で、額面上の並列度は上がっても性能には寄与しないと言ってる
俺が知らないだけでもっと良い最適化が不変変数にかかるなら完全に俺が無知晒したでめでたしなんだが 業務のDBとかででっかいBeanやテーブルさわってるとImmutableこだわると死ぬ気がする
ライブラリレベルだとImmutableすごいよさそうなんだが immutableがいいのはソースの可読性が高まるのと、マルチスレッド化したときにリソースアクセスに問題ないのが保証できることでしょう。バグらなない自信があるなら効率を求めてmutableにするがよろし。 mut にするのもそこまで困難な言語設定ってわけでもないし、
デフォルトが immutable でもいいんじゃねとは思う。
まあ大規模に作ったことはないからその際の困難はわからんけど、そこまで問題にならんのでは? mutにするのをめんどくさくするというのが
let mut構文を採用した理由なので
varはよっぽど何かない限り入らないと思う Haskellのイミュータブルは永続データ構造?参照の使いまわし?
Rustのイミュータブルは?コピーしないと使いまわせない? wasmに出力するのって、依存ライブラリも全部pure Rustじゃないとダメなの? 1.22でOptionにも?使えるようになって、haskellのMaybeモナドっぽく使えて捗るわ
ブロック内だけでも使えたら良いんだけど仕組み的に無理そうか try catchみたいな構文検討されていたような Rustを叩いている奴ってミラーレスカメラを叩いている一眼レフカメラ信奉者と同類に見える
大抵の場合は合理的な方が最終的に選択されるけどな mutable変数扱うなバーカ、というメッセージだと思ってる
必要なら再宣言させるようにして人為バグを減らそうという魂胆は分かるぞ(Javaのfinal教徒感 BufReaderとかReadするStringとかにもmut必要何だからmut禁止とか無理じゃね?
不要なmutだったらワーニング出るでし、必要だったらコンパイルエラーになるでしょ
必要な形で使えば良いだけなのに一体何を議論してるんだ?
ミュータブルが気に入らないならhaskellおすすめ Readした結果はmutableでいいのにlet mutと書かなければならんの面倒
人によってはletで再宣言するのかな 例えばさ
mutな変数1つ宣言してそこに足し上げていくのと、
非mutな計算結果同士を足して新しい非mutな計算結果を作るのと
素朴に考えれば前者の方が省リソースだよな
別にその程度コンパイラの最適化やレジスタ割り当てでどうとでもなるだろうとも思うが https://qiita.com/koji_mats/items/62e85a87cc580e225796
これ見たんだけど、なんでwinがlet mut winじゃないんだろうって不思議に思った。
let win = gtk::ApplicationWindow::new(&app);
win.set_title("Vanilla Text");
で、コードを調べてみたら、こんな感じにFFIを呼んでるだけだから、
概念的にはオブジェクトを変更してるけどRust的にはmutが要らないという仕組みらしい。
ちょっと違和感無い?
fn set_title(&self, title: &str) {
unsafe {
ffi::gtk_window_set_title(self.to_glib_none().0, title.to_glib_none().0);
}
} ポインタの先がどう変更されようが、ポインタを持ってるだけの側は不変。 Rust的な設計の指針というかコツみたいのって無いですかね…
勉強のつもりで外部のCのライブラリとの間に入るちっちゃなFFIのラッパーを書いてみたんですが、Cの感覚で書く->コンパイラに怒られてあーなるほど修正ってのを繰り返してとりあえずは動くようになったんだけど
何をするにも
let foo = xxx ;
{
let bar = foo.xxx() ;
bar.yyy() ;
}
{
let baz = foo.zzz() ;
baz.www() ;
}
{
let bar = foo.xxx() ;
bar.yyy() ;
}
みたいに書かないといけなくて書いた本人でも「何やねんこのウンコ!」ってなってる(´・ω・`)
(Rustがって意味じゃなくて自分の書いたものがって意味で) どんなエラー出してそんな醜いコード書いてるのかを説明してくれないと。 >>338
RustがRustで書かれてるのだからRustのリポジトリのコードを読んで参考にすれば勉強になるのでは?
https://github.com/rust-lang/rust/search?l=rust >>338
cと触れる部分はしょうがないんじゃないの?
その何回も触ってる部分をcで書いてインターフェイスを最小化した後で
rust から呼び出す方が正解なんじゃないかね。 Rustに限らず他言語で書かれたライブラリを利用するときは呼び出し元言語の作法に適合するように改修しないと使いにくいことが多いような >>338
> Rust的な設計の指針というかコツみたいのって無いですかね…
私も知りたいです! >>338 見た感じFoo::xxx : &mut Self -> BarとかFoo::zzz: &mut Self -> bazとなっているのでbarやbazが生きてるとfooにアクセスできないのが直近の原因だと思うけど、
xxxやzzzが本当にFooの変更を伴わないといけないのかを考えないといけない
CellやRefCellを使ってinterior mutabilityを導入したらFoo::xxx: &Self -> Barというメソッドにできる可能性がある
まあ実際のソースがどんなもんなのか知らないから適当だけど >>345
公式Twitterアカウントをフォローしてみれば、リツイートに含まれるアニメ画像の多さで分かるだろ そもそもエンジニアの時点でPCオタみたいなもんだろ 標準ライブラリAPIリファレンス見てるけど難しいなぁ。 map: HashMap<String, usize>をメンバーに持つ構造体Fooを作りHashMap::getをラップするメソッドを定義したいんだけど、
型表記をどう書けばStringとstrの両方を受け取れるようになれるの? panic!で終わらすのでなくErr()を返してエラー時の挙動は呼び出し側に任せる・・・? get で使うなら AsRef じゃなくて Borrow Mercurialも、Python/CからRust/Pythonに切り替えるのか
> Python is also hindering us because it is a dynamic programming language. >>358
ソースどこだよデマ乙
歴史あるVCSがRustみたいなゴミつかうわけねえだろ https://www.reddit.com/r/programming/comments/7hesom/mercurial_oxidation_plan/
・hg本体がpythonなんで起動時のラグが気になる、特にスクリプトからhg呼び出す場合に重いからネイティブにしたい
・python2.7のGILのおかげで高速化のための並列化が面倒
・メモリ安全と並列化をCや古めのC++でやるのはキツい
何故まずpython3に移行しないのかは分からんかった。Rustで書き直すより先にやった方がいいんじゃないかと > For Mercurial, Rust is all around a better C.
> It is much safer, about the same speed, and has a usable standard library and modules system for easily pulling in 3rd party code.
>>359みたいな基地外君発狂しそう。 ソースはRedditwwwwwwwww
ソースは2chよりひでえwwwwwwwwwwww 一次情報はmercurial oxideなんだけどこれが公式mercurialとどんな関係があるかがRedditのスレで言及されてるんだが
モジカス連呼基地外君は発狂中だとurlしか読めないのね >>360
mercurialにpythonで書かれた拡張機能がいっぱいあるからだろうかね 言語が錆でプロダクト名が水銀だから、プロジェクト名が酸化ってのもうまいことつけたな
Python3化を優先しないのは、斜め読みした感じだと「hgコマンドをPythonスクリプトから(必要に応じてPythonインタプリタを埋め込んだ)バイナリにしたい」ってあったから、順番的には確かにそっちは後だな あとは、GILの性能自体はPython3で向上したとはいえ、GILそのものがなくなった訳ではないから、
それで得られる速度向上は並列化と比べてたいしたことないってのもあるんじゃね?
あとPython3はそもそも単純なベンチでは2より遅かった気がする なるほどね。
個人的にはgitよりmercurialに頑張ってほしい VCSは自身の機能や性能も大事だけどそれを使った開発プロセスの整備と提示が大切なんだなあとgithub見て思う
pijulにはちょっと期待してる 公式がマジで言ってんのかこれ。多分gitに負け続けて資金調達のためにモジラに泣きついた感じか。そこまで落ちぶれてたんか
けどまあwikiの他のNewFeature見てみた限り放置も多いみたいだし、これもそのまま忘れ去られる系だな Rustで大きなプログラムは書けない
→Firefoxにしか使われない
→Mozilla以外はまともなプロダクトでは使われない
→負け組プロジェクトしか使われない
進化を楽しみにしてるぞ コンパイル通せない事がそこまで彼のプライドを傷つけるとは……
コンパイルエラーが発生したときに、自動で「大変申し訳ありませんが、」の文字列を追加表示する
コンパイラプラグインを誰か開発すべき Rustつかって書き直すなんて、言うだけはタダだし、言ったことでモジラから金がもらえるなら言うだろうね、落ち目のプロジェクトなら
個人的にはgitより好みだったけどな
そもそも言語変えて書き直すとか非現実的なことできると思ってんのお前ら
チャットワークは記憶に新しいぞ それを解決できるのはスレッドの類をGC対象にできる言語のみだろう
Ponyはできたような気がする ponyってあれか。スポンサー企業が一抜けしたやつか これからやるのにGUIでいいプログラム言語教えてください。Microsoftは無しで。 >>385
おじいちゃん、GUIはブラウザってきまったでしょ? 実際マジで綺麗なGUI作ろうと思ったらブラウザ使った方が良かったりするからなあ
wasm/WebGLのみターゲットにしたGUIツールキットcrateを作る人も出てくるんじゃないかね 簡易なもんつくるなら react をてきとうにいじるのが一番覚えること少ない気がする。 しばらくreact+reduxやってから久しぶりにC#に触ったらやっぱり.NET楽だと思ったわ。
Webアプリ前提ならReact一択でいいけど、スタンドアロンでいいならわざわざ選ばんなぁ。 .NET は何がどう依存してるかわかりずらくてデプロイするのが面倒じゃん。 Rustは何がどう依存してるかわかりずらくてプログラミングするのが不可能じゃん。 >>394
> ずらく
お前はまず日本語を学ぼうな。 日本語マニュアルなんてあるんだな。
相当本気なんだなRust。
Swiftなんて公式は未だに英語だけだぞ。 そういえばPEZYが自分とこのcpuでrust動かしてたな。 Cの代替として使ってるみたいだけど、mutとかunsafeとかめんどくさすぎて話しにならないな やっぱRustは詐欺だな。詐欺会社同士モジラとは馬が合うんだろうな
普通の感覚持ってたら>>405と同じように使い物にならないって感想持てるよなあ RustはSmallTalkと並び称されるべき言語
Rustは死んでも血脈は残り続けるだろう >>405
主要部分丸々Unsafeにした挙句
インラインアセンブラを書いてやればいいですとか
なんでもなさそうに書いてあってわろw プログラミングに限らず安全はタダで得られるはずがないのだが理解出来ない日本人は多い >>406
なぜRustの苦手分野で語ろうとするのか?
これはJava等の高級言語では絶対に出来ないこともRustなら不格好にはなるものの
可能だということを示しているのであってRustで書いた全てのコードがこうなるわけではない。
低級なことをするときはこういう書き方が必要になるというだけだ。
Rustのいいところは低級なところをすべてunsafeでラップすることで、
それより上位層のコードに低級な部分を持ち込まなくて済むようになることだ。
そして、Rustの最大の特徴は高度な型システムとゼロコスト抽象化等の機能であり、
C++, Java以上の賢い抽象化の仕組みを実現しつつC++並みの実行速度で実現できる点である。
unsafeに関しては、あくまでC++の後継を狙っているので低級なコードを書く手段も用意しているというだけに過ぎない。
CやC++にRust程の抽象化や型安全、メモリ安全を保証する機能はあるだろうか?
「そうまでして安全性や抽象化を追求する必要があるのか?」と問われればそれは作るシステムや個人の趣向にもよるだろう。
欲しいと思う人もいるし、それはやりすぎだと思う人もいる。
Rustが苦手としている部分をとりあげて「ほらダメじゃん」とか言われても、
「Rustの得意なところじゃないんだから当たり前じゃん」としか言えない。
要約して一言で言うならば「論点がずれている」。
以上だ。何か反論はあるか?
長文失礼した。 ようわからん
unsafeでくるまれたところでデータ変な風にいじくられたら
結局上までおかしくなるんじゃないの? >>412
要件に合わせて方式選択できて、必要であればその範囲を狭めることができるのがメリットでは? >>411
詐欺師の長文は読むつもりもない
以上だ 404みたいに新しいCPUに移植して特殊な命令使うような話なら
C言語でもインラインアセンブラ使ったりするしかなかろう >>412
別に上でおかしくならないことを保証してくれるとかではないよ。
単にメモリ保護違反とかが起こるなら必ずunsafe内で起こるってだけ。
それでもプログラム全域のどこで起こるか分からないCとかよりはましだろうってことかと。 >>411
rustのセールストークを真に受けちゃった人にしか見えない。 >ゼロコスト抽象化
実際にはzero-costじゃなくてzero-overheadだよなrustって。
わかりづらいけど正当なコストはちゃんと払ってるし。
ところで、javaのクソ翻訳にauto boxing and unboxingを「ボックス化」と訳す
トンデモ訳が蔓延してるんだけど、リージョンでメモリ管理するrustだと
正真正銘のboxed valueがあって、この訳が「ボックス化」だから逆に紛らわしい。 Javaの方が先にあるのに後発が正真正銘だとかどういう了見だよ >>416
Haskellマスターtanakhが逮捕されたと誤解を招く書き方辞めろ 宣伝文句としてはbetter C++だけど、実際の使用例はbetter Cが多い 既成ライブラリの中でメモリ保護例外を吐いた経験がある人ならRustのありがたみが判るはず
マルチスレッドアプリケーションでトレースバックが参考にならないような状態だともう泥縄 そんなコードが散乱してる現場でrustのボローイングに関して
まともに対応できるとは思えんが。 よしんばあったとして、Rustに頼るのは間違ってるだろ
不運続きの人間がカルトにはまるようなもんだ >>428
まあRustなんて有り難がってる時点でなあ >>429
いやそうじゃなくて、あんたみたいに知ったかぶってるやつが多い
そうじゃないのもいるけど しったかぶってるか?
C(++)の後継うたってる割に、動くCコードの移植がチェッカーに阻まれて不可能
グラフのような自己再帰構造が書けない
そもそも開発元が悪名高いモジラで、言語機能の改善がまったくなされないのに何故か使ってると称する会社だけが謎のペースで増える(恐らく金が動いてる)
例のスパコン詐欺会社で運用されていたらしいという負の実績
事実並べただけでRustがいかにクソか分かるだろ
金が動いてる部分だけはソースないが他は全部ソースつきだ みんなランタイムエラーの方がコンパイルエラーより好きなわけ?? んなこたないけどコンパイルエラー出なきゃいいっていう馬鹿が増えそうなのが心配。 >>431
そのまま移植しようとしたらそりゃ難しいに決まってんだろ しかもあのスパコン会社技術力は確かに高いし
社長がうんこだっただけで これ見る限り、素直に c で書いた方が圧倒的に楽だろ。。
完全に話題集めのためだね。
ttp://tanakh.jp/posts/2016-12-20-rust-pezy-sc.html まあ、アホほどいっぱい書き込むからそう見えるだけなんだけども。、 [][][] [][][] [] [][][][] [][] [][][][][] [][] [][] [] [][][][][]
[] [][][][ [][][][][] [][ [][] [] [][][] [] [][][] []
[][][][] [] [] [][][][][][ [] [][][] [][] [][] [] >>437
dgemmみたいな行列演算をチューニングするとどうしてもああいうコードになるんだよ。
てか多分 c で書いたのを話題のために無理やりrustに書き換えたんだろうね。。
unsafeで囲むとかもうrustで書く意味ないだろそれ。。 pezyの例には当てはまらないけど、Cに分けたモジュールリンクするぐらいなら、
unsafe丸囲みの方がビルドが単純になって意味がある。 この手のキチガイは荒らすことが目的だからワッチョイを付けてもいなくならないよ unsafeで囲む意味が無いとかマジで言ってんの?
ここはunsafeだよって一目で分かる利点を理解していない? ワッチョイもunsafeも同じように有用ってことだね ボローチェッカじゃなくてモジラに親を殺されたんだな、かわいそうに
悪名高きとか言われても知らんがな。悪い話もいい話も聞かんが 元々なんでか知らんがMozillaが嫌いだったところに、
コンパイル通すまでがちょっと難しい言語をリリースして、なんか世界的にそこそこバズって
それを自分で使えなかったことで、正気を保てる限界を越えた感じかね
突撃荒らしのバイタリティが妙に高いのも納得できる >>445
例のブログみたいに、全部を囲ったらチェッカーの意味ないじゃんって話では
言語機能としてのunsafeの有用性は分かる
確かに全体をunsafeで囲うなら現状はまだCで書いた方がいいと思う
Rustからだけ使うなら難しい線だが unsafeブロック内のRustコンパイラによるチェックはCコンパイラに劣るということ? 自前のstructのnewメソッドで外部crateのAWSクライアントを作って持たせて、インスタンスメソッドの中でそのクライアントを使いたいんだけど、
そのクライアントがgenerics使ってて実際に返ってくる型が分からない時にstructに持たせる方法ってないのかな
例えばこんな感じの。
[crate]
struct<A:Trait1, B:Trait2> Client<A, B>
[My code]
struct Hoge {
client: Client<?, ?>
}
ソース見たら更に別のバージョンが古めのcrateのモジュールがそこに入ってたりしてて、そうすると同じバージョンの依存crateをこっちでもexternして、それを自分のstructに書いたりしないといけないのかな? 自分でラッパー的なトレイト作って該当の外部structに実装してbox化したら持てそうか
やってみる >>453
>>455
自前トレイトでトレイトオブジェクトにしたら出来た!
トレイトの使い方はまだ慣れてないな [][] [] [][][][] [][] [] [][][][][
[ ][] [ Rust界隈では、RustでLisp処理系を作って初めてRust初心者と認められるからな Rust入門書
Rust初心者 RustでLisp処理系を作れる
Rust中級者
Rust上級者 c++はまってたやつがlisp権威にボコられてrustに走るというわかりやすいストーリー Lisp処理系を作るってLisp以外の言語で作るのRustに限らず普通に難しくね?
Lisp用のパーサとか適当なライブラリ拾ってきて作るってんなら話は別だけど なんせ初心者LTって名目のLT会で、
Lisp処理系書いただの、ベアメタル開発してみただのってお題が平気で出てくるからな
まあ初心者でもこれくらい出来て当然っていう選民思想のなせる技だろう
うっかりLT出てしまった同僚があまりの初心者バイバイ加減に途中抜けしてしまったらしく俺に謝ってきたわ
お前の言う通りRustまわりは録な世界じゃなかったってな 勉強会あるあるだよな
間口を狭める行為だ。
まあ勉強会行くやつなんて勉強するきないわけだから、そうなるわ でも残念ながらrustやりたがる連中の動機のほとんどはそういうマウント飢餓に
よるもんだからしゃーない。 rustはとっつきにくいけどc++(をちゃんと使う)に比べたら簡単だよ
c++初心者のほうがひどい(すごい) C++は会社や学校にやらされてる人が多いから、初心者はちゃんと初心者だろ
勉強会になんか不毛な空気を感じるのは分かる なんでついて行けなかったらマウントなの?
逆マウントじゃねえの? ID:14mdma0k からは例によって非生産的な被害者妄想を感じるな rustの話だぞ?界隈に録な人間がいないのは
言語の元締めが個人情報売りさばきのくせに上から目線だけは世界一のクソ企業モジラだから類友なんだろう
絶対に使ってはいけない言語。まあ実用性もないから使えんけどな rustってc++よりも簡単なのか?
個人的にはc言語経験者であればc++のほうがとっつきやすい気がする CやっててもC++はコード読むのに必要な知識がどんどん増えてくからずっと追いかけてないといけないのがしんどい
追加される仕様は使わなければ問題ないんだけど、コード読む側の負担は考慮してくれない
で、覚えるべき内容もクセのあるテンプレート、言語毎に微妙な差異があるオブジェクト指向、演算子定義等々、厄介なものが多い
複雑なことをしようとしたら複雑なコードになるのが普通のCとは随分違う感じがするよ
個人的には良いCを書けることと良いC++を書けることの関連は薄いと思う 彼はもじらに個人情報を売りさばかれて親を殺された可能性が微レ存 >>483
5chでグダってる時点で、脳内ストーリー確定。 >>484
現実でもちゃんと反Rust反モジラしてるわカス
Rust言語に肯定的に言及してるやつとは関わるなって同僚には言ってる
一度怖いもの見たさでLT行ったやつはあまりの選民思想具合に途中で逃げたと謝ってきた 言語自体に対する批判も「C/C++で動いてたオレのプログラムがRustだとコンパイルも通らん!」しか言えないキチガイ君
もっと具体的な話をしろと言われても何も言えずにモジカス連呼、周囲に必死にネガキャン
そろそろ親を殺されたモジラに会社で孤立もやられるんちゃうか?モジラのせいで会社クビになったり、再就職もモジラが邪魔してくるんじゃないか?
すげえ集団だなモジラって。ブラウザ作って新言語作るだけで1人の人生滅茶苦茶にできるんだもの
全盛期のマイクロソフトやIBMでも中々できなかったぞ >>485
でその活動ってのが5chでグダるになる理由は? >>488
うっかりここでRustに興味を持つやつを逃がすため
特にこのスレはモジラから金もらったのか知らんが妙に持ち上げるやつが多いからな \ /
\ 丶 i. | / ./ /
\ ヽ i. .| / / /
\ ヽ i | / / /
\
-‐
ー
__ モ ジ ラ か ら 金 も ら っ た の か --
二 / ̄\ = 二
 ̄. | ^q^ |  ̄
-‐ \_/ ‐-
/
/ ヽ \
/ 丶 \
/ / / | i, 丶 \
/ / / | i, 丶 \ >>487
×ブラウザ作って言語作るだけ
○世界中の個人情報売り買いして大もうけして工作員送り込んでる
ブラウザも言語もマネロンでしかないわ ブラウザマネロンだけじゃなくて個人情報収集手段だな >>493
ブラウザが集めるメタ情報を個人情報と呼ぶならGoogleが一番の悪だな。
Firefoxなんて足元にも及ばない。
Go言語でもdisりに行けばどうだ? 発想がトンデモ過ぎてワロタ
ブラウザマネロンってブラウザを開発することでマネーロンダリングする手法ってこと?
どうやってロンダリングするんだろ >>494
出た、Googleをスケープゴートにする工作員!
今やクロームなんかより火狐の方が個人情報収集はひどいぞ
なんせ画面のスクショとその上のマウスの軌跡まで送信してるってプライバシーポリシーに明記してるからな >>497
プライバシーポリシーなんていちいち全部読むかよ。
何処に書いてあるかソース元(URL)を載せろ。話はそれからだ。
あと、そんなこと言えるってことはChromeとEdgeとSafariの
プライバシーポリシーももちろん全部読んだんだよな。
Firefoxは読んだけどそっちは読んでないから知らないじゃ話にならないからな。 rustのターゲット層ってぶちゃけc++erだと思うんだけど、
その割にはc++erの間では話題になっていない印象 仕事でC++使ってるとこは開発SDKも含めてC++だしこれまでのノウハウや社内資産あるから困ってないというか
待ってればC++にも新機能入ってくるし C++コーディングはストレスで禿げる
禿げずにC++並みのパフォーマンスを獲られないかという人類の宿願がRust c++は安全に書くのが難しい
rustは速くするのが難しい 何か思い付きで毛無したいが為にに、色々と時系列や整合性矛盾にも気付かないのが居るな。
惜しむらくは、ネタが古過ぎで手抜き過ぎ。 >>505
毛無したい...
なんか卑猥な響きだな。 http://blog.goo.ne.jp/narmuqym/e/5793e3c0dc1680a017e64f72b0fb6856
これがRustを使っているなどと吹聴していた詐欺会社の実態
Rustを使っているなどと大ボラを吹いている他の会社も似たようなもんだろう >>507
> 「STAP細胞仮説は自然過程であり正しい。STAP否定論者は荒唐無稽な進化論否定論者だ」
ワロタ もう叩くのに理屈もへったくれもないな
具体的に何がわるいのかさっぱり >>507
これTwitterで話題になってる糖質のブログやんけ とにかくmozillaに関する物事は全部否定するのが第一で理屈も手段も二の次か
敵意の向け方に糖質に近いふいんき(変換できない)を感じる 最近の荒らしの間では毛の話が流行ってんのか?
てかこいつ脈絡もなくlispの話しだすし@nobkzじゃね? >>507
これRustを批判するために張ったリンクなんだよね(;・∀・)
リンク先にRustの文字が1つもないんだけど。(; ̄Д ̄)?
今軽く調べてみたんだけど、
ここの会社がRustを使ってるって明言しているような情報は見当たらないんだよね。
(見つけられなかっただけかもしれないが。)
Rustを開発に使用してるって情報のソースが無いと説得力が皆無なんだけど。
pezyのコアでRustが動くって情報なら見つかったんだけど、
ただ、Rustが動くのはllvmベースだからとも書いてある。
Rustだけ特別扱いされてる訳でもないようだ。
この流れでRustを批判したいのなら、同時にllvmベースの言語も全部批判対象になるんじゃないのか?
llvmベースって言うと現在代表的なのはC, C++, Swift, Rustくらいかな。
将来的に対応予定(すでに対応済み?)も含めるとGo, D, C#, (うろ覚えだがJavaも)入るはず。
主要なコンパイラ付きの言語のほとんどを敵にまわした気がする。 >>471
プレゼン初心者向けのイベントだったんでしょ。 >>516
横からだが、スレ遡ったら中の人がRustでこの上で動くコード書いてるブログのリンクがあるぞ 中の人って、自称イスラエルハイテクベンチャーCEOとtanakhは何も関係無いだろう Pezyはtanakahを雇っている
tanakhはRust信者
Pezyは詐欺会社よってRustは詐欺!
ってこと?自殺しないの? >>516
まあ元々、Rust批判したいが為にRustに関わりの有りそうなところの批判を持ってくるという、時系列とか因果関係無視したロジックだからねえ・・・
マトモな技術者なら、他言語や他の計算モデルとの比較で批判や改善提案するんだろうけど。 ああ、イスラエルハイテクベンチャーというが詐欺という意味じゃなくて
そいつの言うとおりにPezyのスパコンの性能が嘘だと言ってたのか
納入先もグルじゃないとまず無理なのに ハードウェアで思い出したがfirefox osが生きていたら
rustでアプリ開発みたいな未来もあったんだろうか イスラエルハイテク芸人の記事真に受けてる奴いるの? >>525
社長が詐欺で逮捕された会社の社員よりは信用できる コテ付けるかアンチスレ池。次からこのスレワッチョイありでいい?NGしたいんだけど とりあえずワッチョイありの建てたわ
このスピードじゃ次スレまでまだまだ掛かりそうだし あ、ちなみにワッチョイあり/なしの分裂は運営が認めてる(乱立扱いされない)ので vの数間違えたから一回建てなおした
1514107621使ってくれ ワッチョイ付けて荒らしがワッチョイコロコロしなかった事例なんて見たこと無いんだが なんだっていいわ。言語の話ができれば。
https://blog.rust-lang.org/2017/12/21/rust-in-2017.html
2017の総括が来てるぞ
個人的にはまだLibz Blitzが不十分なのと開発の敷居が下がってないなとは思うが、
チーム的にはおおむね達成されたって認識なのかね? Rust Christmas I gave you my heart >>523
firefox os載ってるパナソニックのテレビが
最近投げ売りを見るようになってきたから試せるぜ。 rustでググるとゲームのrustのほうが出てきた気がしてたがプログラミング言語のrustのほうが出てくるようになった 結局RustはKotlinとかSwiftと比べて何が良いのか
純粋に言語として
ライフタイムとかはコストに見合ってるのか >>539
汎用性ならKotlin
Rustは特化型 そもそも「安全で高速に低レベルな事をする言語」だからね enumがtagged unionだから分岐と構造化束縛時の
スタック操作ばっかになって素直に書くと遅い。
cursesで描画してもそこそこ遅い。
cならuntagged unionだから想定してないメンバに
アクセスしたら落とせばいいからここまで遅くならないよ。
安全な抽象化にそれなりのコストかかってる。 その速度比較に使ったRustとC++のそれぞれのソースコードplz untagged unionで想定してないメンバにアクセスしたときに落とすためにはtag必要では Cのenumを使いたいならbitflagsでやる方が良いかなと今のところ思ってる 今日日パソコンはとても高速なわけだが
Rustでcurses使うと気になるほど遅くなるのか? >>542
>cならuntagged unionだから想定してないメンバに
>アクセスしたら落とせばいいからここまで遅くならないよ。
きちんと落ちるのなら苦労はしてない。
落ちないでスタックぶっ壊しながら突き進むから苦労してるんだろ。
スタック壊されるデメリットに比べればtagged unionのコストなんて安いもの。 そもそもrust stableにもunionは入ってるんでお好きに使うがいいやってのと、
「想定してないメンバにアクセスしたら」ってどう判断すんのって疑問が残る
タグに相当するものを自作してもいいけど、そこまで気にする程のオーバーヘッドを感じたことが無い 数百万回まわしてナノ秒単位で測るマイクロベンチマークならともかく、cursesで違いが分かるとか、ありえんわ 今時のマシンでcurses使うと遅いっていう人間、明らかにニュータイプでは?
もしRustで標準入出力が目に見えて遅いって話なら、
単純に標準入出力のロックに無頓着ってだけのオチだと思う @HiraokaTakuya
Rust で C++ の non type template arguments使いたい時は、適当に中身無しの struct 作るしかないんかな〜(´・_・`)
午後1:18 · 2017年12月29日
他人のツイートなんだけど僕も気になるから教えて(´・_・`) C++ の template<int N> か。
これが使えれば、
impl<T> Hoge for [T; 0]
impl<T> Hoge for [T; 1]
impl<T> Hoge for [T; 2]
...
みたいなのを
impl<T, N: usize> Hoge for [T; N] でまとめられるよね(と良いな) rustのジェネレータってasync function用のコンテキストスイッチしないまがい物か。
ジェネレータだけだと所有権奪ってキャプチャした値返すしか出来ないから
Cloneしないstd::iter::repeatくらいにしか使い道ないな。
ウォームアップしてないjsの倍程度の速度しか出ないけど
resume関数は最適化で綺麗になくなるみたい。 ほぼtraitしか無い状態なのにそんな評価できるの? ターゲットごとに調整が必要だから後回しにされてんのか? コンパイラの最適化の改善くらいかな。
「メモリ使用量を平均で5〜10%くらい削減することに成功した」だそうだ。 この言語ってC++より遅くてJavaより速い感じ? 間違ってはいない。
けどc++とは僅差なのでこんな感じかな。
C++ < Rust <<< Java
テキトーに書いたので異論は認める。 全く同じアルゴリズムならC++のほうが速いはず。
C++のコンパイラはもう成熟してるけど、Rustのコンパイラはまだまだ改善中だから
将来的にはほとんど同じくらいになるんじゃない?
まぁなんにせよ、結局はアルゴリズム次第。 Rustに限った話ではないが世の中のアルゴリズムの大半はC/C++前提に作られているのだから
C/C++の方が速いのは当たり前。新世代で速くしたければそれにあったアルゴリズムが必要 「C++がJavaより早い」というのは「大抵は」が抜けているか、「原理的には」が抜けている
C++でVMとJITは作成しないなど、
いくつかの条件が整うと C++ より Java が早いというケースも存在する
無制限にコストをかけれるという前提なら Java より C++ のほうが早い
https://softwareengineering.stackexchange.com/questions/110634/why-would-it-ever-be-possible-for-java-to-be-faster-than-c CとC++の速度比 ≒ C++とRustの速度比
みたいな感じ? >>574
単純なCだけ頭一つ抜けてて、C++とRustはvtableやsmart pointer由来の遅さを抱えた同じグループ 腕振り回すのが早いからって、仕事も早いと思い込んでるのが未だに居るな。 >>575
検証結果plz
最適化コンパイラがない時代ならともかく今時のコンパイラで有意な差が出るとは思えない vtblと比較するならCの関数テーブルだろう
C++のスマポも必要なとこしか使わないし、使ったらその分だけ遅くなるのは当然 c++もrustもアセンブルコード埋め込めるのだから速度を出そうと思えば出せるのでは 今時、C#みたいなGC付きの言語で3Dゲームが開発できちゃう時代なんだ。
今のPCの性能を鑑みたら、C, C++, Rust の速度差なんてほとんど誤差みたいなもんだろ。
普通は気にするようなもんじゃない。
そんなわずかな差が気になるって言うのなら直にアセンブリでも書いてろよ。
ぶっちぎりで速いぞ。 3DゲームってUnityのことか?Unityの内部はC#じゃなくC/C++では 有能はコンパイラが上手く最適化できるコードを書く
無能はコンパイラが混乱するコードを書く
Cの方が速いとか言う奴は大抵無能 まあそれ言い出したらそもそもそこまでcpu速度に影響ある部分なんて
少ないけどな。
ガベコレねーからrust速いってやつも
スマポないからc速いってやつも
大して変わらん。 将棋ソフトとかチェスソフトは1%でも速くしたいという需要あるんちゃう
実際stockfishをRustで書き直したら速くなったりするのかね >>587
あんまり大きいプログラムじゃないみたいだけど、内部は木構造か
うーん >>585
それも突き詰めると絶対普段はこんなの書かねーっていうベンチマークのためだけのコードになったりするからなあ
>>581は有名な話だけどソース見ると言語によっては酷いもんだぞ rustで書き直すぐらいならC/C++のままでいい 既存のC/C++コードを捨ててまで移行する価値のある言語ではないのはたしかだな そもそもRustが便利だと思ってるやついないだろ
C++書いたことない奴がC++より安全だの同速だの言ってヨイショする
本当にCやC++書いたことあるならただの制限厳しいだけのゴミだと分かる ここはアンチスレだからね。
わざわざまともな話題をここでやることはない。
本スレは過疎 c++ゴミ老害をマウントするために新言語が必要なんだろ。 >>575
速度優先なら
vtable作らない
smartpointer使わない >>583
ゲーム開発はできてもゲームエンジン開発はどうなの 無能が生ポインタを使うとコンパイラの最適化を阻害して遅くなる >>597
横レスだけどCAPCOMのC#自社エンジンはC++でモリモリ書いてあるしC#用VMもC++で独自実装(SlideShareに確か資料があったはず)
Unityだって結局ライブラリも開発環境もC++が大部分よね カプコンのあれはゲーム用に超最適化されたGC詰んでるから… >>584, >>597, >>599
そりゃぁ、ゲームエンジンは速度が求められるからC#じゃ力不足だろうな。
そこまで持ち出されるとグーの音も出ない。
だから「『普通は』気にするようなものじゃない」って書いた。
ゲーム作ろうとするのにゲームエンジンから自作しようとする奴なんて『普通は』いないだろ?
そして、仮にゲームエンジンの開発に使うんだったとしても、
C#みたいなGC付きの言語ならともかく、C, C++, Rustの差は誤差みたいなものでしょ。
なぜなら、C++とRustの差が気になるっていうのなら、当然、C++とCとの差だって気になるはずだよな?
だったらゲームエンジンの開発にC++じゃなくてCを使ってるはずだろ?
でも実際にはCじゃなくてC++が使われている。
ということはゲームエンジンみたいにシビアな領域でもCとC++の差はさほど気にされていないってことになる。
ならやっぱり、C, C++, Rustの差なんて気にするようなものじゃないと言いたかった。 >>575, >>596
Rustは実装にもよるけど vtable はほとんど使わないはずだよ。
「ジェネリックとトレイト境界」を使えば引数に関しては静的ディスパッチが可能。
戻り値のほうは「ジェネリックとトレイト境界」じゃどうにもできないけど、
こっちはTagged Union 使えば大体は何とかなる。
現状、クロージャを返す場合はトレイトオブジェクトを使わざるを得ないけど、
クロージャを返すことって稀だし、そこまで気にするようなことじゃないと思ってる。
Cにはそもそもクロージャ自体が存在しないわけだし。C++でもクロージャは一般的じゃない。
smart pointer に関しても unique_ptr なら遅くはならない。(ほとんど誤差みたいなもの)
だって unique_ptr は参照カウンタ使ってないし、Rallの仕組みを使って構造体(スタック)に
ポインタを持ってデストラクタで解放を行ってるだけだから、その程度で遅くなるわけがない。
そして、Rustはデフォルトが C++の unique_ptr と同じだからやはり遅くはならないはず。
遅くなるのは内部で参照カウンタを使ってるshared_ptrとweek_ptrの2つ。
Rustの場合は参照カウンタは Rc or Arc として標準ライブラリに用意されてる。
まあ、Rustで Rc or Arc を全く使わずに作るってのはちょっと現実的じゃないけど。
まぁ、自分もそれほど詳しいわけじゃないけど、
vtableとsmart pointer はRustが遅い理由にはならないんじゃないかな。
RustがC, C++ と比べて少し遅い理由は他にあると思うよ。
個人的にはまだコンパイラが成熟してないってのが主な理由だと思ってるけど。
結構いっぱい書いたけど、やっぱり結論としてはC, C++, Rust の速度差は普通に使う分には気にすようなものじゃないと思う。 >>602
訂正
week_ptr ×
weak_ptr ○ HashTableがデフォルトで安全側に倒してSipHash使ってるのも大きい気はする
ripgrepやfont-rsなど既存の実装よりも圧倒的に高速なrust実装もあるし、言語自体の差と言うよりも、書き方の差だと思う
constexpr周りはDやC++の方が充実しているけど、build.rsなどで代替できなくもないと思う Unityが出てからC#でゲーム書く人が増えたわけだし、どこかの企業が気合い入れてRustサポートしたエンジン作れば使ってみる人も増えるやろ 速さの差を気にする必要はないとかいう奴って
普段どんなところでコード書いてるプログラマなんだ?
プログラマなら一番速い選択するべきだろ かけれるコストが一定という制約で一番速くなる言語を選ぶと結果は変わるんだよ >>607
「速さ」にも何種類かあるのは理解してる?
最近は開発スピード優先だろ。 開発スピード優先とは言っても
アルゴリズムや計算量知らないで
とんでもない糞コード書く香具師はいる そりゃ論外だ。
開発言語の問題じゃない。開発手法は少しは関係あるか。 Rustでプログラマが意識してないのに走るランタイム処理って何かあるかな?
起動時になんか処理してる?
あとは、メモリ解放時に意外とjemallocが重いとか? かけれるコストを減らすのがプログラマの仕事だろうに……
処理の肝の関数をアセンブリで書くのに一週間かけるのか? > プログラマなら一番速い選択するべきだろ
> かけれるコストを減らすのがプログラマの仕事だろうに……
一番速い言語を選択した上でかけれるコストを減らすという主張のようだが、
コストの上限って大抵あるのよ?
上限ないならプログラム全部アセンブリで書いた上で
お好きなようにかけれるコストを減らしてください
> 処理の肝の関数をアセンブリで書くのに一週間かけるのか?
元になる関数の有無、関数の規模、ボトルネックとしての割合、
複雑さ、アーキテクチャ、既存のテストコードの有無、
作業する人数、スキルと単価の前提すらなく作業時間だけ提示されても
必要なら一週間かけますとしか言えないよね? >>613
> 処理の肝の関数をアセンブリで書くのに一週間かけるのか?
必要ならやるけど
ふつうは、アセンブリで書くというという結論に至る前に
処理の見直しで数ヶ月試行錯誤するかな 本当に必要なら
関数のアセンブリ化くらい一日でやるのがプログラマだろって話な? 処理の肝の関数が一日程度のアセンブリの最適化ですむ程度なら、
絶対に手を付けないな
コードの保守性を考えるとむしろ害悪
ドライバのコードを一週間かけて最適化して劇的に早くしたことがあるが、
関数に対する暗黙の前提とかを見つけて、
ひらめきでニーモニックを最適化していく作業
一日程度でやることじゃない 今時の高性能(で複雑な)なプロセッサの最適化はコンパイラ>人間 移植で高速化する案件ってのは、大概同じ言語で書き直しても高速化するからなあ
要するに作り直しに際して全体を見直すという行為が一番効く 詐欺会社の社員の言うことなんて信じるからRustなんかに飛び付くんやろなあ >>622
お前それインタプリタ言語からコンパイル言語への移植でも同じこと言えんの? GoogleのAIエンジン、別にRustで書けとは言わんがせめてGoにしろやと常々思う
演算量多いんだよバーロー GoogleのサーバサイドではPythonからGoへ置き換わりつつあるみたいだけど、そっちも置き換わるのか スレチだけど、Goはマルチコアでの並列処理に適した言語だからAIエンジンをサーバで動かすなら置き換えて欲しいよね
しかしまぁ、C/C++からRustの移植で早くなるのは、オブジェクトの取り回しが無理やり矯正されることによる恩恵かねぇ
mutexのlock/unlockによるブロッキングが早々起きないから待ち合わせしなくていい所の待ち合わせは矯正されてそう
プログラマが意識して作るならC/C++のままで良いけど、人がやるより機械がやってくれるならそれに越したことない tensorflowの事言ってるなら、pythonで書かれてなかったら誰も使わないよ pythonは利用者==開発者での試験開発には非常に好ましい言語だけど、利用者!=開発者では性能悪くてver.2,3で言語仕様互換性のないRust未満のクソ言語だよ?
AIエンジンを実用ツールとして見ない日曜プログラマはtensorflow(python2 lib)をホクホクと使うけど、実用ツールとして見たらtensorflowは誰も望んでは使わないよ
同じように言語の適材適所を考えないプログラマはRustの適所を考えることもせず、アンチ活動に走るよね
コンパイル通るコード書くの大変だし、ローポインタ操作は好まれないし、日本語書籍少ないしで決して便利な言語じゃないけどRustもハマれば良い言語よな アンチの存在はともかく
アンチと戦うのが好きな人が多いのが難点ですね 演算グラフを構築してGPUに投げる処理をrustで書けば速くなると思ってる低脳っぷりヤバイわ
GPUの100倍も遅いCPUでループ回るのが速いとかマジでどうでも良いからw 今rustで業務アプリ開発してるけど、マルチスレッドでのデータ競合をコンパイル時にチェックしてくれるのが特にいい感じだわ
ただ、今まで気楽に相互参照使ってた所とかrust流の書き方しないとキツイのが結構あるな まあ行列演算のコアなところは今でもアセンブラだったりするわな。
一つの言語で全てのレイヤーを賄おうとするのがそもそも馬鹿すぎる発想。 >>630
挙げてるデメリット全部致命的で、
全く嵌まれば強いように見えないな >>636
それってpythonについて文句言ってんの?それともRust?
それとも両方? >>630
日曜プログラマとかレッテル貼ってdisってみたけど、
実は自分の方がクソど素人だと>>633>>635にバラされた気分はどう?
流行りだからってドカタが無理してAIとか口出さない方が良かったね >>637
Rust
Pythonについては同意見 道具でしかないプログラミング言語ごときに何でそう愛憎うずまくレスが沸くんだぜ やっぱりマイナー負け組言語マニアは余裕がないから
簡単にムキになっちゃうんじゃね Rustが使える有能な言語だと思っている?お前がそう思うんならそうなんだろう お前ん中では
Rustが使えない糞な言語だと思っている?お前がそう思うんならそうなんだろう お前ん中では
お前がそう思うんならそうなんだろう お前ん中では >>640
本当は電気ドリル使った方が楽なのに頑なにスコップ使わせたり、
逆にブルドーザーでやれというようなアホな現場があるのが
ITの世界だったりする。
まあそんなことが続けばその道具を嫌いになるのはわからんでもない。 >>644
わかる
そしてスコップやブルドーザーでも時間や犠牲を払いつつもやれてしまうのがITの世界 >>638
とりあえず、tensorflowのコードを見てないんだなって思った
GPUに投げる演算処理以外のステップ処理とか関数コールとか動的型変数の取り扱いとか
インタプリタ言語がコンパイル言語より遅い理由に挙げられるデメリットをガン無視かよぉ
>>639
IteratorやOption, Resultとか、ハマればC/C++で何行もかけて書いてた所が1行に収まって
短くて可読性高くて性能良いコードになるのはメリットだと思うんだけどなぁ
あとは、makeだのvalgrindだのgoogletestだの色々な3rd party toolを使わなくてもcargoで完結するのホント助かる >>646
3rdパーティツールを使ってないんじゃなくて、利用が簡易ってことだけどな。
そういう怪しげなこと書くくらいならモチっと使い方なり書いた方が普及には繋がると思うよ。
https://qiita.com/kubo39/items/cb84cd0ee89d257ce11e >>646
tensorflowはボトルネックになりそうな所はC++で書かれてるよ
想像でテキトーな事を書くなよ Pythonが科学技術分野で好まれてるのは
numpyやscipyのお陰だから言語に文句つけても意味ないし、
Rustで書くよりnumpyで行列演算した方が速いから
速度面でも移行するメリットがない >>644
ITに限らないような。低能率な環境や命令を棚に上げて生産性向上などと吠える製造業も多いぞ >>650
未だに設計にEXCEL使ってる現場とか多いしね。
自称IT屋がIT使ってない。 >>652
ああ精確には「古いIT」だな。
客には「Excelで台帳管理しないでDBとWebアプリ使いましょう」とか提案する癖に、開発工程ではExcel使ってるという非効率さ。 Excelが悪いとは思わないけど処理の規模が一線を越えてくるとプログラムを書いた方が処理効率や保守性の面で有利になる
関数山盛りの激重スパゲッティワークシートを運用しているところは少なからずあるのでは
あとExcelに表計算ソフト以上の仕事をさせているところも結構あるな 経済学の論文でエクセル使ってて、しかし普通にバグってて問題になってたことがあったな。 >>654
規模がでかくなるとすぐ破綻するが
使い捨て作業でつかうぶんには超優秀
なにもまちがってない まあ実際はエクセルとバージョン管理使ってりゃそれで十分なケースは多いけどね。 とある公的研究施設に嘱託で行ってたときの実話なんだが
・それエクセルでマクロ書いたら多少楽になるんじゃね?って提案
→わけのわからんことに時間使わないで今すぐ手を動かして紙で管理してね
・コピペ満載糞コード見せられ「なぜこれ関数書かないんですか?」とだけ質問
→関数使うと見難くなる、保守しにくくなる、関数は書かないでね
なお、必死で食い下がって関数書くことだけは許してもらった模様
公務員なんてのはPCの前に座って屁こいてるだけで時間が金になるから
みんなこんなもんよ
時間を惜しむと言う発想が無いか、少なくとも民間とは違う rustなんて使ってるやつも同じメンタルだな
成果物出さないでコンパイラにエラーメッセージ出させてるだけで時間が金になるようなやつ
物作らなくていいなら理想の言語だわな けんきゅうしせつのひとが嘱託よりすべてにおいて優れているのは自然の摂理なので
本当にわけのわからない提案をしたり
既存コードに手を突っ込んで意味不明なリファクタをしようとしたりしたんだろう
マクロ化したり関数作ったほうが本当に能率いいなら
許可なぞとらずに自分のところだけそれでさっさとやっちゃう
うまくいくようならあとから提案する >>662
だーれがその「自分で勝手にやったところ」の面倒を見てくれるんだ?
嘱託ごときが定年まで面倒見れるわけもなかろうに
勝手にブラックボックス作るのは何様? 自分の責任範囲内の話だし
特にブラックボックスなところはないが
なにがきにいらんのだ 嘱託に設計を勝手に変えられる「責任」が存在するならそれは嘱託ではなくね?
自分が勝手にやった、自分一人しかわからないものは十分ブラックボックスだ コーディングルールに関数作らないことって明記されてなかったら
べつにいいんじゃないか いや関数ダメとか普通にどうかしてんだろ。。
これでブラックボックス化するからダメ言うんだったら何もできんわ。 そもそもプログラミングってきちんと正しく
ブラックボックス化(カプセル化)しましょうってものだろうに。。。 カプセル化はAPIと内部状態の分離であって
中のコードや仕様を隠蔽するのが目的じゃないんだが ID:pZVQT//+ は何かズレてんな。だから必死なのか。 Rustに限らないが、新しい言語ごり押しする奴や
コーディング規約ガン無視してコード書いたりする奴は、
結局そいつしかメンテできない領域を産み出すだけで、全く生産性に寄与しない
ってことが言いたいだけだぞ >>669
その「APIと内部状態の分離」をなぜ行いたいのかきちんと考えたことはあるのか?
車を運転するのに車の仕組みを知らなくても良いのと同じように、
プログラム(ソフトウェア)を使うのにそのプログラムの仕組みを知らなくても済むようにするため。
さらに言うと、プログラマが他人が書いたAPIを使うのに、そのアルゴリズムを知らなくても済むようにするためだ。
結局のところ、カプセル化の目的は「きちんと正しく」ブラックボックス化を行うことで
利用者側が内部の仕組みを知らなくても使い方を知るだけで済むようにすることだ。
「APIと内部状態の分離」を行うのはそのための手段として最も有用なものの1つというだけに過ぎない。
何の目的もなく「APIと内部状態の分離」を行えば、それは「中のコードや仕様を隠蔽する」のと大して変わらないよ。
もう少し本質をしっかりと考えよう。
君の言ってること自体は必ずしも間違っているわけではないし、言わんとしていることも分からんではないが、
なんというか、、、底が浅いと感じてしまう。 一応補足。
かといってカプセル化した中身は汚くてもいいと言ってるわけじゃないよ。
大多数の人間はカプセル化した中のコードを読む必要性はないけど、
プログラムにバグがないことは絶対に保証できないのだし、
パフォーマンスの改善やらその他いろいろな理由で、
一部の他人は必ず中身のコードを読むことになるからね。 >>663 勝手にブラックボックスを作るべきではない
>>664 ブラックボックスなどないではないか
>>668 プログラミングとはそういうものだ
>>663への反論として>>664はわかるが>>668はなんかずれてると思うがな。 >>674
「そもそも論」の話をしたからな。
ずれてるというか議論のすり替えが起こってるな。
悪かった。申し訳ない。 どうなんだろう
人と違うことやるときは
特に何も決まってなくても提案として言ったほうがいいの? rustに関係ない話持ち込んじゃってゴメンね…
「関数書くな」って真顔で言われたときのショックを伝えたかったの
Cから入った人間だから「プログラムを書く≒関数を書く」
だとどこか思い込んでたようなとこがあったのかなぁ
軽くパニックになったわ
関数書かないで何を書くんだろう…って
関数を書かないレベルの人に言葉を尽くすのは大変だったYO 昔俺が入ったプロジェクトはJavaだったけど、1クラス1スタティックメソッドのみっていう縛りがあったよ 嘱託の契約次第だろ。
まあ、無駄な時間を使わされるようだったら契約違反を盾に交渉するのは正しい。契約外だったら少なくとも追加費用を要求しないとな。 嘱託の人間に「こっちの方がいいから」って理由で
そいつにしかわからないプログラム書かれた側から言わせてもらうとまじでやめろ
お前がどんなにクソだと思おうと言われたようにやれ
嘱託のお前にとっては書いたらおさらばでいいんだろうが、こっちはそれを半永久的にメンテするんだぞ
こっちの形式指定はメンテするためにこっちが必要な条件なんだ だから「新しい言語のRust使います」だの「ナウでヤングなライブラリ使います」だの「イケてるツールのwebpack使います」だのは
お前がお前のために書くプログラムでやれ
嘱託先に納品する物で書くな。それはお前の物ではない 関数切るなって指示も、メンテナンス性考えたら自然とそうなるところもあるだろう
例えばコード上あっちこっち飛ばれたら追えなくなるメンテナもいるんだ
そういう人にもメンテナンス業務させるためにそういう指定になるのは自然なこと
さすがにうちではないけども、そんな奴を抱えてるSIer上流も当然あるだろう 逆にどんどん使ってくれというところもあるし場所によるとしか
どちらのケースが多いかは知らない >>680, >>681, >>682
まぁ、正しいこと言ってるとは思うよ。
納品物に使う言語とかを独断(個人の趣味)で決める奴は確かにバカだと思う。
でも、関数使うんじゃないって強制する側も大概だからな。
従うのが社会的に正しいってだけで、情報工学的には明らかにおかしいこともまた事実。
それと、全部従っておけばいいってのもどうかと思う。
おかしいと思うのなら時間をかけて説得するのも一つの手。
話が極端すぎるんだよ。 人間、数回の経験ですべてがそうであると錯覚しやすいからねー
特に失敗は記憶に残りやすい(将来に活かせるとは言ってない) ところで全く話変わるんだけど。
最近Rustの勉強をしてるんだけど、まだ慣れないし、C++もあまりやってこなかったので、
俺のバカな頭じゃ理解できないことがいっぱいあるから誰か教えて。
質問1
Rustってimmutable参照は複数持てるけど、mutable参照は1つしか持てない決まりになってるよね。
それってたぶんマルチスレッドのことを考えてそうなってるんだよね?(この時点ですでに勘違いしてる?)
けどRustではSyncトレイトとSendトレイトを実装してない限り、スレッド間で変数の受け渡しできないんだよね?
これって逆に言えばSyncとSendを実装してない場合はシングルスレッドなんだからmutable参照が複数あっても問題ないんじゃないの?
なんでマルチスレッドを全く使わないコードを書いてる時でもmutable参照は1つだけしか使えないの?
SyncトレイトとSendトレイトについてなんか勘違いしてる?
質問2
Rustで木構造やグラフ構造を定義する時に循環参照(子が親の参照を持ちたいとか)する時って、たぶんRcとWeakを使うことになるよね?
そして木構造を可変にしたいときはさらにRc<RefCell<T>>って形になるよね?
このRefCell使うとボローチェッカの制約をコンパイルエラーじゃなくて実行時にパニックするように変わるんだよね?
こうするしかないのはRc<RefCell<T>>使わずに木構造を作ろうとして執行錯誤したけど無理だったからそうするしかないんだなと思って納得したんだけど、
RefCell使っちゃうとボローチェッカが効かなくなるからせっかくRustを使ってるメリットが無くなったような気がしてくるんだよね。
それでもRustを使うメリットって何?
RefCell使ってるとこ以外はボローチェッカが効くんだからunsafeコードと同じようにラッパーで包んでやれば上位層に悪影響は出ないよねってこと?
それともC++とかで同じように木構造を作ると、Rustだと単純にパニックするだけだけど、C++だとデバッグがメチャクチャ困難なバグになったりするの?
たとえRefCellを使っていたとしてもRustを使うメリットはしっかりあるんだって思える明確な理由を誰か教えて。
この言語やってるともしかして俺ってすっげーバカなの?って不安になってくる。
長文すいませんが、誰か教えてください。 Rustなんて使った時点で騙されてる
その辺は言語設計が破綻してる証拠
悪いこと言わんからC++きちんと勉強してRustは忘れよう >>688
君ははた迷惑な例のアンチかな?
破綻している証拠とやらをその辺はとか適当な言葉で誤魔化してる時点で説得力がないよ。
てか、君には聞いていない。君以外に聞いてるんだ。 木構造にRcは要らんだろ
各ノードは直接の親にしか所有されないんだから 質問1について分かりやすいのがforループだな
あるベクタをforループ中に、forの対象にしてるベクタそのものにpushするみたいな黒魔術操作を禁止するために
forループを回してる間は回す対象の配列にイミュータブル参照を作ってる状態にしてコンパイラにチェックさせる 質問1がそうなっている理由は、以下のようなケースで解放済みのVecにアクセスしてしまうことを防ぐというのもある
let mut foo = Some(vec![]);
let foo_mut = &mut foo;
let foo_ref = foo.as_ref().unwrap();
foo_mut = None;
println!("{:?}", foo_ref); // drop 済みのVecへのアクセス 重箱の隅だが四行目は
*foo_mut = None
だな >>691, >>692
なるほど。mutable参照が1つしか取れない理由はマルチスレッド以外にも理由があったのか。
単純なコードだけど実際に示されないと気が付けないな。(少なくとも俺は)
やっぱりGC無しの言語はメモリ管理が難しいな。
そして、それをコンパイラがはじいてくれるのはやっぱり有難い。
納得のいく答えが得られた。教えてくれてありがとう。
>>690
それは木構造でも親から子を辿るだけで済む場合に限定されない?子から親を辿りたくなった場合だと無理じゃない?
子は複数いるんだからそれぞれの子が全て親のmutable参照を持つことはできないよね。
だって、mutable参照は1つしか作れないんだから。
そうするとRcとWeakとRefCellを使わざるを得なくなるよね?ならない?使わなくても済む方法があるの?
ちなみにRcじゃなくてArenaっていう仕組みを使うって方法ならどっかのブログで見たんだけど、
その方法だと動的に追加していくことは出来るけど、動的に削除を行うことは出来ないよね。
例えばJavaScriptのDomツリーとかはparentNodeで子から親のNodeを辿れるようになってるし、
appendChildとかremoveChildとかでNodeを動的に追加したり削除したりももちろん出来るよね。
それと同じようなことをRustでもしたかったらRcとWeakとRefCellを使うしかないんじゃないかと思ってるんだけど。 双方向参照する場合はそう
RefCell使わなければならないケースでrustの方がうれしいのは、
実行時にはなってしまうが&mutのエイリアスがチェックされることかな
C++だと領域破壊してもそれらしく動いてしまうとかあり得てバグの発見が遅れる https://news.mynavi.jp/article/20180110-568199/
モジラ工作員ざまあ!!!wwwww
いやー一年は工作でごまかせたかもしれないがさすがにメッキが剥げてきたね!
これが現実!!
騙されてるやつはまだ間に合うぞ! >>698
どや顔で貼ったんだろうけど
記事内でリンクあるランキングでのRustの位置wwwwwwwwwwww
Rustのゴミさの補強にしかなってないwwwwww >>698
そいつはTIOBE IndexでScalaの順位が低いから
参考にならないの事にしたいだけのScala大好きマンだから
話半分以下で聞いとけ そもそも、みんなが使ってる言語だから良い言語みたいな理論を持ち出せば、
PHPをとても良い言語だと認識しければならなくなるんだが。
その辺を>>697はどう考えてるんだ?たぶん何も考えてないんだろうけど。
それとも、もしかしてPHP最高!とか思ってる奴だったか。 >>701
Rustは誰も見向きもしないクソ言語未満っていってるだけで
みんなが使ってる言語は良い言語とは一言もいってないけど? だれも見向きもしない言語ってのはつまり人気のない言語のことだろ。
人気のない言語はクソ言語ってことにすると、逆説的に、
人気のある言語は良い言語になっちゃうよね。 論理学できない人?
見向きもされないのは悪い言語 が真でも
見向きされる言語は良い言語 は真じゃないよ?
論理学できないからRustなんてもてはやすんだろうけど その理屈は論理学として正しいがそれを認めると
順位表では何が良い言語か一生懸命みてもわからんから意味なさそう >>704
それは悪かった。
どうせ君は物事を1か0でしか考えられない人間だと思ってたから、
そういう思考回路の人間だと思って会話を進めようとしてしまった。
じゃあ、別の方向から突かせてもらうけど、
関数型言語って最近(最近というほどでもないか?)の流行りじゃん?
でも、関数型言語の祖先ってLispとか言われてたりするよね。
で、そのLispはかなり昔から存在したわけだよね。
何で昔は一部の物好きだけが使ってて他は見向きもしなかったのに、
今更になって認められていろんな言語にラムダ式とかが採用されたの?
見向きもされない言語はクソ言語のはずなのになんで?
(ちなみにこの理論は反論できる余地があります) Lispが関数型言語の祖先かと言われると副作用だらけだし違和感しかないな
別に最近の言語のラムダ式はラムダ計算を構文に持ち込んだだけで、LispのS式まわりの成果を持ち込んだわけでもなかろうに
どちらかというとHaskellとかML系列の成果の方が主だろう
RustがLisp的な立ち位置になると言いたいんだろうが、言語のお粗末な出来から言ってもそれはない 別にLispに限定した話じゃないよ。
関数型言語って昔からあるよね。でも当時は誰も見向きもしなかったよね。
見向きもされない言語がクソ言語なら関数型言語が
今更になって認められるのはおかしいよね?ってだけ。 言語が変わらなくても時間の経過によって環境の方が変化して評価が変わることは十分に有り得る
プロセッサ負荷やメモリ使用量などの足枷がユルユルになって来たことで評価が高くなったのではないか
従って当時とか現在とかの時世を無視しては語れないこともある それを認めると将来Rustがクソではなかったと証明される余地があるってことで、
それは事実ではないから違うな
今評価されてるのはあくまでラムダ計算であってLispではない、と言えば分かるか? >>709
Yes! That's correct!!
反論の余地とは時代等の外部環境の変化により評価も変化することだね。
なんか別のIDの人が答えちゃったけど。 >>710
ワロタwww
お前は未来人か?
未来人を肯定するならrustがクソ言語であることも認めよう。 >>694
子→親のリンク無し縛りでも動的な追加削除はできると思うけど。
子からのリンクが必要なのは、各ノードへの参照をそのままイテレータとして見せて前後移動したい場合のみじゃね
で、まあ、子からのリンクが絶対必要として、そのためにRc使って要らん参照カウンタと間接参照を各ノード毎に持たせるってすごい無駄に思える
諦めてraw pointerでいいんじゃないかなあ…… 案外、未来でRustで書かれたプログラムが暴走して人類の危機だから、
現代にタイムリープしてきてRustを普及させまいとする工作員の可能性が微粒子レベルで存在……しないか そうだったら5chみたいな辺境じゃなくてもっとちゃんとしたところで活動してるだろ >>716
木構造がどういう構造なのかを勉強したほうがいい >>704からの>>710の流れで草生える
論理学できない人?
ブーメランかな? wwwwwww 言語オタクが喜びそうな機能を盛り込んだら本当に飛びつきやがったw
みたいな言語だよな。 飛び付いたオタクは無事モジラの養分となりましたとさ オッス!オラMozillaの養分!Rustいっちょやってみっか! せやねw
昨日まではcomponentに残ってたんだけどなぁ
また "rustup run nightly cargo install rustfmt-nightly -f" でいれるかー Rustのビルドそんなに遅いか?
Scalaと比べたら誤差だろ >>731
rustup component add rustfmt-preview --toolchain stable
でインストールできるやつのつもりだった
なぜかcargo-fmtは入ってないけど 代入の結果が () を返すのって一見不満なんだが…
#include <stdio.h>
int main() {
int a, b;
a = b = 10;
printf("%d, %d", a, b); // 10, 10
return 0;
}
a = b = 10
p [a, b] # [10, 10]
let b = ref 0 in
let a = b := 10 in
Printf.printf "%b, %d\n" (a = ()) !b (* true, 10 *)
fn main() {
let (a, b);
a = b = 10;
println!("{:?}, {:?}", a, b); // (), 10
}
上から c, ruby, ocaml, rust の結果
所有権のこと考えるとこうなるしかないのかな >>735
うん そのcomponentが木曜日はあったのに 金曜日に無くなって 今見たら復活してた
このままだと「月曜日に市場へ出かけ 火曜日にお風呂に入り 水曜日に力士でデビュー」ですよ
そして確かにcargo fmt無くなってるね まぁ当面rustfmtが呼べればいいんだけど
>>736
その辺りの差異は慣れるしかないかーとあんまり気にしてなかった
言われると確かにもやっとしますな >>736
VBAだと a = b = 10 は a = (b = 10) となり (b = 10)は比較演算になって aはBoolean型になるよ >>740
Rust凄い!Pythonの1.45倍も速い!
って書くと、逆に遅く感じる アンチスレのほうがアンチが話題ふってくれてRustに貢献してる感じする 俺の環境でも
Julia: 8.58sec
Rust: 9.66sec
で1秒遅いな。でも特にチューニングしてないコードで Julia にここまで迫るなら十分だな。 juliaってスクリプト言語なのに、
スクリプト言語に負けて十分な速度と言い張る低級言語wwwwww
いやー信者ってすげえわwwwwww いやでもJuliaに勝とうと思えばIntel Fortran持ち出してくるか
Cで環境固有のattribute使いまくるぐらいしか無いぞ割りとまじで
JuliaもバックエンドはLLVMではあるんだけどな 乱数生成のアルゴリズムが一致してないものを比べても言語の速さは比べられんだろう
Juliaの乱数生成のアルゴリズムが速度面で優れてるってことが分かっただけだ
それでも動的言語でこの速度は確かにすごいと思うが
あとC言語のベンチの結果が載ってないのも痛いな
これじゃJuiliaが速いってことは分かってもRustが遅いかどうかは分からん
でもJuiliaって数値計算特化の言語なんだろ
だったら文字列処理とかは遅いんじゃないの?
もう少しいろんな方面からパフォーマンス測ってみないとなんとも言えんな ***が速いと言われているので使ってみて言うほど速くなった試しはないな
実際に使うときはIO性能も重要だしよく使う言語の方が最適化手法を知っているというのもありそう Rustが将来どの分野で使われるようになるか分からないけど、
少なくとも科学技術計算の分野に食い込むのは無さそうね
過去の資産もない上に速度的な優位も無いんじゃねぇ そもそも既存の資産を置き換えるほどの魅力がない
学習コストもばかにならない そもそもrustの魅力って何?
コンパイル通させてくれない言語って印象しかない コンパイラが手取り足取り教えてくれるから誰でも簡単に安全なコードが書けるよ >>757
rustはスレッド書きやすいと思うんだけど
書きにくいって思う人が書きやすいと思うのはどんな言語?goみたいな?
ネイティブと軽量スレッドの違いあるけど記述自体は殆ど変わらんと思うけど
軽量スレッドが言語に組込まれてないから? コンパイル通せないのが魅力って、つまり
malbolgeみたいな実用じゃなくて難解言語ネタの一種ってこと? そもそも科学数値計算はマルチコア・マルチノードで並列で処理するような >>763
競プロこそ全員違うアルゴリズムなんだから速度比べても当てにならん例じゃね まともに話題提供する人は本スレに書き込んでね。
ここは荒らしたい人専用です。 アンチは話題を提供してくれるという意味ではありがたいが
速度や人気度の話ばっかりで構文系の話が出てこないんだよなぁ。
ライフタイムがジェネリックとごっちゃになって書きづらくね?とか、
box構文いい加減にstableにしろよ いつまでnightlyのままなんだよ?とか
swiftみたいにOption型をOption<T>じゃなくてT?って書けるようにしろよ とか
標準ライブラリ薄すぎだろ?もう少し分厚いの用意しろよ とか
そういう類の文句はなんで出てこないんだ? 最近のKaggleのコンテストでRust使ってる人が上位にいたという話を聞いた 標準ライブラリが少なくて外部crateに頼る方針のことでしょ
node.jsに近くてGoの正反対 Option<T>に関してはSwift使ったことないから全く気にしたことなかったな
OCamlとかScalaとかフツーにOptionって書くし
box構文についてはなくても困らないとかそういう理由だろう
それよりimpl Traitとかdynキーワードとかトレイト境界の特殊化とか
もっと大事なのあると個人的には思うが >>773
それについてはもう知ってる
個人的にもう少し公式が積極的に用意してほしいなという願望を書いてみただけ
ライブラリ探すの面倒なんだよな
ただでさえ学習コスト高いんだから出来るだけ気軽に試せるようにとか
それ以外のところで努力しないと普及しないんじゃって不安になる
アンチ側からもこういった意見が出てもいいと思うんだけど出ないんだよな
速度云々とかStackOverFlowとか質問系サイトでの質問数云々とかばっかりでさ
構文だったり公式の方針とかには不満はないの?「こんな構文はダサすぎる」とかさ rustcでwindows gui用exeをコンパイルするためにコンパイラに指定するフラグって何ですか? >>774
impl Traitって戻り値の型にTraitを指定して限定的に型推論を効かせようとしてるやつのこと?
あれって引数の型も型推論できるんだっけ?
確かnightlyでは動くんだよね?まだstableには出来ないのかな?
トレイト境界の特殊化って何だ?今調べてみたけどこれのことか?
https://qiita.com/sinkuu/items/450ee1219b10072f09e8
へぇこんなのあるのか知らんかった
こういう話題が欲しかったんだありがとう >>765
最速を目指すような解法ならどれも大体同じでしょ >>776
コマンドプロンプト表示させないということならcrateのトップレベルに
#![windows_subsystem = "windows"]
と書けばよい 本スレとやらが過疎ってレベルじゃなく、アンチスレが大盛況なモダン言語()があるらしいwwwwwwwww Rustの構文とかバージョン1.0越えてるのにどんどん新しいRFC承認してばかすか変更加えてる未完成品じゃん
そんな状態でバージョン1系名乗るとかモジラの頭の悪さがよく出てる
そもそもnightlyの機能がないとクロージャー返す関数すらかけないってなんのネタ言語?
トレイト周りも、実装記述できないパターンいくつもあって草しか生えない トレイトとか変な言語機能をオレカッケーで採用なんてするからこうなる
枯れたオブジェクト指向で堅実に設計しとけばこうはならなかったはず
借用とかライフタイムとかはまともにコード書けなくなるくらいガチガチに固めておいてこういうところ雑に採用した結果の産廃言語 まあトレイトについてはHaskellを真似してみたかっただけ感あるし
Haskellで過去に起こった問題を丁寧に繰り返してる感も確かにある stableにするにはまだ早かったという意見には同意する 過疎スレよりキチガイと遊ぶほうが楽しいのは確かだからいいけどね
まともに議論したいのにこっちに書くのはキチガイなだけで そんなに互換性壊さなきゃ入らない機能拡張多い?
do catch とか? stable → try! やめて ? 導入 は、はえーなとは思った 他にも、いちいちネットに繋ぐからクソ遅い上にオフラインで回せないビルドとか
curl | sh - みたいなクソガバセキュリティの方法でインストールさせるとか
エコシステムの設計も狂いに狂ってるし
この言語にどこに議論の余地がある?
gitに対するcvsと同じで、「常にこれと反対の選択をする指標」以外に存在価値はない 実際議論の余地ない言語未満だから本スレ()過疎ってるんだけどなwwwwwwwww 言語仕様が存在せずメジャーバージョンどころかマイナーバージョンが上がっただけで動かなくなる
コードを大量発生させていたかつてのRubyと比べたらからしたらこの程度では騒ぐに値しない 熱心にアンチやってるわりには重箱の隅みたいな話が多すぎる
Mozillaに親を殺されたとかそういう話はないのか Rustで既存のC++移植するってなった結果
箸にも棒にもかからず職場が知っちゃかめっちゃかなって大量退職出た話でもすればいいのか?
ちなみにやってられんと退職した側な あーそれはひでーな
Rustは移植用の言語じゃなくて作り直し用の言語だからな MicrosoftのWebアンケートで、使用言語の選択肢の中にRustあった
この種のアンケートでは初めて見た Rust採用提案を阻止できなかった自分を恨めw
良い言語だけど万人受けはしない(万人は使いこなせない)って言ってるダルルォ
ちなみにお前さんは使いこなせない側な 採用したクソバカも同じこといってたな
書けない奴のレベルが低いってな
そうかじゃあレベル高い奴だけで頑張れってんで一抜けさせてもらう人続出よ >>797
C++を本来の用途に使ってたなら、Rustにしたからって破綻はしないだろ。
有りがちなのは、C++をシステムプログラミング以外に使っちまってるケース。 前の会社ってよりは
Rustとかいう言語未満の言語
それをステマして金稼ぎしてるモジラ
それにホイホイのって導入して現場を破壊する信者
に恨み抱えてる 誰を恨んでるにせよ、それで退職を迫られたってんならともかく
自ら退職したってんじゃ、やっぱりねちっこく逆恨みしてるだけのただのバカじゃん 一度書いたプログラムが好評で次もrustで書きそうな流れだわすまんの まあ冗談抜きにrustの一番のボトルネックはそういう選民思想を生みやすいってところだと思うよ。 つまりRustという言語が悪いのであってRustを導入した人間はMozillaにだまされた被害者と 早くこのスレ使い切ろうぜ
キチガイ君はRustじゃなくても別の何かで辞めてたでしょ このスレに書き込んでいるやつは全員あらしだから使い切るいみないだろ。
またこいつのためにワッチョイなしのクソスレ作らなければいけないんだから。 日本人は技術偏重でシステム設計が苦手。>>797が事実であるならシステム設計に失敗した典型例
Rustを比較的新しめのモダンな他の言語に変えても結果は大差ないはずだ 過去スレでも似たような事言ってた奴だな
結局悪いのはRustじゃなくて、無計画にシステム移植しようとした会社組織と
選民思想こじらせた同僚(上司?)であって
よしんばRustに恨み抱えたとしてもそれでこのスレ突撃って色々対象間違ってやしないかい。 アンチ活動してる人らって
その時間をもっと自分の人生にとって有意義なことに使おうとか思わないのかな まあ今まで解決できなかった問題をrustなら解決できると思うのは間違いだよね。 >>816
特にRustはこう見えて、まだ実績のない新しい技術は採用してないからな
traitはHaskellの型クラスそのままだし
凶悪で有名なボローチェッカだってC++で既に確立されてる
メモリオーナーシップの概念をコンパイラレベルで組み込んでみただけに過ぎない
どれも既に他言語で実績のある(枯れた)ものしか使っていない
Rust(錆)ってのはそういう意味もあるんだろう
Rustは理想ばっかり追い求めたの言語とか揶揄されることがあるが意外と現実主義だよ 個人的には「潔癖症気味の現実主義」というのが一番しっくりくるかな >>817
> Rustは理想ばっかり追い求めたの言語とか揶揄されることがある
いつどこで? >traitはHaskellの型クラス
ダウト
高階型も使えない
型引数つきの実装と具体型実装が(stableでは)共存できない
こんなもんを型クラスといっしょにしたらHaskellerに総括されるぞ >>820
細かい違いはあるけど、トレイトは型クラスのパクリでしょ。
あれだけ似てるにも関わらず、別物だよとか言ったほうがHaskellerにry)、、、 機能のパクリ元が型クラスというのは否定してない
劣化コピー過ぎて
「これを型クラスと同じ機能なんて言うな型クラスはもっときちんとしたものだ」
って(ry されても知らんぞということ 昔のアンチは少しは論理的なところを突いてきたりした物だが最近のアンチはデタラメを書き散らす奴ばかりや
>>816
プログラミング言語は所詮道具だからね。活かすも殺すも使う人次第 >>823
>>822に反論する事も出来ずに、デタラメって書き散らす事しか出来ない(何がデタラメかも説明出来ない)信者の方がレベル下がってるよ 親を殺されたのかとか冗談で言ってたけど、Rustに職を奪われたんじゃあアンチになってもしょうがない 親がどうたらみたいなテンプレ即レスしかできないこんな世の中じゃ >>829
ここにいるのは信者じゃなくてアンチなんだよなぁ 昔、自動車が普及したときも馬車の運転手は職を奪われたらしいね どっちかっていうとそいつらが最初に自動車の運転覚えさせられたんじゃなかったか。 twitterでこのスレの粘着をガイジ呼ばわりするのは気持ちはわかるけどコミュニティの品位下げまりだな。
RTする人もどうかと思うよ。
https://twitter.com/kgtkr/status/957237334772076544 被害妄想だな。Rust叩いてるのは一人じゃなくて複数人だぞ。
Rustヘイトが嫌ならRustでいいもの作って見返してやれ。 晒されるべくして晒されてるとしか思えんがな。
2ch でヘイトばらまくよりも遥かに愚かなことやってるって気づかないのかね。。 >>833
2ch内のあちこちで宣伝活動しまくってた奴か
「Anontown site:5ch.net」 Rust好き()を自称してるの、
モジラのステマにホイホイ乗る情弱か、選民思想こじらせた害悪かのどっちか 誰も言わないから言うけどrust1.0から矩ロージャー返す関数は書けるよね FnBoxあたりは安定してなかった気がするなぁ(うろ覚え Box<Trait>を介してしか返せないのを拡大解釈して返せないと言っている可能性 Javascript(Typescript)とRubyしか書いたことないCの知識すらないゴミなんですが
レベルアップしたくてRustを学習しようと思ってます
みなさんよろしくお願いいたします >>841
他言語では普通は暗黙的にボックス化されるからな。
確かに俺も初めての時はなんでそのままじゃ返せないんだよ(# ゚Д゚)って思った。
メモリ配置とか全く考えてないやつからしてみればそれが欠陥に見えるんじゃない?
>>842
ガベコレ有りの言語しかやったことないんじゃたぶん苦労するとは思うけど頑張ってね NLLとかimpl Traitとかトレイト境界の特殊化みたいに
ないと直感的なコーディングに支障をきたす機能が
nightlyにしかないのが色々と問題だよなあ
今年中にstableに入ってくれるかな? わしゃCを2年くらいやってたけどrustにはかなり苦労してる
futuresがとくに >>847
Cやってた人はHaskell的な型システム及び抽象化に悩む
Cやってこなかった人はボローチェッカに悩む システムプログラミングというかローレベルソフトウェアやハードウェアに対する理解がある人って昔より増えているのかな?
パッと見た感じだと増えるどころか減っているように見えるんだよな。今やスマホやゲーム機のハックも海外頼みだし ハック文化は国柄の違いがある?
国民も警察も役所もバカ真面目がそれなりの割合いる日本ではリスキーとか?
国民も警察も役所も真面目なのが少ない国民性だとやんちゃやっちゃう?? 組み込みハードだったりソフトウェアは昔より圧倒的に入手しやすくはなってる。
ただ、取り組む時間のある奴は減ってる。 組み込みする人は増えたけど既成のフレームワーク等がないと何も出来ない人ばかりじゃね?
ArduinoにしろRaspberry Piにしろそんな感じだし RustからいくつかのターゲットへクロスコンパイルしたいのでLLVMに関する情報を収集しているけど全然無くて笑えない
スライド&薄い本・・・英語blogの翻訳記事・・・
もっとも英語でも少ない感じではある。LLVM IRを俺様命令セットにトランスレートするチュートリアルとかないかな チュートリアルてこれじゃ足りないって話なん?
LLVM Tutorial: Table of Contents ? LLVM 7 documentation
https://llvm.org/docs/tutorial/ 公式が一番情報豊富なのでは
Overview ? LLVM 7 documentation
https://llvm.org/docs/index.html >>856
External Tutorials
の
Tutorial: Creating an LLVM Backend for the Cpu0 Architecture
がそれっぽいけど難しい感じだなぁ・・・読み解くだけでどれだけ掛かるやら 最近キチガイの書き込みがないぞ
不安になるからいつものたのむよ 最近の荒らしはコミュニティの破壊が目的だったりするから人がいなくなれば荒らしも書き込まなくなる 日本語rustコミュニティーはslackがメインだから5ch荒らすのはコスパ悪そう 標準のRustのターゲットセットにないプラットフォームへのコンパイラ移植は素人が齧ってなんとかなるものじゃないだろ
clangだったら何とかなるとかいうレベルの玄人が考えるならまだしも、今からチュートリアル読むとかだとそうでもなかろうし
素直にターゲットプラットフォームに用意されたコンパイラと言語を使えよと組み込み屋のマジレス >>863
それだとメモリ保護のないgccしかないじゃないか
LLVMで任意の命令セット用のコードを吐かせられるようになればRust以外のコードも使える可能性が出てくる Rustさわらなくていい職場に就職できるといいね。 Rustスレの話題がアンチのコメント内容ですらなく、
アンチの人物自体になってるの草 slackでコミュニティあるんだ。
なんだかクローズドなんだね…。 別に誰でも入れるし便利だからSlack使ってるだけでしょ 今のコミュニティはクローズドな登録制が主流でパソ通時代に逆戻り
インターネット初期と比べて身のある情報へのアクセス性は低下している
ゴミ情報はドンドン出てくるが slackはgoogleで引っかからないからクローズな感じするなぁ 「インターネット初期」というのがいつ頃を指してるんだろうか >>876
LinuxカーネルのMLもクローズドってこと?
ばかかな? slackみたいな外から干渉できないクローズドなもの使ってるって時点で
選民思想丸出しなのうける
ほんと内輪で群れてオレツエーやってるだけだな 誰でも入れるって、身分登録すれば入れるって時点で選別入ってるんだよなあ 「選民思想だ! 自分は排斥されてるんだ!」って完全に病人だなコイツ 外から干渉出来ないって何言ってんだ?
githubでもアカウント無いと意見出来ないだろ
参照だけは匿名でやらせろって?
何でそんなに匿名に拘るんだ?アンチ活動したいから? >>864
nimって良い言語があること教えてやろう
みんな大好きPythonライクな文法で、GCがついてる安全ランタイム、さらにはコンパイラにgccも指定できる最高な言語だ
Rustなんてコンパイルが通せない上にコンパイルターゲットが制限される言語なんてやめて、nimを使おうぜwww slack、herokuに誰でも入れるようにするアプリ入れてるからオープンだぞ
おまいらも来いよ >>885
GCが無いと正しく参照を破棄できません、と言うことかな slackって登録しないと発言どころか参照すら出来ない気がするけど違うのかな?
それをオープンと言えるのであればMixiもオープンって事になっちゃうな
昔のBBSはアカウント制ですらなかったけど自治されていたし治安は今よりよほど良かったよ
>>877
ADSLの初期くらいまでかな。個人運営のサービスがコミュニティの中心だった頃 排斥いうたら2chだってIP制限で海外からは投稿できなかったのでは 参照すら出来ない、と参照できるが書けない、
がどれだけ大きな違いなのか理解できない低脳が
Rustを推してると思うと眩暈がするな まぁslackはクローズドだ!で、いいんじゃね?
だから何?という感じだが つーか>>876に同意。サーチエンジンに出てこないんじゃアングラサイトと変わらない だから僕はついていけなくて当然なんですぅ
情報収集能力がないわけじゃないですぅ
他人と関わるコミュ力が無いわけじゃないんですぅ
タダ乗りしたいのに誰も教えてくれないから仕方ないんですぅ
池沼かよw 検索するとネトゲの情報出てくるし
ググらビリティはただでさえ悪いのに
そもそも情報がオープンになってないんじゃ普及しないわな タダ乗りというが、逆に考えてみような?
会員制のサイトに登録しないと言語情報すらもらえない言語、誰が使うんだ?と
gccの情報を得るためにGNUのメーリングリストに登録を強制されるのか? >>898
程度論だろ。
IRCのチャンネルもあるんだし、それなりにネットに記事もあるじゃん?
Racketよりは記事ある感触だけど。
次は「英語だから読めないよ…」か? 言語のslackコミュニティーなんか珍しくもなんともない気はするが アカ無しの所は無責任が複数、アカ有の所は八方美人が多数じゃね?
どちらも技術に関して議論するには向かない環境なんだよな そのslackへのリンクと参加方法を教えてくださいな プログラミング言語 Rust 3 [無断転載禁止]©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1495343069/512
> 512 名前:デフォルトの名無しさん[] 投稿日:2017/08/10(木) 14:00:03.18 ID:g9gtECZC
> >>509
> slackがある
> 登録済の人 -> https://rust-jp.slack.com
> 未登録の人 -> https://rust-jp.herokuapp.com/
> Rock54: Caution(BBR-MD5:b95868ef2c0ed5e765a4d10ada4cf289)
前スレのレスだけどどちらもアカウントがないと見られないようだ
参照できるって言っている人はどこで見ているんだろうね
>>878
LKMLの事を言っているならログは公開されているようだが 👀
Rock54: Caution(BBR-MD5:b95868ef2c0ed5e765a4d10ada4cf289) モジカスが口癖の彼にもSlackであばれて欲しいわ むしろMozillaの人もいるオフィシャルのフォーラムでやってほしい というかSlackに誘導するならそのメリットを論理的に説明してくれよ
論理性がないんじゃ荒らしの有無にかかわらず中身のある議論にならないだろ そもそもslackに入るまでに中の人とリアルで仲良くなって
コミュニティへの貢献を認められて初めてアカウント発行してもらってから
それからまた別の新しい人が入るまで相撲部屋もびっくりの可愛がりが続くんだろ https://rust-jp.herokuapp.com/
どうぞ 👀
Rock54: Caution(BBR-MD5:b95868ef2c0ed5e765a4d10ada4cf289) そのslackいつどこで誰が用意したものなのか怪しいな? まぁ確かにここ見てる日本人相手に愚痴愚痴言うよりも
開発者に直接開発止めろって抗議した方が可能性はあるかもしれないぞ 登録してなくても読めるようになるように準備してるみたいだよ
どっちが閉鎖的なんだか >>911
相談者にとって重要なのはすぐに回答がある事じゃなくて問題が解決することではないのかな?
今のインターネット界隈はドヤ顔で問題の解決に寄与しない回答をする奴がいっぱいいるしな 言語自体に文句付けるのはともかく
slack "も" 使ってることに文句付けるのはさすがに無理がある >>916
当たり前だろ
このスレのレベルの話ならすぐ解決するわ 無理筋なアンチ活動はまともなアンチ活動の足を引っ張るからな ってか、余程、コンパイルを通せなかったのが悔しいんだろうな。
俺色々書いてみたけど、まともに書いてりゃそこまで理不尽な怒られ方しないし、むしろCのノリで書いて通らなかったところは、本気で考えた方が良いところだったよ。
嫌ならGC言語使え、ってのは真っ当だな、と思うぐらい。 slackは知らんけど、このスレもRustはヒープよりスタックを好んでるって言ったら
BoxやVecでヒープメモリ使うからそんなことないとかいう反論が来るくらいにテキトーだけどな
全員が本当にそう思ってるわけじゃないだろうけど、Rustを知らないアフォがドヤ顔してんなと思ったことがある
ユーザもアンチも当てにならないスレだから、双方の言い分を話半分にスレで遊んでる人が実際多そう そういや英語圏だとRedditが機能してるけど日本語はないよね?
Qiitaのが記事があるぐらい? 発言者の分かるslackの方が質は良いな
適当なこというとつっこみが入るし >>923
そりゃ C で書く必要がないくらい共有する資源がなけりゃそうだろうね。 >>927
Cで書く必要が無いからRustで書いてるんじゃん?
Cで書く必要があればCで書いてるだろ。
バカなの? (従来の)Cで書く必要のない/(現在の)Cで書く必要のない
という話だな
Rustが出てその領域が広がった訳だ Cで書く必要がないならRustを使うよりもっと良い選択肢がある
Cでは都合悪くてRustが都合よくなるなんてそれこそ信者に都合のいいシチュエーションは存在しないんだよ Cでは都合悪くてRustでは都合がいいとなると、なんかのパーサとかじゃない?
電文パーサーで毎回危なっかしいコード書くやつ居るからな。
レビューしてると辛い。 OpenSSLをRustで書き直すと良いと思うよ
これ以上に都合の良いシチュエーションなんてそうそう無いと思う >>932
おまえセキュリティモジュール一から書き直すとか正気か?
Rust信者は本当にコンピュータ科学に対して無知なのが良くわかるわ >>933
opensslは猿が書いたかのような酷いコードだからいいんだよ
お前のようなお猿さんに酷さは理解できないだろうけど >>936
その解決に必要なことはテストの追加とリファクタリングであって、ナウい言語()での書き直しではない
実際テストの追加とリファクタリングだけでLibreSSLはうまく中身を安定させた
こんなことも知らないんだからRustなんてもてはやすんだな信者は 問題があろうが枯れていれば充分、はまぁ正しいからな。
スクラッチの方が良かろう。 一から書き直すとして、それが「猿が書いたような」OpenSSLの品質に到達するのはいつだ?
中身は確かに色々ツギハギだが、OpenSSLには長期に渡って枯れた品質というものがある
そしてそれはLibreSSLにフォークされて固められた
一から書き直したものがその枯れた品質のコードに追い付けるようになるまでに
OpenSSLはより枯れて品質も高まる
結局書き直したところで元になったものの品質を越えることなどない
という常識すらないのか rustls面白い 読みやすいー(個人の間奏の感想 memcachedのlibketama互換実装無さそうだな >>943
なりふり構わずなのは詐欺集団の方だろう
少なくともスパコン詐欺については一番分かりやすい見解を出してるのが金子先生だ
金子先生にモジラの資金洗浄まで踏み込んで欲しいがさすがに国政と関係なくなってしまうから
特捜部の調査でモジラとの関係性が出てくるかがポイントだと思ってる 今ある物のクローンを作ったって大した意味はないよな
やるならgcc→clangみたいに一新しないと Rust使うような会社に勤めてたんだし何かしら秀でた才能はあるんだと思ってて
多分それは粘り強さとかなんだろうな
悪い方に使うとただしつこい存在になるし消えて(本当に死んで)欲しい >>931
危なっかしいやつを会社から追い出すためにRustにするって話?
(危なっかしいやつは何を使わせても危なっかしいコードしか書かんだろ) Rustは危なっかしいコード書くとコンパイルが通せないからね
コンパイル通るコードが書けない、Rust死ね。氏ねじゃなくて死ね。
って発狂する奴を追い出せば、残りは危なっかしくないコードが書ける奴だけ残りそう
日本のプログラマ(笑)だと発狂しない奴が一握りしか居なくて立ち行かなくなりそうではある
プログラミングなんて海外に外注した方が安くつくんだからRustなんて書けなくて良いんだよ、とか強がりたい
あと、stackoverflowで相変わらず愛されてるから海外プログラマに任せた方が実際幸せそうだ 不必要にunsafeやallow()を乱発する安全機能すり抜けるような危なっかしいコードを書く奴が現れないとでも? ちゃんとエラー処理せずunwrap多用したりletのプレースホルダ代入多用してコンパイル通したり unsafeやunwrapでビルド成功まで辿り着けてるならまだマシで、>>944なんかはそこにすら辿り着けそうにないからなw
そして、unsafeやunwrap多用してなんとかコンパイル通すバカもついでにふるいから落としちまえ
残るのはC/C++でもRustでも安全なコードを論理的に考えて書けるツワモノだけだ
どっちでも良いならツールチェインやらテスト環境やら依存ライブラリ解決やら一式やってくれるRustのが良いかな
C/C++はPJ毎の環境に慣れるのが面倒だ、、、PJ毎にMakefileだのTestSetだのが違って鬱陶しい https://ideone.com/UqQplz
コンパイルに成功したのに計算が合わない(´・ω・`) 論理的なコードが書けてて良かったじゃん、次はバグのないコード書こうな
っていうツッコミ待ちだよな?マジで質問してるならplay.rust-lang.orgでやってくれよ >>950
Rust使ってコンパイラに叱られるだけでだいぶマシになる。
追い出すとか、そこまで馬鹿ばっかでもないよ。 >>956
おなじレベルのCの静的解析ツールクソ高いからな。 実はRust擁護派の方がコード書けないので
実際にコード書かれて質問されても答えられないんだぞ
>>958の言ってる事はそういう事だからな。分かってやれよ 同じコードをCで書いてみ?きちんと書けると保証しよう
つまりそういうことだ let sum1 = sum1 + column1;
if sum1 != sum1 + column1 {
println!("計算が間違ってます!");
} 途中で書き込みボタン押してしまった
>>964みたいなのCで書こうが駄目だと思う >>965
Cで書けばそういうクソなミスは起こらない ワロタww
これがCならきちんと書けると保証できる子はやっぱりふるいから落とされて妥当じゃないか
>>961
あまりに汚いコードで呆れて読む気が失せたからボケだと理解したんだよ
実際、>>964が指摘するようなしょうもないボケを仕込んでるじゃないか >>957
そもそも10+21+32+43+54+65+76 が間違ってるぞぃ (!= 308) Rust書いてると型合わせとかライフタイム調整とかくだらんことでコードの書き直しさせられて
こういったうっかりバグを仕込む率が跳ね上がる
Cなら一発ですぱっと書けるから本質的ではない書き直しがないので
こういったミスを予防できる訳だ 人間がやるかコンパイラがやるか
どちらも完璧ではないですが、どちらを信頼しますか
これだけやろ、何と戦ってるねん いや、リソース管理分野のRustボローチェッカーは信頼しろよ
ボローチェッカーに親を殺された子が、ボローチェッカーを許すRustユーザを逆恨みして戦ってるんでしょ >>970
ライフタイム調整はCでもやらないか?そりゃコンパイラには怒られないが。
突然事故るコード書かないでほしいな。 slackが嫌ならtwitterはどうだ
rustに入門してしまいそうな人にモジラの悪行を伝えたらきっと感謝されるぞ 9割以上の人達はRustに入門しても直ぐに離れていくと思うから
そんな事する意味ないよ >>957のread_lineの戻り値のResultを処理してないけど
仮に結果がErrだった場合どんな悲劇が想定されるの? >>970
安全なコードを書く事に無関心なら、Rustは使わない方が幸せになる。 それならRustなんかよりPython使った方が絶対良いよな
そりゃGoogleも安全なコードを書くことに完全に無関心で良い試験プロジェクトではPython推しになるわ
>>977
str1有効なデータが入ってなくて後続処理で期待動作が得られない悲劇が起きるんじゃね 型安全を静的解析で絶対的に固定する言語なんてそうそうないよ
PythonどころかCやGo、Swift、Javaだって実行時キャストを許してる(そして、間違ってたらキレる
ボローチェッカーだけじゃなく、そういう型安全に親を殺された子もいるのかもなぁ
>>980
それはそれとして、次スレを立ててくれるか ヘテロジニアスな配列と依存型と継続がほしいぜ。継続は最近のhspにすらあるぜ。
>>931
>電文パーサーで毎回危なっかしいコード書くやつ居るからな。
JSON-RPCとか既存のプロトコルとapi使えなかったの?
rustで書いたらストリームが抽象化されてなくて結構めんどくさいよ。 いまのHSPそんなことになってるのか
継続理解してるレベルの人があの魔改造BASICみたいなの使いたいのか >>988
ラベル型っていうのとラベルを動的に生成して変数に代入して
returnする命令組み合わせるやり方ね。
ラベル型だけだと配列にしてステートマシン書けるくらい。
10年位前からあるけど最近qiitaで記事出てきた。
hsp3系は関数書けるしsmlのモジュールに近いデータ型あって
レコードとタプルがないくらい。
ラベル型でジェネレータとコルーチン実装するくらいのことは
出来るから結構モダンなこと出来るよ。 >>987
昔ながらの電文というのに相応しい()電文送ってくる機械って結構あるんよ。
RS232Cで送ってたまんまのとか。
プリアンブル、データ長、子データ長、子データ区分、孫データ長、孫データ、…子データ長、子データ、ポストアンブル
といったやつ。 ASN.1は標準規格だから使われる場面も多いだろうな。あとBSONもそんなフォーマットだっけ。 >>989
futuresでいいじゃん
言語仕様として第1級オブジェクトに採用したら、今度はまた言語仕様が変わったムキーって言うだろ 互換性保ったまま言語仕様増えることを言語仕様変わったムキーって言ってるのモジラに職を奪われた君だけでは このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 120日 7時間 13分 35秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。