次世代言語24 Go Nim Rust Swift Kotlin TypeScriptat TECH
次世代言語24 Go Nim Rust Swift Kotlin TypeScript - 暇つぶし2ch577:デフォルトの名無しさん
22/04/07 12:20:35.64 pGmXk0tm.net
Rustは順調にhaskell化しているな。
いい傾向だ。

578:デフォルトの名無しさん
22/04/07 12:40:08.52 OdIUq1Z2.net
Rustはプログラミング言語にとって根源的に重要な要素「データ競合やメモリ扱いで安全性が保証される」及び「C言語と同様に最高速&省メモリ」を両立する唯一の言語
新たな言語が出現しないとRust最優位は崩れないのではないか

579:デフォルトの名無しさん
22/04/07 13:09:09.76 a0EStXea.net
Ruby on Rails 7 で、脱Node.js, Webpack, Babel。
IE の死滅により、ES5 へ変換しなくても、ブラウザはES6 のままで動く
WebSocket を使う、Hotwire で、
近年、React に奪われたシェアを回復すべく、
SPA のgame changer を目指すのが、Railsの野望!
Rubyだけで、SPA になったから、React, Vue.js は今後どうなるのか?
Railsが、SPAのシェアを奪えるか

580:デフォルトの名無しさん
22/04/07 13:44:56.72 tEZE72Zs.net
>>564
RustWasmでDOM操作まともにやれるならやってみたいなと思って最近調べてるんだけど、
URLリンク(zenn.dev)
によるとReference Typesを使うとむしろパフォーマンスは下がるらしいし、JSにはまだ到底及ばないらしいんだよね
実際使ってみての感想とか、↑のベンチ取り方おかしいわヴォケとかあったら聞きたいんだけど、どう?

581:デフォルトの名無しさん
22/04/07 14:06:25.86 WjxXuLmC.net
Rustの話は専用スレ立ててそっちでやれよ
ウザイにもほどがある

582:デフォルトの名無しさん
22/04/07 14:34:20.48 86kfLMWB.net
>>578
それはWebのDOM要素とWebAssemblyでのReference Typesの話だろ
Rustなどの特定の言語の話じゃない
それすら理解できないやつが的外れな文句を言うな

583:デフォルトの名無しさん
22/04/07 14:43:19.94 hOTZf/Ps.net
>>578
そんな言論統制したら比較すれの意味がなるなるだろ
Rustの話を禁止したらここはGoの話題だけになりGoがRustに比べてはやってるんの?って勘違いする人がでてくる

584:デフォルトの名無しさん
22/04/07 17:08:40.53 6pGOygc2.net
>>580
実際そうだし何の問題もない。

585:デフォルトの名無しさん
22/04/07 17:13:11.30 uI5WJg3m.net
>>580
Rustは習得が簡単とか大嘘つくやついるしなぁ。
話題にするのはいいけど嘘八百はいかんよ。

586:デフォルトの名無しさん
22/04/07 17:15:20.82 pxHwe1Kf.net
>>582
Rustは簡単やろ
どこが難しい?

587:デフォルトの名無しさん
22/04/07 17:23:30.39 uI5WJg3m.net
>>583
所有権、ライフタイム、moveセマンティック、参照・借用、型システム、その他もろもろの概念を「ほとんど全部使わないと」まともなプログラムができないところ。
だから「C++とHaskellが使えればRustは簡単」とかいうアホなコメントが出てくる。

588:デフォルトの名無しさん
22/04/07 17:57:35.76 +6isarPd.net
>>584
僭越ながら横から失礼しますが、概念の数は学習の難易度とは比例しません。
個別の概念を合わせた結果、目的の用途に合致するようになるかどうかのほうが重要かと思います。
機械語だったら概念の数がRustとGoよりもずっと少なくなると思いますが、機械語を使えばプログラミングしやすくなると思いますか?

589:デフォルトの名無しさん
22/04/07 17:58:57.87 K7k5hu80.net
なるでしょ
文法が少ないからGoは誰でも簡単に使えるのだから

590:デフォルトの名無しさん
22/04/07 18:23:34.25 6J24GmAj.net
>>568
全ての問題が解決すると思ってるのは馬鹿なので相手にしなくて良い
ゼロイチの議論しかしない人もそう
人間誰しも馬鹿な間違いをする可能性があって、間違いを見逃す頻度を大きく下げられることに価値がある

591:デフォルトの名無しさん
22/04/07 18:37:02.12 D5y31O0v.net
>>586
でも両方書ける人はGoよりRustの方がプログラミングしやすいと100%答える現実を見ると
Goは言語機能不足という感じやね

592:デフォルトの名無しさん
22/04/07 18:50:26.86 6pGOygc2.net
>>588
>でも両方書ける人はGoよりRustの方がプログラミングしやすいと100%答える現実を見ると
そんな現実はお前の脳内にしかない。

593:デフォルトの名無しさん
22/04/07 18:56:45.12 wax9VJjI.net
Rustも使いこなせる人でGoの方がプログラミング使いやすいと言う人を見たことないな
こればっかりはGoの貧弱な言語仕様では仕方ないところかと

594:デフォルトの名無しさん
22/04/07 18:56:54.01 pGmXk0tm.net
>>585
「概念の数が増えない段階なら」学習は簡単でしょうな。ADDとかの概念そのものは簡単に学習できる。
ただ、機械語の場合はメモリの位置にも機能&概念があるから、それらを含めると「概念の数が少ない」とは言えない。
あと、
>>584
目的の用途に合致するようになるかどうかのほうが重要かと思います。
というのは学習においては成り立たなくて、「すでに習得した概念 (日常生活なども含む) に沿っているか」の方が重要。
例えばオブジェクト指向はいろいろな概念の集まった複雑な考え方だけど、「対象物を操作する」という日常生活で慣れ親しんだ概念を下敷きにしているから比較的習得しやすい。

595:デフォルトの名無しさん
22/04/07 19:53:12.89 +6isarPd.net
>>591
同意です。
が、私が強調したい部分は、言語仕様が簡略な分、必要最低限の複雑性が代わりに言語以外のところに現れることです。
CPUレジスタの固有機能や命令セットの違いとかもまさにその通りで、言語自体の概念ではないが、目的の用途に取り組む場合に必要なる知識だったします。
RustとGoを学習する場合も勿論、言語を構成する概念だけ、一通り目を通せば終わり、というわけではないですよね?

596:デフォルトの名無しさん
22/04/07 19:53:35.29 48p+VEp6.net
雑魚ウェブプログラマーの俺からするとRustはGoに比べて言語機能がリッチでいいんだが、まだライブラリ(Rustではクレート)が十分に揃ってないように感じるのと、クレートがすごい細かい単位で分割されてるからたくさんクレートを組み合わせて使わないといけないのが難点かな
個人的には早くまともなORMを出してほしい。1番使われてるであろうORMのDieselが非同期に対応してないのは辛いw

597:デフォルトの名無しさん
22/04/07 20:33:59.30 hOTZf/Ps.net
>>593
そうあせるな。JavaだってまともなO/Rマッパーが追加されるまで10年くらいかかってる。
Java
- 1996年 Java 1.0
- 1999年 JavaEE
- 2006年 JavaEEにJPA(O/Rマッパー)追加
 
Rust
- 2015年 Rust1.0

598:デフォルトの名無しさん
22/04/07 20:39:59.88 zb08jYei.net
>>592
そこは>>584で述べた通り、Rustは
「もろもろの概念をほとんど全部使わないとまともなプログラムができない」
というのが学習する上で凶悪な障壁になっている。
例えばPythonなら基本的なメソッド呼び出しから段階的にプログラムを作りながら学習していけるけど、
Rustは関数ひとつ呼び出すにも所有権、スコープ、ライフタイム(RAII)、moveセマンティック、参照・借用あたりの概念を習得しないとそもそもプログラムが作れない。
自動車のマニュアルをいきなり習うようなもので、そりゃ挫折する人間も増えるかと。
まずはオートマで運転に慣れてから限定解除したほうが習得しやすいよね。

599:デフォルトの名無しさん
22/04/07 20:43:09.58 eYC8sBa3.net
25年前からの10年と7年前からの10年を同じく扱いにするなよ。

600:デフォルトの名無しさん
22/04/07 21:06:58.62 /n3eSctb.net
>>587
お前、ホームドアがなかった頃にホームから落ちたことあるか?
俺はないよ。

大都会では用水路に蓋がなく、偶に人が落ちて死んでる。
それらがほぼ暗渠になってるトン菌民とかからすると非難囂々だが、
住んでる連中は蓋がない事に慣れてるし、落ちる事もほぼないので、今後も蓋がされる気配はない。
同様な事はホームドアにも言える。
実際、ホームドアがなかった頃、困った奴はどれくらい居る?
俺は落ちた事も、落ちそうになった事もない。
ホームの端は歩かないというのが鉄則で、
混雑してる場合は何かの拍子で押されて一歩よろめいても問題ない程度の余裕を持って歩く、
それが出来ないなら諦めて人混みの流れに乗る、としてきたからだ。
これは電車通勤してる奴はみんなそうしてるし、実際に殆どの奴は落ちた事がないはず。
落ちるような奴は、そもそも保険も注意も足りてないだけ。
ガードレールがあり、歩道と車道が完全に分離してる道と、そうでない道、どの経路を通るかの選択も同じ。
車が通らない道が一番安全で、次にガードレール付きの歩道がある道、そうじゃない道の順なのは誰でも分かる。
なら、安全な道を選択すれば事故の確率は減らせる。

同じなんだよ。危険性があると分かっているのなら、上位での回避努力は出来る。
それがホームドアがなくても殆どの人が落ちた事がない理由だ。
上位での回避努力をして、さらにチェッカーが付いていれば、さらに事故を減らせる。
しかしRustは、上位の努力をせずにゴリゴリチェッカーだけで安全を確保しようとしてる。
それは俺は違うと思うし、今まで落ちた事もないから、俺にはRust流ホームドアも要らんよ、としか思わない。
(なおホームドア自体は視覚障害者や児童の為に有った方がいいが)
Rustの連中が言ってる安全性は、C/C++で特に困ってない連中には何の魅力もない。
その安全性は多分開発速度の向上に寄与するはずだが、Rustで早くなったって話もないでしょ。

601:デフォルトの名無しさん
22/04/07 21:32


602::17.79 ID:6pGOygc2.net



603:デフォルトの名無しさん
22/04/07 21:32:21.20 +6isarPd.net
>>595
実際は概念一つ一つを念入りに調査せずに、初心者の内はとりあえず思ったまま書いて、
コンパイラに渡してエラーになったら修正するのが普通かと思いますね。
たぶん、人によっては間違ったコードがCIとかでエラーになることを恥と思う気持ちもあるが、些細な問題です。
私もよく、失敗したくないときは、ローカルでコンパイルしてからプッシュするようにしています。
そこは基本的に気持ちの問題ですよね。

604:デフォルトの名無しさん
22/04/07 21:35:29.56 ikFGu1Ah.net
じゃあ動的型付け言語でも問題ないな
自分で気を付ければいいだけなんだから

605:デフォルトの名無しさん
22/04/07 21:38:19.51 +6isarPd.net
>>595
たとえばの話、多くの初心者は再帰関数を使って、スタックオーバーフローを起こして初めて、スタックというものを意識をするわけですが、
それまでは、スタックという概念をまったく気にせずにプログラムを作っていたことも、よくありますよね?
Rustの所有権周りの概念のうち、どれだけこのスタックのアナロジーに当てはまるかは多分人それぞれですが、
少なくとも、所有権の概念を細分化してできた概念の数が、そのまま敷居の高さになることはないと思います。

606:デフォルトの名無しさん
22/04/07 21:41:34.29 bwKax5i+.net
>>597
GAFAMのような大企業はホームから突き落とされるリスクが現実的だからホームドアを必要とするんだよ
ただお前さんのプログラムは攻撃者に狙われるほど広く使われていないというだけ
もちろんそういうマイナーなプログラムに安全性は不要というならそれは自由だけど

607:デフォルトの名無しさん
22/04/07 21:46:07.49 bwKax5i+.net
あと酔っ払ってホームから転落する大人もいるってのもあるな
つまり一流のプログラマでも絶対にミスをしないということはないから機械的にチェックしたいという話

608:デフォルトの名無しさん
22/04/07 21:59:21.50 /n3eSctb.net
>>600
実際俺はJSで特に苦労もしてない。
Rustの信者連中が間違ってるのは、Rust公式勝手訳日本語版まえがき(前スレ990)にある、
> やっかいな落とし穴を回避する術
を学ぼうともしてない事なんだよ。
これを学んでからRustを使えば確かに二重チェックになって意味はあるが、
学ばずに済ませようとするのは間違いだよ。
(とはいえ結果は君らが負うのだから好きにすればいいが)
ホームドアがない時には、端を歩かない、走ったりもしない、というのは鉄則だった。
ホームドアがあるから、走ったりしても安全!というのは明確な間違いだよ。
そんな事をしてる限り、危険予知能力なんて絶対に身に付かないから、
Rust以外の言語だとまともにプログラミング出来なくなるとも思う。
(それも含めて選ぶのもまた自由だけど)

>>602
GAFAM連中は「やっかいな落とし穴を回避する術」を知ってる上でやってるから二重チェックになってて意味がある。
ここのRust信者はこれを知らずに「Rustを使いさえすれば安全!バグ無し!」とか、
一時のHaskell連中と同じ事を言いだしてるから、ただのカルトであり、意味がない。
ただそれはさておき、コンパイラのチェックが厳しければ生産性が向上するはずなのだが、
実際聞いた事ないだろ?
実際には二重チェックとしてしか使われておらず、なければないで済む範囲での使用に留まっているから、
生産性の向上分が見えてこないだけ。
本当にRustじゃないと無理だっていうものがあれば、キラーアプリとしてそれが出てくる。
ないんだから、そういう事。

609:デフォルトの名無しさん
22/04/07 22:07:07.36 gzjYIF1u.net
>>604
やっかいな落とし穴が何に該当するかよくわからないのだけどrustやるならC++での危険回避法を熟知し


610:ておけということ?



611:デフォルトの名無しさん
22/04/07 22:09:45.98 zb08jYei.net
>>599
> 実際は概念一つ一つを念入りに調査せずに、初心者の内はとりあえず思ったまま書いて、
> コンパイラに渡してエラーになったら修正するのが普通かと思いますね。
Rustの場合、初心者がまともに動くプログラムに到達するまでいくつも修正しなきゃいけないのが問題だっつうの。
エンストしまくってたらマニュアル運転の練習もクソも無いわな。
>>601
> たとえばの話、多くの初心者は再帰関数を使って、スタックオーバーフローを起こして初めて、
> スタックというものを意識をするわけですが、
ここからすでに前提が間違っている。
Pythonとかは再帰関数を使用しなくてもプログラムを実装できるけど、
Rustは所有権を使用しなけりゃ変数定義も関数呼び出しもできない。
> 少なくとも、所有権の概念を細分化してできた概念の数が、そのまま敷居の高さになることはないと思います。
ここも間違っている。
細分化して段階的に学習できればまだマシな方で、Rustの場合は所有権の概念をほぼ丸呑みしないとプログラムできない。
クラッチとギアとハンドルを同時に操作しないとマニュアル車を前に進めることもできないようなもんだ。

612:デフォルトの名無しさん
22/04/07 22:32:09.52 /n3eSctb.net
>>605
いやC++に限らず、プログラミング全般で、
そこに危険があれば、どうやったら上位で回避出来るかは、術がある。
これまで何とかやってきてるんだから当たり前だろ。
面倒だから一々言う気もないけど、「データ競合」については前スレで既に書いたとおり、
・メインスレッド+サブスレッドでディスパッチ前に全部解決
で完全に回避出来る。
この構成を採用しているのがC#のGUIで、
どうもお前らは言語に対してのこだわりが過ぎてて、これがC#を褒めてるように聞こえるらしいが、
どの言語であってもこの構成にすれば回避可能で、C#のGUIではそれをフレームワークとして強制してるだけ。
だからC#では、フレームワークを正しく使う気があれば、「術を知らなくても」自然と回避できることになる。
他言語なら、この知識があれば、同様に自前で回避出来るだけ。
Rustの場合はこれをコンパイラのチェックにより同様に「術を知らなくても」回避出来るようにしている。(回避術は異なるが)
その他諸々突っ込んで、「コンパイルが通りさえすればOK」を目指すのも一つの手で、実際そうしてるようだが、
本来それはあくまで「Rustではどういう術を強制する事によって、どの問題を回避している」と認識出来てからやるべき問題。
それを初心者のうちはある程度すっ飛ばしても構わないとは思うが、知らずに済ませるのはどうかと思うよ。
566の(2)のつもりなら特に。
実際にRustが採用している術は、C++でのRAIIとunique_ptrに近いから、
これらを既に常用してたら、グダグダ言われずともRustに移行するだろうよ。
ただ、回避する術は一つじゃないから、違う術を使ってる連中は、Rustを使う事はないだろう。(俺はこちら)
そして本来は、どんな術があるのかを学ぶのが学習で、
元々はデザインパターンもこの方向だったはずだが、何かおかしな事になっちゃって見捨てられた感じになってるが。

613:デフォルトの名無しさん
22/04/07 22:40:48.67 eUNchQrd.net
Rust自体は好きだけどPythonの代替先になるというのは現状個人的には全く考えられないなぁ
単一所有権ベースの書き方が、意識せずとも間違いなく書ける内容なら静的チェックがなくても取り沙汰されないし、それがメリットとしても喧伝されないと思うんだよな
別分野だけど機械学習系だと公式のラッパー先としてまず出てこない言語だし、やっぱ性能とは別の事に頭使いたいジャンルだと不向きだと思うよ
もし広い範囲でPythonの代替になると思ってる人が居るんだとしたら、普段のスクリプティングとかもRustで書いてんのかな

614:デフォルトの名無しさん
22/04/07 22:41:15.91 QfJTmIv3.net
ようしわかった
もうわかった
ついにわかった
言ってほしいんだろ?
そういうことだろ?
Rustはしょうもないクソ言語で未来はないし
GAFAMが使ってるのもそれはそいつらがアホだからだ
ね、これでこの話おしまい
こんなクソ言語だれも使わなくていいからね
心配しなくていいからね
こんなクソ言語消えて�


615:ネくなるから 誰も使わないからね 俺は使うけど



616:デフォルトの名無しさん
22/04/07 22:43:27.27 YR3mJewM.net
いや駄目だ俺が使う

617:デフォルトの名無しさん
22/04/07 23:00:34.39 /n3eSctb.net
>>608
> 単一所有権ベースの書き方
これが演算には絶望的に不向き。ウザイだけ。
ただし鯖等では確かに「上から下に流れる」ように書くので、「単一所有権ベース」でも多分問題なく書ける。
だからまあ、現時点でWeb限定に近いのは、既に住分けてる、とも言える。
他のアプリでも、自前で状態管理するのを極力止めて、内部でRESTfulにすれば、そこそこ行けるはず。

618:デフォルトの名無しさん
22/04/07 23:24:34.67 hOTZf/Ps.net
>>610
ついやいや俺が

619:デフォルトの名無しさん
22/04/07 23:38:47.04 +6isarPd.net
>>606
言いたいことは分かります。
要は学習成果の可視化しにくいインターバルが長いと不利ということですよね?
学習した先に何を求めるかは人それぞれですし、
それって結局、言語機能を部分的にでも成果として、学習者が捉えられるかどうかだけの問題じゃないんですか?
(Rustの所有権を部分的にできるかは平行線なので置いておいて)
案外若い世代はところどころデジタルリテラシーがあるので、
プログラミング学習ができないと危惧して、変にレール敷くような考え方はしなくても良いんじゃないですか?

620:デフォルトの名無しさん
22/04/07 23:51:03.44 eYC8sBa3.net
1ヶ月に一度1ー2時間ほどプログラミングします
といった程度の人達が、あやふやな知識のまま
目的の動くもの素早く作れる言語でないと
広い裾野には訴求しない
ニッチな人のニーズには合致する可能性はあるけど

621:デフォルトの名無しさん
22/04/08 00:23:55.25 PcnkB3on.net
>>607
要はライブラリなど自分が依存するものの中身がどうなっているかはちゃんと把握した上で使えって話と、
自分が困ってないなら無理に道具を変える必要がないって話ね
rustというよりrustを変に持ち上げてる人に対するコメントだった訳ね

622:デフォルトの名無しさん
22/04/08 00:24:56.07 nM4swqos.net
我々の生きているうちにもしそんな素晴らしい汎用言語が出来ると夢が広がりますよね。
未来の言語研究に期待しましょう。

623:デフォルトの名無しさん
22/04/08 00:26:25.71 PcnkB3on.net
>>614
たしかに、次世代言語なんて銘打ったスレに集まるような人向けの言語なんてニッチの最たるものだろうね

624:デフォルトの名無しさん
22/04/08 00:31:27.96 TpfOdACd.net
>>613
>学習した先に何を求めるかは人それぞれですし、
なら、なおさらPythonの代替をRustに求めるのは無理。
まさしく>>608の通り、学習した先に「やっぱ性能とは別の事に頭使いたい」というならRustは不要だわな。
>>609
いやいや、自分もRustは認めているよ? Forthと同じぐらいには。

625:デフォルトの名無しさん
22/04/08 00:47:01.39 nM4swqos.net
>>618
そうですね。別に性能だけの話じゃないと思うが、
いろいろ気にしない人には確かにPythonでプログラミングを勧めるのも一つの手だと思いますね。

626:デフォルトの名無しさん
22/04/08 01:01:29.96 8ljQsUz4.net
Rustに移行するのはC++から来る人が多いだろうな
ptyhon、java,typescript、スクリプト系からは少ないだろう

627:デフォルトの名無しさん
22/04/08 03:06:12.85 Km060/QD.net
>>597
長々と書いてるけど、お前って一人で開発してんの?
なら好きなの使えばいーじゃん。

628:デフォルトの名無しさん
22/04/08 06:34:32.60 z2O+b+J1.net
>>608
Pythonなんて超遅いダメ言語だろ
C/C++に移行すれば10倍くらい速くなるぞ
メモリ使用量も大きく減る

629:デフォルトの名無しさん
22/04/08 07:08:41.73 F6GdhFTs.net
>>622
用途が違うものを比較しても意味ないよ

630:デフォルトの名無しさん
22/04/08 07:36:43.85 5MIkz0s/.net
>>620
JavaScript(


631:Node.js)からRustへ来たけど特に難しいところは無かったよ JavaScriptでPromise返す並行プログラミングしていたから RustでFuture返す並行プログラミングにすぐ移行できた



632:デフォルトの名無しさん
22/04/08 07:50:10.89 aDtoFpcQ.net
RubyやPHPからRustに来る人はゼロではないだろうけど少ないだろ
それぐらいなぜ認めたくないのか?
用途が違う

633:デフォルトの名無しさん
22/04/08 07:51:28.36 3RXqham9.net
みんな色々と考えるんたな。
自分の使う言語を選んで仕事始める人が多いのか?

634:デフォルトの名無しさん
22/04/08 07:54:38.16 atDB72kn.net
>>625
RubyからRustへも多いよ
例えばこのスレでも>>510へのレス状況から少なくとも3名は居る

635:デフォルトの名無しさん
22/04/08 08:00:35.35 aDtoFpcQ.net
病気なのか?

636:デフォルトの名無しさん
22/04/08 08:08:54.70 jLbA7OdY.net
俺がスクリプト言語からRustも使うようになった理由はスクリプト言語っぽく書けて便利で速いから
今後もそういう人が増えるのは間違いない

637:デフォルトの名無しさん
22/04/08 08:15:42.34 CQiu8f2R.net
>>629
完全に同意

638:デフォルトの名無しさん
22/04/08 08:22:48.61 G9TYKjMP.net
ぼくも(^o^)

639:デフォルトの名無しさん
22/04/08 08:38:19.52 16DK1NKj.net
>>626
逆よ
仕事を選ぶと言語が決まることがほとんど

640:デフォルトの名無しさん
22/04/08 09:31:00.03 gFm4wviN.net
>>629
設定に無理があるwテキトーなパースするだけにrustなんか絶対に使わねーよ。

641:デフォルトの名無しさん
22/04/08 09:55:16.26 ncPbKyCt.net
>>633
自分もRustを使っているけどRustで特に困っていることないぜ

642:デフォルトの名無しさん
22/04/08 11:02:37.27 wv8X5M3X.net
>>634
そらRustしか知らなきゃそうなるよ
もっと勉強した方がいいよ

643:デフォルトの名無しさん
22/04/08 11:18:15.72 J3x148PI.net
C/C++/Python/Java/Scala/Goあたりは仕事で書いてたけど今はRustメインだな
他にどの言語を学べばRust使う気がなくなるの?

644:デフォルトの名無しさん
22/04/08 11:29:00.59 CQiu8f2R.net
なんだこのビッグウェーブはw
Rustってとてつもない一大ムーブメントなのか?w

645:デフォルトの名無しさん
22/04/08 11:59:33.01 xydoIMfT.net
>>635
スクリプト言語とRustしか使っていないのですが何を勉強するとよいですか?
速さが必要なものと大きなものはRustを使っています。

646:デフォルトの名無しさん
22/04/08 12:29:19.18 lZxU7PE0.net
>>636
FORTHおすすめ。

647:デフォルトの名無しさん
22/04/08 12:33:53.85 gfZaFbSj.net
テキトーにパースするでもserdeが楽だから使うわ

648:デフォルトの名無しさん
22/04/08 12:50:21.80 uV0lTSE5.net
FORTHやるくらいならLISPやる

649:デフォルトの名無しさん
22/04/08 13:30:54.85 LwBnqH/T.net
Ruby 界隈では、mruby の本が出た。Ubuntu 18.04, C99 対応。
Webで使えるmrubyシステムプログラミング入門、近藤宇智朗、2020/11
Elixir の本も出た。
Ruby on Rails の本を書いている、黒田努の本
Rust は、Rubyと同様の式ベース言語で、Elixirと同様のパターンマッチ
ただ、YouTube で有名な、雑食系エンジニア・KENTA が、
バックエンドのキャリアパスは、Rails → Go のみと断言している!
Elixir, Rustは普及のキャズムを超えなかったから

650:デフォルトの名無しさん
22/04/08 13:52:24.78 VBKiPB4k.net
Goで出来ていることがRustでも容易に出来るようになったことが大きい
そしてRustの方が高速かつ適用範囲も広い

651:デフォルトの名無しさん
22/04/08 13:58:37.76 ueuwLW+z.net
>>615
違うぞ。
つか話が通じないのは全然立ち位置が違うからだが、ここを詰める意味はないので終わりにしたいのだが。
> 自分が依存するものの中身がどうなっているかはちゃんと把握した上で使え
理想的にはそうだが、現実的には無理だし、やる意味もない。
例えば数学関数、sin(x)とかも様々な実装方法はあるが、十分な速度と精度が出れば何でもよく、
sin(x)自体を導出する数学の知識(級数展開)なんて必要ないだろ。
ライブラリにしてもフレームワークにしても、基本的には外面仕様まで抑えればよく、内部まで知る必要はないんだよ。
実際、鯖やJSを書いてる奴等も、ブラウザの実装なんて知る必要ないし、知らないだろ。
ただしそれらの優劣を問う場合、内部実装まで掘り下げないと比較にならないだろ。
「データ競合」について言えば、C#とRustのアプローチは明確に異なるわけだが、
この「異なる」という事を認識し、それぞれの利点と欠点を把握してないと、正しい比較にはならないだろ。
Rust信者は「Rustにすれば僕がどんなに馬鹿でも無知でも全て解決してくれる」と思っているようだが、
これだと比較検討する技術レベルには達してないんだよ。
ただ、「データ競合」については確かにRustにお任せでも回避出来るのだろうし、これ自体が悪い方法でもない。
(一つか、下手すると一つも方法を知らない癖に何故比較検討出来てるつもりなのか?という話)
> 自分が困ってないなら無理に道具を変える必要がない
これも違ってて、だいたい人は困ってる事を認識出来てないものなんだよ。
携帯が無い時代に携帯が無くて困ってた奴は居なかったし、
スマホが無い時代にスマホが無くて困ってた奴も居なかったし、
Rustが無い時代にRustが無くて困ってた奴も居なかった。
だから新しい物を持ってくる場合、「実はあなたはここに困っていたのですが、気づけていません。
Rustを使えばこう出来ます。一度使えば二度と戻れませんよ」と具体例を示さねばならないのだが、
これがないだろ、という話だよ。(納得する物が有れば単に乗り換えれば済むだけ)

652:デフォルトの名無しさん
22/04/08 13:59:03.07 ueuwLW+z.net
RustはC++の特定のスタイルを強制してそれ以外をコンパイルエラーにするように出来てる。
だからそのスタイルを使いたい奴には超フィットするけど、
そうじゃない奴には使えない。(コンパイルエラーになるだけ)
だからやっぱりこの「エラー」ってのは強すぎてて、
> C++での危険回避法を熟知しておけ
これもちょっと違ってくる。
「Rustが採用している『術』」での危険回避をしたいのなら、
それ以外をエラーにしてくれるRustが最適で、同じ事をわざわざC++でやっても抜けを許容される分だけゴミ。
ただ問題は、Rustの場合はそれ以外を許容しないから、いつまで経っても「Rustが採用した『術』」以外の方法を学ぶ事が出来ない。
だって試そうとしてもエラーになるのだから。
だから「Rustが採用している『術』」が間違っていたら(不適切だったら)その時点で終わってしまう。
だからこそ、無駄にカルト化する。言語と心中する事しか許容しないので。
本来は、「Rustが採用した『術』」と「他の方法」を知ってて、長短見極めた上で、
Rustでの採否に納得した奴がRustを使うべきなのだが、
君らは「他の方法」を知らずに「Rustが採用した『術』」をマンセーしてるだけでしょ。それはカルトだよ。
ただし「Rustが採用した『術』」はそんなに悪いものでもないし、
コーディング戦略は大きい単位で適用した方が効率がいいのも事実。
最大単位は「言語」なので、実験としてはいいし、
Rustが無くともC++で同じ事をやってた連中にとっては天国だろう。
だからやたらマンセーしたがる奴が居てもおかしくない。
(ただし実は最上位の「プログラミング全般」という単位があり、
例えば「用意した変数はそれ以降で自由に使える」とかだが、Rustはこれに反しているので混乱も来す事となっている)

653:デフォルトの名無しさん
22/04/08 13:59:38.12 ueuwLW+z.net
長期的展望については、構成上、Rustは(育成含めての)独立したエコシステムを持ててない事がかなりポイントになる。
これはやはりホームドアが分かりやすいと思うが、これがなかった頃、まともな大人は、
・ホームの端は歩かない
・ホーム上では走ったりしない
・ふらつく程は飲まない
等を遵守して、ホームからの転落事故はほぼ0に出来てた。
Rustはこれにホームドアをさらに設


654:置し、物理的に転落しないようにした。 結果、「大人の常識の遵守」「ホームドア」で二重のセキュリティになり、安心感は増してる。 とはいえ、ほぼ精神的なものであり、実際は無くても転落する奴はほぼ居なかったので、実質的意味はほぼ無い。 これが、キラーアプリが存在出来てない理由。(GAFAMはこの使い方) さてここで、「俺はホームドアがない駅なんて知らねえ。老害の常識なんて糞食らえ」というゆとりがいて、 ただの10分間の休み時間でもドッチボールをしようとしてた小学生時代と同様、 駅で10分待つ間にも鬼ごっこ等で遊ぼうとしたとする。 一般社会では「これだからゆとりは」となって袋だたきなのは確実だが、プログラミング界隈では違う。 ・端を歩ける→デッドスペースだった両端の1mを活用出来、輸送能力が10-20%程増す ・走らない縛り無し→ならホームの両端はスカッシュコートに出来るじゃん! ・へべれけでも大丈夫→なら通勤電車内にバーを設置し、1時間飲んでたら家に着いてるとか出来るじゃん! 等、利便性を提供出来れば良しとされる。 俺が「Rustによって新たに提供される価値とは何か?」とさんざん聞いてたのはこれなんだよ。 Rust流のホームドアが無かった頃は事実上無理だった事も何か出来るようになってるはず。 その活用事例は何か、なんだよ。



655:デフォルトの名無しさん
22/04/08 14:00:07.89 ueuwLW+z.net
ただしこれは両刃の剣で、ホームドアがある前提で、それ以前の「大人の常識」を「所詮は老害の戯言」と切り捨てると、
ホームドアがない駅では確実に事故りまくる。今のRustがこれで、既に書いたが、
・「Rustが採用した『術』」以外はエラーにする=Rustではそれ以前の「大人の常識」を試せないし、学べない
んだよ。だから、構成として
・既に大人の常識がある人が、さらにホームドアが設置された駅を使う(GAFAM)
用に出来てて、
・全く何も知らない幼児が、怪我をしながらも危険を学び、次第に大人になっていく(Rust信者)
用には出来てない。(つまりRustだけではプログラマを成長させる事は出来ない)
とはいえ、現実の今時の公園ではブランコすら撤去されてる始末で、
安全重視の、スリルの欠片もなく面白みもない遊具だけになってしまってるが、
ではこれが間違ってるかと言われれば、
昭和時代のヤベー遊具は確かに楽しかったが、でも確かに危なかったし、なんだかなあ、ではある。
つまり、自前での育成(≒プログラマによる試行錯誤)を放棄している点に置いて、Rustが目指している所は、
・Rust専用コーディングドカタ育成
・他言語で育成されたプログラマの取り込み
であって、Rustではプログラミングの世界を成長させる事は出来ないし、プログラマの自主的な成長も促せない。
Rustが出来るのは、やり方を画一的に固定した開発だけだ。
ただこれが悪いわけでもない。実際、フレームワークは同様だし。
だからまあ、立ち位置としては「言語」よりも「フレームワーク」と考えるべきなのだろう。
そうすれば、「Rustに合ってる状況ならRust使え」で、みんな非常に納得出来るだろうし。
ポリシーに合致してないコードを拒絶する点に於いても、フレームワークと同様だし。
(C#の場合にデタラメなコードを食わせてイキってる馬鹿もこのスレには居たが、
この点Rustならエラーなのでフレームワークとしても正しい)

656:デフォルトの名無しさん
22/04/08 14:05:58.17 xmDi13Bx.net
Rustのプログラミングの快適さは
様々なプログラミングパラダイムを巧みに洗練して採り入れているところにあると思う
一つ一つは既存の言語にあるものが多いけど総合的に組み合わされたのはRust特有でそれが�


657:Rーディングのしやすさに繋がっている



658:デフォルトの名無しさん
22/04/08 14:45:33.12 wv8X5M3X.net
昼間から長文とかおじちゃんたち仕事は??

659:デフォルトの名無しさん
22/04/08 14:49:38.98 J+DLQw6K.net
「Javaスクールの危険」みたいな話になってきてるな
URLリンク(web.archive.org)URLリンク(local.joelonsoftware.com)

660:デフォルトの名無しさん
22/04/08 14:54:51.52 zi4mesOO.net
一方でRustは色んなことが身につくからその問題点もないよな

661:デフォルトの名無しさん
22/04/08 14:56:47.94 CQiu8f2R.net
>>650
再起とポインタなんて知らなくてもWebプログラマーはつとまるんだよ
ましてや精神的態度なんて根性論いいだしたら人材不足の今、人なんて集められないよ

662:デフォルトの名無しさん
22/04/08 14:58:59.00 CQiu8f2R.net
>>650は下の(2)の人のことをいってるんであってこのスレにいる大多数の(1)の人たちには関係がないこと。
ーーーーーーー
プログラマーには2種類の人がいる。
自動車産業に例えたら、(1)地方の工場勤務の期間工と(2)研究開発センターのエンジニア
(1)はRustは使用しなくていい。というか理解できなくて使えない。Pythonとかで頭を使わないコード書くだけだから。例えるなら、ラインで組み立て作業を1日延々しているだけのルーチンワーク要員。
(2)はRustなどを使用してシステムプロラミングWebassemblyなどでローレイヤーや基盤を作っていく。例えるなら自動車のエンジンやデザインの設計者。

663:デフォルトの名無しさん
22/04/08 15:07:49.60 Js+ybEIJ.net
自分はCS出てフルスタックやってるから他の立場のことはわからないが
色々やってきた言語の中でRustが最も開発効率良いと断言できる

664:デフォルトの名無しさん
22/04/08 15:13:55.24 FJuOSvU4.net
rustとgoが合体したらいいのになあ

665:デフォルトの名無しさん
22/04/08 15:30:55.82 fiUiUlD4.net
なんか一部のrust推しがすごいっすね

666:デフォルトの名無しさん
22/04/08 16:23:35.95 UBiXicJa.net
>>655
V言語

667:デフォルトの名無しさん
22/04/08 16:57:15.66 PcnkB3on.net
>>656
rust推しだけど変な人が無理筋の推し方してて困ってる

668:デフォルトの名無しさん
22/04/08 17:09:14.19 a6HBTm5x.net
頭の悪い子に限って延々演説するよなw
お前らそれを完全スルーしてて賢いわw

669:デフォルトの名無しさん
22/04/08 17:14:34.86 BG4ZrdKI.net
>>657
Vは確かに最初の宣伝はそんな感じだっけど、現状はRustとGoを足して10で割ったくらいの状態だからなぁ

670:デフォルトの名無しさん
22/04/08 17:54:29.26 0JDStoXf.net
V言語はマクロがないとかクロージャがないとか
あと安定しないままだよね

671:デフォルトの名無しさん
22/04/08 18:14:16.72 CQiu8f2R.net
>>659
スルーというかNGWordに正規表現で
.{50}
としてるからまったく気づかない

672:デフォルトの名無しさん
22/04/08 18:59:02.09 wv8X5M3X.net
>>652
そうして集めたPHPerたちが作ったWebシステムはどうなりましたか

673:デフォルトの名無しさん
22/04/08 19:35:51.32 gFm4wviN.net
>>663
facebookって言って超メジャーなサービスになってるよ。

674:デフォルトの名無しさん
22/04/08 19:40:32.31 wv8X5M3X.net
>>664
facebookのPHPエンジニアが優秀=PHPエンジニアが優秀
という短絡思考には感服致します
障害者学級PHPoorたちの心のより所なんですね

675:デフォルトの名無しさん
22/04/08 19:54:22.21 haRe9nr5.net
このスレだけ見てるとPHPerよりRusterのほうが危険で頭がおかしいと思ってしまう…
実際はそんな�


676:アとはないかもしれないが



677:デフォルトの名無しさん
22/04/08 19:58:36.19 gFm4wviN.net
>>664
え、どうなったか聞かれたから答えたらなぜかPHPともどもボロクソ言われるの、
意味がわからんのだが。

678:デフォルトの名無しさん
22/04/08 20:05:37.41 g/vqQJB9.net
>>654
「unsafeに触らない限りは」だろ。
実際にはフレームワークとかライブラリとかが充実している言語のほうが開発効率は高い。
(すでに開発済みだからという理由だけど)

679:デフォルトの名無しさん
22/04/08 20:09:42.84 nC7N6zb/.net
Rustは欲しいcrateほど放置されてるcrateやwipの空crateが一定数あるのが実用を考えた時に厳しい
RustのWinUI3対応早く来ないかなー
後別に何でもかんでも関数型になって欲しい訳でもないんだけど、スクリプト的な簡単に書きたいモチベーションのある言語に、関数のデフォルトのカリー化と、引数を渡すのと同じ記法での部分適用が導入されて欲しい
個人的に見た目がスッキリするし書くのが楽に感じるので
Fsharp使えというのはそうかもしれない

680:デフォルトの名無しさん
22/04/08 20:31:38.25 wv8X5M3X.net
>>667
元レス読めよ文盲
これだからPHPoorは
さっさと氏ねゴミカス

681:デフォルトの名無しさん
22/04/08 20:39:12.10 IqLRftxA.net
>>668
それはプログラミング言語の問題ではないな
純粋にプログラミング言語の比較でRustより上のものを挙げないと

682:デフォルトの名無しさん
22/04/08 20:39:56.09 haRe9nr5.net
webの世界を支えてるのはPHP

683:デフォルトの名無しさん
22/04/08 20:42:20.02 haRe9nr5.net
>>671
使いやすさから言えばjavaやc#のほうが上だと思う
Rustは使いどころがまだ確立されていない

684:デフォルトの名無しさん
22/04/08 20:48:04.21 4vP7lCV8.net
>>671
なら「標準ライブラリが充実している」でいいよ。
標準ライブラリが言語に含まれないとは言わんよな?

685:デフォルトの名無しさん
22/04/08 20:50:18.47 MnFLToWU.net
>>669
ところでカリー化はラムダではあかんの?

686:デフォルトの名無しさん
22/04/08 20:53:57.99 nx5fqsfT.net
>>673
そこはさすがに誰が見ても
Rust>Javaはあらゆる面から全員一致として
Rust>C#もほとんどの人が同意でしょ

687:デフォルトの名無しさん
22/04/08 21:15:04.96 hRiSi6np.net
>>676
それは過大評価し過ぎでは…

688:デフォルトの名無しさん
22/04/08 21:31:56.88 Br+emjPa.net
言語自体の比較だと現状ではRustが一番かもしれん
新言語が現れなければじわじわと利用環境や利用者を拡大していくのだろう

689:デフォルトの名無しさん
22/04/08 21:33:57.02 a6HBTm5x.net
>>669
> 後別に何でもかんでも関数型になって欲しい訳でもないんだけど
リストのリテラルが無いあたりで割り切りを感じるよな
あくまで軸足は関数型言語にはないという
リストの結合とかカリー化や関数結合もデフォで組み込まれてたら
もっと違う感じだったやろねえ

690:デフォルトの名無しさん
22/04/08 22:02:06.45 GQWBx4Yt.net
ガベージ出まくるからゼロコスト抽象にならない問題点などあるよな
見かけはマクロでわかりやすくする程度が現実解
まあ普通のGC言語でもサポートしてないのが多い中
そこまで必要とされていない機能なのかもしれん

691:デフォルトの名無しさん
22/04/08 22:13:42.74 haRe9nr5.net
なんでIDコロコロ支店の?

692:デフォルトの名無しさん
22/04/08 22:23:42.64 wv8X5M3X.net
いきなりコロしとか言い出すとかマジやべえな

693:デフォルトの名無しさん
22/04/08 23:37:25.21 nC7N6zb/.net
>>675
処理として等価なものが書けるという意味では問題ないよ
それよりもっと簡単に書けるようになるので、あると嬉しいなって

694:デフォルトの名無しさん
22/04/08 23:52:45.49 fiUiUlD4.net
rust推しに狂気を感じるスレ

695:デフォルトの名無しさん
22/04/09 00:07:03.26 il24SwZF.net
それしか言えんのか

696:デフォルトの名無しさん
22/04/09 00:20:56.02 qlihBLS+.net
>>650
似てはいる。
「JavaではCS学生には過�


697:ロ護すぎ」が趣旨だと思うが、 同様にRustを考えるなら ・修得概念は多いがこれは暗記の類であり、チャレンジではない ・コンパイラ頼みで考える事を放棄してるから、成長しない で、アカデミックには不適だ。 大学なんて就職予備校だと割り切るならありだが。 Goなら、 ・修得概念は少なく抑えられている ・構成自体は何でも出来る(はず、多分) ・やたらコピペさせられる点が糞 であって、教育/アカデミックには向いてる。(少なくともRustよりはいい) 「データ競合」「デッドロック」等のバグをコンパイラに頼って回避してる限り、 コンパイラがサポートしてくれない状況では確実にやらかす。 コンパイラのサポート無しでも回避出来る腕だが、さらにコンパイラでダブルチェックする、が正しい。 フレームワークなんて暗記の類で、ちゃんとプログラミングが出来る奴なら、使えば使えるようになってる。 フレームワークは生産性を上げる為の手段であり、 プロダクトを目指さなくてもいい学生の時点で型に嵌めてしまうのは成長を阻害する気がする。Rustがこれ。 (他言語でもフレームワークを使って課題製作して出来たつもりになってるのなら同様ではあるが、 既に書いたようにRustの場合は言語自体がフレームワーク化してるので、これを回避出来ないのが難点)



698:デフォルトの名無しさん
22/04/09 01:45:47.90 H+Mv/KjD.net
コンパイラのチェックが厳しい→コンパイラに頼る→学習にならない
もう言語の利点を語るんじゃなくて、学習に向いてるかどうかってことに話を絞ることでRust批判につなげることにしたのね

699:デフォルトの名無しさん
22/04/09 01:58:00.79 il24SwZF.net
暗記ごときでボローチェッカーに対処できるなら自他ともに認めるRustの学習曲線の問題は発生しないんだよなあ

700:デフォルトの名無しさん
22/04/09 02:01:36.12 il24SwZF.net
あとデッドロックは別にRustで静的に防止できる類のバグではないぞ
メモリリークと同様だね

701:デフォルトの名無しさん
22/04/09 02:15:58.74 eXc0QQCs.net
言語として魅力を感じるのはGoよりRustだが、将来的にGoよりシェアを拡げるかと言われたら疑問

702:デフォルトの名無しさん
22/04/09 02:26:41.71 730EZC4A.net
Rustはシステムプログラミングの分野でだけちゃんと生き残れば大成功だよ
あとは特にハイパフォーマンスや低コストが要求されるとこくらいか
ほとんどのアプリケーションでは、JavaやらPythonやらなりの高水準言語にて、より適す言語が見つかるやろ

703:デフォルトの名無しさん
22/04/09 03:28:08.67 iJevktt3.net
>>691
Javaの諸々の弱点を克服したものがRustであるため
従来Javaで書かれていた分野にRustが食い込んで行きつつあります

704:デフォルトの名無しさん
22/04/09 03:34:37.18 ntDYOunj.net
ツルツル無毛の奇麗な一本筋なんだろうね

705:デフォルトの名無しさん
22/04/09 04:14:38.03 0HVqg1ER.net
FacebookがバックエンドをJavaからRustにした記事でJavaの問題点が多数挙げられていたな

706:デフォルトの名無しさん
22/04/09 05:55:15.91 GQoYu9QH.net
他部分の結論がまだ早いが、環境的な点から考えて、
GoはJavaとPythonと比べて、教育言語として価値が高いことは今のところない
・良くも悪くもOOPではない。抽象化のレクチャの定番が崩れている
・コンベンション重視のせいで、文化風土が専制的
(たとえばインデントは実質タブしか。手法にフレームワークを当てはめがち。考える余地を与えない)
・C言語の代わりにはならず、高級言語として教えるにもポインタの概念が余計
・例外処理/リソース管理/並行処理あたりの重要ポイントの対応方法が独創的で潰しが効かない
以上、拡大解釈せずにあくまで業界最適化言語と


707:考えるのが無難という意見だ



708:デフォルトの名無しさん
22/04/09 06:21:18.57 Qew3WBrk.net
>>695
そのGo批判は間違っている
OOPはclassが無いだけだろ
例外処理もtry-catchが無いだけだろ
GoもRustもどちらもclassやtry-catchは無いが異なる方法を取っているだけにすぎない
言語毎に様々な形態がある部分を取り上げて批判するあなたの視野が狭く偏見を持っているだけにみえる

709:デフォルトの名無しさん
22/04/09 07:21:22.99 qlihBLS+.net
>>695-696
それは教育目的を明確にしておかないと空回りする。単純には以下となる。
・実務: 大学は就職予備校である
・養成: 大学は人材養成所である
・アカデミック: その分野の発展を目指す
695は実務寄りの意見だ。
ただ、実務なら議論するまでもなく現在のシェア、または求人のシェア通りにやるべきであって、
それ以外を選ぶのは教授の趣味でありエゴでしかない。
今ならPython/Java/JavaScript/C#/C++/C/PHP/Rubyの順かと。
650記事と696(と686内俺のGoへの意見)は養成寄りで、人材の底上げを目指したものだ。
> ポインタを使うプログラミングは今日書かれるコードの90%には必要とならず、製品コードにおいてははなはだ危険なものであるということは素直に認める。
> その通りだ。そして関数プログラミングは実務ではほとんど使われていない。それも認める。
> しかしそれでも、最もエキサイティングなプログラミング仕事ではこれらは重要なものなのだ。
> たとえばポインタなしにLinuxカーネルで作業することはできない。
> Linuxのコードを1行も理解することはできず、実際ポインタの理解なしにはどんなオペレーティングシステムのコードも理解できない。
つまりはプログラミングドリルに何を用いるかで、プロダクトを目指したものではない。
だから界隈の文化なんて全部無視でよく、単に、学生の頭の体操/訓練に何が適しているかだ。
この場合、スタート時から色々概念が必要なRustは最悪で、仕様は軽ければ軽い程良く、
早い段階で「仕様とか概念に苦労せず」学生が自在に「こねくり回せる」必要がある。
こねくり回す時の苦労が養成になるので、そこは頑張って苦労しろ、というわけだ。
この用途なら、Goも悪い選択ではない。
が、まあ、素直にCを選択する方が妥当ではあるが。

710:デフォルトの名無しさん
22/04/09 08:15:54.24 yjPUnyR6.net
最初はC → Rustが王道だろうな
さすがにCのままだけでは効率悪すぎる

711:デフォルトの名無しさん
22/04/09 08:16:17.09 cvyLC6WE.net
GoもRustもclassはない
でも実質似たようなことはできる
でも実質は実質であり素直にOOPできるかと言えばそうでもなく変な制約がある
ファイル分割とかしたいとか思わないならその限りではない

712:デフォルトの名無しさん
22/04/09 08:17:47.26 ehpYMGIZ.net
goはある意味goroutineとchannelを使うための言語だしな。そこに価値を見出す人が使えばいいこと。
ただまぁ、独創的だから潰しがきかないとか批判しだしたらpythonも癖が強すぎてたいがいだがな。
結局普及したもの勝ち。

713:デフォルトの名無しさん
22/04/09 08:24:05.70 cvyLC6WE.net
>>698
目的に応じて言語を選んだほうがいい
C→Rustは狭すぎるし心に余裕がなくなるし楽しくない
標準的なGUIもないから入門には不向き
個人的には間にGC言語やPython挟んだほうがいいと思うよ

714:デフォルトの名無しさん
22/04/09 08:54:42.92 0xXBKlCN.net
>>701
PythonよりはRustの方がええやろ
Pythonは偏り過ぎ

715:デフォルトの名無しさん
22/04/09 08:56:00.27 LAfniSDw.net
バランスいい言語ないの(´・ω・`)

716:デフォルトの名無しさん
22/04/09 09:09:13.58 ehpYMGIZ.net
個人的にはswiftがそこそこモダンな機能を一通り備えていながら癖の強くない文法でバランスがいい言語だと思うけど、
Apple依存というところが最大のネック。

717:デフォルトの名無しさん
22/04/09 09:09:29.66 H+Mv/KjD.net
ないです
RustのGUIクレートってどれがいいんだろ

718:デフォルトの名無しさん
22/04/09 09:33:25.59 cvyLC6WE.net
コンパイラチェックが厳しいで思い出した
全然関係ないけど自分は麻雀が打てない
ゲームではできる
自分では上がりだと思ってても実際は上がれなかったりする
結局ゲームで判定してもらってる
どこが悪いのかは自分で分かっていない
コンパイラのチェックでは原因が出るのでどこが間違ってるのかはわかる

719:デフォルトの名無しさん
22/04/09 09:43:27.34 7NJqkFJL.net
Rustのコンパイラはどの部分とどの部分がどういう問題となっていて今回のエラーとなっているのかを
複雑なケースでも丁寧に教えてくれて学習効果も高いですね

720:デフォルトの名無しさん
22/04/09 10:38:03.26 ALVqghU/.net
結局 c -> c++ -> rust って感じに進まないと理解できないと思うがな。
いきなり c -> rust で何をやってるか理解できるとはとても思えん。
この種のことをrust信者はすぐ誤魔化す。

721:デフォルトの名無しさん
22/04/09 10:45:26.66 n9UcTFQC.net
>>708
どのあたりが理解できないと思う?

722:デフォルトの名無しさん
22/04/09 10:47:43.60 3YobdmGS.net
>>708
そこは完全に逆
C++は学ぶ必要なし
今となっては何の価値もない言語
C++を学んでも回り道をしている無駄なunique_ptrくらいしかRustのために役に立つ知識がない

723:デフォルトの名無しさん
22/04/09 10:53:42.52 EFTB/rfv.net
>>708
自分はそのルートだったけどC++を経由する必要はどうかなぁ
現代のC++をマスターするのはRust以上に難しいし、初心者が自分でどこまで学べばいいかを判断するのも難しそう
まぁ結局我々は初心者ではないので推測で言ってもあまり意味はないけど

724:デフォルトの名無しさん
22/04/09 11:02:06.42 SpxMIjuY.net
要するにマロックだろ?

725:デフォルトの名無しさん
22/04/09 11:11:18.68 UvtYS0nS.net
単刀直入に言うと
実はC++とRustには共通点が非常に少ない
特にC言語との共通点を除くとほとんど残らない
だから学ぶべきはC→Rustが正解

726:デフォルトの名無しさん
22/04/09 11:38:59.26 P+77Yson.net
>713
>実はC++とRustには共通点が非常に少ない
そういう嘘をつくからRust信者はクソ言われるんだよ。
Rustの根幹をなすメモリ安全性はC++のRAII/unique_ptrから着想を得た所有権/ムーブセマンティクスの運用を徹底することによって実現しているし、
Rc/ArcもC++のshared_ptrの機能を強化しているだけ。
引数渡しをムーブセマンティクスデフォルトにするという致命的ミスをしているからC++と別物のように見えるけど、
C++ユーザーからすればC++を少し洗練させたぐらいにしか見えない。
その実体を知りながら「共通点が非常に少ない 」とか言うのは詐欺師ぐらいなものだ。

727:デフォルトの名無しさん
22/04/09 11:49:01.58 0K2sKttC.net
C++に着想を得ているのはそうだと思うけど、歴史通りの順番で学ぶ必要ある?
(その理屈だと最初はパンチカードからかな…)
C++の後付したわかりにくいmoveを学ぶより、最初から洗練された方を学んだほうがいいと思うけど

728:デフォルトの名無しさん
22/04/09 11:53:43.59 EFTB/rfv.net
C++の歴史を追っていくみたいなのは、言語設計的にはすごく学びがあって、好きな人にはおすすめなんだけど
ただプログラミングがしたい人におすすめできるかというと…

729:デフォルトの名無しさん
22/04/09 11:55:25.64 cvyLC6WE.net
現実的にはPythton or Java or C# → C  → Rustかな

730:デフォルトの名無しさん
22/04/09 12:00:59.18 LZU2nudI.net
最近のC++はなんとRustの後追いをしている状況
例えばRustの中核となっている enum OptionとResult そして Iterator
Optionは C++では std::optionalで これはC++17でようやく導入された
Resultは C++では std::expectedで これは現在導入に向けて審議中
Iteratorは C++では std::rangesで これはC++20でようやく導入された
このようにRustでの成功を見てC++が後から導入となっている
最近導入されたばかりなのでC++入門書や解説サイトにはもちろん出てこない
【結論】C++は学ぶ必要なし

731:デフォルトの名無しさん
22/04/09 12:05:05.94 cvyLC6WE.net
C++は無駄に増改築を繰り返された老舗旅館
通路の途中で無駄に段があったり渡り廊下があったり
HPに書いてある現代風の部屋に泊まれる場合もあるけど古い部屋に泊まることもある

732:デフォルトの名無しさん
22/04/09 12:09:41.54 EFTB/rfv.net
C++98ならそんな増築感はなかったけど、そこまで戻るとRustとの共通点もほとんどなくなっちゃうしなぁ

733:デフォルトの名無しさん
22/04/09 12:15:44.17 ehpYMGIZ.net
RAIIとテンプレートメタプログラミングが発見されてから独特の進化を始めたな。

734:デフォルトの名無しさん
22/04/09 12:16:15.06 cvyLC6WE.net
>>718
>>720
新しい部分を指してC++を学ぶべきと言ってるのではないと思うよ
それまでのC++からC++11 以降の新しい流れをみるんだろ
C++で何が都合が悪かったか判る

735:デフォルトの名無しさん
22/04/09 12:19:37.41 EFTB/rfv.net
>>722
それって歴史を知っている我々には分かるけど初心者に分かる?

736:デフォルトの名無しさん
22/04/09 12:24:26.93 cvyLC6WE.net
>>723
自分はC++を学ぶべきとは思ってないけど何が都合が悪いのか体験したらいいということだろうと推測
初心者にわかるかどうかは知らない
初心者にはjava C# Pythonを勧める

737:デフォルトの名無しさん
22/04/09 12:26:21.53 2dOqhr+x.net
C++の増改築を学ぶのはムダな枝も多くて学ばないほうがいい
RustはC++含めた様々な言語から色々採り入れているけど
洗練して整合性あるようコンパクトに採り入れてるからシンプル

738:デフォルトの名無しさん
22/04/09 12:36:22.62 HmFS1ypI.net
>>694
URLキボン

739:デフォルトの名無しさん
22/04/09 12:42:40.46 cvyLC6WE.net
フレンド関数とか学んでも使いどころなどない

740:デフォルトの名無しさん
22/04/09 12:44:13.05 qlihBLS+.net
>>706
> どこが悪いのかは自分で分かっていない
Rustで作ったゲームなら、フリテンですor役がありません、と親切に教えてくれるよ
と信者の代わりに突っ込んでみる

741:デフォルトの名無しさん
22/04/09 12:51:14.42 byaB+Tw8.net
Rustのコンパイラは賢い先生みたいなもので不十分なところを的確に適切に指導してくれる
昔Rustは学習難易度高いと言われていたためコンパイルエラーに最も力を入れたプログラミング言語へと成長した

742:デフォルトの名無しさん
22/04/09 12:52:42.79 lI/OjvKQ.net
レス番がとびとびなんだがそんなに長文書き込んでるやついるの?w

743:デフォルトの名無しさん
22/04/09 13:05:08.55 P+77Yson.net
>715
何をトンチンカンな指摘をしているんだよ。
>713 >実はC++とRustには共通点が非常に少ない
に対する反論なのに、
>715 歴史通りの順番で学ぶ必要ある?
とか共通点の話と何の関係も無いだろ。
Rust信者はこういう詭弁を弄するクソしかいないのかね。
あと、言語の話をしているのに
> (その理屈だと最初はパンチカードからかな…)
とか言語じゃないものを引っ張り出すようなアホな反論するなよ。

744:デフォルトの名無しさん
22/04/09 13:10:56.96 Wb48yUxI.net
>>718
C++から見てRustのそのシンプルで分かりやすい記述と概念は羨ましい
だからRustから輸入する形で取り入れることになった

745:デフォルトの名無しさん
22/04/09 13:23:59.57 P+77Yson.net
>718
>最近のC++はなんとRustの後追いをしている状況
Rust信者は我田引水が酷いな。
C++の標準化が遅いのはC++が巨大だからであって、しがらみのないRustの方が採用早くなるのは当然だろ。
> Optionは C++では std::optionalで これはC++17でようやく導入された
初出はboost::optionalで2003年8月
> Resultは C++では std::expectedで これは現在導入に向けて審議中
これはboost::outcomeが初出かな? 2014年
> Iteratorは C++では std::rangesで これはC++20でようやく導入された
そこそこ違いがあるけど、boost::rangeは2003年。
どれもRustリリース前のものばかりだろ。
RustがC++のアイディアをパクって先行実装しただけじゃね?

746:デフォルトの名無しさん
22/04/09 13:25:35.27 OTzifHJR.net
C++の貧相なラムダ式見て涙出てくるわ
おばちゃんの必死の若作りみたいで痛々しい
>>730
相変わらず読む価値無しの駄文オナは続いてるようだよw

747:デフォルトの名無しさん
22/04/09 13:29:34.12 il24SwZF.net
スレリンク(tech板)
そろそろこっちでやってくれませんか?

748:デフォルトの名無しさん
22/04/09 13:41:58.59 xJyQ5Sl3.net
>>733
C++にはRustのenum(=型収容付きenum=タグ付きunion)が無いため
それらC++のバージョンはRustのものより劣っている
それではRustに勝てない

749:デフォルトの名無しさん
22/04/09 14:01:07.29 n9UcTFQC.net
スレタイの言語間で争える話題ないか考えてみたけど
それぞれ狙うところがバラバラで共通項がないな

750:デフォルトの名無しさん
22/04/09 14:06:05.68 J0gE1zR3.net
rustスレでやれば
もうJavaレベルには普及しないって結論じゃん

751:デフォルトの名無しさん
22/04/09 14:11:30.90 cvyLC6WE.net
次のスレからRustの話題は荒れるから禁止にしてスレタイからも削ろうw

752:デフォルトの名無しさん
22/04/09 14:14:38.49 ehpYMGIZ.net
このスレで荒れてくれる分には構わんわ。C++スレとかRustスレとかを荒らさないで。

753:デフォルトの名無しさん
22/04/09 14:19:25.04 mmQa05p2.net
便利さを理解するために不便さを体験するべきか否か論な訳だけど、個人的にはそれをするにしては遠回りが過ぎるのがC++という長大な壁だと思っているので経由する必要はないかなと思ってる
代わりの話としてZigとかどうよ
依存型的なコンパイル時計算と実行時計算をフラットに書ける感じ
結構賛否両論来そうな話題だと思う

754:デフォルトの名無しさん
22/04/09 14:22:44.53 cvyLC6WE.net
あれるのは上等なのか
関数オーバーロードがない言語は軒並み糞

755:デフォルトの名無しさん
22/04/09 14:27:38.36 OWfDePLk.net
オーバーロードあると高階関数に渡すときに一手間かかるのがヤダ

756:デフォルトの名無しさん
22/04/09 14:30:13.22 cvyLC6WE.net
標準ライブラリの標準関数のシグネチャー変える言語は糞

757:デフォルトの名無しさん
22/04/09 14:31:10.30 DIYn4SHb.net
教育には自分を撃てる言語を使った方が良いのでは?

758:デフォルトの名無しさん
22/04/09 14:31:48.55 cvyLC6WE.net
コンパイルするときにファイルのフォルダ階層に依存する言語は糞

759:デフォルトの名無しさん
22/04/09 14:33:14.01 gSPSOhuN.net
pythonガチアンチ勢がいるらしいな

760:デフォルトの名無しさん
22/04/09 14:38:25.49 cvyLC6WE.net
mainのあるファイルから連鎖的に参照されないと同じフォルダにあってもソースがコンパイルされない言語は糞

761:デフォルトの名無しさん
22/04/09 14:40:09.03 cvyLC6WE.net
言語じゃなかったな
コンパイラ環境か?コンパイラドライバか?

762:デフォルトの名無しさん
22/04/09 15:06:56.55 BphNan8J.net
言語依存の特性というよりはコンパイラがインクリメンタルかリカーシブルかなんて、言語にほとんど関係ない・・・

763:デフォルトの名無しさん
22/04/09 15:33:43.71 cvyLC6WE.net
じゃあ
ファイル名がクラス名やモジュール名と一致してないとダメな言語は糞

764:デフォルトの名無しさん
22/04/09 17:12:33.80 +P+cdtWg.net
自分じゃ話題も振らないのに他のスレでやれとかいう輩って・・・

765:デフォルトの名無しさん
22/04/09 17:40:19.06 qlihBLS+.net
>>741
> 便利さを理解するために不便さを体験するべきか否か論
そう捉える奴も多いのだろうが、それだと完全に精神論になってしまうだろ。

コメントで要求されてる「Howは要らない。Whyを書け」と捉える


766:べき。(C++はRust仕様のコメント) つまり、C++でどういう手法が試され、結果としてRustが何を採用してるかを紐解けば、 Rustが何故こうなっているのかが分かる、というわけ。 信者がひたすら「Rustは正しい」と信じることしかできないのは、Whyを知らず、妥当性の判断能力がないから。 ただしHowはRustの場合は文法にしてしまっているので、 Whyを知らなくても、知ってる奴と同等のコードは生成出来てしまう。 だからプロダクト目的のRustドカタには必要がないのも事実。 (これはフレームワークに於いて、何故こんな構造を採用したのか?とか考える必要がなく、 ただ従って正しく使えば生産性が上がるのと同様) 逆にアカデミックとか、Rustの次の言語を考えたい奴がWhyを抑えないのは問題。 信者ではなく、自分で判断してRustを選択したと言いたいのなら、Whyを知らないといけない。 (知ってないと判断出来ないはずなので、論理的に矛盾する。 これはC++の全てを知っておけという意味ではなく、 Rustで採用された「データ競合」「寿命管理」「例外処理」等の対処方法については、 当然だが他のやり方も存在しており、それぞれ一長一短有るから統一されてない。 それらを知らずに、Rustのやり方しか知らず、ひたすらRustマンセーなら、それはただの信者と言える)



767:デフォルトの名無しさん
22/04/09 18:34:35.92 JZiB2qZH.net
色んな言語やってきたが総合的にみてRustが現在のプログラミング言語の中の最強言語で間違いない
理論的に任意の言語が動き実際にも多数の言語が動かされているWebAssemblyにおいてもRustが利用トップである客観的事実もある

768:デフォルトの名無しさん
22/04/09 18:36:58.31 il24SwZF.net
話題は>>577で振ったけどスルーされました(^p^)
実際どうなんすかこれ、Yewとかその辺の利用者の使用感知りたいんだけど

769:デフォルトの名無しさん
22/04/09 18:48:35.17 SpxMIjuY.net
C++理解した程度でプログラミング理解したと思ってるのが痛々しい

770:デフォルトの名無しさん
22/04/09 20:19:57.41 cvyLC6WE.net
Rustはボロー周りとEnumだけがよくできていて他はそうでもない
長期で運用しにくいしょうもない弱点だらけ

771:デフォルトの名無しさん
22/04/09 20:26:08.31 n9UcTFQC.net
>>757
例えば?

772:デフォルトの名無しさん
22/04/09 20:26:09.05 TpQINAdx.net
そうだぞこんなの使ったら駄目だぞ
俺は使うがな

773:デフォルトの名無しさん
22/04/09 20:31:58.00 cvyLC6WE.net
レスをたどる能力もないのかRustの機能や制約を知らないのか自分で何かを調べる能力がないのか
どれなんだろう?

774:デフォルトの名無しさん
22/04/09 20:34:48.49 TpQINAdx.net
まとめるの面倒だからしないけど弱点だらけだぞ
それでも俺は使うがな

775:デフォルトの名無しさん
22/04/09 20:38:12.58 cvyLC6WE.net
言語面は置いといてrustはまずcargoを何とかしろ
モジュールパッケージの参照の仕組みを改善しろ

776:デフォルトの名無しさん
22/04/09 21:14:44.30 HNoOQ+Ya.net
次世代次世代つって結局Rustしか話題に上がってないやんw

777:デフォルトの名無しさん
22/04/09 21:34:11.92 lI/OjvKQ.net
>>763
つまり次世代はRust覇権が確定。Rust一択ってこと。
VScodeが覇権したようにプログラミング言語もそろそろRust一択にしようよ

778:デフォルトの名無しさん
22/04/09 23:10:39.42 SpxMIjuY.net
GoやクソバカPHPoorが滅びるべきというのには同意

779:デフォルトの名無しさん
22/04/09 23:31:48.47 qlihBLS+.net
それがRustが現在も今後とも流行らない理由だろうね

780:デフォルトの名無しさん
22/04/10 00:20:38.04 xqQhhwbp.net
他の言語でもRustのように広い意味でのデータ競合を実行前にチェックしてくれたらいいのに
そうすればその分の実行時デバッグを無くすことができるのに

781:デフォルトの名無しさん
22/04/10 00:52:23.84 fmRbxCQk.net
>>767
それ、馬鹿の一つ覚えだろうけど、割とマジに、データ競合で困る事なんて無いぞ。
もしみんなが本当にデータ競合に困りまくってたら、あらゆるアプリがRustでキラーアプリ化してるはずだろ。
実際は誰も困ってないし、さらにホームドアを付けたところで元々バグもないから差別化出来ず、キラーアプリ化もしてない。
面倒なのでスルーしたが、256で突っ込まれてるように、
実行時デバッグをそれほど必要としてる時点でプログラマとしてはポンコツ。
初心者なのを自覚して、まずはコードを頭の中で動かせるようになる事を目指すべきだよ。

782:デフォルトの名無しさん
22/04/10 00:52:41.03 dmNwgspZ.net
とかく計算系のライブラリの高速実装がGPGPU関係なくRustよりC++が優先されているのが悲しいが個人でなんとかできる規模でもなく

783:デフォルトの名無しさん
22/04/10 01:03:58.92 fmRbxCQk.net
>>769
やれば分かるが演算系はリソースの確保/開放ははっきり言ってほぼ必要ないので、
C++どころかCでも全く苦労しない。
しかもRustだと使い回すには一々所有権を気にしないといけないだけ面倒。
他言語なら見えれば何度でも問題なく使えるのに。
だからその辺がRustメインになる事はあり得ないと思うけど。実用重視なら尚更。
境界チェックが一々入る分だけ無駄に遅くなるのも致命的ではあるし。
俺は演算部分だけCのdllにして、GC言語からそれを呼び出すのが最強だと思うけど。
つまりNumPyでいい。(なお俺は使った事無いが)

784:デフォルトの名無しさん
22/04/10 01:07:40.61 clYg/AzK.net
>>768
超巨大なコードベースの前で人は簡単にポンコツになるよ
Sanitizerやclang-tidyへのgoogleの投資を見れば分かる
ただこの手のツールが必要になる言語やアプリは限られているから
あらゆる領域でデータ競合抑止が役に立つというのは偽だとは思うが

785:デフォルトの名無しさん
22/04/10 01:22:47.07 fmRbxCQk.net
>>771
それはコードベースが巨大すぎて見落とす確率が高くなるだけだろ。
ただし事実としてこれはあるのは認める。
これについては、Web系見てて思ったんだが、
Java(OOP): どんな巨大なコードでも、20年前のコードでも、メンテナンスしてみせる!!!
Web系(Restful): そもそも巨大にならないように分割。
 一人で管理出来るサイズ(1,000-10,000程度)なら管理も簡単だし、コードも最悪書き捨てでもいい。
で、俺はWeb系の方が正解じゃないかと思いだしている。
だから、Javaを殺すのはWeb系だろうなとも思っている。

786:デフォルトの名無しさん
22/04/10 01:24:17.90 7I8wnXlj.net
Rustのプログラミング開発効率の良さには感動した
めっちゃ便利やな

787:デフォルトの名無しさん
22/04/10 01:24:40.32 fmRbxCQk.net
あ、すまん、分かると思うが、772訂正。
× 1,000-10,000程度
○ 1,000-10,000行程度

788:デフォルトの名無しさん
22/04/10 01:35:56.55 o4uZiwRi.net
>>772
用語の使い方からも
間違った対比からも
知的レベルの低さが露呈している
そこは単純にモノリスvs.マイクロだけであってOOPやRESTは関係ない

789:デフォルトの名無しさん
22/04/10 01:51:37.37 lgnAhvFe.net
>>772
web系というかブラウザやらOSやらの低レイヤーで考えるべきかと
OSもマイクロカーネルにしたらバグ少なくなるのかね

790:デフォルトの名無しさん
22/04/10 01:55:17.11 G67EgXPk.net
Nimの話題ロクに出てこないね
自分は使ったことないけど、使ったことある人はどう?
他の言語との違いや特色教えてくれると嬉しい

791:デフォルトの名無しさん
22/04/10 01:55:40.00 fmRbxCQk.net
>>775
まあ揚げ足取りはどうぞご自由にだが、話は通じてるようだ。
それで、反論は出来ないのか?
だとすると、やはりRust信者は低脳だとしか思えない。
(議論する気があるのなら、そのレスでは駄目だし)
・巨大化したコードベースではどうしても見落としが発生する


792:から、全部所有権を強制化してコンパイラでチェックする という直接的な解決策をRustは採用しているが、 ・そもそも巨大化しないようにひたすら分割し、見落としが発生しにくい規模に抑える という、上位アーキテクチャでの解決策もあるのだよ。 これは「データ競合」の時も言ったろ。 そこに問題があれば、解決策もそれなりに用意されてる。(格好いいかはまた別だが) それでは解決出来てない!不十分だ!と言うのなら、 どうにも取りきれなかったバグがRustによって取りきれ、結果的にキラーアプリ化するはずなのだが、 実際これがないだろ。 なら、これまでの地味な方法でも何とかなってたって事なんだよ。



793:デフォルトの名無しさん
22/04/10 02:03:42.86 fmRbxCQk.net
>>776
> OSもマイクロカーネルにしたらバグ少なくなるのかね
通説としてはそういう事になっている。(まあ知ってると思うが)
Linusはモノリシックカーネルの利点を言ってるけど、あれは俺は後付だと思うよ。
とはいえ速度重視ならモノリシックの方が上だし、
堅牢性重視ならマイクロカーネルってのは、技術的にも正しいと思う。
俺が言ってるのはもっと単純な話で、
機能が少なければ、実装に必要なコードも少なく済み、見落としも減る、という、至極当たり前の話。
だから「仕様を必要最低限に絞る事こそ最強」という話だね。
これもよく言われているとも思うけど。
だから、マイクロカーネルの方が仕様が小さいから実装コードも減り、結果的に「見落とし」のバグは減ると思うよ。

794:デフォルトの名無しさん
22/04/10 02:03:43.80 Yq6q8jid.net
Nim、vlang、Zig、Zenらへんはマイナーすぎてなんとも
D言語が使われなかったのと似たような理由で使われなさそう

795:デフォルトの名無しさん
22/04/10 02:04:15.32 UjiUu+PI.net
結論は変えるつもりがなくそこに至るまでの論理だけを手を代え品を代えひねり出し続ける
信者もそれに対する批判も不毛なんだ

796:デフォルトの名無しさん
22/04/10 02:06:36.51 NYexxOz5.net
>>778
アーキテクチャとアプリと言語は全て別問題なのに区別がつかずにごっちゃに話しているキチガイに見えます

797:デフォルトの名無しさん
22/04/10 02:21:42.17 UjiUu+PI.net
そんなことより次々世代言語にどういう特徴を持った言語が来るか予想しようぜ

798:デフォルトの名無しさん
22/04/10 02:34:28.97 NYexxOz5.net
>>780
IT大手各社が珍しく揃って支援&採用しているRustだけが最近のプログラミング言語の中で長期に残りそう
>>783
Rustを置き換えるような次々世代言語は
Rustが備えるC言語並の速さ省メモリと安全性を押さえた上で異なるアプローチとなるだろうけど
Rust関係の論文が多い状況からすると理論的な裏付けが先行研究としてあるものの中から出てくるのかな

799:デフォルトの名無しさん
22/04/10 08:39:07.48 K0blu0OJ.net
C2とATS2のことも忘れないであげてください!

800:デフォルトの名無しさん
22/04/10 09:17:53.01 fmRbxCQk.net
>>782
それはRust信者はプログラマではないからだな。
プログラマは全レイヤで最適化を模索する事が出来る。(本来は)
例えばだいぶ前にスマホ見てて踏切の内側と外側を間違えて死んで話題になってたが、これについて
・現場(踏切の改善):踏切内の障害物検知器の精度を上げ、人が間違って立ち止まってる場合も検出し、電車を緊急停止させる(Rust)
もありだが、
・運用(経路選択):そもそも踏切を通らない経路を選択する。歩道橋があればそれを使う。
・運用(マナー):歩きスマホ禁止。イヤホンも爆音にはせず、周りの人の声も聞こえる程度にしておけば気づけたかも?
・運用(ポリシー):外でボーっとしない。事故に巻き込まれる確率は0ではないのだから、


801:常にある程度は周りに気を付ける ・アーキテクチャ:高架化して踏み切り自体を無くす(C#) アーキテクチャ面での対策が根本対策になるが、現実的には運用での回避になってる。 大人の場合はマナー/ポリシーで回避し、 これを期待出来ない小学生には、通学路なら歩道橋を設置して、経路選択での対策が為されてる。 「データ競合」も同様に、 ・現場(チェッカ):所有権を厳密に管理し、コンパイラでチェック(Rust) もありだが、 ・運用:難しい事はしない。競合する可能性のある場所は限定的にして、見ればバグに気づける程度にする ・アーキテクチャ:スレッド構成上、そもそも競合が発生し得ない(C#) で、アーキテクチャでの対策が根本対策だが話が大がかりになり面倒になるので、 大体は運用で対策され、でも何とかなってるというのが実態だ。 通常は言語選択はアーキテクチャよりさらに上のレイヤか、そもそも独立した軸なので、 言語比較で一番下のレイヤ(現場)での改善のみに限定するのが間違ってる。 そして重要なのは、既存の言語でも根本対策はやる気になればすぐに出来るんだよ。多少面倒なだけで。 だから信者の言う「Rustでなければ無理だった」というアプリが存在せず、キラーアプリも出てこないわけ。 Rustは「一方ロシアは鉛筆を使った」の米国側を突き進もうとしてる。これもありだが、ロシア側もありなだけの話。



802:デフォルトの名無しさん
22/04/10 09:21:12.35 n6k1Ijhp.net
この人は無駄で無意味な間違った例え話を延々と繰り返し妄想の世界に住んでいる

803:デフォルトの名無しさん
22/04/10 09:21:25.28 sR7YmRYu.net
Scalaの方がKotlinより機能豊富だけどWeb系では落ち目になったね
Scalaの方が好きだが

804:デフォルトの名無しさん
22/04/10 09:26:20.41 BLmvSJJ5.net
>>788
Scalaは結構好きで長く使っていたけど
使っているとどうしてもJVMが見えてしまう部分があって
Rustに乗り換えちゃったな

805:デフォルトの名無しさん
22/04/10 09:29:58.47 93k1uAXl.net
rustaceanはある時期を境に爆発的に表に出てきてプログラミング界隈を圧倒する未来が見える

806:デフォルトの名無しさん
22/04/10 09:41:23.13 BLmvSJJ5.net
表に出るかなぁ?
OSやコンパイラ、ミドルウェアあたりに侵食して、気付かないうちに全員が依存してる、みたいな状況なら有り得そう

807:デフォルトの名無しさん
22/04/10 10:05:57.88 W8i2G4wq.net
scalaはコンパイルが困憊るほど遅すぎた

808:デフォルトの名無しさん
22/04/10 10:55:59.09 vR2aNwQM.net
>>779
>Linusはモノリシックカーネルの利点を言ってるけど、あれは俺は後付だと思うよ。
後付けというか経験知からの意見だろ。
Linusはそもそもが理論家なわけでもないし。
仕様を最初から小さく絞れるとか考えてる奴は全く的外れとしか言いようがない。

809:デフォルトの名無しさん
22/04/10 11:21:10.49 7HDkHX8h.net
Linux作り始めたときからタネンバウムと論争しているのに理論家じゃないとか後付けとか

810:デフォルトの名無しさん
22/04/10 11:26:19.70 nRSUY8iy.net
一部だけ小さくしてバグ減っても意味ないよ。
部分的な最適化はシステム全体の最適化の視点では上手く機能するわけではないからね。
一つ前のFreeBSDで話題になって詳しい人が説明してくれてた。
スレリンク(unix板:794番)

811:デフォルトの名無しさん
22/04/10 11:41:39.32 vR2aNwQM.net
>>794
だからLinusはタネンバウムみたいな理論家を嫌ってんだろ。議論の中身理解してないのか?

812:デフォルトの名無しさん
22/04/10 12:14:41.45 N1Kz0CTA.net
>>783
C言語より10倍速い言語が現われて界隈歓喜

813:デフォルトの名無しさん
22/04/10 12:18:37.19 W8i2G4wq.net
>>783
Googleに頼めば全て完成する

814:デフォルトの名無しさん
22/04/10 12:31:07.74 2AahvlRa.net
次世代はシンプルな言語仕様+強力な静的チェックだと思う
Rustみたいに事前の宣言でガチガチに縛るんじゃなく、型推論やフロー解析を積極的に利用して利用のされ方に基づいた型チェックや生存期間のチェックを行う
まあこのままいくとJavaScript+VSCodeがそれになるかもしれないが

815:デフォルトの名無しさん
22/04/10 12:46:03.55 fBzqkVFD.net
>>799
ことweb界隈で使われる言語に関しては前半同意
サービス独自の機能をスピーディーに開発することが求められるweb界隈において、プログラマ自身が考えないといけないことが多くなるrustはまず普及しない

816:デフォルトの名無しさん
22/04/10 12:55:32.64 fmRbxCQk.net
>>793
運用していくうちに追加追加で仕様が段々膨らんでいくのはある程度仕方ないとして、
それでも更新タイミングで不要な仕様を出来るだけ削除して仕様を絞るのは基本中の基本だろ。
マイクロカーネルもある意味これで、「カーネルがやるしかない事しかやらない」という、最小仕様を目指したものだ。
プログラミングに於いて小さい仕様を目指すのは大正義だし、みんなそうしてる。
(出来てるかはまた別。特にJava分野。
対してWebの場合はこの辺切り捨てるしサービス終了もありありなので、
反発はあるかもしれないが、仕様が雪だるま式に膨らんでる事はない。
俺はこの辺、Java流の「どんなに大きくなっても何とかしてみせる」ではなく、
Web流の「定期的に棚卸しで削除」の方が長期的には正しいのではないかと思いつつある、という事)

>>794
Linusは当初から分かっててモノリシックを選択したのはいい。
当時の速度的にそれが妥当だったのも分かる。
ただ、今となってはマイクロカーネルにすべきだし、徐々にでも変更していくべきだと思うよ。
今でもモノリシックの利点を説いているのは、後付のように思える。

817:デフォルトの名無しさん
22/04/10 13:03:29.70 WQm20ac3.net
>>794
「俺は後付だと思う」って予防線貼ってるし、そこまで知らなかったんだよ、きっと
許してあげて

818:デフォルトの名無しさん
22/04/10 13:10:21.13 BLmvSJJ5.net
>>799
Rustのように型が強力でコンパイル時チェックの細かいGC言語ってのが現状ないから
そこは新言語の余地がある気がしている
JSだとどうしても型はガバガバにならざるを得ないからなぁ

819:デフォルトの名無しさん
22/04/10 13:17:50.89 blp15KeH.net
言語には向き不向きがあるわけで
それを無視してRustがすべての言語を置き換えるみたいな話をしているのがおかしい
C/C++の置き換えは進むかもしれないけどwebやスマホやPCアプリとかでは採用されないでしょ
普通はどの言語が最適かをいろいろ検討して決めます
なんか通販の広告みたいなんだよね
良いことしか言わないし
大手IT企業が採用ってのは通販広告の有名人も愛用!みたいな感じ
コンピュータ関係の新技術の売り文句は100%そうだった試しはないので話半分で聞いていた方がよいと思う

820:デフォルトの名無しさん
22/04/10 13:30:51.71 fBzqkVFD.net
>>804
ほんまこれ
このスレの一部のRust信者がRustこそ至高みたいなノリだけど、このノリについていけないRust推し結構いると思う

821:デフォルトの名無しさん
22/04/10 13:55:42.06 UjiUu+PI.net
いつでも最初から型が要るのは足枷というのは確かに思うわ
そうなると漸進的型付けってやつかねえ
TS以外のaltJSは死んだとかだれかが言っていたが、Haxeの再興もあるか?

822:デフォルトの名無しさん
22/04/10 14:04:03.83 WXrh5iWM.net
>>805
というよりRustは好きだけど別に推してはないという
誰も使わなくていいよ
俺と一部のお前らが使うだけでいい
みんなに使ってもらう必要なんて一切ない

823:デフォルトの名無しさん
22/04/10 14:14:16.90 li


824:fo30Qd.net



825:デフォルトの名無しさん
22/04/10 14:16:40.89 WXrh5iWM.net
アンタにレスしてないから気にしないでね
人を小馬鹿になんかしてないし
Rust以外の言語も好きだし
そもそもどの言語も馬鹿にしたりしない

826:デフォルトの名無しさん
22/04/10 14:23:28.49 sejldIDY.net
こういう屈折した性格の勘違い野郎ばっかで本当に近づきたくない。扱いにくいのに能力なんてないし言語触ってれば最先端だと勘違いしてる、とんでもねえバカ

827:デフォルトの名無しさん
22/04/10 14:40:08.25 9taU8UGO.net
RustはMozillaのステマでfirefoxのRust導入は
不可能と叩きが暴れてた頃が懐かしいなあ~

828:デフォルトの名無しさん
22/04/10 14:57:34.06 fmRbxCQk.net
>>810
まあ勘違い馬鹿は必ず存在するのである程度致し方ない。
連中は基本的に「難しい言語使ってる僕すごい」であり、
プログラミング言語の優劣を自己で判断する能力はないので、
何か新しく「凄いけど難しい!!!」とされる言語が出てきたら勝手に移住する。
だから、対策としては、何でもいいから新しい言語を作って適当に吹聴する事だね。
そうすればRust界隈も浄化される。
なお一時期はC++の連中の選民思想が超絶にウザかったが、これが今はRustになってるだけ。
ならC++スレはどうなったかと思って見てみたら、完全にお馬鹿の溜まり場になってたわ…。
まあ○○言語を使ってれば賢いって事にはならないので、当然でもあるのだが。

829:デフォルトの名無しさん
22/04/10 15:13:47.07 nUqmGYW5.net
ちんちんシュッ!シュッ!シュッ!

830:デフォルトの名無しさん
22/04/10 15:18:10.17 LCNa54V5.net
完結に喋れない病気直ってないの?

831:デフォルトの名無しさん
22/04/10 15:22:51.62 fmRbxCQk.net
>>783
はっきり言えば、誰も「新言語」なんて必要としてないだろ。
欲しがってるのは、各自が気に入った言語での、
・バグを自動的に検出してくれるゴリゴリのリンター
・Cと同速で動く爆速環境
であって。
はっきり言ってRust信者の「Rustは書きやすい!!!」すら方便で、連中は
・リントが強く、データ競合が起きない
・寿命管理ががっちりしてるので、GCなくてもメモリリークが発生しにくい
事がRustの買いだと言ってるわけだが、
Rust信者すら、信者になる前に使ってた言語でこれらを満たす状況になってたら、そのままその言語を使い続けてるだろ。
寿命管理はGCが爆速なら(リアルタイム系以外は)誰も文句言わないのでこれで決まり。
データ競合バグは言う程問題でもないが、
これをどうしても避けたいのなら、JSのように基本シングルスレッドにしてしまえば根本解決する。
だからこの2点が必要とされてるのなら、JSの爆速環境があれば済む話。
JSにおいて速度の枷は動的型であり、だからこそTSでアノテートだが、JSに変換して実行してる現在では速度メリットはない。
だからV8(JSエンジン)がTSをそのまま食うようになれば、解決する。期待値としては多分現行の倍速程度にはなる。
あるいはBlazor(WebAsembly)がこれに近い状況。
ただし世界が望んでるのは、Python/RubyがとりあえずJS並に高速化する事だね。
ただ俺はPython/Ruby連中が高速化についてあまり真剣に取り組んでない(ように見える)のは意味が分からないのだが。
Matzも新言語作るんだーとか言ってたと思ったが、あんたがやるべきなのはRubyの高速化でしょうが、と。

832:デフォルトの名無しさん
22/04/10 15:22:54.24 WXrh5iWM.net
>>811
なんか最初の頃はMozillaの印象強かったよねえ

833:デフォルトの名無しさん
22/04/10 15:24:50.68 x8


834:oklrTT.net



835:デフォルトの名無しさん
22/04/10 15:33:46.76 lgnAhvFe.net
>>815
ruby3はruby2の3倍高速化というお題目でそれなりの成果を出した訳だけどそれでもまだまだ足りないと言うのね
スクリプト言語で高速化するためにはボトルネック箇所をCなりで置き換えるのが普通
JSはブラウザで動かさなければならないという制約上言語自体を高速化する必要があり
ブラウザベンダー大資本がつぎ込まれた結果高速化した
前提がかなり異なるから同じことがruby/pythonに起こることはないのではないか

836:デフォルトの名無しさん
22/04/10 15:56:47.79 fmRbxCQk.net
>>818
> ruby3はruby2の3倍高速化というお題目でそれなりの成果を出した訳だけど
それよく勘違いされてるが、
3倍になった『部分がある』だけで、全体が3倍になったわけではないよ。
(これは公式でもこう『追加』アナウンスされてたはず)
俺が思う割と正当な比較はこれだが、
> URLリンク(1.bp.blogspot.com)
> URLリンク(okuranagaimo.blogspot.com)
「Pythonは100倍以上遅いぞ」なんて言われる事も多く、
C比だとJSで5-6、Python/Rubyは80-100程度だと思ってる。
だからまずはJS並にするだけで16倍程度は高速化するわけであり、CやCythonは嫌だ…な連中には十分だと思うんだよ。
Rubyも16倍のクライアントを捌けるようになれば鯖代も半分以下に出来るだろうし。
(そもそもコードが汚れるのは無理に速度チューニングしたコードにするからであり、
馬鹿みたいなコードでも速く動くのならコードも綺麗に保てるし)
> 前提がかなり異なるから同じことがruby/pythonに起こることはないのではないか
逆に言えば、金さえつぎ込めば改善出来るわけで、
改善項目とそれに要する金額をずらっと羅列して、クラファンで資金が付いたところから実行、
十分な結果で採り入れられたらそいつがその資金を給料として獲得、とかいう方式にすれば、
割とすぐにでも行けるんじゃないかと思うんだけどな。

837:デフォルトの名無しさん
22/04/10 15:58:01.34 UjiUu+PI.net
>>815
> JSにおいて速度の枷は動的型であり、だからこそTSでアノテートだが
違うよ
ブラウザがTSをそのまま食えるようにするというのは開発者側でトランスパイルする必要性を無くすだけで実行速度の改善を目的としたものではないよ
ていうかその方向性はasm.jsとかPNaClみたいな先駆者がいて彼らの現状の到達点がWASMという経緯があるよ

838:デフォルトの名無しさん
22/04/10 16:21:05.00 fmRbxCQk.net
>>820
> 実行速度の改善を目的としたものではないよ
それは知ってるが、JSの速度改善には型の固定(静的型)が必要だから、「『Any無しの』TSを食わせる」必要があるんだよ。
その前段階として「TSを食わせる」が必要なわけ。
(実際やろうとしてるかは知らん)
asm.jsはお世辞にもいいものとは思えない。
あれもJSエンジン内で型を固定出来てるわけではないし。(ただJITだとあれでも行けるのかな?)
PNaClは知らない。けど削除されちゃったよね。
ただwiki見る限りWebAssemblyでいいから削除、みたいな感じのようだが。
「Any無しのTSを食わせる」位ならBlazorでWebAssemblyしろってのはその通りだが。
だからWASIも方向性としては有ってて、最高に上手く行け�


839:ホJVMを置き換える事になるかもしれんけど。 (Java言語そのものは死なず、JavaからWebAssemblyを吐くようになるだけだが)



840:デフォルトの名無しさん
22/04/10 16:49:31.19 UjiUu+PI.net
知らなかったくせに

841:デフォルトの名無しさん
22/04/10 16:53:31.25 QEMS6G9N.net
毎日Rust攻撃してる人、暇なんかな。
別の事に時間使えはいいのに、と他人事ながら思うよ。

842:デフォルトの名無しさん
22/04/10 16:57:09.68 7HDkHX8h.net
AssemblyScript や Static TypeScript の話をどこかで聞きかじったのが混ざってるんだと思う


次ページ
最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch