次世代言語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/16(水) 19:24:55.51

そもそもがさあ
他の言語のライブラリにあるファイルオープン時に指定したファイルがなければ作って開いてくれるようなオプションないのか？

**デフォルトの名無しさん** · 2022/02/16(水) 19:38:23.34

>>250
それこそクソ構文にしか見えないけど採用してる言語あるの？
Point(x, y) if 0 < x && x < 5 => {
みたいなガード条件書けなくない？

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

C#とかだと複数のプロパティ値を使ったマッチングも当たり前にやっている

**デフォルトの名無しさん** · 2022/02/16(水) 20:09:46.22

>>250
Errはenum Resultのタグだからそれは理解が間違っている

>>251
無くても必要なら一瞬で書けるから困らない
例えば関数にするならこのようになる
fn open_or_create(path: impl AsRef<Path>) -> io::Result<File> {
File::open(&path)
.or_else(|err|
if err.kind() == ErrorKind::NotFound {
File::create(path)
} else {
Err(err)
}
)
}
このようにorを使う方が見やすく分かりやすい
matchでOk(x) => x, となったらorと覚えればよい

**デフォルトの名無しさん** · 2022/02/16(水) 20:25:14.55

なにかミスってない？

**デフォルトの名無しさん** · 2022/02/16(水) 20:58:53.96

C#はここ十年さわってないので分からんけど
> Err(ref error.kind() == ErrorKind::NotFound) => {
みたいに書けるってこと？
そもそもC#にパターンマッチなんかあったやろか？
switchがせいぜいあるだけでは？
あと型もletでdestructできるやつじゃなくて
せいぜい (変数 is 型) でシコシコ調べていくだけでは？

**デフォルトの名無しさん** · 2022/02/16(水) 21:00:56.89

>>250 のkind() は構造体のフィールドとのマッチじゃなくてメソッドの戻り値との比較だから
パターンとして取り扱えるようになるべきではないと思う
構造体のフィールドなら普通にパターンマッチできるよ

**デフォルトの名無しさん** · 2022/02/16(水) 21:07:22.97

>>251
File::options()
.write(true)
.create(true)
.open("hello.txt")
で済む話ではあるから例が微妙というのはあるかもね

**デフォルトの名無しさん** · 2022/02/16(水) 21:19:06.45

見返してみると
Err(ref error.kind() == ErrorKind::NotFound)ではなく

Err( ErrorKind::NotFound)
とかけたほうがいいなと

**デフォルトの名無しさん** · 2022/02/16(水) 21:25:48.26

上のソースは海外の有名なサイト？？？からほぼ丸パクリなんだな
そっちも突っ込みどころ満載のソースなんだけどパクったほうはさらにおかしくなってる

変なところだらけ
これとか
let f = File::open("hello.txt");
let f = match f {

それに引き続いたこれ
match File::create("hello.txt") {

そして
Err(e) => panic!("Tried to create file but there was a problem: {:?}", e),
と
これ
Err(error) => {
panic!("There was a problem opening the file: {:?}", error)
},

**デフォルトの名無しさん** · 2022/02/16(水) 21:30:10.73

>>256
ググればわかる
C#はもう全然別物になってるしこれからも変わる予定

誰得？と思うけど

**デフォルトの名無しさん** · 2022/02/16(水) 21:41:12.68

>>253
Rustでも複数マッチングは当然できる
例えばorの概念
let v = match (p, q) {
　(true, _) => "前者",
　(_, true) => "後者",
　(_, _) => "失敗",
};

>>255
matchをorで書き換えなら254で合ってる
目的達成だけならoptionsを使う258で合ってる

>>259
そういう単純なエラー型を自分で設計して使うならそれでOK
今回は std::io が返すエラーだから Err(struct io::Error { ...(フィールド非公開) }) となる
つまり Err(err) で受けて err.kind() で種別を取り出すことになる
なぜこうなっているのかは理由があるのでソース std/io/error.rs を読むべし

**デフォルトの名無しさん** · 2022/02/16(水) 21:51:01.16

>>260
その変数のシャドーイングも二段階のmatchもpanic!の使用もそれ自体は間違っていない
君は文句をつけることと間違った動かないコードを出すことしかできていない
こちらは改善案として二段のmatchではなくResultをorする>>254というシンプルで動くコードを示した

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

視点がずれてる

変なところが多い=美しくないと言ってるんだけど
意味のあるシャドーイングならわかる
変数使って受けてるのに次ではmatchダイレクト

panicを一行で書いたりブロックをつけて書いたりちぐはぐ

書いた奴は馬鹿なんだろう

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

クソど素人にこれだけ書かれるのは馬鹿なんだろうしそれも理解できないのはどうなんだ？

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

批判だけならバカでもできる
具体的な代案を出せるかどうかが全て
これはどの世界でも同じ

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

いやいや
何を例としてるか全然わかってなかったろ？

具体的に書かれて初めてわかったろ？
そういうところだよ
汚いソースすらわからないんだろ？

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

rusｔ入門サイトにこんなクソみたいなコード乗せるな
Rustの品格が下がる

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

>>267
こちらは具体的な代案を>>254に出した
君は文句をつけるだけで何も生み出せなかった
これが全てだ

**デフォルトの名無しさん** · 2022/02/17(木) 01:06:25.84

rustが汚いって話からサンプルコードが汚いって話にすり替わってるな

**デフォルトの名無しさん** · 2022/02/17(木) 08:14:31.32

>>257
>>250は単一化あたりを想定しているんだろ。
本来なら
Err(ref error),
error.kind() == ErrorKind::NotFound
か
Err(ref error) and
error.kind() == ErrorKind::NotFound
あたりだけど。

**デフォルトの名無しさん** · 2022/02/17(木) 08:14:54.96

もう十分だよ
初心者にありがちな「言語仕様が汚い発言」でしかないのがわかったからもういいよｗ

**デフォルトの名無しさん** · 2022/02/17(木) 23:22:49.91

彼は当初Rustの言語仕様が汚いと主張
それが無理筋だとわかると誰か個人が書いたサンプルコードが汚いと主張を変更
ところがそれも修正案すら示せず敗走か

**デフォルトの名無しさん** · 2022/02/18(金) 11:21:48.86

初心者にありがちな発言
「コンパイラのバグ」
「言語仕様が汚い」
「バリバリ書く」

**デフォルトの名無しさん** · 2022/02/18(金) 11:53:36.75

>>271
それ前者はパターンで後者は条件
だからRustのmatchの『パターン if 条件』がわかりやすい

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

まだ富士山２合目な発言「美しい言語、感銘を受ける」「コンパイラが教師」「初心者にありがち」

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

>>274
Objective-Cだけはマジ言語仕様汚ねーなって思った

**デフォルトの名無しさん** · 2022/02/19(土) 09:03:05.11

Objective-Cはちょっとしか触ったことないけどすこ
mac開発で使ってる人からすると欠点が見えてくるのかな？

**デフォルトの名無しさん** · 2022/02/19(土) 11:31:16.52

記号呪文のオンパレード

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

Objective-Cは、あの突き抜けたキメラ感が好きかな。

**デフォルトの名無しさん** · 2022/02/19(土) 15:13:03.46

Obj-Cそんなに悪くないぞ
RubyのC拡張書いてる感覚に近い

**デフォルトの名無しさん** · 2022/02/19(土) 18:59:30.44

いつもの貼っておきますね

美しきObjectice-C
http://love-motif.com/article/art_13.shtml

**デフォルトの名無しさん** · 2022/02/19(土) 20:52:26.77

そういえばC#やってからJavaに触ると.NETフレームワークの設計が如何によく出来てるかを思い知る

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

OSXが出てから一般向けの参考書が本屋に並ぶとか信じられないことになったが
昔は図書館の奥底まで潜らないと本が出てこなかったり
興味あるけどなんか手を出せる状況になかったなObjectice-Cは
linuxにgnustep入れてちょこちょこっとサンプル動かして満足してた
いやほんとAppleのおかげでだいぶ脚光当たったなマジで

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

Obj-CはどうかしらんけどSwiftはまあ良いと思う
依存がでかいときのビルドはつらすぎだけど

**デフォルトの名無しさん** · 2022/02/20(日) 09:06:02.64

>>283
具体的にどういうところがでしょうか？
興味あります
1つか2つ例を挙げていただけると幸いです

**デフォルトの名無しさん** · 2022/02/20(日) 23:34:18.52

>>283
Javaの何と比較しての話？
標準ライブラリとか？

**デフォルトの名無しさん** · 2022/02/21(月) 03:36:10.49

そいつはC#おじさんだから触っちゃダメ、Goスレでも暴れてる

**デフォルトの名無しさん** · 2022/02/21(月) 15:07:07.57

波かっこによるブロックのため、
　　　　}
　　　}
　　}
　}
でディスプレイを無駄に占有されて可読性が減る事と
文末のセミコロン（C系）やコロン（Python等）強制で無駄にタイピング量が増えるのが嫌なのですが（強制でなければむしろ好き）、
あれらって、どんな魅力が有るのですか？
javascriptでデータ量を減らせて難読化できるメリットはわかりますが・・・・。
ちなみに自分は{}もpython.nimの様なインデントによるブロックで良いと思うし、
function()はfn()で良いし、println()はp()で良いし、arrayOf(1,2,3)は(1,2,3)で良いと思います。

**デフォルトの名無しさん** · 2022/02/21(月) 15:49:13.16

C言語の出始めは関数名とか省略していて可読性悪いとか言われてたなぁ。

**デフォルトの名無しさん** · 2022/02/21(月) 15:58:43.16

C言語が出る前からプログラミングしてたん？
すごい大先輩ですね

**デフォルトの名無しさん** · 2022/02/21(月) 16:38:51.99

記号＝読めない
英単語＝読める
みたいな批判は古いけど今でも一理ある

char **argv;
pointer< pointer<char> > argv;

**デフォルトの名無しさん** · 2022/02/21(月) 16:58:48.39

おいおい
そんなのタイプしたくないよ

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

頻度が高いものほど短くていい
意味不明な記号でもいい
*こそがまさにそれで
*こそがまさにC言語の象徴

**デフォルトの名無しさん** · 2022/02/21(月) 18:20:09.87

>>289
Lispスタイルの }}}} はどう？
シンタックスハイライトや自動インデントなどで後続の文のネストのレベルは適切に調整されるという前提で

**デフォルトの名無しさん** · 2022/02/21(月) 20:53:51.80

>>289
だからおのずと深いネストや長い関数を避けるようになる教育的効果がある。

とかpython信者が言うんだよな

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

どうせお前らは嫁や彼女のおっぱい見てオッパイソンとか内心思ってるんだろ。

**デフォルトの名無しさん** · 2022/02/21(月) 23:34:00.09

Lispは基本すべてが()で
関数の終わりは
))))))
とかなりがち
スーパーカッコ
]
というのも提案されたが流行らなかった
カッコを閉じると対応するカッコを自動で示してくれるのが
よかったのかなあ(viの show match)
プログラムが大きくなるとどっちにしても一画面では
収まらなくなるし

識別子の名前を短くすると一見してなんだか分からないし
プログラムが大きくなるとわけが分からなくなりやすい

一応理由はある。経験則だけど

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

>>295 Lispスタイルという名前がついていたのは知りませんでした。Thanks。
昔、それをやった時に「｛と｝の対応がわかりにくい」 => 「}のつけ忘れで謎のバグを誘発」という結論に達しました。
だから｛と｝で囲む事自体が無い言語が良いなと思っています。もちろんendで閉じるのも面倒です。

>>289 ｛｝でブロック形成する言語のメリットは「対応するカッコにジャンプ」機能が有るエディタでは多少メリットが有りますが、エディタに「ブロックの先頭・末尾に移動」機能が有ればインデントでブロック形成する言語も互角なので、あまり意味がないメリットかもしれませんね。

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

>>299
Lispスタイルというのは世の中にそういう用語があるのではなくて
単にLispでよくやられているように～ということが表現したかっただけ
紛らわしくてすまん

**デフォルトの名無しさん** · 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っぽく書き直しちゃってたら時間かかるのは仕方ない