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

**デフォルトの名無しさん** · 2021/08/22(日) 08:59:03.31

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2021/08/22(日) 21:13:45.05

本当に知らない人のために言うと、全部ブログ記事のパクリ
なので相手にしてもマトモなレスが返ってこない。無視で良いよ

**デフォルトの名無しさん** · 2021/08/22(日) 21:21:33.85

>>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")

**デフォルトの名無しさん** · 2021/08/22(日) 21:27:47.34

>>26
アセンブラだってスタック使うでしょ？

**デフォルトの名無しさん** · 2021/08/22(日) 22:19:09.36

>>29
組込みだとRAMチェックが終わるまではスタック使わないとか普通にあったりする

**デフォルトの名無しさん** · 2021/08/22(日) 23:42:29.56

>>30
ほー、なるほどね
だからって>20はおかしいよね

**デフォルトの名無しさん** · 2021/08/23(月) 00:53:35.51

アセンブラは型がない
アセンブラだけで作ったライブラリも可読性のためにはCの型を宣言する
宣言したらもうCのライブラリとして利用可能にするだろ常識的に

つまり旧世代言語のコードを減らすとかいうおかしな目的意識の代わりに
ライブラリを増やすという適切な意図がある

**デフォルトの名無しさん** · 2021/08/23(月) 01:09:17.02

そこはCもC++もRustも同じでアセンブリ含めて相互に呼び出し可能
だったらコンパイル通った時点でメモリ安全性を保証できるRustで基本的に書いてどうしても必要な部分のみアセンブリというのが現在の流れ

**デフォルトの名無しさん** · 2021/08/23(月) 03:28:42.97

型付けアセンブリ言語という研究かなり昔にあったよね？
どうなったの

**デフォルトの名無しさん** · 2021/08/23(月) 05:35:18.87

>>31
おかしくないよ、そういうコードはアセンブラでないと書けないから

**ハノン** ◆QZaw55cn4c · 2021/08/23(月) 05:39:50.18

一応 MASM には型はありますが？

**デフォルトの名無しさん** · 2021/08/23(月) 06:59:34.18

>>34
masm とかでも構造体を定義できたりするけどやればやるほどC言語で良くね？とかなりがち

**デフォルトの名無しさん** · 2021/08/23(月) 13:47:20.63

どうせWEB屋が好きな/使ってみたい言語ランキングでしょ

**デフォルトの名無しさん** · 2021/08/23(月) 18:03:58.81

nim もっとカッコイイ名前が良かった
julia よりマシだが

**デフォルトの名無しさん** · 2021/08/23(月) 18:27:25.22

GoもRustもNimもJuliaも検索性わるすぎるんよー

**デフォルトの名無しさん** · 2021/08/23(月) 19:25:50.37

Cは？

**デフォルトの名無しさん** · 2021/08/23(月) 21:15:07.01

>>35
せいぜいCで代替できないケースもある、だな
「代用不可」は言い過ぎ

**デフォルトの名無しさん** · 2021/08/23(月) 21:19:05.15

C/C++/Rustは中でアセンブリ書けるので大丈夫
どうしても必要な部分がある時は使われている

**デフォルトの名無しさん** · 2021/08/23(月) 21:38:44.27

>>42
スタック無しが要件なら代替不可
そうでないならあんたの言う通り

**デフォルトの名無しさん** · 2021/08/23(月) 22:01:28.04

>>39
G. M. Julia 「……」
https://ja.wikipedia.org/wiki/%E3%82%AC%E3%82%B9%E3%83%88%E3%83%B3%E3%83%BB%E3%82%B8%E3%83%A5%E3%83%AA%E3%82%A2

**デフォルトの名無しさん** · 2021/08/23(月) 23:23:44.42

>>34
それに近いのがllvm ir

**デフォルトの名無しさん** · 2021/08/24(火) 00:13:51.84

wasmとllvmって
どうしても必要とは言えない所でアセンブラ使ってるよな

**デフォルトの名無しさん** · 2021/08/24(火) 01:00:35.96

>>44
もうトートロジーに陥ってるじゃん…
無理しないで>20は命題として偽だって認めなよ

**デフォルトの名無しさん** · 2021/08/24(火) 05:37:31.25

>>48
ああ、それでいいんじゃね？
別にお前がそう思うのは自由だし

**デフォルトの名無しさん** · 2021/08/24(火) 06:23:15.51

>>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

**デフォルトの名無しさん** · 2021/08/24(火) 06:24:41.13

このリポジトリではレイトレーサーを様々なプログラミング言語で実装し
実行速度を比較してるが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

**デフォルトの名無しさん** · 2021/08/24(火) 09:08:23.82

大手IT企業たちをはじめ次々となぜRustを採用しているのかの理由のうち一番大きな点は、
直面しているセキュリティ等のバグの原因の大半がメモリ安全性の逸脱に伴うものであり、
メモリ安全性を保証する論文に基づいたRustがそれら問題点を解決することが明確となっている点にある。

**デフォルトの名無しさん** · 2021/08/24(火) 10:07:34.07

>>52
論文に基づいたメモリ安全性の保証が大きいですね
IT業界の状況

プログラミング言語「Rust」のための「Rust Foundation」設立 -- AWS(Amazon)、Microsoft、Google、Mozilla、Huaweiが創設
https://japan.zdnet.com/article/35166267/

Facebookが「Rust Foundation」に参加
https://japan.zdnet.com/article/35170192/

**デフォルトの名無しさん** · 2021/08/24(火) 14:54:36.93

>>51
コード読んだ訳じゃないけど1番上のやつnimはコメントにfast inverse square root使ってるって書いてあるし比較できなくね？

**デフォルトの名無しさん** · 2021/08/29(日) 20:34:53.75

>>52
言ってる事は正しいが実際の理由はそうではないと思う。C/C++に比べればメモリ安全性はその通りだが
多くの言語ではGCがあるためにメモリ安全性をほぼ保障をしているが、わざわさRustを採用するのは
極めて大きいメモリーを扱うプログラムやリアルタイム性を追求される要件があり、それがGCのSTWや
GC時間を無視できないから

**デフォルトの名無しさん** · 2021/08/30(月) 00:46:35.99

メモリ安全性の話にGC持ってくるとは
何か勘違いしてないか

**デフォルトの名無しさん** · 2021/08/30(月) 10:54:55.14

GCに限った話でなくてもUnsafe使えば全部同じ、自身が使ってなくても（速度を出すために）ライブラリで使ってる。
Unsafe使わなくても完全に防げるわけでは無い。これはgoもnimもDも同じ
「大手IT企業たちをはじめ次々となぜRustを採用しているのか」の一番の要因は55の言う通りだと思う

**デフォルトの名無しさん** · 2021/08/30(月) 11:07:11.50

>>55
扱うメモリーの大きさは関係ない

応答速度の程度のことをリアルタイム性とは言わない
プログラミングの分野でリアルタイム性という言葉は別の意味を持つ
Rustはリアルタイム性を求めて使われてるわけではない

**デフォルトの名無しさん** · 2021/08/30(月) 11:19:37.82

C/C++の移行とJavaやGoからの移行では理由が異なる
現状大半は前者
つまりもともとGCを利用してない分野なので>>55の認識は間違い

**デフォルトの名無しさん** · 2021/08/31(火) 08:45:13.59

>>59
現状、SNSなどのサーバーサイドのプログラムでGCのStop The World が遅くて
移行した企業を見たが。見たのは一例だけど。
C++からの移行は、Rustを作ったところのMozilla自身がFireFoxで行ったものが
有名で後は数例だけを聞いた。

**デフォルトの名無しさん** · 2021/08/31(火) 08:57:06.99

いやいやC/C++でも今で土器は大規模プログラムだとGC使用してる場合がある。Boehm GCや
TCMallocなんてまさにそれ、もちろんカーネルプログラミングやドライバ開発では使用されないが
純粋なC/C++で起こりうる何も考えていないヒープ確保の断片化による肥大化を抑える。ただし
GCの最大時間を指定できるものもあるが、Rustに比べれば確実にこのブロックでメモリー解放が
起こるという予測可能性が無い。
大手IT企業という話であれば、これはカーネルプログラミングなどでは無いだろう。
確かにSTWなどからの低レテンシーやCPUスパイクが小さい事をリアルタイム性とは言わないが
現実として自動運転や大規模ウェブサイトでは、ほんの数十ミリ応答を受け付けない事は致命的で
あり、すべてではないがそういった見方を排除あるいは全否定すべきではない
言語的なバッファオーバーフロー耐性などは１側面に過ぎない。

**デフォルトの名無しさん** · 2021/08/31(火) 16:03:34.84

GCは参照されないオブジェクトを探すだけなので
参照カウントが1か2以上かチェックしたくなったらもうGCは役に立たない

**デフォルトの名無しさん** · 2021/08/31(火) 16:56:17.54

>>61
自動運転の制御プログラムでGC使ってたのがRustに移行した事例あるの？

Discordの事例はレイテンシが致命的だったわけではないぞ
それにサーバーサイドでRustへの移行がペイするDiscordレベルの規模と速度が求められるようなシステムは0.01%もないから
残りの99.99%はどうなのかが重要

**デフォルトの名無しさん** · 2021/08/31(火) 18:27:45.08

GCがサーバの遅延原因とわかるなら、重いGCを動作しない設定にしといて
一時的にサービスから外す＞プロセス再起動＞サービス再開
で済む話

**デフォルトの名無しさん** · 2021/08/31(火) 18:56:45.11

そもそもDiscordはC/C++じゃなくてGoだった
GoからC++に変えるよりもGoからRustに書き換える方が良さげなのは何となく分かる

C/C++をRustで書き直したってあるのかね？servoも最初っからRustだったはず

**デフォルトの名無しさん** · 2021/08/31(火) 19:35:22.26

数年後rustは糞言語だったって評価されそう

**デフォルトの名無しさん** · 2021/08/31(火) 19:36:48.62

C++が既に十分に優れているということを言いたいのかもしれないけど、
C++からRustに書き換えないのは単純に難しいからだと思うぞ

**デフォルトの名無しさん** · 2021/08/31(火) 20:00:37.49

違うよ
既にあるものを移植する案件が少ないだけ
しかし大規模改修や新規案件ではC++を利用する意義がなくなったのでRust採用が多い
もちろんC++だけからではなくFacebookのようにJavaからRustのパターンもある

**デフォルトの名無しさん** · 2021/08/31(火) 20:56:18.00

>>65
ChromiumOSやAndroidはコンポーネント単位でRust導入が進んでるプロジェクトかな
あとはcurlがバックエンドをRustにする作業中

**デフォルトの名無しさん** · 2021/09/01(水) 00:08:09.87

>>66
糞言語でも広まると糞言語だと言われない場合も多い。
広まってしまったらそれまで。例えばPythonとか。

**デフォルトの名無しさん** · 2021/09/01(水) 01:35:43.66

最良言語を目指すやつはすぐ仕様変更するのが欠点だな
Pythonも仕様変更はあったが古いバージョンを虐待しなかったのがよかった

**デフォルトの名無しさん** · 2021/09/01(水) 03:34:40.38

>>71
Rustはedition制で後方互換性を完全に保証しているから安心して使用できますね

**デフォルトの名無しさん** · 2021/09/01(水) 06:09:56.27

>>65
Firefoxがそうだろ
あと、Windows10の一部もRustに書き換え中ってニュースもあったな

**デフォルトの名無しさん** · 2021/09/02(木) 15:26:46.45

サーバー書くならGoかRustかって感じだけどどっちもパッとしないんだよな
シンプルと複雑の中間が欲しいわ

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

>>74
無難にいくなら
TypeScript/Node
C#
Java or Kotlin
あたりだろうな

**デフォルトの名無しさん** · 2021/09/02(木) 18:06:33.02

Dartはサーバ側でも使ってねとアナウンスあったけど、
クライアント側と同じ言語で書ける以外の利点は特に無いのかな

**デフォルトの名無しさん** · 2021/09/02(木) 18:11:04.37

>>74
複雑？？
イメージだけで語ってるやろ

**デフォルトの名無しさん** · 2021/09/02(木) 18:37:13.19

サーバ用途ならcrystalがええんちゃうかね。rubyをコピーした資産が多そう

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

別に1つの言語に拘る必要なくね
rust導入するとしても丸ごとリプレースする必要はない

**デフォルトの名無しさん** · 2021/09/02(木) 19:29:02.15

>>71
pythonも2から3への移行はだいぶ苦労したろ。
あれで脱落しなかったのは割と奇跡的だと思うわ。

**デフォルトの名無しさん** · 2021/09/02(木) 20:00:41.23

もしコンパイラ言語ならgccとかllvmも同時に移行しないとコンパイルできなかったりして

**デフォルトの名無しさん** · 2021/09/02(木) 20:34:58.67

>>80
慌てる乞食は儲けが少ない

**デフォルトの名無しさん** · 2021/09/02(木) 22:06:53.19

AndroidでもRust使うってよ
https://security.googleblog.com/2021/04/rust-in-android-platform.html

**デフォルトの名無しさん** · 2021/09/03(金) 13:29:52.44

Rustの最大の欠点はシンタックス。異論は認めない

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

>>84
他にも色々あるよ。

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

誤解を恐れずに言うとRustが嫌われるのはバカには理解出来ない難解さだろ

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

本質的でない複雑さもあるからね
たとえばRustは標準ライブラリがGoなんかに比べると貧弱なので、自前で実装したりコミュニティのパッケージに頼らざるを得ないシーンが多い

**デフォルトの名無しさん** · 2021/09/03(金) 18:25:24.07

>>86
rustの問題はこういうバカがイキってる所だと思う

**デフォルトの名無しさん** · 2021/09/03(金) 19:59:54.63

少なくとも、全てのアルゴリズムをRustではアプリのsafeモードでは扱えない。
例えライブラリをunsafeモードで書いたとしても。
それが最大の欠点。
書き方が面倒なのが次の欠点。

**デフォルトの名無しさん** · 2021/09/03(金) 20:30:12.82

全部unsafeで書けば面倒さは無くなりそう

**デフォルトの名無しさん** · 2021/09/03(金) 22:16:03.68

Rustでライブラリやメソッドを unsafe で書いて、それを safe モードから
使っても、決してCと同じ効率では利用できないアルゴリズムが存在する。

**デフォルトの名無しさん** · 2021/09/03(金) 22:27:23.15

>>91
理由は、Cで昔から至って普通に使われていたアルゴリズムのかなりもののが、
Rustだと借用規則に違反してしまうから。
学問的にも正しくて使い方を誤りさえしなければ安全である事が分かっていても、
Rustでは借用規則に違反するので最初からコンパイルエラーになってしまって
使えない。
それらのアルゴリズムは、unsafeモードの中だけに借用違反を閉じ込めよう
としても無理。なぜんばら、根本的に借用規則に違反していて、
それがそのアルゴリズムの本質で要(かなめ)の部分だから。

**デフォルトの名無しさん** · 2021/09/03(金) 23:01:26.75

>>84
様々なプログラミング言語と比較しても
Rustの基本シンタックス記法は素直なほぼ標準タイプ
最大派閥のC系と比較してもRustは条件式にカッコが不要なくらいかな

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

>>92
嘘つき
未だに例示できないくせに

**デフォルトの名無しさん** · 2021/09/03(金) 23:30:25.11

次にお前は連結リストと言う

**デフォルトの名無しさん** · 2021/09/03(金) 23:34:16.62

ハッシュマップ

**デフォルトの名無しさん** · 2021/09/04(土) 02:34:46.85

rustって最終的にはjavaみたいな奴隷専用言語になりそう

**デフォルトの名無しさん** · 2021/09/04(土) 03:07:14.01

そうだ。rustは君のものだ。

**デフォルトの名無しさん** · 2021/09/04(土) 04:09:47.08

たしかにRustは非常に書きやすいしコンパイラのrustcが賢くてミスを直す候補を探し出してきて表示してくれるので便利だけど
奴隷の生産性まで上がるものなのかね

**デフォルトの名無しさん** · 2021/09/04(土) 04:50:10.07

今の日本はだいたいが奴隷。

https://oshiete.goo.ne.jp/qa/3737411.html
> １５世紀のアメリカでは、教育と結婚の権利を与えられ財産を持つことも可能で、低賃金の労働者と言えるものでした。

**デフォルトの名無しさん** · 2021/09/04(土) 08:12:27.52

元々、共有やコピー、参照の違いをまともに理解してない奴に限ってrustを評価する傾向にあるのがな。。
はっきり言ってそれをまともに意識してるコード書くやつはそれほど便利だと思ってない。

**デフォルトの名無しさん** · 2021/09/04(土) 11:12:27.56

>>94
あなたは、数学は出来ないね？
俺は数学は得意だから、例がすぐ浮かぶぞ。

**デフォルトの名無しさん** · 2021/09/04(土) 11:14:39.89

ヒント:
safeモードに借用規則がある限り、メソッドの中にunsafeを閉じ込めようとしても
絶対に無理なアルゴリズムが存在する。

これが理解できないのは、数学力が足りない。数学力は生まれつきのものが大きくて、
ワーキングエリアの大きさや、想像力の問題。

**デフォルトの名無しさん** · 2021/09/04(土) 11:17:19.47

なぜ例を提示しないかと言えば、本当のことを教えたくないからだ。
嘘だからではない。
本当のことを教えるのはもっと時間が経った後でいい。
時間が経ったらだんだんと本当の事が広まっていくだろう。
俺は最初からそれがわかるが、分からない人は分からない人なりの人生を送れば
いい。それが俺の才能だから。
俺の才能を全ての人に分け与えるわけにはいかない。

**デフォルトの名無しさん** · 2021/09/04(土) 11:20:31.21

コンピュータの世界は、どんなに頭のいい人でも時間が経てば追いつかれる。
平易に解説されたり、または、ライブラリなどが難しいことを閉じ込めて
誰でも使えるようにしてしまうからだ。
だから頭のいい人もその間のタイムラグだけで差を付けるしかない。
だから、本当の事をすべては明かさない。

**デフォルトの名無しさん** · 2021/09/04(土) 11:30:28.20

入力するデータに依存するアルゴリズムなんじゃないの
C/C++なら自由に実装できるけど実務上は不正データがないかチェックするハメになるという

**デフォルトの名無しさん** · 2021/09/04(土) 12:30:13.91

>>106
全く関係ない。
数年後には秀才達が解説してくれるだろうから、分からない人はそれまで待とう。

**デフォルトの名無しさん** · 2021/09/04(土) 12:37:18.23

もしかして、ボローチェッカに怒られるコードをunsafeブロックに入れればエラーを回避できると思ってやってみたらできなくて、
それでここまでずっと言い訳してるのか？

**デフォルトの名無しさん** · 2021/09/04(土) 13:11:05.75

例示しろって言われてアウアウしてるんだろw
長文で言い訳グダグダ書いてるのが哀れですらある

**デフォルトの名無しさん** · 2021/09/04(土) 14:04:36.94

引っ込みがつかないとはまさにこのこと

**デフォルトの名無しさん** · 2021/09/04(土) 14:14:32.96

借用で表現できないアルゴリズムって何だろう。

**デフォルトの名無しさん** · 2021/09/04(土) 14:19:15.62

ループで書けないけど再帰でならかける、とかはあるけど、完全に書けないのはあるかなぁ…

**デフォルトの名無しさん** · 2021/09/04(土) 14:31:27.43

やはり、数学の才能の無いやつらには、分からないんだな。

**デフォルトの名無しさん** · 2021/09/04(土) 14:34:12.53

>>112
>ループで書けないけど再帰でならかける、とかはあるけど
ないでしょ

**デフォルトの名無しさん** · 2021/09/04(土) 16:16:10.33

>>104
教えたくないならこのスレくんなよ

**デフォルトの名無しさん** · 2021/09/04(土) 16:22:49.98

はい、スルー検定4級不合格です

**デフォルトの名無しさん** · 2021/09/04(土) 17:35:39.84

数学的才能がない人は、人から言われたことを鵜呑みにするだけで自分で考える事が出来ない。

**デフォルトの名無しさん** · 2021/09/04(土) 17:40:09.63

どのスレでもどの問題についてもいつも同じパターン
指摘されても具体的なケースを示せない人や具体的なコードを出せない人は『イチャモンをつけるだけのダメな人』

**デフォルトの名無しさん** · 2021/09/04(土) 17:40:36.61

今回の事を見ても分かるように、ヒントを与えられても、それを部品として
組み立てて結論を導くことが出来ない。
そういうひとはいいプログラムはできない。
自分でアルゴリズムを発明することも出来ない。

**デフォルトの名無しさん** · 2021/09/04(土) 17:41:48.84

>>118
違う。
ヒントを与えられても、自分で組み立てて正しい答えをひらめくことが出来ない
人しかそのスレに来ていないだけ。
答えを知っていても、与えないだけ。

**デフォルトの名無しさん** · 2021/09/04(土) 17:48:30.37

実世界でも一緒だな。
言い訳ばかりして具体例を出せない人を相手にしても話が進まず時間の無駄。
そういうバカは無視するのが正しい。

**デフォルトの名無しさん** · 2021/09/04(土) 17:54:17.63

優秀な人から正しい答えを簡単に教えてもらえると思ってるのはどういう教育されて
きたんだろう。
情報量も払わないくせに。

**デフォルトの名無しさん** · 2021/09/04(土) 17:55:05.92

>>121
それはあなたの周りに居る程度の低い人の話。
俺は違う。

**デフォルトの名無しさん** · 2021/09/04(土) 17:58:34.94

お前の情報なんて要らんからコテつけてくれ
最初から避けるから

**デフォルトの名無しさん** · 2021/09/04(土) 18:25:26.65

情報は与えないが、本当のことを言ってるのにうそ扱いしないでくれ。
ちゃんと思考力や理解力が有る人には正しいことが分かる。
このスレに今居る人は、俺以外は数学的能力が足りてない。

**デフォルトの名無しさん** · 2021/09/04(土) 18:29:06.33

>>125
十分説得できるくらいの話をする気がないやつなんざウソつきとして扱うしかないやろ