次世代言語23 Go Nim Rust Swift Kotlin TypeScript

**デフォルトの名無しさん** · 2021/11/28(日) 16:59:19.16

スレタイ以外の言語もok

前スレ
次世代言語22 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1629590343/

**デフォルトの名無しさん** · 2022/02/22(火) 02:06:26.37

凡人なので Bracket Pair Colorizer みたいなエディタ支援がないと
3階層以上のカッコの対応が正しいかどうか自信が持てない

**デフォルトの名無しさん** · 2022/02/22(火) 02:20:32.61

>>299
中カッコやendで閉じないとエディタが助けてくれないのよ
インデントをどうするかをエディタが助けることができない

**デフォルトの名無しさん** · 2022/02/22(火) 12:22:36.19

>>301
Bracket Pair Colorizer は、もう必要ない

既に、VSCode に実装されたから

**デフォルトの名無しさん** · 2022/02/23(水) 16:27:32.36

>>303
>Bracket Pair Colorizer は、もう必要ない既に、VSCode に実装されたから

良い世の中になったなぁ。vimでも実装されればいいのに。特に、対応するカッコを線でつなぐ機能はExcelにも無いのでステキ。

**デフォルトの名無しさん** · 2022/02/23(水) 16:40:31.88

https://github.com/search?q=vim+rainbow
色着くだけなら

**デフォルトの名無しさん** · 2022/02/25(金) 00:55:39.55

>>305 Thanks。対応するカッコを線でつなぐ機能も有れば更にステキ。

>>289
>javascriptでデータ量を減らせて難読化できるメリットはわかりますが・・・・。

javascriptは行末セミコロン強制ではないので、自分で書いていて今ごろ意味不明な事が発覚。修行が足りぬ。

C言語の先輩であるFORTRANは行末セミコロンは無くてもプログラミングできていたので、C言語系の文末セミコロン強制の意義はいまだに不明です。
構文解析の負担を少しでも減らして、コンパイルを高速にするためでしょうか？

**デフォルトの名無しさん** · 2022/02/25(金) 02:23:42.73

Cのセミコロンはalgolのセミコロンやcobolのピリオドを引きづっている
ここで一連の処理が終わりという意味でターミネータを置いた
改行を書かずにぎっしり書くときにどこで切っていいか分かるからね
自然の文に近かろうといういい加減な理由
当時はまだ人間にとっての書きやすさとか
人間にとっての読みやすとさかほとんど配慮されてなかった

**デフォルトの名無しさん** · 2022/02/25(金) 04:31:10.49

Rustはセミコロンの有無で文か式(値)かを分けている

if condition {
　a = p + q;
} else {
　a = x + y;
}

これをifの中を文ではなく式(値)にすると

a = if condition {
　p + q
} else {
　x + y
};

もちろん改行やインデントは自由なので
a = if condition { p + q } else { x + y };
こう書いても同じ

波括弧は区切りとして不可欠であり
多重時の対応関係となるだけでなく
波括弧はブロックを形成しスコープの管理にも不可欠

例えば波括弧により新たなブロックを形成することで
ロックを取得した変数がブロック終了時に自動解放され
その時にロックも自動解放されるなど安全設計にも波括弧が活躍

このようにセミコロンと波括弧はRustにおいて非常に重要な意味を持つ
きちんと活用したプログラミングにおいてはセミコロンも波括弧も無駄ではない

**デフォルトの名無しさん** · 2022/02/25(金) 12:38:43.75

Ruby on Rails で有名な、民泊のAirbnb、JavaScript スタイルガイド

ステートメントを明示的に終了し、
不足しているセミコロンを検知するようにリンターを構成すると、
問題に遭遇するのを防ぐのに役立ちます

一方、Rubyでは、セミコロンを付けない

**デフォルトの名無しさん** · 2022/02/25(金) 14:56:07.65

JavaScriptはセミコロンを省略しようとすると、ハマる罠がいろいろあるからね

**デフォルトの名無しさん** · 2022/02/25(金) 17:57:34.96

自由な書き方ができるというのは無駄だと思うけど？
”波括弧は区切りとして不可欠であり（略）波括弧はブロックを形成し（略）変数がブロック終了時に自動解放”
これも別に2種の異なる記号文字の波カッコである必要はない。いちいちカッコ対応を合わせる必要もあるし、Pythonのような
オフサイドルールでも実現できるし、Rubyのように{}とbegin/endで意味が違う言語のほうがしっかりしてますよ
もともとのCではセミコロンはソースのパース処理を楽したいだけで、こんなに好意的に信じられるとはｗ

**デフォルトの名無しさん** · 2022/02/25(金) 18:24:41.24

>>311
そういうおもちゃ的な簡単な言語は波括弧なしでも書けるような構文しかないから何とかなってるけど
そうでない場合は波括弧が最もベストであるから様々な言語で採用されています

**デフォルトの名無しさん** · 2022/02/25(金) 18:37:10.71

ErlangもHaskellも波かっこなんて使わないけど？ Fortranもないし、Juliaには合併型につかうけどブロックじゃないし
これらをおもちゃと言えるならさぞかし素晴らしいプログラム書いてるんだろうな。私の意見は「最もベスト」ではなく
ただ単に何も考えず人口の多い言語からひきずられただけ

**デフォルトの名無しさん** · 2022/02/25(金) 18:56:15.50

FORTH最強

**デフォルトの名無しさん** · 2022/02/25(金) 20:33:35.67

Juliaのendで閉じるのはマジでメリットがわからん
予約語が増えるし、エディタの機能で閉じ括弧にジャンプすることも出来なくなるし

Juliaなんて特にFortran出身のガイジみたいに長いコード書くガイジを招き入れようという言語なのによ

**デフォルトの名無しさん** · 2022/02/25(金) 20:36:28.34

既に書いたようにRustは積極的にセミコロンも波括弧も活用していて無駄がない
波括弧もブロックだけでなく列挙体定義、構造体定義、モジュール定義、トレイト定義、実装定義など多岐にわたる
ブロック自体も様々な制御構文に登場するだけだなく、クロージャや非同期のブロックなどの他に、所有権スコープを別にするためにブロック内ブロックも使うため、開始も終了も1文字で済む波括弧はRustにとってベストとなっている
セミコロンも>>308に書いたようにセミコロンの有無で文となるか値となるか変わってくるなど重要な意味を持っている

このようにセミコロンと波括弧はRustにおいて非常に重要な意味を持つ
これらをきちんと活用したプログラミング言語においてはセミコロンも波括弧も無駄ではない

**デフォルトの名無しさん** · 2022/02/25(金) 20:36:50.10

rubyでもたまに変数名にend使っちゃって(´・ω・｀)ってなるわ

**デフォルトの名無しさん** · 2022/02/25(金) 21:22:07.17

可読性を損なわない範囲で新しい仕組みができればと

**デフォルトの名無しさん** · 2022/02/25(金) 21:39:31.34

>>306
FORTRANは行末記号を使わない代わりに行継続を明示しているだけ。

**デフォルトの名無しさん** · 2022/02/25(金) 21:41:12.00

昔は画面に出せる文字数も少なく見通しが悪くなるのでインデントなど使わなかった
フルスクリーンエディタでもなかった
誰もインデントなど使わず意味の通じる範囲で一行に区切り入れてどんどん文を書いていった

fortranなんて一行の文字数が固定だったし複数行になる場合は非常に見づらかった

**デフォルトの名無しさん** · 2022/02/25(金) 21:43:41.48

行末記号を使わない＝書きかけか記述バグありの場所

**デフォルトの名無しさん** · 2022/02/25(金) 21:50:02.35

大学でfortranの授業があり友達が勉強のためにと20万ぐらい出してパソコン用のFORTRANのパッケージを買った
俺達が今はFORTRANは実質大学でしか使われておらずモダン（）な言語がもっと安く買えることを教えると
もっと先に言ってくれと激怒した

彼は一年の前期しか使わないFORTRANを購入したんだ
後期はPascalだった

Pascalを買っててもそれはそれで…
自分はCのパッケージを買ったんだなあ

**デフォルトの名無しさん** · 2022/02/25(金) 23:51:11.41

インデント言語はコードの自動生成がやりづらいという欠点はあるかな
文を出力するときにその文を含むスコープのインデントレベルだけ空白文字を出力するようなロジックが必要
括弧が必要な言語なら生成後フォーマッタにかけれぱきれいなコードになる

まあたいした差ではないとは思うけど

**デフォルトの名無しさん** · 2022/02/26(土) 01:49:42.07

Ｒｕｓｔは配列の１要素の更新参照を渡したら
ほかの配列要素がすべて更新できないという
発狂するような仕組みになっている

**デフォルトの名無しさん** · 2022/02/26(土) 02:01:50.91

本当にそれがやりたくて、かつインデックスが重ならないことを保証できるんならunsafe使っても許されるケースっぽい

**デフォルトの名無しさん** · 2022/02/26(土) 02:12:02.48

配列の1要素の更新参照をとるときにどの要素が選ばれるかが実行時に決まるとどの要素も変更されうることになるからじゃないの？

**デフォルトの名無しさん** · 2022/02/26(土) 02:48:53.09

>>308 >>316
>波括弧はブロックを形成しスコープの管理にも不可欠
インデントでブロックを形成する仕様でもスコープの管理できるのでは？
つまり、この時点では波カッコは不可欠ではないのでは？

別の言い方をすれば Rustで波カッコの代わりに、インデントでもブロックやデータの入れ子関係を表せるように言語の設計変更が可能ではないか？と思います。

あと次のnim言語の例の様に「ifの後ろにイコール記号が無ければ値(p + q か x + y)を返し、有れば機能 (bに1か2を代入)を実行」という言語仕様をすれば行末セミコロンは不要になるのでは？

a = if condition:
　b = 1
　p + q # a = p + q かつ b = 1となる
else
　b = 2
　x + y # a = x + y かつ b = 2となる
参考：https://2vg.github.io/Nim-World/condition/if.html

**デフォルトの名無しさん** · 2022/02/26(土) 03:08:20.09

CやRustの波括弧とセミコロンはインデントがあろうが無かろうがタブとスペースが混じっていようがインデント幅がバラバラになっていようが一行に式や文がいくつ書かれていようがルールさえ守っていればコンパイルできるようにしろ、自由にコードを書かせろ、というために存在しているんじゃないか。
コーディング規則をきちんと守ってインデントする書き方なら波括弧使わずにインデントでブロックの範囲を指定できる。

**デフォルトの名無しさん** · 2022/02/26(土) 03:15:38.69

>>327
Nimでは一行に複数ステートメントを書きたいときだけセミコロンでステートメントを区切るようになっている。
Statement list expressionを使えば以下のように書ける。

var b: int
let a = if condition: (b = 1; p + q) else: (b = 2; x + y)

**デフォルトの名無しさん** · 2022/02/26(土) 03:43:46.90

>>324
かなり習熟が必要だけど、あらかじめそういうことを理解して考慮していれば
そもそもそういう操作が必要ないように設計できるようになってくるので、どんどん困らなくなってくるよ

ライフタイムらへんはもっと難しいから、初心者はしばらくの間悩まされるし、
やはりどうにもこうにもRustの学習曲線はやばいよね

**デフォルトの名無しさん** · 2022/02/26(土) 03:47:06.26

>>324
split_mut使うなどのworkaroundはあるよ

**デフォルトの名無しさん** · 2022/02/26(土) 06:26:28.15

>>327
Rustだとブロックの先頭ですぐに別のブロック開始させる場合もあるけど
インデント方式でやるといきなり二段階インデントが深くなるのはわかりくいから波括弧が向いてると思う

あとセミコロンも関数の最後の返り値の場所で別の関数を呼んだとき
セミコロンを付けると文になって呼んだ関数の副作用のみ利用で返り値無しとなり
セミコロンを付けると式(値)となって呼んだ関数の返り値が自分の返り値となる
完全にセミコロンの有無しか違いがないからRustでは波括弧もセミコロンも必須かな

**デフォルトの名無しさん** · 2022/02/26(土) 08:10:01.51

昔とはコーディング環境が違うから何とでもできるけど

本当にRustはコーディング時間と学習時間が他の言語の倍ぐらいかかる

**デフォルトの名無しさん** · 2022/02/26(土) 09:10:31.11

専用のIDEがあって、インテリセンス使えれば学習曲線が明らかに下がると思うよ

**デフォルトの名無しさん** · 2022/02/26(土) 14:12:26.25

下げてどうする？

**デフォルトの名無しさん** · 2022/02/26(土) 21:21:46.56

>>332
>インデント方式でやるといきなり二段階インデントが深くなるのはわかりくいから波括弧が向いてると思う

いきなり二段階インデントは確かに嫌ですね。
そういった場面が思いつけないので例を出して頂けるとありがたいです。

**デフォルトの名無しさん** · 2022/02/26(土) 21:23:24.03

他の言語はパフォーマンスの改善とタイミングバグの対応に10倍かかんのよ

**デフォルトの名無しさん** · 2022/02/26(土) 22:44:30.76

うそばかりだな

**デフォルトの名無しさん** · 2022/02/27(日) 13:41:36.31

他の言語で1%ぐらいで発生するバグがrustでは発生しにくいように書ける
でもアホだとそもそもそこまでコードが書けないで放り投げる

コードはバグ込みでも動くものが完成しなければいけないと思うけどRustはそこまで到達しにくいかしないか
同じコードでも3倍ぐらいコーディング時間がかかる

**デフォルトの名無しさん** · 2022/02/27(日) 14:50:22.24

色んなプログラミングをやってきたがRustが一番プログラミングしやすい
色々と言語仕様が洗練されていて書きやすいことが大きい
それに加えて開発効率が非常に高いことが挙げられる
特に実行しながらのデバッグが激減した

**デフォルトの名無しさん** · 2022/02/27(日) 16:00:43.26

>>339
これ

**デフォルトの名無しさん** · 2022/02/27(日) 16:26:56.85

rustではブロックも式だから、インデントは向かないだろう？

**デフォルトの名無しさん** · 2022/02/27(日) 17:46:13.38

c++で書いたコードをRusｔで書き直してると叫びたくなるがしゃあない

**デフォルトの名無しさん** · 2022/02/27(日) 18:10:09.84

静的型付け言語の中だとRustが最も書きやすいかな
特に強力なおかげでデバッグなどでもロジック本体に集中できる点がいいかな
この点は異論があまり聞かれないよね

**デフォルトの名無しさん** · 2022/02/27(日) 18:12:31.33

>>343
どうして？ライブラリがないから？

**デフォルトの名無しさん** · 2022/02/27(日) 18:31:50.94

クラス指向じゃないから抽象化の設計が変わってくる

**デフォルトの名無しさん** · 2022/02/27(日) 18:54:50.37

ロジック本体に集中できると書いてる人はjavaかC#あたりでも使っていたら良かったんじゃないかと

**デフォルトの名無しさん** · 2022/02/27(日) 19:00:54.33

rustが書きやすい理由は関数シグネチャの情報量が多いこともあると思う
関数の型定義を見るだけでパラメーターや戻り値の値域や、所有権の移動有無が明確に分かるのは大きなメリットかと

**デフォルトの名無しさん** · 2022/02/27(日) 19:02:15.12

あと関数に渡したオブジェクトの変更可能性の有無が分かるのも良い点 (これはC++などでも分かるが)

**デフォルトの名無しさん** · 2022/02/27(日) 19:10:22.84

機械的にやってないからってだけだよね
そりゃ自分でRustっぽく書き直しちゃってたら時間かかるのは仕方ない

**デフォルトの名無しさん** · 2022/02/27(日) 19:34:13.88

とにかくRusｔが好きでただ褒めたいだけみたいなレスばかり

**デフォルトの名無しさん** · 2022/02/27(日) 20:07:19.60

Rustは割と学習コストが高いぐらいが欠点らしい欠点

**デフォルトの名無しさん** · 2022/02/27(日) 20:16:19.32

C++やってるとそんなに学習コストは高くないな
デフォルトでムーブっていうのはムーブ知らない人は苦労すると思うが

**デフォルトの名無しさん** · 2022/02/27(日) 20:45:36.21

学習コストが高いっていうのって正直みんなどう感じてるんだろ？

ある意味、RUSTでプログラミングできるっていうのがステータスになってプログラマとしてこういう言語でやっていきたいワクワク感ってのがある。
昨今のPythonのブームは、AIとか自動化とはいいんだけどPython自体は確かに誰でもプログラミングできるかわりに、pythonでプログラミングできるということがなんのステータスにもならない歯がゆさを感じていた。
やっぱりC言語でポイントをマスターしてmalloc/freeとかでメモリ管理をガリガリ書いていて誰でもできるわけではないプログラミングができていた達成感というのを欲していた。
そういう悶々としていた自分にRustがでてきた久しぶりにワクワクしている。
そういうのってない？

**デフォルトの名無しさん** · 2022/02/27(日) 20:48:49.55

RefCellのborrow_mutとかその辺がマジで難しいと思うよ
なんでこんなことしなきゃならんのかって思う

**デフォルトの名無しさん** · 2022/02/27(日) 20:57:13.39

C++のヘッダ取り込みの仕組みを改良してくれたら普通に現役で戦えるのに

**デフォルトの名無しさん** · 2022/02/27(日) 21:10:22.93

Rustもコンパイルが遅いな
マクロだからか？

**デフォルトの名無しさん** · 2022/02/27(日) 21:16:17.18

>>354
めちゃくちゃわかる
Pythonは便利さで考えると間違いなく個人的一位なんだけど、何らかの別の知識と組み合わせないと価値が生み出せない感じは確かにある。
C書いてる老人からしたら「インタープリターなんてけしからん」って感じで毛嫌いされるし...
純粋にプログラマとして名乗るなら一つはコンパイラ型言語を習得する必要がありそうだ。

**デフォルトの名無しさん** · 2022/02/27(日) 23:07:26.84

Pythonはパッケージ管理とか型付いてないライブラリがウザい

**デフォルトの名無しさん** · 2022/02/27(日) 23:37:07.72

というかCargoはマジで優秀すぎて、他のあらゆる処理系に真似してほしい

**デフォルトの名無しさん** · 2022/02/27(日) 23:42:37.49

フロントエンドの人が最近Rust書いてるけど
JSしか書いたことない人が書ける言語じゃないと思うが

**デフォルトの名無しさん** · 2022/02/27(日) 23:58:09.11

JSでちゃんとしたものを書けるスキルがある人にとっては楽勝な気も。

**デフォルトの名無しさん** · 2022/02/27(日) 23:59:48.77

プログラム言語に求められるニーズはホント、多様なんだな、と思った。
GoやPythonの様に仕様を簡単にして仕事をサクッと済ませたい人も居れば、「一般人では到達し得ない難易設定に取り組んで他者と差別化したい」という人も居る。
商品開発と同じで皆にドンピシャハマる言語は無いし、それを無理に作ろうとしたら、万人が物足りなさを感じる折衷案になってしまうのだろうな。

と言いつつ、皆にドンピシャハマる言語を模索している自分が居る。
「型設定、メンドクサイ～」という人はC++で言うautoを使えばいいし、「自動化・縛り無しはバグの元！」という人はintやconstや所有権を追加すれば良い。どちらの書き方でも同じ言語上で動くし、お互いの書き方が気に入らなければ「付け足す・削る」だけで対応できるような、そんな、移植性の高い言語を作りたいものだ。

**デフォルトの名無しさん** · 2022/02/28(月) 00:28:38.71

ステータスのためじゃなく楽だから使ってるだけ

**デフォルトの名無しさん** · 2022/02/28(月) 00:30:29.35

>>355
どの辺に難しさを感じたの？
コンパイル時のborrow checkerと同じことを実行時にチェックするだけだからRefCellが難しいと言うより借用周りの規則がややこしい？

**デフォルトの名無しさん** · 2022/02/28(月) 00:32:24.14

>>357
マクロはほとんど影響ないと思う
小規模のcrateをたくさん組み合わせることが多く、プロジェクトごとにそれぞれコンパイルする必要があるので
単純にコンパイル対象のコード量が多いというのはよく言われている

**デフォルトの名無しさん** · 2022/02/28(月) 15:08:46.61

cargoは独善的すぎて好きになれんわ。遅いし。

**デフォルトの名無しさん** · 2022/02/28(月) 15:19:11.30

その通り、cargoを持ち上げてる上げてる奴とは全く仲良くなれそうもない。
cargoが遅くてダメダメ、なんで遅いのかを調べるとRustのトレイトの仕組みに行き着くという罠...

**デフォルトの名無しさん** · 2022/02/28(月) 15:37:37.25

>>365
可変参照を実行時に得たいというrustの事情はわかるのだけど
そもそもコンパイル時に参照解決できないデータ構造はめちゃくちゃ多い
その辺りをもう少し書きやすくならないかなと思う
結局面倒だからunsafeに逃げてしまうのではないかと
まだうまく言語化できずモヤモヤしてるが

**デフォルトの名無しさん** · 2022/02/28(月) 15:44:40.05

借用規則を考慮した設計が難しい、ってことかな

**デフォルトの名無しさん** · 2022/02/28(月) 16:29:36.75

Rust以前のコードしか書いたことない人は
借用しっぱなしで平気だからいろいろ困ってしまう
Rc<RefCell<T>>で考えられるようになると
共有所有権をクローンして持っておいて
必要な瞬間のみ動的に借用するって方法を覚える
そうして、時間軸上のスコープとでもいうか借用の瞬間を小さく管理することを覚えるのである
そうして、今まで人類は所有権と借用についていかに無頓着にやり散らかしてきたのかを反省するのである

**デフォルトの名無しさん** · 2022/02/28(月) 16:42:42.62

>>371
それはわかるんだけど
その代償としてプログラマーが支払わなきゃならない代償がデカすぎると感じる
これはコンパイル時の様々なチェックとは本質的に違う努力で
rustを騙すためにやらなきゃならないバッドノウハウの類であると感じる

**デフォルトの名無しさん** · 2022/02/28(月) 17:21:22.82

>>371
GCで困らない、システムプログラミングしない人としては、
そんな面倒な事したくないなって、思ってしまう。

**デフォルトの名無しさん** · 2022/02/28(月) 17:29:54.30

せめてどうにか速くならないかとcargoをRAMDISKにしようとするとCARGO_TARGET_DIR=/tmp/.cargo/...と出来るのは
良いんだけど、コンパイルのためのworkじゃなく、targetディレクトリだから成果物がそこにできてしまうという（笑
速くなるんだけどね。。

**デフォルトの名無しさん** · 2022/02/28(月) 18:10:55.65

>>369
はっきり言ってツリー構造とかはunsafeでいいと思うよ

**デフォルトの名無しさん** · 2022/02/28(月) 18:11:17.29

>>372-373
それはrustがnot for youという話なのでは

**デフォルトの名無しさん** · 2022/02/28(月) 18:13:00.49

Rust持ち上げてる内容を見ると他の言語でも普通にあるやつが多い
C++しか使ったことがないうぶな人なんじゃないかな

**デフォルトの名無しさん** · 2022/02/28(月) 18:19:03.53

頓珍漢で的外れ

型推論も賢い　←　むしろ型推論実装されてて賢くない奴ってどれなんだよ
アトリビュートが言語本体と独立していて　←　当たり前　他でも同じそれが属性

Cargoが良い　←　他より優れているとは思えない

強力な型推論およびトレイト静的実装型宣言により実際の型名を記述する必要がない　←　当たり前　もともとそういうもの

**デフォルトの名無しさん** · 2022/02/28(月) 18:27:45.82

>>374
たしかに中間ファイルのビルドキャッシュはプロジェクト間で共有しつつ、最終生成物はプロジェクト内に出力するオプションがちょっと欲しいな
Goがそういう感じだったかな

**デフォルトの名無しさん** · 2022/02/28(月) 18:31:01.98

そもそもrust自体言語機能が優れていることは標榜してない
他のモダンな言語の "当たり前" をシステムプログラミング領域でも実現したというのがポイントでは

**デフォルトの名無しさん** · 2022/02/28(月) 18:37:53.82

エ、エラーメッセージが親切…

**デフォルトの名無しさん** · 2022/02/28(月) 19:04:01.39

>>380
GCなく高速で動く便利なプログラミング言語が登場したことが非常に大きい
そこへ加えて強力な静的型付けにトレイトの枠組みが加わりプログラミング開発の生産性が大きく上昇

**デフォルトの名無しさん** · 2022/02/28(月) 19:09:23.31

せやなあ
あくまでRustの重要なところはオーバーヘッドが少なく比較的安全に、システムプログラミングやベアメタルプログラミングが行える処理系だというところだよね
この特徴だけでも他の言語と大きく差別化されるけど、モダンな型システムも便利だから低レベル以外のレイヤーでも使いたがる人がいる、って感じよね

**デフォルトの名無しさん** · 2022/02/28(月) 19:14:51.86

>>380 みたいなのを見ると安心するけど、
>>381-383 みたいなのを見ると新興宗教団体のように見えるのがRust

**デフォルトの名無しさん** · 2022/02/28(月) 19:23:32.63

381はおちょくりだし383は380と同じことを言っているだけのような
382は自分の主張を繰り返すだけの人

**デフォルトの名無しさん** · 2022/02/28(月) 19:38:39.03

>>380で終わっておけば「今週末ちょっとRustやってみようかなぁ」になるけど
>>381-383が続くことによりくどくなり、「うへぇ・・・Rust関わりたくねぇ」になりそうってこと

壁からちょっと手を出すと子猫が飛びついてくるけど
全身見せて手を差し伸べようとすると逃げていくのと一緒

**デフォルトの名無しさん** · 2022/02/28(月) 19:46:15.31

ムリに関わる必要はないし
誰もそれを強いてはいないぞｗ
あの言語はC++で苦しんだ連中が手を伸ばすもんだよきっと

**デフォルトの名無しさん** · 2022/02/28(月) 19:52:14.78

うちの場合だけどスクリプト言語からRustにして良かった点
・型を中心とする強力な言語機能による開発効率の大幅上昇
・メモリ省力化と高速化CPU負荷激減によりサーバー/クラウド等リソースとコスト大幅削減
・アプリやシステムなど反応速度も高速になり様々な利用者が快適となった

**デフォルトの名無しさん** · 2022/02/28(月) 20:12:49.15

スクリプト言語から移行出来るような高機能なデファクトのフレームなんてRustにあったっけ・・・

**デフォルトの名無しさん** · 2022/02/28(月) 20:26:42.23

I/O待ちが大半なWebアプリじゃなくて
I/O処理やデータ加工が主体な処理なんじゃない？
そういうのでもスクリプト言語で書かれてるケース結構みるし

**デフォルトの名無しさん** · 2022/02/28(月) 20:33:18.52

>>390
そんなしょうもないケースわざわざRustにしたらメンテする人いなくなるだけ
そもそも>>388以外が答えても意味ない

**デフォルトの名無しさん** · 2022/02/28(月) 21:27:33.71

「コンパイル時に参照が決まらないデータ構造に対して解決にはなってない」のがrustのいけてないところ
ここにたどり着いた俺を褒めてくれ

**デフォルトの名無しさん** · 2022/02/28(月) 21:27:36.69

過剰アンチも異常者に見えるからやめといたほうがいいぞ

**デフォルトの名無しさん** · 2022/02/28(月) 22:17:24.10

>>392
バグがあるとしたらそこが怪しいって絞り込めるだけで十分。
しかもそういう参照が決まらない場所なんて限定的だし

**デフォルトの名無しさん** · 2022/02/28(月) 22:21:48.16

CPU セントリックな処理じゃないの？
少数の同じデータを繰り返し使うような、行列処理みたいな

Ruby on Rails みたいな、全ての関数が平均的に呼ばれるようなものは、
どうにもならないでしょ？

例えば、Ruby JIT で、1万個の関数を機械語にコンパイルしても、対して速くならない

手続き中心処理はダメ。
データ駆動型じゃないと、速くならない

**デフォルトの名無しさん** · 2022/02/28(月) 22:49:27.28

>>395
そういうのにスクリプト言語を選択してるのがおかしいだけで、Rustでなくても何でも普通に書けばそれなりに速い。
また繰り返しになるがRoRを置き換えられるようなRustのフレームなんてあったっけ？
そもそも>>388以外が答えても意味ない

**デフォルトの名無しさん** · 2022/02/28(月) 23:22:44.01

>>389
各自の分野と対象レイヤーがバラバラだろうから一般的な話になるが
開発のできる普通のプログラマーにとってはほとんどの分野でRustが実用的に使えるようになってるな
しかし切り貼りや書き換えや各種設定などだけでやりくりする似非プログラマーにとってはまだ厳しい

**デフォルトの名無しさん** · 2022/02/28(月) 23:29:23.70

>>392
それはRustが最高速を出すために
ジェネリクスを具体的な型に対してコンパイル時に静的にモノモーフィングするからであって利点の一つ
もちろん稀なケースでは動的にディスパッチしたほうが有利なこともあるのでRustは静的と動的のどちらも選べる

**デフォルトの名無しさん** · 2022/02/28(月) 23:58:18.16

>>396
うちではRoRは使っていません
その階層での汎用的なフレームワーク全体を作るのは大変でしょうが
必要な機能のみを必要な用途に特化して用いていますのでそのようなものを必要としていません

**デフォルトの名無しさん** · 2022/03/01(火) 00:00:29.40

>>399
はい、嘘乙ｗ

**デフォルトの名無しさん** · 2022/03/01(火) 00:02:10.33

>>397
エコシステム完成を宣言！？なんでもござれ？？？？
なわけないだろｗ嘘乙ｗ