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

**デフォルトの名無しさん** · 2022/09/17(土) 19:05:49.83

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2022/09/17(土) 19:33:06.93

>>1-11
乙

>>9
それなら「反省点リスト」を整備・公開したほうがいいと思うけどなぁ。
Rustはすでにビジネスになっているからそんなことしないだろうけど。

**デフォルトの名無しさん** · 2022/09/17(土) 19:41:09.59

>>16
知ったかぶってしまいました。

**デフォルトの名無しさん** · 2022/09/17(土) 19:54:28.59

>>15
そのメモリ管理バグが引き起こしているセキュリティ脆弱性の根絶ができる新たな言語がRustしか登場しないのはなぜだろう
今世紀になってからも色んな言語が誕生してきたけどリスクを残す手動メモリ管理のままか戦力外のGCへ逃げるか両極端しかない気がする
現在求められている要件をRustしか満たしていないためにRustが唯一解となり採用されていってる感じだ

**デフォルトの名無しさん** · 2022/09/17(土) 20:09:21.63

>>18
*メモリリーク除く

**デフォルトの名無しさん** · 2022/09/17(土) 20:16:48.13

前スレのこれ
「Chrome」は「MiraclePtr」でさらに安全に～Googleが「解放後メモリ利用」対策を開設診断性が向上するという副次的効果も
https://forest.watch.impress.co.jp/docs/news/1439971.html
「Chrome」で対処されているバグの種類
https://asset.watch.impress.co.jp/img/wf/docs/1439/971/image3.png

>ChromeはRustで書き直せばバグを1/4に減らせると言われているね

Rustでの循環参照、メモリーリークのことを考慮するとちょっと話は変わるんじゃない？

**デフォルトの名無しさん** · 2022/09/17(土) 20:22:03.88

FirefoxってChrome対比で深刻なバグないの？

**デフォルトの名無しさん** · 2022/09/17(土) 20:25:47.68

>>19
Rustでは禁忌の循環参照を除きメモリリークすることは絶対にない。
一般的に、循環参照を解放するにはコストが非常に高いトレーシングGCを用いるしかないため、
高速性が求められる言語では循環参照を作らずにツリー構造＋弱参照という形にする。

**デフォルトの名無しさん** · 2022/09/17(土) 20:30:40.35

>>22
禁忌関係なく
前スレ952
>意図しなくても、「偶発的に」循環参照が作られることはありそうだ。

例
https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=0d4932743de9a2d3f91b215fe3a4757b
て確定した

**デフォルトの名無しさん** · 2022/09/17(土) 20:31:42.43

rustはエラーメッセージがc++より親切

**デフォルトの名無しさん** · 2022/09/17(土) 20:34:45.17

>>23
コードを読めないのか？
わざわざ複雑なことをして自分で循環させてるじゃん
自然には循環参照が起きないことの証明となっている

**デフォルトの名無しさん** · 2022/09/17(土) 20:34:50.37

>>22
現実世界でも禁忌を避けられると良いですね。

**デフォルトの名無しさん** · 2022/09/17(土) 20:37:43.52

数のstackoverflow v.s. 質のJetBrains

stackoverflow
https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-programming-scripting-and-markup-languages

jetbrains
https://www.jetbrains.com/lp/devecosystem-2021/ruby/
https://www.jetbrains.com/lp/devecosystem-2021/rust/
https://www.jetbrains.com/lp/devecosystem-2021/go/

Ruby https://i.imgur.com/zqmf96u.png お一人様 7% ほとんどの人が仕事で使っている
Rust https://i.imgur.com/olB9F6L.png お一人様 86% ほとんどの人が個人の趣味

**デフォルトの名無しさん** · 2022/09/17(土) 20:45:40.72

会社や客先の方針で無理やり使わされるプログラミング言語と違って
個人的な趣味で自由に言語を選べる状況でも使われるRustはやっぱりプログラミングがしやすいため？

**デフォルトの名無しさん** · 2022/09/17(土) 20:47:10.92

>>28 Rustは言語オタク

**デフォルトの名無しさん** · 2022/09/17(土) 20:56:06.27

ヌルポインタには解放前も解放後もないわけで
生ポインタの解放後メモリ利用というのはポインタがヌルではないから深刻なバグになる

弱参照は解放後は絶対にヌルになる（絶対に解放されるとは言ってない）

生ポインタと弱参照を比較するのが正しい
それ以外の比較は誤解を助長している

**デフォルトの名無しさん** · 2022/09/17(土) 20:58:06.96

>>30は言語オタク

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

プロレス終わった？

**デフォルトの名無しさん** · 2022/09/17(土) 21:16:27.18

Rustのやり方は賢面白くて賢いなあと思った

①まずRustでは言語仕様からNullポインタ(Null参照)を排除
➁従来のNullポインタ相当を使いたいときはenum Option型のNone値を使用
③None値はポインタ(参照)とは全く別の型だからそのまま使えば型エラーにできる
④しかしOption型はenumすなわちタグ付きだから毎回メモリが無駄に使用される？？と思ったら
⑤言語仕様上Nullポインタを完全に排除したのでNone値を示すために生成コードではNullポインタを使える

概念上の安全性と生成コードの効率性を分離して両立させているんだな

**デフォルトの名無しさん** · 2022/09/17(土) 21:18:59.74

C23の話は無いのか？

**デフォルトの名無しさん** · 2022/09/17(土) 21:21:47.68

>>34 マウスは買いより始めよ

**デフォルトの名無しさん** · 2022/09/17(土) 21:29:01.11

>>33「zero overhead abstraction」抜けてるぞ

**デフォルトの名無しさん** · 2022/09/17(土) 21:34:15.84

Zigもsound null safetyだな
https://ziglang.org/documentation/master/#Optional-Pointers
?がprefixなのが独特

**デフォルトの名無しさん** · 2022/09/17(土) 21:35:45.30

Rustではポインタだけでなく数値もNonZeroXxx型が各サイズ用意されたね
例えばOption<NonZeroU64>型はu64型と同じ64bitで表現されNoneの時に値0
従来の言語でのプログラミングでゼロ値を特殊扱いで値が無いことを意味させていたケースも安全に扱えるみたい

**デフォルトの名無しさん** · 2022/09/17(土) 21:46:11.34

Zig Playgroundもあるんだがサーバーが弱っちい
https://zig-play.dev/
素直にローカルだな

https://zenn.dev/voluntas/scraps/4111a964e3e07f
学ぶモチベーション
> C++ や Rust は自分には難しい
> Wasm に出力してブラウザで利用したい

CGOでGoからZigのライブラリを呼び出す
https://zenn.dev/mazrean/articles/4b7d9ba78fd073
>Cの問題点を改善しつつ、Cの果たしていた役割を綺麗に代替できており、非常に良くできていると感じました。

潜在的ターゲット層はそれなりにありそうだ

**デフォルトの名無しさん** · 2022/09/17(土) 21:53:11.57

C++とRustが難しいって単なるバカなんだろ
まとまな企業がZigを使うようになることはありえないな

**デフォルトの名無しさん** · 2022/09/17(土) 21:54:23.15

さすが Uberほどになるとまだβなんて関係ないか

How Uber Uses Zig
https://jakstys.lt/2022/how-uber-uses-zig/

Uberが資金援助も始めている
https://news.ycombinator.com/item?id=31478562

ZigはCMakeの代替となるか
https://zenn.dev/ryoppippi/articles/9efc7b621ec853

**デフォルトの名無しさん** · 2022/09/17(土) 22:06:06.81

>>20
下の記事みたいに、ChromeはRustの良さが活かせないんじゃない？規模も大きいし。
https://postd.cc/tsc-go/

**デフォルトの名無しさん** · 2022/09/17(土) 22:15:29.24

>>42
興味深い
>tscをGoに移植する作業は、Vercelがスポンサーとして資金を提供しています。
VercelってSvelteも囲い込んだな

あとRustのままだとお金出なかったのか

**デフォルトの名無しさん** · 2022/09/17(土) 22:32:25.64

規模ねぇ
ripgrepにはお世話になってるけど、tscとかに比べたら規模も大きいとは言えないだろうし。

**デフォルトの名無しさん** · 2022/09/17(土) 22:50:28.88

>>15
これは凄いなあ。
メモリーアクセスをコンパイラが管理するRustでは、出来ないのでは？

**デフォルトの名無しさん** · 2022/09/17(土) 22:51:25.05

C++は熟練するとやりたいことが全てできるようになる。
制限フリー。

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

>>38
ゼロ値を特殊扱いするケースってほぼ名義尺度だから直和型(あるいはenum)で十分じゃね？
算術演算できるような値の場合は負の値を特別扱いすることが多いような

**デフォルトの名無しさん** · 2022/09/17(土) 23:06:01.91

>>45-46 tsc-rust中止の tsc-goの教訓で言うと「向いてない」
このスレ的には「軍事予算級じゃないと不可能」

>>15 このスレの住人が書きそうな口調で笑った
こんな記事を聖書のように毎回持ち出してたのかw

> 周期的な可変参照を持っています。
原文
> cyclical mutable reference
Circular reference(循環参照)の事言ってるのか？

**デフォルトの名無しさん** · 2022/09/17(土) 23:09:44.26

>>47
C++は、トレイツやコンセプトで自由に出来るね。
さらに一歩進んでコンパイル時に3Dモデルの静的レンダリングやってる人も居たね。
おっそろしほど何でもできる。
制限フリー。

**デフォルトの名無しさん** · 2022/09/17(土) 23:12:09.98

>>42
それ大規模だからできなかったのではなく単なるそのまま移植だからしなかったんだよ
そこでの選択肢はそのRustで作製して62倍速となったプロトタイプをそのまま完成させていくか
お手軽に同じGC言語へ文法や言語依存部分だけ書き直すかのどちらかの選択
速さよりもお手軽かつたまたまスポンサーが付いた方を選んだ
ライバルが出現したり利益に直結しないならいくら遅くても構わない
あと今までが遅すぎたから僅かな速度向上でも喜ばれる

**デフォルトの名無しさん** · 2022/09/17(土) 23:15:13.11

>>50
> Rustで作製して62倍速となったプロトタイプ
Bun(Zig) vs deno(Rust)について一言🎤

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

>>51
その件は言語は全く関係ない
Node.js(by C++)がそれらの中で一番遅い原因はC++が遅いためか？
違うだろ

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

>>48
>>15 を確認せず適当に答えるけど、書き込める記憶域を予測可能な周期性でアクセスすると、それが（攻撃者が知りたい情報を読み取れるような）脆弱性となる。

・ユーザーが同じ操作を繰り返すなどの理由で、先ほどと同じサイズの記憶域をアロケートし、また開放することを繰り返す。
・同じサイズであるがゆえに、システムは先ほど解放されたばかりの記憶域を効率よく返してしまう。

これを防ぐために、返却された記憶域をすぐには使わず、一時退避させる。
ということでは？

**デフォルトの名無しさん** · 2022/09/17(土) 23:21:47.17

>>52
いや、それはC++が悪いであろう。
なぜならC++は光の速度を超えるために作られたのだから。
反省してC++26に反映するべし。

**デフォルトの名無しさん** · 2022/09/17(土) 23:27:38.60

C++において、コンパイル時定数（constexpr）は、コンパイル時計算が適用される。
したがって、コンパイル時定数としてデータを渡すなら、コンパイル時に3Dオブジェクトのレンダリングを完了してしまえるということである。
もちろん、3Dに限らず制限フリーです。
そんな道楽にうつつを抜かすのがC＋＋黒魔術部です。
入部に特別な条件はありません。
さああなたも今日から黒魔術士を目指しましょう。

**デフォルトの名無しさん** · 2022/09/17(土) 23:29:58.26

>>52 二枚舌が捗ってるね
素直に Bun vs node vs deno -> 速度 Zig > C++、Zig > Rust
tsc-rust vs tsc-js -> 速度 Rust > javascript
なのでは

**デフォルトの名無しさん** · 2022/09/17(土) 23:33:02.02

>>56
二枚舌って、安倍元総理生き返ったの？
統一教会やるじゃん。

**デフォルトの名無しさん** · 2022/09/17(土) 23:35:54.87

>>55
おまえさん初心者なんだな
コンパイル時確定定数をコンパイル時に算出できるプログラミング言語くらいいくらでもある

**デフォルトの名無しさん** · 2022/09/17(土) 23:37:52.85

>>57 おやおや
Rust無理筋上げが逆効果だと気づいて
C++無理筋上げに応用しようとしているMAUI/C#erですか？

**デフォルトの名無しさん** · 2022/09/17(土) 23:39:34.68

C++ならconstexprは0秒実行です。
なぜならコンパイル時に計算が終わっているからです。
これは凄いです。

プロシュート兄貴も言っています。
> 「計算する」と心の中で思ったならッ！
> その時スデに計算は終わっているんだッ！
> 「計算した」なら、使ってもいいッ！
まさにC＋＋です。

**デフォルトの名無しさん** · 2022/09/17(土) 23:42:17.56

ペッシ「分かったよプロシュート兄ィ！！兄貴の覚悟が！“言葉”でなく“心”で理解できた！」

**デフォルトの名無しさん** · 2022/09/17(土) 23:43:06.26

>>60-61 ほかスレで身バレしてたね見苦しいよツベ頑張りなよ

**デフォルトの名無しさん** · 2022/09/17(土) 23:47:37.11

>>60
コンパイル時に計算を終わらせるくらいなら君の大嫌いなRustでもできるし凄いことでも何でもない

**デフォルトの名無しさん** · 2022/09/17(土) 23:48:30.63

>>62
その御方は私ではないけれど、私は本名を名乗ってインターネッツしてるので、身バレも糞もないのですよ。
ツイッターもフェイスブックも本名アカウントで認証バッジもついております。

**デフォルトの名無しさん** · 2022/09/17(土) 23:55:34.21

キミの限界は、きみ自身にあるんじゃない。
言語の限界が君の限界を決めるのだ。
さあC++で限界を超えろ！

**デフォルトの名無しさん** · 2022/09/17(土) 23:56:40.04

Just do it！！

**デフォルトの名無しさん** · 2022/09/17(土) 23:57:14.61

ハァハァ、興奮して鼻が膨らんできた（笑

**デフォルトの名無しさん** · 2022/09/18(日) 00:01:22.70

>>60
C++は単なるimmutableをconstで表すため
本当の定数つまりコンパイル時定数をcostexprで表さざるを得なくなっちゃってるよな

Rustではconstがコンパイル時定数だからわかりやすい
もちろん同様にコンパイル時に関数を呼んで計算させて定数をコンパイル時点で算出確定させることができる

**デフォルトの名無しさん** · 2022/09/18(日) 00:05:06.77

>>68
だめだ！それじゃあダメなんだッ！
「本当の定数がある」じゃないッ！！！
俺たち黒魔術部員ならッ！「ファッ！？？」「実行時定数が無いのッ！？」
と考える！！！！

**デフォルトの名無しさん** · 2022/09/18(日) 00:10:32.55

ここだけゲハ板

**デフォルトの名無しさん** · 2022/09/18(日) 00:11:17.78

コンパイル時計算は理屈上はJITの方が有利でしょ
実行時の統計に基いて頻出パターンを事前計算するとかできるからな

**デフォルトの名無しさん** · 2022/09/18(日) 00:13:17.20

>>71
よし、その理論をC++26へ提案する栄誉を貴様に与えよう。

**デフォルトの名無しさん** · 2022/09/18(日) 00:15:59.99

>>48
それは単にVercelの人の能力がないのでは？
rustcはRustで書かれてるんだしコンパイラは得意分野なんだけど
なんで実装できないなんて判断をしたのか謎すぎる

**デフォルトの名無しさん** · 2022/09/18(日) 00:22:09.73

>>71
JITの方が当然不利
実行前にコンパイルを済ませてしまうC++に勝つことはできない

**デフォルトの名無しさん** · 2022/09/18(日) 00:39:41.33

Vercelの人のブログ見たけどtscをそのまま移植しようとしたのか？
流石にそれは無理でしょ
typecheckerの仕様だけリバースエンジニアリングして
その仕様をrustで実装するようにしないと
あらゆるオブジェクトが参照であるtypescriptのコードを移植するとか流石にそんなことをやる発想が微妙

**デフォルトの名無しさん** · 2022/09/18(日) 00:42:56.71

確かにGoならあらゆるオブジェクトを参照にできるし
クロージャもあるしそのまま移植するのには向いてるかもな

**デフォルトの名無しさん** · 2022/09/18(日) 01:08:52.24

元のtscのコードの多くの部分がガベージコレクションに依存していると書いているから
それらを治して本格的に高速にする道を選ぶか
サボって同じGC言語へ移植する道を選ぶか
今回は後者にしただけだろう

普通にある一般的なケースでは
システムに何らかの限界が来て新たな設計をする機会で他の言語にする
何もかもほぼそのままで言語だけ変える特殊なケースならばGC言語の範囲内の中で選ぶしかない
世界中の人々が今後も使い続けるものならば非GC言語へ移植する価値もあるとは思うが

**デフォルトの名無しさん** · 2022/09/18(日) 01:28:43.72

tscが遅いからそれより早いトランスパイラを作るという目的なら別にGoでも良い気はするね
ただどこかで踏ん張ってRustに移植するという作業は人類にとっても価値があると思うけどね

**デフォルトの名無しさん** · 2022/09/18(日) 01:30:28.35

GC言語使って参照を持ち放題で問題ないって
それってプログラマがデータ構造とメモリレイアウトを正確に理解していない
つまり副作用を追跡できないことを意味する
でかいコードベースでその状態はかなりまずいよ

**デフォルトの名無しさん** · 2022/09/18(日) 01:36:10.67

副作用を追跡できないからテストコードを書く必要が出てくる
参照と書き換えの制限はテストコードも不要にする
tscを再設計する時が来てる

**デフォルトの名無しさん** · 2022/09/18(日) 01:40:45.22

>>79
GC言語はプログラム設計やその中のデータ構造設計が酷くてもなんとなく動いてしまいがち
もちろんバグは発生しやすくなるしデバッグしにくいしメンテもしにくいし機能追加や改善など大変
非GC言語が苦手な人や難しいという人はそのあたりのデータ構造含めたプログラム設計をきちんと出来ていないダメな人

**デフォルトの名無しさん** · 2022/09/18(日) 01:42:28.72

>>81
困ったら適当に参照持たせたら終わりだしな
しかもそれを書き換えたりもする
めちゃくちゃだよな

**デフォルトの名無しさん** · 2022/09/18(日) 07:35:50.11

じゃあここにいるRust玄人たちでRust使ってtsc作り直せよ
Vercelの人は能力不足だとかほざいちゃってるし

**デフォルトの名無しさん** · 2022/09/18(日) 07:53:59.80

>>41
これの原因？

ウーバーで大規模ハッカー攻撃か　システムほぼすべて乗っ取られる
https://www.asahi.com/articles/ASQ9J5SQ0Q9JUHBI01N.html

安全な言語を使いたいな

**デフォルトの名無しさん** · 2022/09/18(日) 08:09:37.13

>>39-41
このコンボで精神崩壊したのか。
それで>>84でUber disやら深夜のVercel dis

GAFAMのやらかしなんてキリがない二枚舌が捗ってる

**デフォルトの名無しさん** · 2022/09/18(日) 08:21:46.99

Rustが失敗だったからCarbonの開発が始まったんだよな

**デフォルトの名無しさん** · 2022/09/18(日) 08:27:50.32

前スレ >GCで良ければGC言語使えば良いよ

Google >Rustで良ければRust使えば良いよ

Google >Rust使えないから Carbon始めました

**デフォルトの名無しさん** · 2022/09/18(日) 08:29:42.37

>>84
それソーシャルクラッキングだから言語なんて1mmも関係ないぞ

**デフォルトの名無しさん** · 2022/09/18(日) 09:08:02.19

>>86
Carbon公式FAQを読みなさい
If you can use Rust, ignore Carbon
とのサブタイトルから始まりRustの方が良いと書かれている
Carbonは既存C++コードのための存在

**デフォルトの名無しさん** · 2022/09/18(日) 09:09:29.57

Google >Rustで良ければRust使えば良いよ

Google >Rust使えないから Carbon始めました

まんまじゃねーか

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

複オジ(26) >初心者向けのVS本は最低

**デフォルトの名無しさん** · 2022/09/18(日) 09:23:45.71

CarbonはC++に強く依存したプロジェクトのためのものなので、そうじゃないならRustを使え、
とわざわざ書いてあるんだな

**デフォルトの名無しさん** · 2022/09/18(日) 09:29:02.34

Google >Rustで良ければ Rust使えば良いよ

Google >Rust使えないから Carbon始めました

まんまじゃねーか

**デフォルトの名無しさん** · 2022/09/18(日) 09:30:03.67

RustはRustに強く依存したプロジェクトになるという欠点があるからな。
Rusteseはそれが狙いなんだろうけど。

**デフォルトの名無しさん** · 2022/09/18(日) 09:39:52.76

>>94
Rustese>こっちの水は甘いよ
Google >Rust沼はスルーする

**デフォルトの名無しさん** · 2022/09/18(日) 09:59:36.68

>>95
GoogleはRustを使いまくっていて
AndroidとLinuxがRust導入することになったのもGoogleの強いRust推しがあったためだよ
一方で既存のC++によるシステムは次に大規模システム改変があるまではこのまま使い続けたいけど
C++には問題が多すぎるからCarbonでそれまで延命するっていう話だよ

**デフォルトの名無しさん** · 2022/09/18(日) 10:07:15.64

>>96 もうRustは諦めな向いてなかった

Goスレの自己紹介レスうける

**デフォルトの名無しさん** · 2022/09/18(日) 10:12:06.21

そもそもGoogleはRustを安定的に支えるために設立したRust Foundationの発起人やんけ

**デフォルトの名無しさん** · 2022/09/18(日) 10:21:51.07

>>84
こういうのはだいたい最初の突破口はクラウドの設定ミスかソーシャルエンジニアリング

**デフォルトの名無しさん** · 2022/09/18(日) 10:38:43.71

C/C++用のライブラリ書く機会多いもんなぁ
だがここにRust使ううまみは全く無い

**デフォルトの名無しさん** · 2022/09/18(日) 10:41:29.51

Rustはなんでも「Rustなら最高に安全に、高効率でできる」と言って、開発効率を無視するのがなんか違うよなって思ってる。
すぐに「長期的にはRustの方が開発効率が良い」とか言うし。

「最初は負債を負ってでもプロダクト出さなきゃしゃーねーだろ、後で返済しろ」みたいなまともなビジネス要件を完全に無視されるので、なんなのよって思うことが多い。

**デフォルトの名無しさん** · 2022/09/18(日) 10:55:40.65

その比較対象がC++なら間違ってないだろ

**デフォルトの名無しさん** · 2022/09/18(日) 10:57:40.17

大風呂敷はともかく
言語仕様に絞ればRustはプログラミングしやすくて開発効率が高いのは事実だと思うぜ
その点まで否定する人はいないと思うが

**デフォルトの名無しさん** · 2022/09/18(日) 11:00:24.83

>>101-103
負債まみれでも、とりあえずRoRが良い現実解>>27

**デフォルトの名無しさん** · 2022/09/18(日) 11:04:33.30

C++には自由がありそうでないんだよな
bad_allocを投げない自由があるとか綺麗事を言うが実質的にそんな自由はない

**デフォルトの名無しさん** · 2022/09/18(日) 11:09:26.06

>>41
zigはzenとの確執がありそうで怖い

**デフォルトの名無しさん** · 2022/09/18(日) 11:12:40.00

C++は脳汁が出るぜィ！！

**デフォルトの名無しさん** · 2022/09/18(日) 11:13:36.91

>>105(26) 前スレまでのC/C++のレベル見てC++に寄生すな

>>106(26) www Zigも攻撃対象か。zenが全面的に悪い

**デフォルトの名無しさん** · 2022/09/18(日) 11:16:05.92

競技プログラミングでC＋＋が好まれるのは、脳汁が出るからです。
ランナーズハイやクライマーズハイと同じ、あるいはゾーンに入ると表現されることもあります。
RPGで言えば、加護を受けて無敵状態の時間帯です。
どうだ！C＋＋凄いだろ！！

**デフォルトの名無しさん** · 2022/09/18(日) 11:19:12.61

ぜ語尾でマウントの複おじ
な語尾で主観垂れ流しの複おじ
体言止めで証明失敗の複おじ
各種取り揃えております

**デフォルトの名無しさん** · 2022/09/18(日) 11:21:18.22

>>106(26) Zig丸コピして日本でZenを立ち上げた張本人? OKAMOTO
https://connectfree.co.jp/legal/specified_commercial_transactions/

**デフォルトの名無しさん** · 2022/09/18(日) 11:27:33.70

ツイ 12年前「19の大学生です」か
完全一致
とんだ泥棒やろうじゃないか

**デフォルトの名無しさん** · 2022/09/18(日) 11:43:05.79

まともにRoRやれば良いんじゃない？現実解>>27

**デフォルトの名無しさん** · 2022/09/18(日) 12:01:46.79

法的な泥棒には当たらないけどOSS倫理的にはNG

Zigがわざわざ日本語の声明を出している
Zigソフトウェア財団とZenプログラミング言語に関する声明
https://ziglang.org/news/statement-regarding-zen-programming-language/
>コネクトフリー社の創設者であるテイト氏は、不完全な技術論により彼自身の行動を正当化しようとすると同時に、契約条項を利用してZigの貢献者がこのオープンソースプロジェクトに更に貢献する事を阻止しています。また、コネクトフリー社のZenはZigを表面的にリブランディングしたものに過ぎません。このようなテイト氏の過去と現在の振舞いから、日本の専門家や会社がこうしたクローズドソース製品に頼り生計をたてようとするのは、私どもの良識としてはお勧めできません。

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

Rubyリクルーター > RoRやれば良い