次世代言語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/

**デフォルトの名無しさん** · 2021/12/02(木) 14:41:59.12

C++の巨大プロジェクトは絶対にメモリ関連のバグがたくさんあるからな・・・。

**デフォルトの名無しさん** · 2021/12/02(木) 14:54:42.94

C++とtypescriptやってる人は大抵rustもやってそう
>>25の意見は正しいと思う
rust推しだったけど意味不明な推しが多くて最近はもうgoでいいって思った

**デフォルトの名無しさん** · 2021/12/02(木) 15:11:50.02

>>31
それはある
強力な型の扱いや関数型言語に近い性質などが非常にプログラミングしやすくてRustは言語のセンスが良い
高速になるとか安全になるとかはオマケとして付いてきたｗ

**デフォルトの名無しさん** · 2021/12/02(木) 15:33:13.06

そこがおまけならnimとかでいいじゃん

**デフォルトの名無しさん** · 2021/12/02(木) 16:27:40.33

Rustはシャローコピーに関する地雷を極めて踏みづらいのはメリットかな

**デフォルトの名無しさん** · 2021/12/02(木) 16:28:07.24

NimはRustのような値付きenum及びそのパターンマッチングがないから使えん
Nimだとオブジェクトバリアントが限界で機能不足

**デフォルトの名無しさん** · 2021/12/02(木) 16:32:00.04

どちらもどうでもいいよそんなの趣味の範疇
オマケだというならgoの圧勝で終わり

**デフォルトの名無しさん** · 2021/12/02(木) 16:38:10.56

Goはそういう点ではNimよりも機能不足

**デフォルトの名無しさん** · 2021/12/02(木) 16:50:11.44

そんなの趣味嗜好の範疇なんだってｗ

**デフォルトの名無しさん** · 2021/12/02(木) 16:50:41.52

パフォーマンスどうでもよくて、そういう好みなら、ScalaとかHaskellが合うかもね

**デフォルトの名無しさん** · 2021/12/02(木) 17:02:19.38

ある意味
Haskellから美味しい部分をもらってきた手続き型言語がRust

**デフォルトの名無しさん** · 2021/12/02(木) 17:12:39.13

そうね、Rustはいろいろなシンタックスが用意されててすごいよ

パフォーマンスがどうでもいいなら、borrow checkerとかで安全にしてるRustより、
GCを使いつつ参照透過性を保つHaskellのほうがいろいろ整然とされてて見通しが良い気がする

まあいろいろ好みや、向き不向きとかあるだろうけど

**デフォルトの名無しさん** · 2021/12/02(木) 17:17:04.28

>>40
Goの機能不足は誰もが認める合意事項
だからこそGo2作っているわけで

**デフォルトの名無しさん** · 2021/12/02(木) 18:08:26.45

Nimも機能少ない方だから、Goでいいじゃんってなりがち
そういう意味ではGo/Rustの次世代って難しいな
GoとRustでシンプルと複雑の限界まで振ってあるから
その中間解を取ってしまうと中途半端になるという

**デフォルトの名無しさん** · 2021/12/02(木) 18:51:26.15

goはテンプレート有れば私的には文句ねぇが現今のinterfaceのアプローチと異なる且つ重複する部分が多くきな臭いよね
ただまぁあそこまで洗練されたcoroutine featureは他に見ないしgcの改良だけでもいいかなとも思う

**デフォルトの名無しさん** · 2021/12/02(木) 19:24:47.38

nimはオリジナリティがなく器用貧乏な感じ
golangだけでなくどの言語も独自の進化を続けているだけで機能不足なわけじゃない
rustは高速性と安全性を取ったら何も残らないゴミクズ

**デフォルトの名無しさん** · 2021/12/02(木) 19:39:44.60

元rust推し装うの笑う
もう流れはとめられんよ

**デフォルトの名無しさん** · 2021/12/02(木) 19:42:44.71

>>47
Go信者は根拠なくデタラメに他言語たちを罵倒するのはどうして？
理解できないから具体的に指摘できないため？

**デフォルトの名無しさん** · 2021/12/02(木) 19:57:21.48

あわしろ氏はRustを使うべきと言ってる。

**デフォルトの名無しさん** · 2021/12/02(木) 21:14:08.06

元々rust推しなのは事実だからなｗ
ただ俺が推してるのはごくごく一部の高スループットや巨大データを扱うサーバーやデータベースなどの分野であって
OSなどハード寄りや普通のアプリで向いているとは思っていない
rustの流れなんて誰も作ってないし意識もしてないと思う
自然に流れが出来るなら流れに任せるけど違和感しかなければ推せなくなる
根拠がないのは客観的な話ではなく、主観をそのまま言ってるからだよｗ
あと俺はgo推しじゃないし、汎用なやつだと消去法で総合的にgoのコスパが一番いいと思ってるだけ

**デフォルトの名無しさん** · 2021/12/02(木) 21:28:41.46

>>51
具体的にRustを使って何が問題なのかをどうぞ
コピペでは無理な具体的かつ詳細な説明をお願いします

**デフォルトの名無しさん** · 2021/12/02(木) 22:01:59.81

Nimは言語自体の機能は必要最低限にしてtemplateやmacroでユーザが自由に言語の機能を拡張できるようにしようという考えだから。

**デフォルトの名無しさん** · 2021/12/02(木) 22:14:35.17

分かるだろｗ議論しても荒れるだけだから無駄
大雑把に言って初心者に難しい理由の説明しづらいルールが多いから一般向けに流行らないということ
nimについてはそうだね

**デフォルトの名無しさん** · 2021/12/02(木) 23:08:40.70

ゴミクズとまで言い切った割には普通の話だな…
PythonやJSから入った初心者に勧めるならそりゃGoだろう

**デフォルトの名無しさん** · 2021/12/02(木) 23:59:00.94

そうだよ大雑把な話でないと定義や粒度が合わなくてそもそも話せないからな
あとrustから「高速性と安全性を取ったら」って前提を抜かないでゴミクズだけ引用しないでくれ

**デフォルトの名無しさん** · 2021/12/03(金) 00:16:18.89

こいつネット記事で聞き齧った程度の
浅いことしか言えてないし
実際はrustで hello world 書いたことすら無さそう

**デフォルトの名無しさん** · 2021/12/03(金) 00:17:26.23

遅くて安全じゃない言語は元がなんであれゴミクズなんでは...

**デフォルトの名無しさん** · 2021/12/03(金) 04:23:17.06

何をもって「安全」とするのやら
非同期回りも含めるとスクリプト系だいたい全部アウトになります？

**デフォルトの名無しさん** · 2021/12/03(金) 04:45:15.91

なんのことやらしらんけど、Rustや他の参照透明性のある言語のことを言いたいのかな

**デフォルトの名無しさん** · 2021/12/03(金) 04:47:18.61

安全な言語、について

**デフォルトの名無しさん** · 2021/12/03(金) 08:53:10.36

>>59
マルチスレッドでのデータ競合を入れるならコンパイル型もほぼアウト
実際静的にチェックできるのはRustくらいじゃない？
Goなんかはgoroutineで気軽にデータ競合しうるから、コンパイル時にチェックできるといいんだけどなぁ

**デフォルトの名無しさん** · 2021/12/03(金) 09:07:52.00

で、具体的にお前は何をrustで作ってんの？

**デフォルトの名無しさん** · 2021/12/03(金) 09:14:09.01

>>57
その人とは別人で悪いが、Rustでは最早ハロワを自分で書く必要がない

**デフォルトの名無しさん** · 2021/12/03(金) 09:15:22.04

またしょうもない定義の話になってるし・・・
分かれよｗ変なところに噛み付いてないで自分の意見をちゃんと言え

**デフォルトの名無しさん** · 2021/12/03(金) 12:02:53.40

rustは言語処理系書きやすい
安全性とか高速さは関係なくて代数的データ型が使いやすければ他の言語でも代替はできるとは思うが
rustが一番使い慣れてるのでrustで書いている

**デフォルトの名無しさん** · 2021/12/03(金) 15:17:45.07

データ競合については、Haskellとかも起きないよね

**デフォルトの名無しさん** · 2021/12/09(木) 00:24:44.17

rustは言語仕様以外の点がな..
https://sabotage-linux.github.io/blog/3/
https://blog.adelielinux.org/2017/11/18/our-official-stance-on-the-rust-programming-language/
https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedom_flaws

**デフォルトの名無しさん** · 2021/12/09(木) 01:13:30.58

このスレの言語で挙げられてる問題すべて解決してるものある？
NimはCにコンパイルされるからブートストラップの問題も対応アーキテクチャの問題もなくなるのかな？

**デフォルトの名無しさん** · 2021/12/09(木) 02:43:44.63

これRustなんだね
https://github.blog/2021-12-08-improving-github-code-search/

**デフォルトの名無しさん** · 2021/12/09(木) 12:38:32.33

むしろブートストラップの問題が表面化してる点はもうrustの圧勝って話に見える

**デフォルトの名無しさん** · 2021/12/10(金) 10:43:45.25

>>69
Nim言語のコンパイラはNim言語で書かれているんだけどCコンパイラさえあればビルドできるようになっている。
Nimコンパイラをソースコードからビルドするときは、Nimのコンパイラから出力されたC言語のNimのソースコードのリポジトリnim-lang/csources_v1をビルドしてから最新のNimコンパイラをビルドするようになっている。
https://github.com/nim-lang/Nim#compiling

**デフォルトの名無しさん** · 2022/01/26(水) 05:57:30.61

サーバーサイドは本当にGoが丁度いいな
typescriptと構文にてるし、node.jsから移行しやすいのが最高

**デフォルトの名無しさん** · 2022/01/26(水) 20:59:23.59

NimがGoとRustの間を縫って次世代トップに躍り出る予感
巨大IT企業のバックアップが付けば一気に跳ねると思う

**デフォルトの名無しさん** · 2022/01/26(水) 21:09:35.46

GoやRustと比べると言語としての魅力がよくわからないんだよな。
オフサイドルールスキー専用言語？

**デフォルトの名無しさん** · 2022/01/26(水) 21:25:25.23

Nimなんか別に誰も使ってないし特に期待もされてないでしょ
世の中に山ほどある俺言語の一つに過ぎないよ

**デフォルトの名無しさん** · 2022/01/26(水) 21:59:22.52

Nimはわざわざ選択する理由がないんだよな
楽に書くならGoだしちゃんと書くならRustなわけで
もうちょっと特徴が欲しい

**デフォルトの名無しさん** · 2022/01/26(水) 22:07:13.93

1. 実行速度、バイナリサイズ、メモリ使用量
→CトランスパイルなのでCに近い値

2. 安全性
→メモリ安全性高い

3. 生産性
→スクリプト言語並み

4. 機能性
→シンプルな機能と、強力なメタプログラミング

Nimは1・2と3の両立性が高く、比肩する言語が無い
3と4は常にトレードオフなので正解が無いが、Nimの割り切り方は良い

**デフォルトの名無しさん** · 2022/01/26(水) 22:16:29.06

GoもRustも実行速度とメモリ使用量が大きすぎるし、C/C++は生産性や安全性に問題が大きすぎる
その打開策としてNimを使う事ができる

複数言語を使い分けるよりも、1つの言語でまかなえるならば、学習コストや再利用性の面から越したことはないしね

**デフォルトの名無しさん** · 2022/01/26(水) 22:23:32.14

ただ他の言語と違ってコミュニティが貧弱すぎるのが欠点
言語性能自体とは直接の関係はないが、こればっかりは痛い
大手企業とか人気ソフトに使われる様なきっかけが無いと永遠に人気に火がつかないままだと思う

Go/Dart/KotlinはGoogle、Rust/JuliaはMozila、SwiftはAppleの後押しがあるけど、Nimは一切そういうの無くて、コアな人気だけが細々と支えてる状態

**デフォルトの名無しさん** · 2022/01/26(水) 22:32:35.02

>>79
NimってRustより速くてメモリ使用量少ないの？

**デフォルトの名無しさん** · 2022/01/27(木) 00:32:14.69

>>78
1と2ってGo/Rustくらいの世代だとほぼ標準装備なんだよね
そりゃ多少の優劣はあるだろうがアプリの特性差やプログラマのスキル差から考えると誤差
そうすると構文が一部の人にマッチするって部分しか残らない感じ

**デフォルトの名無しさん** · 2022/01/27(木) 09:11:54.39

Rustのメモリ使用量が大きいとかヤバイな

**デフォルトの名無しさん** · 2022/01/27(木) 09:32:04.47

nimはd言語の二の舞

**デフォルトの名無しさん** · 2022/01/28(金) 09:21:04.21

nimは、goと比べると今風の書き方が出来るのが良いかな。
でも、コミュニティが弱いのが辛い。

**デフォルトの名無しさん** · 2022/01/31(月) 06:52:54.15

https://kdy1.dev/posts/2022/1/tsc-go
tscの型チェック機能をgoで書き直すらしい、vercelが支援してるみたい
初めはテストとしてrustで書き直して型チェック速度が62倍になって
ただ、rustで書き直すのは適していないと考えてgoに移植することを選択したと

フォーラム https://news.ycombinator.com/item?id=30074414

**デフォルトの名無しさん** · 2022/01/31(月) 07:42:59.19

>>86
要約

一部Rustで書き直してテストしたら62倍速となり当然速かったけど
tscのコード全体がGCに依存しまくっているため移植ではなく全面書き直しとなってしまう
そこで妥協案としてGCで動作するGoへ移植することにした

**デフォルトの名無しさん** · 2022/01/31(月) 09:04:41.29

こんなもん本家の開発についていけなくなって早晩放棄されるのが目に見えてるだろ
まだRustだったらMSが支援してくれる可能性もあったかもしれないけどね
完全に手段が目的化している不毛なプロジェクトの典型だな

**デフォルトの名無しさん** · 2022/01/31(月) 09:05:57.74

SASS なんて、元々のRuby から、
多言語でも使えるように、C++ のnode-sass（LibSass）へ移植したけど、
開発が難しすぎるから、頓挫した

今は、Dart Sass

Dartもマイナーな言語だし、
TypeScript か何かで作らないと、また開発に行き詰るかも

C/C++, Rust など実行速度が速い言語は、開発が難しすぎる。
可読性が悪く修正できないので、開発費・開発期間が増える

**デフォルトの名無しさん** · 2022/01/31(月) 10:12:07.29

>>89
C/C++の可読性の悪さは
Rustで改善されていてとても使いやすくなっている
GC依存で設計された既存システムをそのまま移植するのは無謀だが
最初からGCに依存せずに設計が可能でありRustなら可読性が問題になることはない

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

自分はRustのCargoとその気になればunsafeで自由に書けるのが気に入ってる
Rustはとにかく美しいと思うな

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

たしかに、Cargoらへんのエコシステムに関してはC++とは勝負にすらならないな
npmを反面教師にしたのかな、よくできてるよね

**デフォルトの名無しさん** · 2022/02/01(火) 14:13:16.30

Rustが美しいと思うのはどういう点なのか、具体的に聞きたくなる。これはC/C++と比べてる話じゃなく現代的な言語の話で
無駄にタイプ量が多くマクロと言語が一貫してなく、アトリビュートも独立しおり言語との一貫性が全くない

**デフォルトの名無しさん** · 2022/02/01(火) 14:17:41.49

例えば const fnやコンパイル時定数などはコンパイル時にコードを動かして計算したりするが、一方でアトリビュートで
#[cfg(unix)]とかやったりして思想がバラバラ、まあ破綻はしてないしC/C++のマクロなんかと比べれば100倍ましだけど

**デフォルトの名無しさん** · 2022/02/01(火) 14:19:22.77

>>93
型推論も賢く強力な静的型付け言語なのにタイプ量は少ない
アトリビュートが言語本体と独立していて区別しやすくプログラミングする上で見やすい

**デフォルトの名無しさん** · 2022/02/01(火) 15:56:11.68

>>93
マクロと言語が一貫してる言語ってどういうイメージなんだろう
Lispしか思い浮かばなかったけどさすがに違うよね

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

>>92
Cargoが良すぎて今まではちょっとしたスクリプトをPythonで書いてたのだけど
そういうのも全部Rustで書くようになってしまった

>>93
むしろこのアトリビュートが好きで
同一ファイルにtestをちゃちゃっと書けるのだったり
あーこれこれ、こういうのが欲しいんだよってのがほぼ全て揃っている

大小様々なソフトウェアを書くためにやっと人類が手に入れた言語かなって
だがなんかマンセーしすぎてスマソ

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

Rustの長い長い型名
https://qiita.com/mp2147483647/items/4cc56b0cc80369828a88

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

>>93
マクロはRustの言語ルールを満たしていなくてよいところが要点
その定義文法も変換が主たるものだから別記法が理に適っている

>>98
Rustは強力な静的型付けにより安全と効率を両立させている
結果としての型名が長くなることがあっても
強力な型推論およびトレイト静的実装型宣言により実際の型名を記述する必要がない
その例は極端な特殊な例にも関わらず同様にして最終型名を記述せずに済んでいる

**デフォルトの名無しさん** · 2022/02/03(木) 02:33:37.86

もしかしてrustってめちゃくちゃ完成度高くね？
バックエンドだけじゃなくて
wasmでブラウザのフロントエンドにも進出してくるっぽいし
typescriptのシェアも奪いそう

**デフォルトの名無しさん** · 2022/02/03(木) 11:10:49.98

Go人気らしいけど嫌い
やっぱりC++使いはRustに行くべきなんかな

**デフォルトの名無しさん** · 2022/02/03(木) 11:48:25.31

Rust、アルゴリズム書くのに超絶向いてないよ。

**デフォルトの名無しさん** · 2022/02/03(木) 13:51:46.29

アルゴリズム書くのは普通疑似言語でやるわな

**デフォルトの名無しさん** · 2022/02/03(木) 17:00:23.94

>アルゴリズム書くのは普通疑似言語でやるわな
何言ってんの？

**デフォルトの名無しさん** · 2022/02/03(木) 18:00:00.71

アルゴリズム自体の記述には自然言語か疑似言語かpythonみたいなスクリプト言語使うのが多いのでは

｢アルゴリズムを書く｣ってアルゴリズムを使ったプログラムを書くという意味？
そうだとしたら対象が広すぎるのでもうちょっと具体化して欲しい

**デフォルトの名無しさん** · 2022/02/03(木) 18:01:17.86

そんなしょーもない誤魔化しはしなくていいよ。

**デフォルトの名無しさん** · 2022/02/03(木) 18:07:41.52

アルゴリズムと一概に言ったってソートみたいなのは別にrustでも普通に書けるでしょ
どういうアルゴリズムを実装しようとして困ったのか教えて欲しい

**デフォルトの名無しさん** · 2022/02/03(木) 18:24:36.45

じゃあB-tree、赤黒木、ダイクストラ、フィボナッチtree、なんでもいいから書いてみりゃいいよ。

**デフォルトの名無しさん** · 2022/02/03(木) 18:28:40.55

木構造やグラフ構造が書きづらいって話かな

**デフォルトの名無しさん** · 2022/02/03(木) 18:59:23.99

変な日本語だな
アルゴリズムの勉強には向いてない、ということを言いたいんだろうけど

**デフォルトの名無しさん** · 2022/02/03(木) 19:05:25.62

どうでもいいイチャモンづけにこだわるやつだな。。
だから実際組んで見ろって。。何もしないくせに。

**デフォルトの名無しさん** · 2022/02/03(木) 19:12:44.13

新しいrustの弱点の話聞けるかと思ったら結局いつものグラフ構造の話だったので興味を失ってしまっただけです

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

>>112
Rustでキューとかスタックとかって便利に使えるの？

所有権の関係で、要素をいじるときはpopしてから操作するのかしらん？

**デフォルトの名無しさん** · 2022/02/03(木) 19:34:47.62

>>113
普通は get_mut に類するメソッドが用意されててコレクションから取り出さなくても編集できるはず
同じコレクション内の他の要素への参照を持たせようとすると難しいかもね

**デフォルトの名無しさん** · 2022/02/03(木) 19:51:02.49

>>114
サンクス。
さすがにスタック・キュー(所有者)に要素の操作を移譲するようなことはしないか。実用上は妥当なところか。

**デフォルトの名無しさん** · 2022/02/03(木) 19:57:30.61

>>113
言語と切り離して論理的に考えた時に
安全な構成と操作ならばRustでも簡単
危険な構成や操作ならばRustでは出来ない(unsafe使えばCと同じ操作が可能)

さらに加えて
危険な構成や操作に成り得るが
限られた一貫した用い方をしている限り安全な場合
新たな型を作って危険な操作を内部に閉じ込めてしまい
安全な操作のみ外部に提供することで利用者はunsafeを用いずに済むことができる
Rustの標準ライブラリもそのようにして作られている

**デフォルトの名無しさん** · 2022/02/03(木) 23:53:53.52

>>112
毎回そうやって曖昧にして逃げてるんだね。進歩ないね。

**デフォルトの名無しさん** · 2022/02/04(金) 00:36:32.80

>>117
そこはグラフも表現できないクソ雑魚言語乙ってあおるべきなのになんで下手くそな人格攻撃してしまうのか

**デフォルトの名無しさん** · 2022/02/04(金) 12:24:28.50

具体的にするならミュータブルなグラフ構造をスレッドセーフに扱うのは人類が思っている以上に難しいことで、それを言語側の制約で扱うならこうならざるを得ないくらい難しい問題だ、ということではないの？

**デフォルトの名無しさん** · 2022/02/04(金) 13:24:42.43

例えば何かノードをたどっている最中にいつの間にか戻り先が変わってるとかいちいちケアしてコード書けないから、結局排他処理やスナップショットすりなんらかの工夫が必要
データ構造の操作だけ完璧に仕上げても応用きかないからそこまで深く考える必要ない

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

そうね
スレッドセーフを諦めれば他の言語に近いくらいに簡単にできるのではないか

**デフォルトの名無しさん** · 2022/02/04(金) 15:44:53.55

C言語→Rustするトランスパイラーですべて解決じゃね？
Rustだからメモリも安心安全だぞ

**デフォルトの名無しさん** · 2022/02/04(金) 17:43:24.41

>>95-99
今どきのコンパイル型言語で型推論が強力でない言語なんてありますか？#[attribute(key = "value", value2)]とか書いててタイプ量は少ない？
最近は自作のアトリビュートが書けるようになりましたが、普通は言語サブセットは小さくして、そのサブセット言語でアトリビュートを実現してれば
このように無理やりカスタムアトリビュートを出す必要はなかった。
一番の最低なところはCargoだと思う、これのせいでコンパイルが異常に遅い。Pythonでもpipやデコレーターはありますがホントにマンセーですね
マクロの定義文法も変換が主たるものだから別記法が理にかなっているとの事ですが、設計段階では、そんな事は一言もホアレは
言ってません。0.2でクラスが導入され、0.3でインターフェースが導入され、0.4でトレイトが出来てクラスが削除された。1.0以降も酷い互換性の
破壊が続いて、安定しだしたのは1.20以降です。
個人的に気に入らないのはfunctionはfnとするのにmutableはmutと使用頻度が高いものがfnよりタイプ量が多い事。「::」も無意味に
2回打たせる意味が分からない。アトリビュートも#[...]とか異常に無駄。ほかの言語のようにパターン束縛表現があるので@は使えませんが
「#」だけで良いでしょう・・・
確かにマクロ呼び出しは「!」とわざと区別するように思想が影響していますが、マクロ中の$はマクロ展開ではコンパイラを単純化させて
コンパイルを速くするためだけにプログラマへ負担を押し付けているだけです。ただ「!」もNeverと別の意味があり、暗黙の型強制なんて
わざと敷居を高くすることに言語設計者は考えているとしか思えない
Occamで最初のバージョンが作られたけど、インデントスタイルのオフサイドじゃなくC/C++風にしたのは、好みで｛｝スタイルを好む人が
多いから（タイプ量は増えますが）許容範囲でしょうが・・・

**デフォルトの名無しさん** · 2022/02/04(金) 17:50:56.66

趣味・好みじゃなくて問題があるという話なら
なぜ本家じゃなくここに書くw

**デフォルトの名無しさん** · 2022/02/04(金) 18:12:52.54

0.2からおっかけてたのならattributeの文法議論の時にそれ主張しとけば良かったのに

あとcargoのせいでコンパイルが遅くなるというのはどういうこと？
パッケージマネージャーがあるせいでcrateが細分化されてリンク時間が延びることを言いたい？

**デフォルトの名無しさん** · 2022/02/04(金) 19:21:26.70

>>123
Rust 1.0がリリースされた2015年よりも昔の0.x時代の話で叩いても無意味ですぜ
あとは1文字タイプ量が多いとかどうでもよい話ばかり
言語機能については批判がないということはRustの優秀性を認めてるわけか

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

Rust並に実行速くて
Rustよりもプログラミングしやすい言語がない
結果として現時点でのベストな選択肢はRust

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

c言語の型宣言も後置にしてくれねーかな。

**デフォルトの名無しさん** · 2022/02/05(土) 08:13:51.74

Rustの唯一の欠点は、メモリ管理をしないといけないところだな。
ここも選択肢を用意してくれれば良いのに。

**デフォルトの名無しさん** · 2022/02/05(土) 10:00:32.68

手動でメモリ管理したい人向けの言語に何言ってんだ

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

そうは言っても、メモリ管理したい人って需要少なくない？
今のままでは、C.C++代替以上にはなれない気がする。