21/08/22 09:45:11.46 vEK5NNFF.net
スレタイの言語はNim以外はどれも現役世代だね
3:デフォルトの名無しさん
21/08/22 10:27:07.87 QorwbXcj.net
永遠に次世代？
4:デフォルトの名無しさん
21/08/22 10:31:36.24 0Cz6ueFz.net
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています
Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます
Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ
なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？
Nimの実験的特徴 バージョン1.5.1
URLﾘﾝｸ(nim-lang.github.io)
第二プログラミング言語として Rust はオススメしません Nim をやるのです
URLﾘﾝｸ(wolfbash.hateblo.jp)
Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる
「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます
5:デフォルトの名無しさん
21/08/22 10:40:01.99 A59qHoiu.net
>>4
このコピペ難読性が高い
6:デフォルトの名無しさん
21/08/22 10:42:34.82 23z7MXhT.net
>>4
NimはGCがあるからC++やRustの立ち位置には立てないよ
7:デフォルトの名無しさん
21/08/22 11:47:58.60 F7Qbx3up.net
NimやるならGoでよくね？ってなる
8:デフォルトの名無しさん
21/08/22 12:02:38.26 TsBps+dy.net
▼スレタイランキング
1位：Rust（21回 Part1～）
2位：Go（15回 Part1～）
3位：Kotolin（14回 Part4～）
4位：TypeScript（14回 Part7～）
5位：Swift（10回 Part7～）
6位：Haskell（7回 Part7～）
7位：Scale（5回 Part1～）
8位：Elixir（4回 Part1～）
9位：Dart（3回 Part9～）
10位：Julia（3回 Part14～）
11位：Erlang（2回 Part1～）
12位：Nim（2回 Part21～）
13位：Crystal（1回 Part14～）
14位：Bosque（1回 Part17～）
15位：V（1回 Part19～）
9:ハノン
21/08/22 12:03:30.88 .net
>>8
説明を求めます
10:デフォルトの名無しさん
21/08/22 12:09:40.80 TsBps+dy.net
>>9
このスレのスレタイに入ってる言語はスレを立てる人が次世代だと思う言語を自由に入れていい
このランキングはスレタイに入った言語を集計したもの
○○回は入った回数、Part○～は初出のスレ番号
11:デフォルトの名無しさん
21/08/22 12:13:56.42 0Cz6ueFz.net
>>970
マクロのシンタックスを別で覚える必要がない
Rust のマクロは構文が全く変わってしまいます。
そしてそれは脳が全力で受付を拒否する素敵な仕上がりとなっております。
公式で自ら「マクロベースのコードの欠点は、組み込みルールの少なさに
由来するそのコードの理解のしづらさです。」と言いのけちゃう代物で
「なんじゃそりゃ」と言う言葉しか出ません。
Nim は構文がそのまま使えます。なので強力なマクロを使いこなすための
障壁の低さは比べ物になりません。
12:デフォルトの名無しさん
21/08/22 12:18:13.68 pVXVequb.net
>>7
NimのライバルはGoやね
13:デフォルトの名無しさん
21/08/22 12:31:26.49 0Cz6ueFz.net
>>970
Rust の良いところ
さすがに Rust を批判ばかりしていては公平性に欠ける報道となり官邸から怒られます。
Rust にも良いところはあります。
fn <- 短い！
proc <- 長い！
これはメリットですよ。タイプが2回ずつ減るのは素敵なことです。
しっかしこれだけ馬鹿げた冗長さを押し付けてくる言語のくせして、
何故ここだけすっきりしているのやらさっぱり意味がわからないです。
あ、結局ディスってもうた・・・。
14:デフォルトの名無しさん
21/08/22 12:43:28.59 9KEf5rUH.net
>>13
まともなプログラマーはタイプ数を気にすることはない
それよりも目的毎の機能性質で使い分ける
functionと長い言語もあればCやshのように0文字の言語もあるがタイプ数で何かを決めることはない
15:デフォルトの名無しさん
21/08/22 13:54:26.77 cx6/dnxW.net
Cで充分
16:デフォルトの名無しさん
21/08/22 14:45:49.07 1RKLPni9.net
func を fn とするだけで開発効率が上がると思ってとかどうしようもない馬鹿だろ。
17:デフォルトの名無しさん
21/08/22 14:48:48.39 1fJ/nSvN.net
Nimの最新のガベージコレクタARC(Automatic Reference Counting)は参照カウンタ方式でRustのRc<T>やC++のstd::shared_ptr<T>と似たようなもの。
C++のshared_ptrと違ってカウンタはatomic intじゃないので複数スレッドから共有はできないけど高速にカウントを増減できる。
Move semanticsによって余計なコピーが発生しない。
変数が不要にったところに自動的にデストラクタが挿入されるのでメモリが解放されるタイミングは決定論的に決まる。
(他の言語のガベージコレクタのように実行するたびに違うタイミングでメモリが解放されることはない)
前スレで勘違いされていたけど、NimのView typesやRustのボローチェッカーって
スタックから消された変数とか解放されたヒープを間違って参照したり書き込んだりを
防ぐものでメモリリークを防ぐものではない。
Nimはガーベージコレクタ、Rustはスコープから出たらメモリ解放するとか参照カウンタを使って
メモリリークしないようにしている。
NimでARCを使っておけばガベージコレクタのコストは参照カウントの増減だけなので
パフォーマンスに影響することは殆どない。
NimをGC無しで使う必要性はほんどない。
Nimを組み込みに使っている人もいる。
18:デフォルトの名無しさん
21/08/22 14:51:17.95 1fJ/nSvN.net
NimのARCに関する情報
nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html
Nimを組み込みに使っているプロジェクト
github.com/PMunch/badger
github.com/exelotl/natu
github.com/clj/nim-esp8266-examples
19:デフォルトの名無しさん
21/08/22 16:20:01.00 5RAXclM6.net
結論
NimをGC無しにすることは不可能
つまりC/C++/Rustの代わりに用いることはできない
20:デフォルトの名無しさん
21/08/22 17:01:59.91 emx92kjF.net
Cはスタックを無しにすることは不可能
つまりアセンブラの代わりに用いることはできない
21:デフォルトの名無しさん
21/08/22 17:11:25.30 BUYgKjYJ.net
>>17
嘘つき
参照カウンタ方式はコストが高いので、
Rustでは必要最小限の部分でのみ、プログラマーが明示的にRc型(Reference counter型)を指定した時だけ使われます。
Rustでは通常時は参照カウンタなんて使われません。もっと高速に動作します。
22:デフォルトの名無しさん
21/08/22 17:36:42.19 0Cz6ueFz.net
>>4
技術書典に出会っていなかったら俺はNimをさわってないと思う
背景
俺たち「そろそろ技術書典に参戦するか」
俺たち「何書く？」
俺たち「マイナー言語を触ってみよう。言語選択は早い者勝ちね」
ワイ「(マイナーの定義はさておき)Nimでオナシャス」
ワイ「(アドカレあるし、記事まとめておくかぁ...)」
Nimとは？
Nim は アンドレアス・ランプフ氏によって設計・開発された命令型、マルチパラダイム、
コンパイル言語という特徴を持つプログラミング言語です。
アンドレアス・ランプフ氏は3DICC社に所属するエンジニアです。彼はNim開発以前に様々
な言語を触っていたようです。が、どの言語も満足せず、自身で作成することにしたようです。
それがNimプロジェクトの始まりで、2005年頃のようでした。
当初NiｍはNimrod(旧約聖書の登場人物)という名前でしたが、マーケティング上の理由から
2014年12月29日にリリースされたバージョン 0.10.2 からNimに変更されました。
23:デフォルトの名無しさん
21/08/22 17:38:20.64 9u04hent.net
Nim ARCは全て参照カウンタ方式になってしまうからパフォーマンスに影響が出て不利だね
24:デフォルトの名無しさん
21/08/22 17:58:26.12 sVqTe99t.net
Rustでグラフ構造を作れないとか言いそうな奴に
ARCでグラフを作らせたら駄目だろ常識的に考えて
25:デフォルトの名無しさん
21/08/22 20:28:01.36 A59qHoiu.net
>>20
ちょっと意味が分からない
26:デフォルトの名無しさん
21/08/22 21:04:38.19 +3UN9nhX.net
つまりレジスタだけ使ってのプログラムってことだろ。
そんなんやる必要ほとんどないが。
27:デフォルトの名無しさん
21/08/22 21:13:45.05 nqrywZna.net
本当に知らない人のために言うと、全部ブログ記事のパクリ
なので相手にしてもマトモなレスが返ってこない。無視で良いよ
28:デフォルトの名無しさん
21/08/22 21:21:33.85 0Cz6ueFz.net
>>4
Nimの特徴
直感的でわかりやすいシンタックス
公式サイトの記載からNimの特徴を見てみましょう。
以下は公式サイトに掲載されているNimのコード例です。
Nimの最初の特徴して挙げられているのが、そのシンタックスで、曰く「直感的でわかりやすい」とのことです。
Python(のインデントを含めた多くの特徴)やPascalを参考にしているらしいので似ていると思いますが、シンプルですね。
import strformat
type
Person = object
name*: string # Field is exported using `*`.
age: Natural # Natural type ensures the age is positive.
var people = [
Person(name: "John", age: 45),
Person(name: "Kate", age: 30)
]
for person in people:
# Type-safe string interpolation.
echo(fmt"{person.name} is {person.age} years old")
29:デフォルトの名無しさん
21/08/22 21:27:47.34 A59qHoiu.net
>>26
アセンブラだってスタック使うでしょ？
30:デフォルトの名無しさん
21/08/22 22:19:09.36 8ga57bIU.net
>>29
組込みだとRAMチェックが終わるまではスタック使わないとか普通にあったりする
31:デフォルトの名無しさん
21/08/22 23:42:29.56 A59qHoiu.net
>>30
ほー、なるほどね
だからって>20はおかしいよね
32:デフォルトの名無しさん
21/08/23 00:53:35.51 dRBSj4mI.net
アセンブラは型がない
アセンブラだけで作ったライブラリも可読性のためにはCの型を宣言する
宣言したらもうCのライブラリとして利用可能にするだろ常識的に
つまり旧世代言語のコードを減らすとかいうおかしな目的意識の代わりに
ライブラリを増やすという適切な意図がある
33:デフォルトの名無しさん
21/08/23 01:09:17.02 PPErbdyj.net
そこはCもC++もRustも同じでアセンブリ含めて相互に呼び出し可能
だったらコンパイル通った時点でメモリ安全性を保証できるRustで基本的に書いてどうしても必要な部分のみアセンブリというのが現在の流れ
34:デフォルトの名無しさん
21/08/23 03:28:42.97 UerQU9YF.net
型付けアセンブリ言語という研究かなり昔にあったよね？
どうなったの
35:デフォルトの名無しさん
21/08/23 05:35:18.87 js8xmVB9.net
>>31
おかしくないよ、そういうコードはアセンブラでないと書けないから
36:ハノン
21/08/23 05:39:50.18 .net
一応 MASM には型はありますが？
37:デフォルトの名無しさん
21/08/23 06:59:34.18 53a1qHWJ.net
>>34
masm とかでも構造体を定義できたりするけどやればやるほどC言語で良くね？とかなりがち
38:デフォルトの名無しさん
21/08/23 13:47:20.63 Rq8RLuIS.net
どうせWEB屋が好きな/使ってみたい言語ランキングでしょ
39:デフォルトの名無しさん
21/08/23 18:03:58.81 Rrt4HCug.net
nim もっとカッコイイ名前が良かった
julia よりマシだが
40:デフォルトの名無しさん
21/08/23 18:27:25.22 w0EZLKOJ.net
GoもRustもNimもJuliaも検索性わるすぎるんよー
41:デフォルトの名無しさん
21/08/23 19:25:50.37 zx6dvezD.net
Cは？
42:デフォルトの名無しさん
21/08/23 21:15:07.01 4kP0uHrS.net
>>35
せいぜいCで代替できないケースもある、だな
「代用不可」は言い過ぎ
43:デフォルトの名無しさん
21/08/23 21:19:05.15 Rok9YfeI.net
C/C++/Rustは中でアセンブリ書けるので大丈夫
どうしても必要な部分がある時は使われている
44:デフォルトの名無しさん
21/08/23 21:38:44.27 7bphh6MO.net
>>42
スタック無しが要件なら代替不可
そうでないならあんたの言う通り
45:デフォルトの名無しさん
21/08/23 22:01:28.04 S3FojqMf.net
>>39
G. M. Julia 「……」
URLﾘﾝｸ(ja.wikipedia.org)
46:デフォルトの名無しさん
21/08/23 23:23:44.42 A8ur8654.net
>>34
それに近いのがllvm ir
47:デフォルトの名無しさん
21/08/24 00:13:51.84 +0eKMgme.net
wasmとllvmって
どうしても必要とは言えない所でアセンブラ使ってるよな
48:デフォルトの名無しさん
21/08/24 01:00:35.96 Fpbrw/6U.net
>>44
もうトートロジーに陥ってるじゃん…
無理しないで>20は命題として偽だって認めなよ
49:デフォルトの名無しさん
21/08/24 05:37:31.25 IO38Iq2z.net
>>48
ああ、それでいいんじゃね？
別にお前がそう思うのは自由だし
50:デフォルトの名無しさん
21/08/24 06:23:15.51 hoyVPhaC.net
>>21
>>23
NimはGCがあるから遅いと言っている人はNimではすべての変数がヒープ上に確保されると勘違いしているのでは。
基本的にはNimでヒープが確保されるのは組み込み型のstring、seq[T]とref型とクロージャがキャプチャした変数を入れるenvironmentだけ。
seqはC++のstd::vector, Rustのstd::vecに相当するもの。
最適化で実際にはヒープに格納されない場合もある。
C/C++/Rustと同様に関数内でvar x = 1と書いたらその変数はスタックに作られる。
以下のコードのようにobject型をrefをつけずに作るとヒープは確保されない。
NimとC++でCircleオブジェクトとPointオブジェクトを作って与えられた点が円の内側にあるかどうかテストするプログラムを作った。
最適化をオンにするとNimもC++と同様にtestCodeはレジスタだけを使って計算するコードを出力している。
godbolt.org/z/fG7cbcq8P
godbolt.org/z/G7Yf6nd34
以下のコードでは変数名sでseq[Circle]を作っている。
seq[Circle]はヒープにオブジェクトを格納するがCircleオブジェクトのデータはヒープ上に連続して格納される。
なのでseq[Circle]のヒープのアドレスを無理やりfloat配列へのアドレスにキャストするとCircleの内容を見ることができる。
wandbox.org/permlink/AiTKGe0YPkryduPB
51:デフォルトの名無しさん
21/08/24 06:24:41.13 hoyVPhaC.net
このリポジトリではレイトレーサーを様々なプログラミング言語で実装し
実行速度を比較してるがNimが一番速い。
また行数も比較的短い。
github.com/edin/raytracer
こちらでは単語の数を数えるプログラムを様々なプログラミング言語で実装し
実行速度を比較してる。
github.com/benhoyt/countwords
結果として簡単に書いたプログラムではNimのほうがRustより速くなり
最適化したコードではNimがRustより僅かに遅くなる程度。
benhoyt.com/writings/count-words/#performance-results-and-learnings
簡単に再帰関数でフィボナッチ数列を計算するNimとRustのコードを書いてみたんだが
Rustのほうが遅い。
オーバーフローチェック有
Nim 287ミリ秒
wandbox.org/permlink/eHu9IOiFfhMUY66y
Rust 376ミリ秒
wandbox.org/permlink/SHxQij4aj9pYFUZn
オーバーフローチェック無し
Nim 187ミリ秒
wandbox.org/permlink/KM2XOoSHLO9Oy5Rx
Rust 300ミリ秒
wandbox.org/permlink/6SQgnE1rPcUqzfZK
52:デフォルトの名無しさん
21/08/24 09:08:23.82 8IlJ2cew.net
大手IT企業たちをはじめ次々となぜRustを採用しているのかの理由のうち一番大きな点は、
直面しているセキュリティ等のバグの原因の大半がメモリ安全性の逸脱に伴うものであり、
メモリ安全性を保証する論文に基づいたRustがそれら問題点を解決することが明確となっている点にある。
53:デフォルトの名無しさん
21/08/24 10:07:34.07 BT6OtRuy.net
>>52
論文に基づいたメモリ安全性の保証が大きいですね
IT業界の状況
プログラミング言語「Rust」のための「Rust Foundation」設立 -- AWS(Amazon)、Microsoft、Google、Mozilla、Huaweiが創設
URLﾘﾝｸ(japan.zdnet.com)
Facebookが「Rust Foundation」に参加
URLﾘﾝｸ(japan.zdnet.com)
54:デフォルトの名無しさん
21/08/24 14:54:36.93 MFD20u5I.net
>>51
コード読んだ訳じゃないけど1番上のやつnimはコメントにfast inverse square root使ってるって書いてあるし比較できなくね？
55:デフォルトの名無しさん
21/08/29 20:34:53.75 TMfqiUgQ.net
>>52
言ってる事は正しいが実際の理由はそうではないと思う。C/C++に比べればメモリ安全性はその通りだが
多くの言語ではGCがあるためにメモリ安全性をほぼ保障をしているが、わざわさRustを採用するのは
極めて大きいメモリーを扱うプログラムやリアルタイム性を追求される要件があり、それがGCのSTWや
GC時間を無視できないから
56:デフォルトの名無しさん
21/08/30 00:46:35.99 kkNE5PqB.net
メモリ安全性の話にGC持ってくるとは
何か勘違いしてないか
57:デフォルトの名無しさん
21/08/30 10:54:55.14 6iKzd6aE.net
GCに限った話でなくてもUnsafe使えば全部同じ、自身が使ってなくても（速度を出すために）ライブラリで使ってる。
Unsafe使わなくても完全に防げるわけでは無い。これはgoもnimもDも同じ
「大手IT企業たちをはじめ次々となぜRustを採用しているのか」の一番の要因は55の言う通りだと思う
58:デフォルトの名無しさん
21/08/30 11:07:11.50 M/wulqx+.net
>>55
扱うメモリーの大きさは関係ない
応答速度の程度のことをリアルタイム性とは言わない
プログラミングの分野でリアルタイム性という言葉は別の意味を持つ
Rustはリアルタイム性を求めて使われてるわけではない
59:デフォルトの名無しさん
21/08/30 11:19:37.82 laDLLmjr.net
C/C++の移行とJavaやGoからの移行では理由が異なる
現状大半は前者
つまりもともとGCを利用してない分野なので>>55の認識は間違い
60:デフォルトの名無しさん
21/08/31 08:45:13.59 SlncBcTV.net
>>59
現状、SNSなどのサーバーサイドのプログラムでGCのStop The World が遅くて
移行した企業を見たが。見たのは一例だけど。
C++からの移行は、Rustを作ったところのMozilla自身がFireFoxで行ったものが
有名で後は数例だけを聞いた。
61:デフォルトの名無しさん
21/08/31 08:57:06.99 7zPv8PJ6.net
いやいやC/C++でも今で土器は大規模プログラムだとGC使用してる場合がある。Boehm GCや
TCMallocなんてまさにそれ、もちろんカーネルプログラミングやドライバ開発では使用されないが
純粋なC/C++で起こりうる何も考えていないヒープ確保の断片化による肥大化を抑える。ただし
GCの最大時間を指定できるものもあるが、Rustに比べれば確実にこのブロックでメモリー解放が
起こるという予測可能性が無い。
大手IT企業という話であれば、これはカーネルプログラミングなどでは無いだろう。
確かにSTWなどからの低レテンシーやCPUスパイクが小さい事をリアルタイム性とは言わないが
現実として自動運転や大規模ウェブサイトでは、ほんの数十ミリ応答を受け付けない事は致命的で
あり、すべてではないがそういった見方を排除あるいは全否定すべきではない
言語的なバッファオーバーフロー耐性などは１側面に過ぎない。
62:デフォルトの名無しさん
21/08/31 16:03:34.84 pBk/Kvod.net
GCは参照されないオブジェクトを探すだけなので
参照カウントが1か2以上かチェックしたくなったらもうGCは役に立たない
63:デフォルトの名無しさん
21/08/31 16:56:17.54 s/B3pX4y.net
>>61
自動運転の制御プログラムでGC使ってたのがRustに移行した事例あるの？
Discordの事例はレイテンシが致命的だったわけではないぞ
それにサーバーサイドでRustへの移行がペイするDiscordレベルの規模と速度が求められるようなシステムは0.01%もないから
残りの99.99%はどうなのかが重要
64:デフォルトの名無しさん
21/08/31 18:27:45.08 2Z3a814f.net
GCがサーバの遅延原因とわかるなら、重いGCを動作しない設定にしといて
一時的にサービスから外す＞プロセス再起動＞サービス再開
で済む話
65:デフォルトの名無しさん
21/08/31 18:56:45.11 +8DUbqPW.net
そもそもDiscordはC/C++じゃなくてGoだった
GoからC++に変えるよりもGoからRustに書き換える方が良さげなのは何となく分かる
C/C++をRustで書き直したってあるのかね？servoも最初っからRustだったはず
66:デフォルトの名無しさん
21/08/31 19:35:22.26 wuud9+ob.net
数年後rustは糞言語だったって評価されそう
67:デフォルトの名無しさん
21/08/31 19:36:48.62 tid2JAjH.net
C++が既に十分に優れているということを言いたいのかもしれないけど、
C++からRustに書き換えないのは単純に難しいからだと思うぞ
68:デフォルトの名無しさん
21/08/31 20:00:37.49 JHqwYLi1.net
違うよ
既にあるものを移植する案件が少ないだけ
しかし大規模改修や新規案件ではC++を利用する意義がなくなったのでRust採用が多い
もちろんC++だけからではなくFacebookのようにJavaからRustのパターンもある
69:デフォルトの名無しさん
21/08/31 20:56:18.00 Srcy774Z.net
>>65
ChromiumOSやAndroidはコンポーネント単位でRust導入が進んでるプロジェクトかな
あとはcurlがバックエンドをRustにする作業中
70:デフォルトの名無しさん
21/09/01 00:08:09.87 +dwouIiT.net
>>66
糞言語でも広まると糞言語だと言われない場合も多い。
広まってしまったらそれまで。例えばPythonとか。
71:デフォルトの名無しさん
21/09/01 01:35:43.66 GVO/11SU.net
最良言語を目指すやつはすぐ仕様変更するのが欠点だな
Pythonも仕様変更はあったが古いバージョンを虐待しなかったのがよかった
72:デフォルトの名無しさん
21/09/01 03:34:40.38 MtyAaHfZ.net
>>71
Rustはedition制で後方互換性を完全に保証しているから安心して使用できますね
73:デフォルトの名無しさん
21/09/01 06:09:56.27 OZGdMA/h.net
>>65
Firefoxがそうだろ
あと、Windows10の一部もRustに書き換え中ってニュースもあったな
74:デフォルトの名無しさん
21/09/02 15:26:46.45 ONfZsKfr.net
サーバー書くならGoかRustかって感じだけどどっちもパッとしないんだよな
シンプルと複雑の中間が欲しいわ
75:デフォルトの名無しさん
21/09/02 17:59:05.47 PDrIjWiD.net
>>74
無難にいくなら
TypeScript/Node
C#
Java or Kotlin
あたりだろうな
76:デフォルトの名無しさん
21/09/02 18:06:33.02 wNaONt6G.net
Dartはサーバ側でも使ってねとアナウンスあったけど、
クライアント側と同じ言語で書ける以外の利点は特に無いのかな
77:デフォルトの名無しさん
21/09/02 18:11:04.37 2FuyxSW6.net
>>74
複雑？？
イメージだけで語ってるやろ
78:デフォルトの名無しさん
21/09/02 18:37:13.19 6gOJWbCR.net
サーバ用途ならcrystalがええんちゃうかね。rubyをコピーした資産が多そう
79:デフォルトの名無しさん
21/09/02 18:51:33.01 UQhR0inN.net
別に1つの言語に拘る必要なくね
rust導入するとしても丸ごとリプレースする必要はない
80:デフォルトの名無しさん
21/09/02 19:29:02.15 bHl+beee.net
>>71
pythonも2から3への移行はだいぶ苦労したろ。
あれで脱落しなかったのは割と奇跡的だと思うわ。
81:デフォルトの名無しさん
21/09/02 20:00:41.23 XW9HOgOw.net
もしコンパイラ言語ならgccとかllvmも同時に移行しないとコンパイルできなかったりして
82:デフォルトの名無しさん
21/09/02 20:34:58.67 lSTkj0Rg.net
>>80
慌てる乞食は儲けが少ない
83:デフォルトの名無しさん
21/09/02 22:06:53.19 2FuyxSW6.net
AndroidでもRust使うってよ
URLﾘﾝｸ(security.googleblog.com)
84:デフォルトの名無しさん
21/09/03 13:29:52.44 gdUOZxn5.net
Rustの最大の欠点はシンタックス。異論は認めない
85:デフォルトの名無しさん
21/09/03 15:16:50.54 9y+1HwQb.net
>>84
他にも色々あるよ。
86:デフォルトの名無しさん
21/09/03 15:34:17.82 yHlVBJE7.net
誤解を恐れずに言うとRustが嫌われるのはバカには理解出来ない難解さだろ
87:デフォルトの名無しさん
21/09/03 17:09:30.99 K5OdE3wo.net
本質的でない複雑さもあるからね
たとえばRustは標準ライブラリがGoなんかに比べると貧弱なので、自前で実装したりコミュニティのパッケージに頼らざるを得ないシーンが多い
88:デフォルトの名無しさん
21/09/03 18:25:24.07 qtYdCVwr.net
>>86
rustの問題はこういうバカがイキってる所だと思う
89:デフォルトの名無しさん
21/09/03 19:59:54.63 9y+1HwQb.net
少なくとも、全てのアルゴリズムをRustではアプリのsafeモードでは扱えない。
例えライブラリをunsafeモードで書いたとしても。
それが最大の欠点。
書き方が面倒なのが次の欠点。
90:デフォルトの名無しさん
21/09/03 20:30:12.82 33gOMWg5.net
全部unsafeで書けば面倒さは無くなりそう
91:デフォルトの名無しさん
21/09/03 22:16:03.68 9y+1HwQb.net
Rustでライブラリやメソッドを unsafe で書いて、それを safe モードから
使っても、決してCと同じ効率では利用できないアルゴリズムが存在する。
92:デフォルトの名無しさん
21/09/03 22:27:23.15 9y+1HwQb.net
>>91
理由は、Cで昔から至って普通に使われていたアルゴリズムのかなりもののが、
Rustだと借用規則に違反してしまうから。
学問的にも正しくて使い方を誤りさえしなければ安全である事が分かっていても、
Rustでは借用規則に違反するので最初からコンパイルエラーになってしまって
使えない。
それらのアルゴリズムは、unsafeモードの中だけに借用違反を閉じ込めよう
としても無理。なぜんばら、根本的に借用規則に違反していて、
それがそのアルゴリズムの本質で要(かなめ)の部分だから。
93:デフォルトの名無しさん
21/09/03 23:01:26.75 HcIIq6Rh.net
>>84
様々なプログラミング言語と比較しても
Rustの基本シンタックス記法は素直なほぼ標準タイプ
最大派閥のC系と比較してもRustは条件式にカッコが不要なくらいかな
94:デフォルトの名無しさん
21/09/03 23:02:45.90 HcIIq6Rh.net
>>92
嘘つき
未だに例示できないくせに
95:デフォルトの名無しさん
21/09/03 23:30:25.11 EGT6hvvH.net
次にお前は連結リストと言う
96:デフォルトの名無しさん
21/09/03 23:34:16.62 ojcqN+X9.net
ハッシュマップ
97:デフォルトの名無しさん
21/09/04 02:34:46.85 j+KqajCA.net
rustって最終的にはjavaみたいな奴隷専用言語になりそう
98:デフォルトの名無しさん
21/09/04 03:07:14.01 7+Hy81Ja.net
そうだ。rustは君のものだ。
99:デフォルトの名無しさん
21/09/04 04:09:47.08 iqtSb51S.net
たしかにRustは非常に書きやすいしコンパイラのrustcが賢くてミスを直す候補を探し出してきて表示してくれるので便利だけど
奴隷の生産性まで上がるものなのかね
100:デフォルトの名無しさん
21/09/04 04:50:10.07 7+Hy81Ja.net
今の日本はだいたいが奴隷。
URLﾘﾝｸ(oshiete.goo.ne.jp)
> １５世紀のアメリカでは、教育と結婚の権利を与えられ財産を持つことも可能で、低賃金の労働者と言えるものでした。
101:デフォルトの名無しさん
21/09/04 08:12:27.52 elqVYRSe.net
元々、共有やコピー、参照の違いをまともに理解してない奴に限ってrustを評価する傾向にあるのがな。。
はっきり言ってそれをまともに意識してるコード書くやつはそれほど便利だと思ってない。
102:デフォルトの名無しさん
21/09/04 11:12:27.56 EwYrh1qJ.net
>>94
あなたは、数学は出来ないね？
俺は数学は得意だから、例がすぐ浮かぶぞ。
103:デフォルトの名無しさん
21/09/04 11:14:39.89 EwYrh1qJ.net
ヒント:
safeモードに借用規則がある限り、メソッドの中にunsafeを閉じ込めようとしても
絶対に無理なアルゴリズムが存在する。
これが理解できないのは、数学力が足りない。数学力は生まれつきのものが大きくて、
ワーキングエリアの大きさや、想像力の問題。
104:デフォルトの名無しさん
21/09/04 11:17:19.47 EwYrh1qJ.net
なぜ例を提示しないかと言えば、本当のことを教えたくないからだ。
嘘だからではない。
本当のことを教えるのはもっと時間が経った後でいい。
時間が経ったらだんだんと本当の事が広まっていくだろう。
俺は最初からそれがわかるが、分からない人は分からない人なりの人生を送れば
いい。それが俺の才能だから。
俺の才能を全ての人に分け与えるわけにはいかない。
105:デフォルトの名無しさん
21/09/04 11:20:31.21 EwYrh1qJ.net
コンピュータの世界は、どんなに頭のいい人でも時間が経てば追いつかれる。
平易に解説されたり、または、ライブラリなどが難しいことを閉じ込めて
誰でも使えるようにしてしまうからだ。
だから頭のいい人もその間のタイムラグだけで差を付けるしかない。
だから、本当の事をすべては明かさない。
106:デフォルトの名無しさん
21/09/04 11:30:28.20 GpbNmj1Q.net
入力するデータに依存するアルゴリズムなんじゃないの
C/C++なら自由に実装できるけど実務上は不正データがないかチェックするハメになるという
107:デフォルトの名無しさん
21/09/04 12:30:13.91 EwYrh1qJ.net
>>106
全く関係ない。
数年後には秀才達が解説してくれるだろうから、分からない人はそれまで待とう。
108:デフォルトの名無しさん
21/09/04 12:37:18.23 HK0EkPCX.net
もしかして、ボローチェッカに怒られるコードをunsafeブロックに入れればエラーを回避できると思ってやってみたらできなくて、
それでここまでずっと言い訳してるのか？
109:デフォルトの名無しさん
21/09/04 13:11:05.75 gkfG02et.net
例示しろって言われてアウアウしてるんだろw
長文で言い訳グダグダ書いてるのが哀れですらある
110:デフォルトの名無しさん
21/09/04 14:04:36.94 jLCLkIuV.net
引っ込みがつかないとはまさにこのこと
111:デフォルトの名無しさん
21/09/04 14:14:32.96 qlWaKbMU.net
借用で表現できないアルゴリズムって何だろう。
112:デフォルトの名無しさん
21/09/04 14:19:15.62 qlWaKbMU.net
ループで書けないけど再帰でならかける、とかはあるけど、完全に書けないのはあるかなぁ…
113:デフォルトの名無しさん
21/09/04 14:31:27.43 EwYrh1qJ.net
やはり、数学の才能の無いやつらには、分からないんだな。
114:デフォルトの名無しさん
21/09/04 14:34:12.53 ZqoEpBUe.net
>>112
>ループで書けないけど再帰でならかける、とかはあるけど
ないでしょ
115:デフォルトの名無しさん
21/09/04 16:16:10.33 kqbJw6T2.net
>>104
教えたくないならこのスレくんなよ
116:デフォルトの名無しさん
21/09/04 16:22:49.98 ZtXzgEKZ.net
はい、スルー検定4級不合格です
117:デフォルトの名無しさん
21/09/04 17:35:39.84 HcNFP2te.net
数学的才能がない人は、人から言われたことを鵜呑みにするだけで自分で考える事が出来ない。
118:デフォルトの名無しさん
21/09/04 17:40:09.63 iqtSb51S.net
どのスレでもどの問題についてもいつも同じパターン
指摘されても具体的なケースを示せない人や具体的なコードを出せない人は『イチャモンをつけるだけのダメな人』
119:デフォルトの名無しさん
21/09/04 17:40:36.61 HcNFP2te.net
今回の事を見ても分かるように、ヒントを与えられても、それを部品として
組み立てて結論を導くことが出来ない。
そういうひとはいいプログラムはできない。
自分でアルゴリズムを発明することも出来ない。
120:デフォルトの名無しさん
21/09/04 17:41:48.84 HcNFP2te.net
>>118
違う。
ヒントを与えられても、自分で組み立てて正しい答えをひらめくことが出来ない
人しかそのスレに来ていないだけ。
答えを知っていても、与えないだけ。
121:デフォルトの名無しさん
21/09/04 17:48:30.37 FwiYtexa.net
実世界でも一緒だな。
言い訳ばかりして具体例を出せない人を相手にしても話が進まず時間の無駄。
そういうバカは無視するのが正しい。
122:デフォルトの名無しさん
21/09/04 17:54:17.63 HcNFP2te.net
優秀な人から正しい答えを簡単に教えてもらえると思ってるのはどういう教育されて
きたんだろう。
情報量も払わないくせに。
123:デフォルトの名無しさん
21/09/04 17:55:05.92 HcNFP2te.net
>>121
それはあなたの周りに居る程度の低い人の話。
俺は違う。
124:デフォルトの名無しさん
21/09/04 17:58:34.94 GpbNmj1Q.net
お前の情報なんて要らんからコテつけてくれ
最初から避けるから
125:デフォルトの名無しさん
21/09/04 18:25:26.65 HcNFP2te.net
情報は与えないが、本当のことを言ってるのにうそ扱いしないでくれ。
ちゃんと思考力や理解力が有る人には正しいことが分かる。
このスレに今居る人は、俺以外は数学的能力が足りてない。
126:デフォルトの名無しさん
21/09/04 18:29:06.33 kqbJw6T2.net
>>125
十分説得できるくらいの話�
127:ｷる気がないやつなんざウソつきとして扱うしかないやろ
128:デフォルトの名無しさん
21/09/04 18:40:45.92 HcNFP2te.net
>>126
だから、詳細を不特定多数の人達に言うわけにはいかないと何度も行ってるじゃないか。
問題点を明確にしたら改良されてしまう恐れがある。
それは俺の立場からしたら最悪で、問題点は問題点のまま改良されずにずっと
残っていてくれたほうが都合が良い。
129:デフォルトの名無しさん
21/09/04 18:57:20.36 FwiYtexa.net
無能なやつが思い込みで延々と言い訳に終始。
スレの邪魔でしかない。
130:デフォルトの名無しさん
21/09/04 20:36:57.34 j+KqajCA.net
>>127
問題が１パターンだけなら
それだけ意識すればいいんじゃん
131:デフォルトの名無しさん
21/09/04 20:45:10.80 iqtSb51S.net
存在するかどうかすら例示されていない空想の問題について話をするのは
少なくともプログラミング言語のスレでは無意味
132:デフォルトの名無しさん
21/09/04 21:51:42.85 CUdge0sZ.net
>>130
同意
133:デフォルトの名無しさん
21/09/05 04:52:30.40 j+9BaQO4.net
これでは日常生活も大変だろう‥
134:デフォルトの名無しさん
21/09/05 11:58:59.75 TAzC3d8r.net
スレのレベルが低すぎ。
本当に頭のいい人が言ってる正しいことが理解できない人ばっか。
135:デフォルトの名無しさん
21/09/05 11:59:36.21 TAzC3d8r.net
このスレでは、たった一人だけが正しいことを言って、他はみんな間違ってる。
136:デフォルトの名無しさん
21/09/05 12:08:33.41 2jP3+tuQ.net
はいNG
137:デフォルトの名無しさん
21/09/05 12:11:17.36 3IKjsp8l.net
自分のことをたった1人とか言っちゃう猿
138:デフォルトの名無しさん
21/09/05 12:32:10.27 TAzC3d8r.net
アホどもめ。
139:デフォルトの名無しさん
21/09/05 15:07:01.68 LgQhIBwq.net
Aを教えてくれ→解答a
Bを教えてくれ→解答b
Cを教えてくれ→解答c
一生これを続けるつもりか？(たまにそういう人物がいるが明らかに向いてない)
気をまわして x 使え！
(そうすれば A も B も C も解決するよ！！)
っていう解答が来ると「教えてくれない！！！」とキレる
140:デフォルトの名無しさん
21/09/05 22:17:48.95 XzVpFLw9.net
糖質御用達言語RUST
141:デフォルトの名無しさん
21/09/06 05:10:39.90 xB3x8Lax.net
>>139
逆だぞ
この糖質はRustのアンチ
142:デフォルトの名無しさん
21/09/06 09:30:22.04 NkVKbvcc.net
フェルマーでさえ問題そのものは明らかに提示したというのに、問題そのものも一意に定まらない状態で教えてｸﾚｸﾚしかここには居ないバカばっかりって言ってるんだよな
143:デフォルトの名無しさん
21/09/07 09:33:01.92 AwNiMUSI.net
生ポインタがない言語では
まずグローバルな配列を使うアルゴリズムに変換し
次にグローバル変数とかstatic変数禁止の規則に違反しないように書き直す
これができない人はJavaでもstatic変数を使うことになる
144:デフォルトの名無しさん
21/09/08 12:12:45.69 on4QL4Ij.net
めっちゃパフォーマンス悪くなりそう
145:デフォルトの名無しさん
21/09/08 20:56:23.70 UIi59Wds.net
ポインタと配列インデックスはパフォーマンス的に等価じゃね？
146:デフォルトの名無しさん
21/09/08 22:07:00.68 qzNSvV6w.net
等価っていうかそれを遅いと宣言したらJavaもC#もGoもみんな等しく遅いことになる
147:デフォルトの名無しさん
21/09/08 23:52:20.69 7Stt1ihW.net
Cみたいな無能言語を除けば配列インデックスには境界チェックが入るからポインタと同じではないよ
148:デフォルトの名無しさん
21/09/09 00:23:24.04 3/x9wOmm.net
少なくともC++とNim言語ではコンパイルオプションで配列、vector、seqの境界チェックをオフにすることができる。
149:デフォルトの名無しさん
21/09/09 00:54:48.17 ByOcyvaf.net
vector<T>型を更に抽象化してV<T>とすれば
高速なVと安全なVを二刀流できたのに
150:デフォルトの名無しさん
21/09/09 09:35:35.54 H5Pm1mBI.net
少なくともRustは境界チェックを全とっぱするのではなく必要に応じてuncheckする仕組みがある
151:デフォルトの名無しさん
21/09/09 09:49:27.01 nDPpxxc9.net
実際のところ境界チェックのロスってどんなもんなの
組み込み向けはともかく一般的なCPUだと分岐予測とパイプラインのおかげでロス少なそうな印象だが
152:デフォルトの名無しさん
21/09/09 14:53:53.92 a5R4sWP8.net
少なくとも{.push checks: off.}あるいは{.push boundChecks: off.}でNimも部分的にオフにできるはずだが
コンパイル時の境界チェックだけであれば、これは(通常はboundary checkをしないが)C/C++などにも、当然
ながら出来るだろう。RustはもちろんUnsafe{}でほぼすべてチェックを除外することも可能だが、通常は
releaseでも（当然Debugでも）Runtime boundary checkは入る。Goの場合も同様だが、少しずつ”不要な”
ランタイム時のチェックは最適化/改善されて来ている、これはRustも同様であろう
URLﾘﾝｸ(go101.org)
もちろん実行時のチェックが入ることが問題と言っている訳ではなく、通常は安全ではないなら入れる”べき”
だし、デフォルトで入らない安全性側に倒れない言語は古いとしか言いようがない。この実行時のチェックを
エリミネイトする記述の、この分野はJavaの最適化が一番進んでいると思う。
boundary checkに掛るコストを見積もるのは非常に困難だが、上記の言う通りCPUに余裕があり、分岐予測や
投機実行に空きがあれば”さほど”の違いは無いが、最悪は２倍近いメモリと、１ループ毎に２つ程度のCMP命令が
入る事により、全くチェックしないC99などと比べれば1.5倍-2倍程度遅くなるのも当然
153:デフォルトの名無しさん
21/09/09 23:38:57.23 f/JM052X.net
>>150
正解
154:デフォルトの名無しさん
21/09/11 04:07:36.44 w5S7rLqj.net
『具体例は教えられないが問題がある！』君は敗走しちゃったね
155:デフォルトの名無しさん
21/09/14 22:08:36.31 s29FvQzO.net
負けました。もう勘弁してくらはい。
156:デフォルトの名無しさん
21/10/03 20:16:28.62 rU4PBp3b.net
Stack OverflowのServeyであった
給料が高くて人気な言語に
Rust Julia Elixir Clojureあったけど
みんなマクロがあるからなのかな？
マクロがある言語じゃないと今後スケールはしない？
157:デフォルトの名無しさん
21/10/03 21:21:16.47 f+cxTxee.net
人気あるって言えるのかな？案件の絶対数は他の言語に比べて少ないと思うが。
158:デフォルトの名無しさん
21/10/03 21:30:20.91 +hZ9cv9k.net
バッチやdcl、スクリプト系の非効率実行、脆弱性がクラウド提供側で嫌われて
突き詰めたところに制御構造をメタ記述出来るコンパイル言語の需要が有ったかんじ
159:デフォルトの名無しさん
21/10/11 22:26:58.15 BHOOgNKr.net
Rustって、本当に流行ってるんですか？
海外では、総じてプログラマのスキルが高いから流行っているのですか？
日本の感覚だと、一部の技術好きの人達がベンチャー精神にあふれる会社で使っているだけのイメージなのですが。
C言語すら、まともに使えているのかあやしい開発体制の多い日本で、Rustは難しすぎないですか？
（流石に、C言語は言い過ぎかもですが、C++でまともに開発できる体制なんて、夢のまた夢ですよね。）
将来的には、一部のOS開発等を除いて、Goとか敷居の低い言語に落ち着くのだと思っているのですが。
160:デフォルトの名無しさん
21/10/12 00:32:47.27 c4kB5fU7.net
チームにバカが居ると開発効率が悪くなるからRustの難しさはバカよけになる
161:デフォルトの名無しさん
21/10/12 02:21:39.98 1W2DSIiH.net
>>158
Rustはむしろ簡単
考え方を変えることで単純化することに成功した
C++などの既存の複雑な考え方に囚われてしまう頭の固い人にとっては難しくみえるだけにすぎない
162:デフォルトの名無しさん
21/10/12 08:35:14.39 H70LQP2o.net
メモリ破壊バグのないCとかデータ競合バグのないGoを書くのに比べたらRustは簡単
コンパイラに怒られたら直せばいいだけ
163:デフォルトの名無しさん
21/10/12 14:00:16.57 JJ3t9gVC.net
Rustはプログラム書いたことない意識高い系が喧嘩する。forを使うなだとか、こっちの方が短く書けるだとか
164:デフォルトの名無しさん
21/10/12 15:05:47.06 1W2DSIiH.net
>>162
Rustでそういうことは起きていない
ちなみにC言語のfor ( ; ; )文はRustに存在せずIteratorベースのもののみ
165:デフォルトの名無しさん
21/10/13 13:28:21.94 V99uCirA.net
>>158
Pythonも10年前はそんな感じだった
日本は相当遅れてると観て良い
166:デフォルトの名無しさん
21/10/13 13:29:46.77 V99uCirA.net
>>159
同じ理由でC++よりCの方が良いって言われてるね
167:デフォルトの名無しさん
21/10/13 17:06:10.92 +919yhfB.net
>>163
for-inは普通にあるし、map/filter/fold/collectを使えと言う話は読み易さの問題はある。
いまでもrustスレは意識高い系が喧嘩してるようなもの、競技プログラミング的な書き方は
止めろだとか、初心者が書いたコードを貶す
168:デフォルトの名無しさん
21/10/13 18:19:54.35 fXfbCLiK.net
>>166
そんな喧嘩は起きていない
初心者が書いても同じになりイテレータをメソッドチェーンで回すかfor inで回すかの2通りしかない
競技プログラミングの件はどの言語でも同じだが速さだけ求めて汚いプログラミングするのは競プロ専用スレでやるべきなのだろう
169:デフォルトの名無しさん
21/10/13 19:35:38.13 VbHeyYt0.net
こんな奴ばっかり
170:デフォルトの名無しさん
21/10/13 23:53:56.11 W/9iWpHx.net
>>166
for-inを使うにはIntoIterator実装が条件だから結局イテレータの元で統一されていますね
そこに混乱はないと思います
171:デフォルトの名無しさん
21/10/13 23:57:31.98 wiC5i83X.net
これが会話のドッジボールですか
172:デフォルトの名無しさん
21/10/15 12:49:40.87 nPSdjqiL.net
そう言う事を言ってるんじゃないのに、「統一されてますね」このにじみ出る性格の悪さとしつこさが嫌。
そりゃ他人から嫌がられるよお前は、一生ロンパーロンパーしとけよ
173:デフォルトの名無しさん
21/10/15 13:35:11.51 TiF/o4Oy.net
そして静かにC/C++が生き残る・・・とな
174:デフォルトの名無しさん
21/10/15 14:08:53.65 8deGlJY8.net
ほんと進歩ないよな。。だから歴史って重要なわけよ。
175:デフォルトの名無しさん
21/10/15 14:48:47.55 5sSC8oS1.net
歴史から長いものにはまかれろという以外にどんな教訓が学べるというのか
176:デフォルトの名無しさん
21/10/15 15:16:58.35 8deGlJY8.net
機能ゴテゴテ盛り込んで失敗。くらいはそろそろ理解して欲しいもんだがね。
177:デフォルトの名無しさん
21/10/15 16:31:03.08 XGfxQXO+.net
無駄な機能が多すぎる言語は失敗してるよな
一方でRustとGoが成功したのは不要な機能を見極めて削ったことも大きい
どちらもclassすら無いしtry-throw-catchも無い
シンプルでわかりやすい言語となり成功した
178:デフォルトの名無しさん
21/10/15 17:14:22.04 5sSC8oS1.net
つかれたよ
179:デフォルトの名無しさん
21/10/15 20:33:51.67 w61IhFeo.net
まあ、テキストの塊で表現していることに変わり無いしな。
これからはビジュアルプログラミングだろう。
180:デフォルトの名無しさん
21/10/15 20:40:41.27 w61IhFeo.net
>>176
C++のclass自体は簡単で便利な仕掛けだけどね。やってることはそんなに難しいことでもないし。
Rustは学習コストが大きいっていうのはよく言われることだけどね。
181:デフォルトの名無しさん
21/10/15 20:46:36.53 XGfxQXO+.net
>>179
むしろ学習コストは低い
GoもRustもclassなんか導入していなくてC言語と同じくstructつまり構造体を用いる
182:デフォルトの名無しさん
21/10/15 22:47:09.07 rb+Oscx7.net
Rustの学習コストが低いと思っているのはなかなかすごいな
メジャーな言語で、Rustより学習コストが高い言語挙げてみいよ
183:デフォルトの名無しさん
21/10/15 22:50:16.66 5sSC8oS1.net
Scala
184:デフォルトの名無しさん
21/10/15 22:50:39.45 5sSC8oS1.net
Haskell
185:デフォルトの名無しさん
21/10/15 22:50:55.08 5sSC8oS1.net
C++
186:デフォルトの名無しさん
21/10/15 22:59:02.83 cXrj7rPD.net
C++は最初にある程度かけるようになるまではそんなに大変じゃないけど
コンパイラの挙動が怪しいから言語仕様読んでどこかでUB踏んでないか調べる、みたいなとこまでいくと
Rustの方が簡単だったなぁ、と思う
187:デフォルトの名無しさん
21/10/15 23:54:26.80 awitBW+b.net
そもそもの話
次世代言語って必要なの？
って最近疑問に思ってる
188:デフォルトの名無しさん
21/10/16 00:14:02.74 dPfgeqZY.net
>>186
ずっとFORTRANとCOBOLでも使ってろ
189:デフォルトの名無しさん
21/10/16 00:40:25.95 O4GIW+Mr.net
>>187
それは流石に前世代なんでない？
現行世代の似たような言語が増えてってるだけで
その中から次世代を探そうとしても一長一短があるだけで
次世代って感じはどの言語からも感じられない
って個人的な疑問
190:デフォルトの名無しさん
21/10/16 01:01:04.43 GQKUTzD/.net
いま次世代でも数年たてば時代遅れになる。
それならいつでも最新のC++にすれば良いのでは？
次世代ではないけれど。
191:デフォルトの名無しさん
21/10/16 01:33:55.93 0owCAudu.net
>>188
そういう意味では画期的なプログラミング言語はRustしかない
C/C++を完全に置き換えることができる条件「ネイティブコードにコンパイルされる」「ガベージコレクションが無い」「低レイヤもすべて操作可能」を満たしながら
「メモリ安全性を保証」という従来は相容れなかった条件を同時に満たした初めてのプログラミング言語がRust
そのため二つの方向の移行が進んでいる
・C/C++ → Rust (メリット: メモリ安全性が保証される)
・Java等GC言語 → Rust (メリット: GCなくネイティブに最高速となる)
>>189
Rustの出現でついにC++から解放された
192:デフォルトの名無しさん
21/10/16 02:05:47.39 N8k1BZc2.net
Rust個人的には推しだけど確かに最近の5chは変な信者が多い
193:デフォルトの名無しさん
21/10/16 02:49:28.47 MVC0A82Z.net
>>190
だから歴史を学べと。
それまるっきり30年前にc++が言われてたことまんまだから。
194:デフォルトの名無しさん
21/10/16 03:21:07.83 0owCAudu.net
>>192
Rustはコンパイルが通ったらメモリ安全性を保証するが
C++はコンパイルが通ってもメモリ安全性を保証しない
そのためC++で書かれたものはメモリ安全に関するバグを産出してきてそれがセキュリティ脆弱性の7割を占めているとGoogleもMicrosoftも述べている現状
195:デフォルトの名無しさん
21/10/16 12:10:44.93 MVC0A82Z.net
だからGoogleもMicrosoftもどれだけ言語ダメにしてきたか、少し頭使って調べてみてくれ。
そのお題目がいかに名目だけか実際大規模でビルド体制整えて運用してみればよくわかるから。
196:デフォルトの名無しさん
21/10/16 12:33:30.03 vbkw9O81.net
>だからGoogleもMicrosoftもどれだけ言語ダメにしてきたか、少し頭使って調べてみてくれ。
GoogleやMicrosoftがダメにした言語ってなんだろう？
自分で作って結局普及しなくて捨てた言語ってことかな。
197:デフォルトの名無しさん
21/10/16 12:55:55.35 6WTAYzCY.net
Googleが作った言語ってGoとDartだけ？だったらどっちもダメにしてないな
Minecraftは多そう
198:デフォルトの名無しさん
21/10/16 12:56:41.58 6WTAYzCY.net
>>196
予測変換ミス
199:デフォルトの名無しさん
21/10/16 13:33:53.37 N8k1BZc2.net
>>194
大規模でビルド体制整えて運用してみて発生する問題って、技術によって解決すべき問題ではないんじゃね？
具体的な話を聞かないと何とも言えないけど、デマルコ本で言われるような社会学的側面の問題じゃなかろうか
200:デフォルトの名無しさん
21/10/16 14:38:48.10 0owCAudu.net
>>194
・RustはGoogleが作った言語ではないしMicrosoftが作った言語でもない
・RustはFirefox開発のためにMozillaが作った言語
・前代未聞の革命的な言語>>190であったためライバル社たちも導入した
・さらにAmazonやFacebookなどIT大手が揃ってRustを支持し採用している
201:デフォルトの名無しさん
21/10/16 17:59:55.50 5x+WFlZB.net
>>191
分かるわ…、宗教のような気持ち悪さを感じる。rust推しだけど
202:デフォルトの名無しさん
21/10/16 20:13:04.25 nF4n8/aE.net
>>186
よくあるのは、CやRustのマクロは必要ないからマクロ無し言語が必要だというパターン
203:デフォルトの名無しさん
21/10/16 22:43:22.32 MVC0A82Z.net
>>199
mozillaがネットスケープも含めてどれだけ失敗したか理解してるか？
facebookで多く使われてるphpがそんな素晴らしいか？
amazonのc++コードの汚なさを理解してるか？
バカは何度でもブランド意識でくだらんことを広めたがる。そして忘れた頃に同じことを繰り返す。
そういうバカはもううんざりなんだよ。
204:デフォルトの名無しさん
21/10/16 23:05:31.31 nF4n8/aE.net
たとえばPythonとRustのような両極端なら同じことを繰り返してない感がある
両者の中間ぐらいを理想とすると変化に乏しいバカに見えるからやめたほうがいい
205:デフォルトの名無しさん
21/10/16 23:24:00.10 yuQVo/8c.net
>>202
貴方はRustを叩けるほどRustを理解することが出来なかったため
仕方なくRustと全く無関係なことを一生懸命に叩いている
結果的にRustを叩くことが一つも出来ていない
206:デフォルトの名無しさん
21/10/16 23:28:51.24 N8k1BZc2.net
個人攻撃やめなー
207:デフォルトの名無しさん
21/10/17 05:07:24.12 Aq3hRABL.net
なんでRustって成功しているの？
MSもGoogleもAppleもダメだったのに、やっぱり少し不親切なぐらいの方がいいのかな・・・・
208:デフォルトの名無しさん
21/10/17 06:34:07.94 atjZW8su.net
Kotlin もよろしく
209:デフォルトの名無しさん
21/10/17 06:58:29.73 PnF0LE+q.net
CとかJavaとかPythonみたいなメインストリーム言語であるような、
他の言語の経験がない人を対象にした、プログラミング自体をその言語使って学んでいく初学者向けの分かりやすい本ってRustにはないよね
どの本もプログラミング既学者向け
210:デフォルトの名無しさん
21/10/17 08:11:41.68 y3veWc+v.net
本は無い
コミュ力で盗め
ってみんな割と本気で思ってそう
終わりだねこの力
211:デフォルトの名無しさん
21/10/17 11:05:04.81 MkgjpPUe.net
>>180
classの基本は変数とそれを操作するメソッドを一体化して扱おうっていうことだから、
ハードウェアのアナロジーとして捉えればそれ自体はさほど難しい概念ではないけどね。
まぁ、C++もいささか肥大化しすぎた感じでもあるけれど（笑）
Rustはclassを廃止したけど、結局structだけでは無理だから
implやtraitを持ち込んだんだよね？
traitの段階でどこにimplされるのかが決まっていないから、どのstructの
メンバを参照するのかを探すのがちょいとうっとおしかったかな。
Cで、構造体に関数へのポインタを入れた時は第一引数に構造体自体への
ポインタを渡したりしたから、ソースコード上でも、「こいつはどこを見るつもり？」
というのはよく分かったけどRustじゃ&selfだから、一見すると、
「お前は誰だぁ！？？」って感じで。
継承ができない・・・とかいっても、そもそもRustはオブジェクト指向言語って
わけじゃないから、そのあたりは割り引いて考えないといけないんだろうけど。
212:デフォルトの名無しさん
21/10/17 11:23:57.78 Lu+6ZGga.net
成功してると思い込みたいバカが持ち上げてるだけだろ。
それだけ学習すれば済むと思い込みたいバカがな。
213:デフォルトの名無しさん
21/10/17 12:18:01.28 3vXZmfmW.net
JAVAの良さは何かな
最初の頃は一度書いたらすべてのプラットフォームで動作すると宣伝していたのに
214:デフォルトの名無しさん
21/10/17 13:50:04.06 y3veWc+v.net
>>212
本を買わなくても無料の情報と空気を読めばプログラミングができる
一方C++は本を買わないとついていけないビジネスモデル
215:デフォルトの名無しさん
21/10/17 14:16:08.94 6j2makCm.net
Javaは次々に新しいフレームワークができて
バージョンアップも早い
動かすだけで一苦労
が何回も繰り返される
216:デフォルトの名無しさん
21/10/17 16:18:33.33 KyO3PKvk.net
>>210
> Rustはclassを廃止したけど、
> 結局structだけでは無理だから
> implやtraitを持ち込んだんだよね？
その発想はオブジェクト指向プログラミングに毒されているかなと思います
むしろRustは関数型プログラミングの視点から見れば素直に理解しやすいです
まず代数的データ型としてRustでは
『直積』をC言語と同じstructで
『直和』はC言語のunionでは機能不足なので値付きenum (＝タグ付きunion)で表しています
もちろんこれらstructとenumはジェネリックに定義されて0個以上の他の型から構成されます
それらの上での(Haskell等の)『型クラス』としての位置付けがRustのtraitです
つまりある一つの側面としては
RustはC言語に関数型言語の概念を持ち込んだ手続き型言語という捉え方をするとわかりやすいでしょう
加えてC言語系統では今まで実現できていなかったメモリ安全性の保証に成功したことが大きいですね
217:デフォルトの名無しさん
21/10/17 18:28:05.52 ESmnvthu.net
>>212
ちゃんとしたオブジェクト指向
218:デフォルトの名無しさん
21/10/17 18:33:14.43 YptL43pX.net
classを廃止したとか笑うわw
219:デフォルトの名無しさん
21/10/17 18:35:13.51 7+j7XRcJ.net
>>196
Dartって一時期めっちゃ死にかけてなかった？
220:デフォルトの名無しさん
21/10/17 18:48:49.33 MaJoh28m.net
>>218
各ブラウザにDartVM積んでJavaScriptを置き換えようとしてたけど断念し、選ぶ価値の無いAltJSと化した死に損ない
最近はFlutterで息を吹き返して、Dart単体でも多少は使えるようになってきたような
221:デフォルトの名無しさん
21/10/17 19:14:55.95 MkgjpPUe.net
>>215
オブジェクトと実体が一体になるというのは、組み込み用途でもわかりやすい
アナロジーなんだよね。
Rustの「こいつは誰をいじってるの？」というのが宣言されている段階で
確定していないというのは読む側のことを考えていないからなぁ。
メモリ安全というけど、間違った構造体にimplしてしまうと、そちらのメンバを
壊すことになるわけで、そこはコンパイラも実行段階でも引っかからないしね。
違う型の構造体に同じ名前のメソッドが来るというのは割とよくある話なんで、
そのあたりの混乱というのか、コンタミネーションをしないように
ファイルを分割するなりして、記述の時点で気をつけないといけないかなぁ。
そのあたりを「書き方」で工夫してやらないといけない。
222:デフォルトの名無しさん
21/10/17 19:26:32.07 QqhGhKAl.net
そもそも実用レベルのプログラミングでリソースの確保解放でバグは出ない。
意味のない営業文句。
223:デフォルトの名無しさん
21/10/17 19:51:35.57 uRTUEgiz.net
>>220
> Rustの「こいつは誰をいじってるの？」というのが宣言されている段階で
> 確定していないというのは読む側のことを考えていないからなぁ。
その辺はOOPにおけるインターフェースと同じでは？
> メモリ安全というけど、間違った構造体にimplしてしまうと、そちらのメンバを
> 壊すことになるわけで、そこはコンパイラも実行段階でも引っかからないしね。
これどういうこと？
224:デフォルトの名無しさん
21/10/17 19:58:40.22 y3veWc+v.net
ネットの無料の情報には意味のない営業文句などが大量に混ざっている
225:デフォルトの名無しさん
21/10/17 20:43:02.47 QqhGhKAl.net
伸長するメモリー領域には素直にstd::vectorを使えば良い。
性能は順当に劣化するが、それで良いと思う。
226:デフォルトの名無しさん
21/10/17 23:37:29.30 QqhGhKAl.net
明日の朝は大阪で11度らしいのでコートを忘れずに。
227:デフォルトの名無しさん
21/10/17 23:48:16.60 KyO3PKvk.net
>>220
Rustではジェネリックな型から見ると様々なtraitを実装する(指定する)ということは次々と制約を課すことであり
対象はstructだけではなく全ての型であってenumでも数値でも文字列でも何に対しても共通です
その上で別視点から見るとある型に様々なtraitを実装していくということは様々なtraitの機能をサポートしていくことでもあるわけです
> 間違った構造体にimplしてしまうと、
> そちらのメンバを壊すことになるわけで、
そんなことは起こりえません
あるtraitをその構造体に実装(impl)できたのならば間違っていなかったわけです
そしてその実装は自分で行うのですからメンバを壊すという意味不明なことは起こりえません
おそらくプログラミングをしたことがなくて大きな勘違いをしていると思われます
228:デフォルトの名無しさん
21/10/17 23:50:24.15 QqhGhKAl.net
本当にそれでバグが無くなるなら良いが、見当違いのことを一生懸命してるように見えるぞ。
229:デフォルトの名無しさん
21/10/17 23:53:18.81 Rod/beEv.net
>>221
それは君が間違っている。
以下の記事引用の最後の段落を読んで現実を知ろう。
グーグルやマイクロソフトが「Rust」言語でOS開発、背景に国家による諜報活動の影
URLﾘﾝｸ(xtech.nikkei.com)
1970年代初めにUNIXの開発にC言語が採用されて以来、OS開発はCやその後継であるC++の独壇場だった。グーグルはこれまでもAndroidの開発にJavaやKotlinを採用していたが、カーネルやデバイスドライバーなどOSの下位レイヤーの開発にはC/C++しか使ってこなかった。RustはC/C++と同様に下位レイヤーの開発に使用する。
グーグルは数千万行にも及ぶ既存のC/C++のコードを書き換えるのは不可能としており、新規のコードの開発にのみRustを適用する方針だ。それでもOS開発の常識が数十年ぶりに変わるのだけは間違いない。
RustはWebブラウザー「Firefox」を開発する米Mozilla Foundation（モジラ財団）が開発を主導するプログラミング言語だ。開発が始まったのは2006年で、安定版であるバージョン1がリリースされたのも2015年のことだ。まだ新しいプログラミング言語をグーグルやマイクロソフトがOS開発に採用する理由は、OSのセキュリティー強化にある。
Rustは、プログラムに必要なメモリーの確保や解放に関連するバグが生じない「メモリー安全」が保証されたプログラミング言語である。それに対してこれまでのOS開発に使われてきたC/C++は「大規模な開発においてメモリー安全なコードを記述することがほぼ不可能」（マイクロソフトのブログ「We need a safer systems programming language」より）なのだという。
【脆弱性の70％がメモリー管理バグに起因】
グーグルによればAndroidに存在した深刻なセキュリティー脆弱性の70％近くがメモリー安全に関するバグに起因するという。同様にマイクロソフトも、同社製品に存在したセキュリティー脆弱性の70％がメモリー安全に関するバグに起因すると述べている。C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と考えて、Rustを採用するに至ったというわけだ。
230:デフォルトの名無しさん
21/10/18 00:00:05.81 U4M03mzh.net
>>228
10年後にはまた別のことを言ってる。
再現性のないバグのほとんどすべてがメモリーに起因するのは間違いないが、メモリーの確保解放とはまた別の話。
Rustのやり方で上手くいかないことは、C++を使う者ならとうの昔に気付いている。
231:デフォルトの名無しさん
21/10/18 00:03:14.89 U4M03mzh.net
Haskellこそ救世主である。
232:デフォルトの名無しさん
21/10/18 00:09:24.28 gU1bKDav.net
>>229
Rustがメモリ安全性の問題を解決している
これはC++とRust両方でプログラミングしたことある人ならば全員が理解していること
233:デフォルトの名無しさん
21/10/18 01:15:23.81 U4M03mzh.net
Rustじゃ無理、Haskellこそ次世代言語。
234:デフォルトの名無しさん
21/10/18 02:37:41.54 mrfOLNSK.net
>>227
ほんそれ
235:デフォルトの名無しさん
21/10/18 02:39:28.50 mrfOLNSK.net
>>225
温暖化ωですね判りますωω
236:デフォルトの名無しさん
21/10/18 02:42:33.77 mrfOLNSK.net
>>229 に同意
>>228 読んで騙される香具師は素人
237:デフォルトの名無しさん
21/10/18 03:31:02.12 cK47AFx9.net
Rustがメモリ安全だって主張している人はRustのメモリ安全とは具体的に何なのかソースも添えて説明すべきでしょう。
そうしないとあの言語だってメモリ安全だとか俺ならC/C++でも十分メモリ安全に書けるからRust不要って言われちゃうよ。
俺の知っている限りではRustのメモリ安全にはメモリリークしないことは含まれていないのでリークする可能性があるらしい。
RustにはC++のようなデストラクタがあるので解放し忘れることはないらしいが
C++のstd::shared_ptrに相当するRc<T>はReference count方式なのでお互いに参照しあうとメモリが解放されない。
238:デフォルトの名無しさん
21/10/18 05:42:04.96 gU1bKDav.net
>>235
GoogleとMicrosoftが嘘を言ってると主張？？
その記事にあるようにAndroidやMS製品に存在した深刻なセキュリティー脆弱性の70％近くがメモリー安全に関するバグに起因するとGoogleとMicrosoftがそれぞれ同じ主張をしている
>>236
C++わかるなら話が早い
ご存知のようにC++のスマートポインタは使い方を間違えてもコンパイラは通してしまい気付くチャンスがない
つまりC++は人間によるチェックに依存しているためコードが複雑化するとどこかでメモリ安全性を壊すバグが生じてきた
Rustはその言語仕様からメモリ安全性を壊すコードをコンパイラが認識してコンパイルを通さない
そのためコンパイルが通ったコードはメモリ安全性が保証される初のプログラミング言語となった
そこでIT大手各社がRustを採用支持>>53するというプログラミング言語の歴史でも初の事態となった
239:デフォルトの名無しさん
21/10/18 09:29:18.21 deQZOXkA.net
>>208
GoやってからRustやれば良い
間違ってもJSから入ってはいけない
240:デフォルトの名無しさん
21/10/18 10:40:12.86 oPyph5kC.net
静的チェック万能論者は信用できんわな。
それで減るものも多いが、あいつらは嘘を信じ始めている。
241:デフォルトの名無しさん
21/10/18 11:26:29.68 CRhgpEvH.net
これ四色定理でやったやつだ
証明が嘘ではないことと証明の可読性を両立するのをやめた
証明が万能だと信じるなら両立をあきらめられない
万能ではないと判断すれば可読性は捨てられる
242:デフォルトの名無しさん
21/10/18 12:55:52.50 nWV7c8cM.net
>>236
公式ドキュメントには確かにメモリ安全性をちゃんと定義した箇所って無いね
近いのはあるけど……
URLﾘﾝｸ(doc.rust-lang.org)
> If all you do is write Safe Rust, you will never have to worry about type-safety or memory-safety. You will never endure a dangling pointer, a use-after-free, or any other kind of Undefined Behavior.
243:デフォルトの名無しさん
21/10/18 13:49:45.64 4dXA0uuo.net
ダングリングポインタを作らない、に尽きるんじゃないの
244:デフォルトの名無しさん
21/10/18 14:15:47.57 CRhgpEvH.net
変数の寿命が有限になった原因は2種類ある
スタックとヒープ
一部の言語ではヒープの定義をライブラリに丸投げするから言語仕様で定義しない
あとはスタックを定義するだけ
245:デフォルトの名無しさん
21/10/18 15:25:39.78 fRkWn8Ak.net
237のような気持ち悪い信仰がとてつもなくrustの普及を阻んでいる。
246:デフォルトの名無しさん
21/10/18 15:42:51.62 r9t2S6+p.net
メモリ破壊やリークが絶対存在しないプログラムでも
データ次第ではいくらでも飛ばせる
247:デフォルトの名無しさん
21/10/18 16:41:38.35 a937BLhH.net
なんかずれていってんな。
誰も万能とか言ってないのに、あくまでも他言語と比較しての話なのに。
248:デフォルトの名無しさん
21/10/18 17:24:02.54 +nrbTxfF.net
rustはgc使わずにメモリ解放できるから速くて安全ということなのだと思ってたけど、そういう単純な話でもないのかな
249:デフォルトの名無しさん
21/10/18 17:55:52.34 sVAVzshE.net
奴隷はrust使ってくれた方が助かる
250:デフォルトの名無しさん
21/10/18 18:18:29.34 W4UMdHtn.net
優秀な人からRustへ流れてるよな
C++が言語として完全敗北してしまったところが興味深い
251:デフォルトの名無しさん
21/10/18 18:26:09.16 sw4A5qdT.net
Rustのセールストークなどに惑わされず
Rustがやろうとしたことを冷静に理解しきってるのがC++erという
C++を知らなかったりニワカ知識だったりする人が騒いだり対立を煽って楽しんでる
252:デフォルトの名無しさん
21/10/18 19:13:39.89 gU1bKDav.net
>>250
C++とRust両方のプログラミングができるならば
C++の欠陥であるポインタ使用ミスがあってもコンパイルが通りメモリ問題を引き起こしてきた件をRustが解決したと理解できるはずだが
253:デフォルトの名無しさん
21/10/18 19:54:57.93 sw4A5qdT.net
いたずらに否定したりせず
慈しみ、見守ってるってこと
254:デフォルトの名無しさん
21/10/18 20:29:15.76 CRhgpEvH.net
トークがどれだけうまくなっても人の話を聞かない相手には効果がないよな
聞き方や読み方のレベルを上げた方が早い
255:デフォルトの名無しさん
21/10/18 20:40:39.51 9iPUXHWE.net
C/C++理解してれば
Rustは不要ですよ
256:デフォルトの名無しさん
21/10/18 20:44:49.04 oPyph5kC.net
むしろrustで問題解決とか言ってるやつのc++コードがどれだけひどいのか観て見たくなってきたわw
257:デフォルトの名無しさん
21/10/18 21:28:21.41 CRhgpEvH.net
事実が見えるまで粘るより仮定した方が早い
258:デフォルトの名無しさん
21/10/18 21:57:02.11 W4UMdHtn.net
もしC++がRustに勝る点が一つでも残っていれば
C++しか書けない人がこれほど発狂することなかったろうに
259:デフォルトの名無しさん
21/10/18 23:49:18.78 k0GYnhD+.net
超次世代言語Dart
260:デフォルトの名無しさん
21/10/19 01:27:04.57 PbORd8vw.net
C/C++で完璧なコードかけるならどこいっても歓迎されると思うよ
それが誰もできないんだからrustに流れてるってことでしょ
261:デフォルトの名無しさん
21/10/19 03:17:45.56 +8M5kAvN.net
>>259
いや完璧なコードを書けるというのが勘違いであり凄いプログラマーでも間違いを起こすことがある
だからこそ人間頼みではなくコンパイラがチェックした方が良いと誰もが辿り着いた
262:デフォルトの名無しさん
21/10/19 05:43:42.06 mawS91w/.net
>>255
俺も。
メモリーの確保解放ですべて解決みたいな主張してるから余計に不思議。
263:デフォルトの名無しさん
21/10/19 07:01:04.92 3gMaYVXy.net
俺はここの耄碌よりGAFAMを信じますけどね
264:デフォルトの名無しさん
21/10/19 07:40:41.53 HngacVLx.net
自分で考えろ低能
265:デフォルトの名無しさん
21/10/19 07:49:05.09 +Znhh+E9.net
GAFAM？
FAANGじゃなくて？
Mって何？
266:デフォルトの名無しさん
21/10/19 08:22:28.00 0uJXMEOT.net
自分で考えている時には命令文や疑問文を使う必要がない
否定文なら使ってもいいけど
267:デフォルトの名無しさん
21/10/19 08:25:01.48 L5e5F1nS.net
>>264
Apple
Amazon
Microsoft
268:デフォルトの名無しさん
21/10/19 08:47:54.47 T9srRJav.net
GoがC/C++/Rustに比べて若干遅くなる要因ってGC以外なにがあるの？
269:デフォルトの名無しさん
21/10/19 08:56:27.98 9axoCOPN.net
二番目はAppleと言われてるけどどう考えてもAmazon
ケツから将来性の無い順番で消える、つまりGAFAMのMが消えてGAFAになったので
次のAppleが消えてGAFになる
270:デフォルトの名無しさん
21/10/19 09:55:30.99 T9srRJav.net
GAFAMって言葉が生まれたのはGAFAより後では？
MSをハブったらかわいそうってことで生まれたような
将来性が一番微妙だからハブられてたんかもしれんけども
271:デフォルトの名無しさん
21/10/19 10:09:08.48 L/QTVpd7.net
まあFacebookよりは明らかに上やから入って当然ではある
272:デフォルトの名無しさん
21/10/19 13:41:00.66 HngacVLx.net
国産検索エンジンはなぜつぶされるのか
273:デフォルトの名無しさん
21/10/19 19:00:05.85 089JTvXc.net
Crystal入れてちょんまげ
274:デフォルトの名無しさん
21/10/19 19:37:36.30 OaBrXs9n.net
crystalはrubyライクという以外あまり特徴がないよな。次世代言語としてどこで存在感出せばいいのか
275:デフォルトの名無しさん
21/10/19 20:15:37.83 LrPlA7Vp.net
>>254
一人で作業するなら好きな言語使えば？
276:デフォルトの名無しさん
21/10/20 09:10:49.09 OEiI06HQ.net
>>261
++
277:デフォルトの名無しさん
21/10/20 16:10:03.72 lLepbwfw.net
Nim version 1.6 is now officially released!
278:デフォルトの名無しさん
21/10/21 09:29:50.15 Hd41fW1K.net
Nimくん自分とこのスレに書き込まれずにこっちにばかり話題が来るのちょっとかわいそうになってきた
279:デフォルトの名無しさん
21/10/23 00:34:45.65 o3xA5lbA.net
>>273
Crystalの開発は、Rubyの特徴である優雅さと生産性の高さ、コンパイラ言語の特徴である実行速度の速さと
効率の良さと型安全を目的として、2011年6月に開始された。バックエンドにLLVMを利用することによって
効率的な機械語を生成することができる。
他のコンパイラ言語と比較して、高度な型推論とユニオン型の組み合わせによって、高水準スクリプト言語の
ような簡潔な記述を実現している。
Goに影響されたファイバー間の通信を行うための軽量なチャネルとファイバーが実装されている
280:デフォルトの名無しさん
21/10/23 01:42:06.05 psrWRCod.net
俺が思うに
このスレに登場する言語は次世代言語なんかでは無く
狂信者がいる言語にしか見えない
次世代言語の話してるのに「C++」という単語の出現頻度の高さがそれを物語ってる
旧来の狂信者がいる言語と新しい狂信者がいる言語の
宗教戦争の場がこのスレだと感じた
281:デフォルトの名無しさん
21/10/23 08:56:00.74 qfDvYrOr.net
気がつくのが遅いよ、きみ!
282:デフォルトの名無しさん
21/10/23 10:07:43.64 rv17aNSC.net
>>279
ちょっと前まではC++が最速最強言語だったからでしょう
ただし唯一の欠点がメモリ安全でないコードも生じ得て現実にセキュリティ脆弱性なども招いていること
そこで次世代言語としてC/C++と同じく最速でありつつメモリ安全性を保証する真の最速最強言語Rustが登場したことから旧世代のC++が比較対象として話に出るのでしょう
283:デフォルトの名無しさん
21/10/23 11:45:11.96 kIBEGvOM.net
むしろアニメの登場人物全員JKにするみたいな奴が狂信者
爺婆はいても信者はいない
284:デフォルトの名無しさん
21/10/23 12:14:12.92 OTpUh678.net
c++の唯一の欠点とかw
285:デフォルトの名無しさん
21/10/23 13:05:15.91 kIBEGvOM.net
賛成とか反対とか言えなくてへらへら笑ってるのも悪いんだよ
286:デフォルトの名無しさん
21/10/23 15:14:01.04 kbstlDmN.net
>>281
結局最速にするにはunsafeするやん。そういう誤魔化しをあえて語らんところが信用を失うんだよ。
287:デフォルトの名無しさん
21/10/23 17:40:45.89 o3xA5lbA.net
rusterの気持ち悪いのが一番嫌い、お前が自分とこの発音で盛り上がるスレに書いてろ
288:デフォルトの名無しさん
21/10/23 17:46:02.31 Usgnsf5k.net
最初から全部unsafeで書けばいいのに
289:デフォルトの名無しさん
21/10/23 18:07:07.88 A4VxVCoL.net
>>285
意味不明
比較ベンチマークのRustプログラム等を見ても普通のアプリのRustソースを見てもunsafeは出てこない
290:デフォルトの名無しさん
21/10/23 18:10:31.38 dzQukzcx.net
RustってC++のmoveが楽になった言語の認識だったけど
ここ読むと捉え方ちがうような気がしてきた
291:デフォルトの名無しさん
21/10/23 18:12:33.07 rnZCdbOY.net
>>288
競プロでもしてんじゃね
292:デフォルトの名無しさん
21/10/23 18:14:14.05 kIBEGvOM.net
最安で欲しい物を手に入れる方法が購入ではなく盗むことだとしたら盗むか？
unsafeで最速にするというアイデアはそういうイメージ
293:デフォルトの名無しさん
21/10/23 18:26:04.70 A4VxVCoL.net
>>289
メモリ安全性保証などの話は別にしても
C++は最初の小さな家Cを何度も建て増ししてきたような言語
Rustは最初から最新のパラダイムを洗練して採り入れた言語なのでプログラミングのしやすさがかなり違うかな
294:デフォルトの名無しさん
21/10/23 18:53:49.04 OfW/Ted4.net
誰もがc++ありえんと思ってて、代わりの候補もたくさん出てきた中で、ようやく使い物になりそうなのがrust
295:デフォルトの名無しさん
21/10/23 19:14:18.65 JF+Bwqfj.net
C++が互換性を無視して不必要な機能をばっさり切り捨てることができればだいぶましな言語になる気がするけどそんなことはできないんだろうな。
296:デフォルトの名無しさん
21/10/23 19:41:04.11 kIBEGvOM.net
互換性がないバージョン1から3があるなら
最も不必要なのは2なんだよ
2を無視して1の互換性を重視するのは言うほど悪くない
297:デフォルトの名無しさん
21/10/23 20:21:23.52 8QkqEddx.net
たしか、あわしろ氏がLinuxをRustで書き直すプロジェクト始めたはず。
298:デフォルトの名無しさん
21/10/23 20:24:24.83 rnZCdbOY.net
どこで？
299:デフォルトの名無しさん
21/10/23 21:01:07.99 WtF24tRL.net
>>285
0か100しか認めないタイプか？
ストレスでハゲてそうだな。
300:デフォルトの名無しさん
21/10/23 23:36:13.26 rsO/lln+.net
Rustは難しい言語ではない。気軽に始めてみるところからスタートしよう。Rust活用企業の現場に聞いてみた
URLﾘﾝｸ(engineer-lab.findy-code.io)
松本おおおおおおおお！
301:デフォルトの名無しさん
21/10/24 14:51:32.96 x5aKIXa7.net
FacebookはReactとかVRあるから日本でも結構重要なポジションになりつつあるな
SNSは全然流行ってないとしても
302:デフォルトの名無しさん
21/10/24 17:16:59.20 MlWNQcCM.net
c++の安心側に制約を追加したSmart c++は欲しい。Rustは要らない。
303:デフォルトの名無しさん
21/10/24 18:13:51.90 NLtlOSxj.net
D言語の話した？
304:デフォルトの名無しさん
21/10/24 19:18:02.70 4GW3Pp+f.net
F#……
305:デフォルトの名無しさん
21/10/24 20:44:53.71 x5aKIXa7.net
F#って結局何作れる言語なの？
306:デフォルトの名無しさん
21/10/24 23:46:02.08 J36a/Om9.net
>>301
プログラミングしやすいRustがあるのにC++ベースにはもう戻りたくないよね
307:デフォルトの名無しさん
21/10/24 23:51:33.94 x5aKIXa7.net
そういえばWebAssembly Studioなんてのがあるのを最近知った
URLﾘﾝｸ(webassembly.studio)
308:デフォルトの名無しさん
21/10/25 00:38:46.00 Zg5tRANc.net
>>301
c++23で契約プログラミングが標準化されたら改善するかも？
309:デフォルトの名無しさん
21/10/25 00:42:01.96 Zg5tRANc.net
そういやrustって契約プログラミングをサポートする文法あったっけ？
310:デフォルトの名無しさん
21/10/25 01:31:51.79 13mKJPww.net
URLﾘﾝｸ(crates.io)
311:デフォルトの名無しさん
21/10/25 23:17:33.61 vPVmdF1Z.net
結局、データの共有かコピーかが楽に設定できるかどうかってことに焦点が当たって、
rustは捨てられることになるよ。
こんな明らかなことさえわからん連中ばっかなのが面倒ごとだな。
312:デフォルトの名無しさん
21/10/25 23:55:02.93 Hh6pHipi.net
コピーの反対はムーブかもしれないので、コピーの反対は共有だろうという雑な考えを捨てよう
313:デフォルトの名無しさん
21/10/26 10:23:33.99 oHFZf85O.net
>>267
goroutineのネイティブスレッドとM:N関係。軽量と言っても、当然、中でコンテキストスイッチのように
実行の切り替えがある。他の言語は（機能が）無いので真っ当に比較出来ないが、ほかの言語で似た外部の
ライブラリを入れるとgoより重たいし、nodeのように、I/Oバウンドな非同期しかないと1つが詰まったら
全部止まるデメリットがある。goのGCが遅めなのは、当然、このgoroutineの並行性における不可分操作が
難しいからであり、rustのRc/Arcやnimの--gc:arc/orcに比べ並行性を保ちながら参照カウントを不可分の
操作にするとコストがとても大きくなるためと言われる。多くの人が勘違いしているのは、理論上はRcより
（トレース系のGCは）GCのほうが効率的（高速化が望める）だ、ただしGCはネックが生じる
314:デフォルトの名無しさん
21/10/26 11:22:52.21 UCZJSiVy.net
バカが老害ガー言われ始めるのに大体１０年くらいかかる。
こうして流行は終わる。
315:デフォルトの名無しさん
21/10/27 12:05:58.55 6tzLPjk/.net
Crystal入れてください
316:デフォルトの名無しさん
21/10/27 14:14:45.58 P9D6Cr2V.net
存在感微妙だし。nimもいらんな
317:デフォルトの名無しさん
21/10/27 15:48:46.91 G9Y5/nKM.net
Zigでもいれとく？
318:デフォルトの名無しさん
21/10/27 16:26:23.01 Jg7L84/d.net
Vがいいかも
319:デフォルトの名無しさん
21/10/28 12:19:59.27 pk2ZbUG1.net
Vの良さでも語ってくれ
情報少なすぎてよく分からない
320:デフォルトの名無しさん
21/10/28 13:00:24.39 owG9GWEY.net
あれは詐欺だろ
321:デフォルトの名無しさん
21/10/29 00:13:25.52 RD2SEv+6.net
vlangは0.3が全然出ないね。mutを後から導入したのがよほど不具合頻発になったのだろうか
322:デフォルトの名無しさん
21/10/30 02:12:19.09 CsJIfRO2.net
次に取り沙汰されるのはKokaみたいなAlgebraic Effectsのある言語だと思う
323:デフォルトの名無しさん
21/10/30 02:29:08.63 qGEfyGin.net
取り沙汰される、って何年後のことやねん
やたら表現力高そうだし、ベストプラクティスがなかなか定まらなそう
324:デフォルトの名無しさん
21/10/30 03:11:26.17 U9OTRLVf.net
rustだgoだと言ってたら一瞬Vが騒がれて消えてなくなって今はnimなの？
今ならrustでいいじゃん
クッソ速くて賢くて小さくて安全でどこでも動いて便利な使いやすい言語誰か作ってくれ
一番大事なのは速いことな
325:デフォルトの名無しさん
21/10/30 08:15:37.97 fF4OSUNs.net
Nim is efficient, expressive, and elegant.
どこらへんがどうエレガントなのか謎やわ
326:デフォルトの名無しさん
21/10/30 10:49:51.87 5VdQtJkF.net
「エレガントさ」とか「楽しさ」で売ってる言語はクソの法則
327:デフォルトの名無しさん
21/10/30 11:52:44.92 YSY9yYdl.net
他の言語の存在を無視したりOSの存在を無視したりしたら
まともな説明ができなくなる
空虚な言葉を使うのは原因というよりむしろ結果
328:デフォルトの名無しさん
21/10/30 13:21:47.38 U9OTRLVf.net
むしろ複数のコンピュータをまとめて1つの環境として扱い、その環境で最適化して実行可能な言語を作ってくれ
329:デフォルトの名無しさん
21/10/30 13:40:35.45 OQ2dRDm5.net
>>327
速度優先とメモリ効率優先は誰が決めるの?
330:デフォルトの名無しさん
21/10/30 14:03:03.78 U9OTRLVf.net
>>328
細かい部分は最適配分して決めるとしか
最初は適当なヒューリスティックでいい
331:デフォルトの名無しさん
21/10/30 22:25:15.35 G/S2+R78.net
>>324
公式は3つ挙げてる。macro記述と言語そのもの差異がほとんど無いことを挙げている。$aとか別言語になったり
してない。もう１つはpython風の構文がエレガントだと言っている（これはpython風の構文を多くの人が嫌うの
で賛否が分かれると思う）もう１つは多くの言語が該当するので書かない。個人的にはvar/letじゃなくlet mutや
いちいち打つ::や、マクロで!とかの方がエレガントだと思わんけど、goでいえばpanicがあるのにtry/catchが無い
（多値戻りの2番目にerrorを入れてif判定させる）、genericsがまだ無いのもエレガントとは思えない
332:デフォルトの名無しさん
21/10/30 22:27:20.82 G/S2+R78.net
>>327
Juliaでは、標準ライブラリの一つとして提供されているDistributedモジュールで分散メモリ並列計算を実装して
いる。Juliaのベースインストール状態では、2種類のクラスタがサポートされる。（1つはローカル）
・複数のマシンからなるクラスタ。--machine-fileオプションで指定する。パスワードが不要なSSHを
用いてJuliaのワーカプロセスを指定した計算機で分散される
@distributed for i = 1:100000
a[i] + b[i]
end
こういうのが１つの実行環境で複数のコンピュータでクラスタ実行される
--machine-fileで
3 164.67.165.21 # 3process
5 164.67.165.22 # 5process
333:デフォルトの名無しさん
21/10/30 22:36:16.21 G/S2+R78.net
まあmacro記述を簡単にインライン展開するために別言語風になるのも分かるけど、、名前衝突が起きないように
デフォルトで別名に自動で名前を付けて展開してインライン展開する場合は特殊タグを付けるほうが
334:デフォルトの名無しさん
21/10/30 23:31:55.44 U9OTRLVf.net
>>331
そんなの言語レベルのサポートいらんやん
分散も並列化も勝手にやってくれ
プロセスもマシンも意識したくない
意識してもいいけど必須じゃなく、自動で可能な限り適切にリソースが配分されてほしい
プロセスとかそんなざっくりした単位でもなくね
それが実現可能な言語を用意せよと言っている
335:デフォルトの名無しさん
21/10/31 00:40:29.24 Qz/5KmYR.net
それって言語じゃなくてOSとか別のレイヤーが果たす役割じゃね？
336:デフォルトの名無しさん
21/10/31 00:43:34.15 e5ZzvOAs.net
言語レベルサポートが無いということは、分散も並列化も勝手にやったら不可分解の通常のforループも
分解されてしまうので、そんなことは不可能。繰り返し順次実行と、（表現上は繰り返しだが）並列実行
では意味も結果も異なる。
要らないというコンピューター言語学での証明は無い。思想的には集合要素に対するmap/reduceなどが
並列の操作ができるからと言って、forだけで表現できる語彙ではない。言語の標準ライブラリにreduce
などのAPIがある事は、それそのものが（並列に実行していないのに）並列性の表現と同じ意味。
CPU側でそれが並行操作可能か、何らしらのマーカーは必要というのは素人以外はすぐ分かる事
>”言語を用意せよと言っている”おまえ何様やねんｗ
337:デフォルトの名無しさん
21/10/31 00:44:58.68 LjLsZLEJ.net
プログラミング言語という概念すら理解してないのがこのスレの住人のレベル
338:デフォルトの名無しさん
21/10/31 01:28:26.60 e5ZzvOAs.net
>>334
その通り。分散コンピューティング/グリッド・コンピューティングなどではミドルウェアが利用される。
Erlangなどでも、分散処理できるがspawn(node, ...)などノードを意識しなくてはならない。また
CPU処理が分散できたからと言って、ファイルシステムなどローカルしかないため、大規模分散には
分散ファイルシステムが必要になり、Googleのようにbigtableができ、その上で耐故障性を備えるように
仮想化して、スケールアウトやオーケストレーションのためにkubernetesなどなど、別レイヤーが
果たす役割が多い
339:デフォルトの名無しさん
21/10/31 01:35:34.83 sAwtPlvj.net
そういうことじゃないｗ
俺様が言ってるのはマシン/アプリ/ライブラリ/OS/デバイスの垣根を超えて
言語とそれらの複合環境がカバーしうる汎用な表現が可能な言語やｗ
作れｗ
340:デフォルトの名無しさん
21/10/31 01:43:15.98 e5ZzvOAs.net
基地外かあ…、この業界こういうの大杉壮大な能無し基地外のかまってちゃん
341:デフォルトの名無しさん
21/10/31 01:47:23.36 sAwtPlvj.net
例えば組み込み制御系で使えばCの配列を作るのと同じ記述でスケールしたら分散KVSもどきやらが出来上がるような言語
並列実行可能かどうかはあるロジックの入力が別のロジックの出力を使ってるかどうかだけ
342:デフォルトの名無しさん
21/10/31 01:58:47.24 sAwtPlvj.net
できそうにないだろ？
既存のアーキテクチャにどっぷりなら
高速にぶん回したかったらrustでもC++でもgolangでも使えばいいし
スケールするだけで十分な速度が出るなら誰でも使える言語を使ってスケールすればいいし
僅かに違う新しめの言語の差分をネタに趣味・嗜好を語るよりは夢を語った方が有意義でないかい？ｗ
343:デフォルトの名無しさん
21/10/31 02:01:52.96 dE1SXutD.net
Common Lisp
344:デフォルトの名無しさん
21/10/31 02:08:26.79 e5ZzvOAs.net
おまえのチンポコの穴から並列でションベン出来るか考えてロンパーロンパーしてろｗくそ基地外ｗ
345:デフォルトの名無しさん
21/10/31 02:12:58.45 e5ZzvOAs.net
おまえがいるだけで世の中迷惑、人の足引っ張りまくり、親に迷惑かけまくり、誰もがお前を見ると顔をしかめる。
クズの癖に１つも優れた能力も、努力もなく、相手を貶し、悦に入る
問題の原因の根本たるおまえが消えて無くなれば、よほど有意義