Rust part20

**デフォルトの名無しさん** · 2023/03/03(金) 00:45:28.73

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part19
https://mevius.5ch.net/test/read.cgi/tech/1673926892/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2023/03/22(水) 13:00:26.42

>>251
おいおいなんで急にハッシュマップが出てくるんだよ
そんなんで大丈夫か？

Vec<Option<V>>みたいなデータがどこからともなく自然発生するわけないんだから全体のパイプラインを考えろって言ってるの
現実的かつ具体的なユースケースで考えような

**デフォルトの名無しさん** · 2023/03/22(水) 18:31:25.27

ナイーブなハッシュテーブルをVec<Option<T>>で実装する人はいるかもしれない

**デフォルトの名無しさん** · 2023/03/22(水) 21:00:04.56

うちも値域が限定されてる離散値はArrayかVec<Option<T>>使う

**デフォルトの名無しさん** · 2023/03/22(水) 21:30:41.78

マニュアルに書いてるような内容をやたら饒舌に語るとChatGPT感出るね

**デフォルトの名無しさん** · 2023/03/22(水) 21:32:36.00

>>255
>ナイーブなハッシュテーブルをVec<Option<T>>で実装する人はいるかもしれない
その場合でもTは(u64, K, V)

**デフォルトの名無しさん** · 2023/03/22(水) 21:36:57.10

Vec<Optionは普通に使うぞ
今書いてる部分と似たようなことをしてるregexのソースを見たらVec<Option使ってる
普通そうなるよな

**デフォルトの名無しさん** · 2023/03/22(水) 22:15:33.42

>>257
まるで知能は互角で内容だけが違うみたいな言い方だが
知能の差を見せつければいいだけだよ

**デフォルトの名無しさん** · 2023/03/22(水) 23:19:58.21

Vec<Option<T>>が使われないなんていう話は誰もしてないのにね
話が通じなくてもう面倒くさ過ぎるわ

**デフォルトの名無しさん** · 2023/03/22(水) 23:35:18.64

たぶん論点はfilter_mapの話からここ

> vec![None, Some((1, 2)), None, Some((3, 4)), None];みたいなのはこれがすでに入力値に対して何かしら関数適用した結果なんだよね

> Vec<Option<V>>みたいなデータがどこからともなく自然発生するわけないんだから全体のパイプラインを考えろって言ってるの

でもこの主張は間違っていて
疎なデータ構造ならいきなりVec<Option<T>>が現れる
初期値オールNoneから飛び飛びにSome化していく
そのVec<Option<T>>は何度も使うからのイテレータ処理の一時的に現れるものでもない

**デフォルトの名無しさん** · 2023/03/23(木) 00:27:50.25

構うから暴れるんすよ

**デフォルトの名無しさん** · 2023/03/23(木) 07:45:41.23

グラフ構造でVec<Option<usize>>使うこともある
さらにインデックス自体のマッピングにも使われたり
// Maps old index to new index. None if not yet visited.
let mut remap: Vec<Option<usize>> = vec![None; self.nodes.len()];

**デフォルトの名無しさん** · 2023/03/23(木) 08:16:41.69

公式ドキュメントとchatgpt
これだけあれば全て滅びる

**デフォルトの名無しさん** · 2023/03/25(土) 10:51:05.32

人間があれやこれやするよりも
全部 AI 翻訳に任せりゃインジャネーノ

**デフォルトの名無しさん** · 2023/03/27(月) 10:33:42.84

>>263
本当にそうだったね

**デフォルトの名無しさん** · 2023/03/27(月) 13:18:10.65

そのうち
課題を見つける能力
課題を提起する能力
がメインとなるんやろな
1人会社が当たり前になりそう

**デフォルトの名無しさん** · 2023/03/27(月) 17:47:50.73

>>268
今までもそうだったけど気づいてない人が多かったというだけ
解けることが事前にわかってる問題を与えられて解くだけの人は今までも価格競争にさらされ段階的に置き換えられてきた

機械学習による変化は機械に解かせることのできる問題の抽象度が上がったこと

**デフォルトの名無しさん** · 2023/03/30(木) 21:28:14.05

samタレットを壊されないかつ迎撃もできる状態で設置する方法ってない？
拠点屋根に四台設置してんだけどログインする度に毎回壊されてるわ

**デフォルトの名無しさん** · 2023/03/30(木) 21:34:58.46

ごめんスレ間違えた

**デフォルトの名無しさん** · 2023/03/31(金) 12:09:07.07

それはrustだろ？ここはrustスレ。間違えるなよ

**デフォルトの名無しさん** · 2023/04/01(土) 04:03:16.63

Interface 2023年5月号
550号特別企画　2大特集　Linuxでも正式サポート，組み込みや車載で注目を集める　質実剛健 Rust言語
3月25日発売 (定価 1,200円＋税)

第1特集：C言語と比べて理解する
第2特集：マイコンで動くフル機能Rust
特別付録：初めてのRustプログラミング
新連載：毎号実験！自律移動ロボット

**デフォルトの名無しさん** · 2023/04/01(土) 16:12:14.56

>>273
面白そうだな。組み込みだと実装依存のCコードがまかり通っていたりするからな

**デフォルトの名無しさん** · 2023/04/02(日) 17:52:37.39

interface読んでる連中には難しいんじゃないの？

**デフォルトの名無しさん** · 2023/04/02(日) 18:01:44.10

むしろこれを機に組み込みの勉強でも始めてみようかしら

**デフォルトの名無しさん** · 2023/04/02(日) 18:02:25.20

>>273
本屋で見てきた。個人的にめぼしい解説はCMSIS-DAPくらいで
大体The Embedded Rust Bookで十分かな

**デフォルトの名無しさん** · 2023/04/02(日) 19:09:06.81

組み込みだったらmrubyだよね
しらんけど

**デフォルトの名無しさん** · 2023/04/03(月) 00:25:42.34

そのうちrust謹製の組み込み OS とか出てくるんじゃねえの

**デフォルトの名無しさん** · 2023/04/03(月) 00:53:16.98

>>279
Google が KataOS を発表してる。今は CantripOS と改名してるっぽいな。
どこまで本気なのかよくわからんけどコードは Github に有るから見物してみたらいいんじゃない？

**デフォルトの名無しさん** · 2023/04/03(月) 09:12:06.30

組み込み分野を目指す学生はPythonばっかり
これを機にRustやCやC++にも目を向けて欲しい
組み込み分野の実務でPythonはつぶしがきかない

**デフォルトの名無しさん** · 2023/04/03(月) 11:15:42.36

組み込みでPythonとか使うのか
一番親和性の感じられない組み合わせやな

**デフォルトの名無しさん** · 2023/04/03(月) 11:32:22.07

ラズパイでしょ

**デフォルトの名無しさん** · 2023/04/03(月) 11:39:22.47

ラズパイは組み込みじゃないだろｗ
組み込み向けだと MicroPython とかあった気がするけど使われてるのかねぇ

**デフォルトの名無しさん** · 2023/04/03(月) 11:55:49.94

ラズパイはLinux系OSが動いていてX Windowを立ち上げてデスクトップPCにすることも可能な環境
昔からからの組み込みが指すのはOSがないもしくは簡易なものしかない環境でありそこでPythonは使われない

**デフォルトの名無しさん** · 2023/04/03(月) 12:04:38.11

組み込みかどうかと言うより
ミッションクリティカルかどうかと言ったほうが正確か

**デフォルトの名無しさん** · 2023/04/03(月) 12:08:34.80

同等以上に曖昧に思う。

**デフォルトの名無しさん** · 2023/04/03(月) 12:26:19.63

組み込みならFORTHだよね。

**デフォルトの名無しさん** · 2023/04/03(月) 15:05:13.27

ミッションクリティカルの意味わかってないだろw

**デフォルトの名無しさん** · 2023/04/03(月) 15:14:52.29

javaですら使われるんだから場所によってはpythonもあるだろう

**デフォルトの名無しさん** · 2023/04/03(月) 16:24:30.55

このスレ複製おじ来なくなって平和になったなｗ

**デフォルトの名無しさん** · 2023/04/03(月) 17:14:33.32

10年後くらいには組み込みの指すやつが10GHz・20GBくらいになってんだよ

**デフォルトの名無しさん** · 2023/04/03(月) 22:15:51.09

Python だって組み込みに使われるのはわかるよ。
でもそれをホスティングする環境は何で書くんだって話よ。
アプリケーション部分だけ書ければ良しというわけにもいかんだろう。組み込みってのは。

**デフォルトの名無しさん** · 2023/04/03(月) 22:22:41.19

組み込みの定義次第

**デフォルトの名無しさん** · 2023/04/03(月) 22:46:10.84

自分の中の組み込みはリアルタイムシステム
CかC++

**デフォルトの名無しさん** · 2023/04/03(月) 23:08:31.70

>>290
javaですらというか、javaはもともと組込みを視野に入れて開発されたものだしな

**デフォルトの名無しさん** · 2023/04/04(火) 12:59:01.65

普通のWindowsPCを何かの筐体に入れればそれは組み込みだがそういう話じゃないよな
実装的には一般的なアプリと何も変わらないわけだし

**デフォルトの名無しさん** · 2023/04/04(火) 19:20:19.03

みんな、組み込みに食いつくね
連想するの分野がひとそれぞれなんだね
おいらは組み込みといったらファームウェアだな

**デフォルトの名無しさん** · 2023/04/04(火) 20:28:06.15

PICじゃなきゃ組み込みじゃないって感じなのかな？
数年前に関わった仕事じゃFPGAとARMが両方乗っかってて
OSも入ってるやつで測定データをCのソケットでUDP送信させたけどこれ組み込み？

**デフォルトの名無しさん** · 2023/04/04(火) 20:50:26.77

>>297
それも組み込みだがなんらかのデバイスの制御はするだろ。
しないってのならさすがに組み込みとは言わんと思うが……。

**デフォルトの名無しさん** · 2023/04/04(火) 21:47:02.28

技術的には低レイヤーと称する方が適しているのだろうな。せいぜい軽量のRTOSあたりまで

>>300
汎用性に乏しい装置は原則組み込みじゃね
ゲームコンソールもどちらかと言えば組み込みだと思うし
デジタルサイネージとかも該当するだろう(ラズパイ使っている例もあるらしい)

**デフォルトの名無しさん** · 2023/04/05(水) 02:16:43.52

>>301
steam deckがLinuxベースという話もあるので
ゲームコンソールが組み込みかどうか…

テレビもLinuxが入ってたりするしなあ

**デフォルトの名無しさん** · 2023/04/05(水) 11:08:42.58

>>302
Steam Deckは携帯ゲーム機の形をしているだけで任意のOSを使用できるのだからPCでしょ
>>301でいうゲームコンソールはCS機やAC機等のゲームを実行することしか想定していない装置のこと
テレビもどちらかと言えばゲームコンソールよりでは

**デフォルトの名無しさん** · 2023/04/06(木) 10:45:28.99

>>303
デバイスドライバやファームウェアをひとつも書いてないってことはなかろうし、
デバイスに固有の低レイヤプログラミングの部分は組み込みと言ってもいいんじゃないの。

**デフォルトの名無しさん** · 2023/04/06(木) 11:27:07.02

普通組み込み用途と言えばコンピュータ制御の電子機器のために使う用途やろな
・メモリなどのリソースが少ない環境でも使える
・応答時間などのタイミング制御のために実時間処理ができる
こういうのにRustが強いのは何となくわかる
コンパイル時に静的に解決できる範囲が広いからな

**デフォルトの名無しさん** · 2023/04/06(木) 12:37:50.23

全然違う話でごめん
以下のような処理がある時にf(**item)と参照外しを2回も必要とするのは違和感あるけどそういうもの？

let v: Vec<i32> = vec![1, 8, 4, 5, 9, 6, 3];
let valid_index_list: Vec<usize> = v
.iter()
.enumerate()
.filter(|(_, item)| f(**item))
.map(|(index, _)| index)
.collect();

**デフォルトの名無しさん** · 2023/04/06(木) 12:42:05.41

組み込みシステムと組み込みプログラミングで微妙に境界線が異なる

例えばサーマルカメラ内蔵のAndroid端末を使った検温システムは組み込みシステムだけど
サーマルカメラのSDKを利用した検温アプリ開発は組み込みプログラミングとは呼ばないかもしれない
サーマルカメラのSDKを作る開発は組み込みプログラミングと呼べる

**デフォルトの名無しさん** · 2023/04/06(木) 12:56:01.04

確かにSoCや基板の事情がソフト側から見えてると
（memory mapped I/O直接叩くとか）
OSの有無によらず組み込みっぽい感じはするな

**デフォルトの名無しさん** · 2023/04/06(木) 15:14:50.96

>>306
なんかオジっぽいコードだね
普通はDeref Coercionを活用する
その例ならfを&i32 -> boolにすれば明示的derefは不要
filter関数がownership取るのは変

ついでにfilter_mapでまとめて
.filter_map(|(index, item)| f(item).then_some(index))
シグニチャ変えられない特別な事情があるならパターンマッチで|(index, &item)|としてderefしておく

**デフォルトの名無しさん** · 2023/04/06(木) 16:55:58.17

>>306
値を返すイテレータも参照を返すイテレータもあるから
どちらでも不都合のない仕組みにしようとするとそうなるんじゃないの。
参照が二重になるのはごく普通のこと。

その二重の参照をどうやって剥がすかには選択肢があるけど。

**デフォルトの名無しさん** · 2023/04/06(木) 18:19:32.48

>>306 >>309
Vecのインデックスをフィルタリングしているだけだから
iter()もenumerate()もmap部分も不要
シンプルにこれだけでよい
(0..v.len())
.filter(|&index| f(v[index]))
.collect();

**デフォルトの名無しさん** · 2023/04/06(木) 18:50:13.90

俺はそれやだな

**デフォルトの名無しさん** · 2023/04/06(木) 19:01:16.65

俺もそれはちょっと遠慮したい

でもまぁそこは論点じゃないんでしょ
iter().filter()は常に&&Tになるから**itemするのが一般的かどうかを聞いてるんだよね？

**デフォルトの名無しさん** · 2023/04/06(木) 19:34:52.41

>>311
イテレータでのアクセス (シーケンシャルアクセス) とランダムアクセスが混ざるのがなんか嫌な気持ちになる。
Vec や配列であることが分かっているときなら問題はないというか、
むしろ状況が整理された良いコードだとも思うんだけどなんか心理的な抵抗感が……。

**デフォルトの名無しさん** · 2023/04/06(木) 21:02:27.27

またイテレータの話してる

**デフォルトの名無しさん** · 2023/04/06(木) 22:26:13.61

>>313
into_iter()でT自体を回してるときにfilterで消費しないように&Tを使っているために
iter()で&Tを回してるときは&&Tになってしまうわけだな
3つの点
・&&Tを考える概念的なわかりにくさ
・記述と可読性
・最適化後の最終コード
それそれで不利があるのかどうか？

**デフォルトの名無しさん** · 2023/04/08(土) 17:58:41.25

イテレータおじさん.....。

**デフォルトの名無しさん** · 2023/04/08(土) 23:26:42.03

多数の文字列をいくつでも追加で登録できて、
その登録した各文字列の参照(&str)を、
その登録オブジェクトが生きてる間は自由に使えるような機能のクレートありますか？

追加のみで削除機能がなければ安全に参照&strを返してその参照をずっと安全に使い続けられるインタフェースを提供できそうですが、
実現にはunsafeを使わざるを得ないため何かデファクトスタンダードなクレートがあるか知りたいです。

**デフォルトの名無しさん** · 2023/04/09(日) 00:21:16.51

Vec<String>

**デフォルトの名無しさん** · 2023/04/09(日) 00:32:20.15

Vecは追加のために&mutを使うから&strを持ち続けられないか

**デフォルトの名無しさん** · 2023/04/09(日) 01:16:25.16

は？

**デフォルトの名無しさん** · 2023/04/09(日) 01:36:27.91

もしかしてこういうこと？
let mut v = Vec::new();
v.push("first".to_string());
let first: &str = &v[0];
v.push("second".to_string());
let second: &str = &v[1];
println!("{first} and {second}");
コンパイルエラーだな

**デフォルトの名無しさん** · 2023/04/09(日) 01:42:07.16

文字列専用じゃないけどarena系の実装でいいのかな
typed_arena（https://docs.rs/typed-arena/latest/typed_arena/index.html）がよく使われてるみたい

use typed_arena::Arena;

fn main() {
let arena = Arena::new();
let a: &mut str = arena.alloc_str("abc");
let b: &mut str = arena.alloc_str("def");
let c: &str = arena.alloc_str("ghi");
println!("{a}, {b}, {c}"); // abc, def, ghi

a.make_ascii_uppercase();
b.make_ascii_uppercase();
let d: &str = arena.alloc_str("jkl");
println!("{a}, {b}, {c}, {d}"); // ABC, DEF, ghi, jkl
}

**デフォルトの名無しさん** · 2023/04/09(日) 01:56:50.49

だとしたらinterior mutabilityでやる話だね

**デフォルトの名無しさん** · 2023/04/09(日) 02:19:43.49

use string_cache::DefaultAtom;

fn main() {
let s1 = DefaultAtom::from("example");
let s2 = DefaultAtom::from("example");

assert_eq!(s1, s2);

let s1_ref: &str = &*s1;
let s2_ref: &str = &*s2;

assert_eq!(s1_ref, s2_ref);
}

**デフォルトの名無しさん** · 2023/04/09(日) 02:43:31.70

シンボルテーブルか

**デフォルトの名無しさん** · 2023/04/09(日) 16:31:56.46

>>323,325
質問者はコレクションを求めてるんだろ

**デフォルトの名無しさん** · 2023/04/10(月) 08:37:09.69

Rustのwebフレームワークって2023年現在どれがおすすめですか?

**デフォルトの名無しさん** · 2023/04/10(月) 10:35:11.69

そんなに数多くないと思うから10～20個くらい試して何が良かったか教えてよ

オススメ聞くってことはここで挙げられるようなやつ全部試して感想聞かせてくれるってことでしょ
決めるのに好みも入ってていいんだから
なんなら「名前が気にくわない」「アイコンがダサい」くらいの理由でもいい

**デフォルトの名無しさん** · 2023/04/10(月) 10:45:58.73

規模とか構成とかでも良い選択は違うのでなんとも言いにくいな。
比較的に万能で定番なものは actix, axum, rocket あたりだと思うが。

**デフォルトの名無しさん** · 2023/04/10(月) 12:38:17.63

Tide 使っとけば間違いない

**デフォルトの名無しさん** · 2023/04/10(月) 15:48:33.90

パフォーマンスより、単純明快なwebフレームワークが知りたいな
PythonならFlask的な
どうせDBがボトルネックになるし

**デフォルトの名無しさん** · 2023/04/10(月) 18:28:14.17

そういうの自分で調べられない人はもう少しエコシステムが成熟してからRustを検討した方がいいよ

**デフォルトの名無しさん** · 2023/04/10(月) 19:05:09.35

どうせ○○がボトルネックになるし
↑
こういう発想は大事
細かいところにだけ着目してvtableのコストがどうのとか
クロック数でいくらどうのとか
そういう連中よりは遥かにセンスがある

**デフォルトの名無しさん** · 2023/04/10(月) 19:20:23.61

>>334
クラウドだとCPU時間やメモリに課金されるから
「ユーザの体感速度にほんど影響がないからいいや」とはならない。
スループットだけ見てればよい時代は終わった。

ローカルでちょっとした GUI がわりにする程度ならどうでもいいけど……。

**デフォルトの名無しさん** · 2023/04/11(火) 23:57:13.30

ディスパッチの話で負けた負け犬が遠吠えこいてんのか

**デフォルトの名無しさん** · 2023/04/26(水) 20:19:48.59

Rustに限った話じゃないけど非線形(条件分岐を少なからず含む)な関数のテスト条件って普通どうやって作るの？
例えばRGB888フォーマットの色1と色2を飽和加算合成する関数を作ったのでテストしたいとする
すべてのパターンをテストすれば確実だが2の24乗もあってあまり現実的ではない
最小値と最大値と線形から非線形に移行する付近のみテストするとか？

**デフォルトの名無しさん** · 2023/04/26(水) 20:42:58.19

境界付近をテストするので良いと思う。
網羅的にテストしたつもりでも実際の問題ってのはどうせ
想定してないところから出てくるもんだから事前に何もかも盛り込むのは無理。
問題が出たときにテストを追加して同じ問題をもう出さない (後退はしない) ようにして
徐々に良くしていくしかない。

**337** · 2023/04/29(土) 21:52:25.06

>>338
あと追加するなら加算のテストくらいかな
0+1=1、1+1=0+C、1+0=1・・・ビット単位ならパターンはそこまで多くないし
ググっても具体的に何をテストすべきかみたいな解説はあまり出てこない気がする

**デフォルトの名無しさん** · 2023/05/02(火) 10:56:16.58

スレに人が来なくなったのはGWなのとchatGPTでPG需要減ってきたからか

**デフォルトの名無しさん** · 2023/05/02(火) 12:05:52.42

sudoとsuがRustで書き直される。メモリ安全性向上へ
https://news.yahoo.co.jp/articles/296d15d7c1f7190ff1646f4d52f8df8c56c0e132

**デフォルトの名無しさん** · 2023/05/02(火) 12:09:31.43

このままLinuxの公式言語になってしまうのだろうか？
それはそれでちょっと寂しい

**デフォルトの名無しさん** · 2023/05/02(火) 12:15:20.08

へぇ、Rustって知らないところで着実に市民権獲得し始めてるんやな
まぁ確かに“安全性”、“堅牢性”ってのは売りになるわな

**デフォルトの名無しさん** · 2023/05/02(火) 12:21:25.01

とは言ってもパラダイムが違うものを組み合わせるのは
それはそれで色々としんどいから
新規プロジェクトからということにはなるわな。
あるいはモジュール単位で徐々に……といったところか。

**デフォルトの名無しさん** · 2023/05/02(火) 13:10:44.65

純粋に質問なのですが、Windowsだとユーザ権限プログラムから感知できない全画面確認画面(コード署名表示付き)を
手動クリックすることによって権限昇格するAPIやファイル実行オプションを用いるのですが、
Linuxのsudo、suはそういうOS提供APIの単純ラッパ以外の処理が必要なのですか？

**デフォルトの名無しさん** · 2023/05/02(火) 14:14:52.25

>>345さんの祖末なチソチソもっとよーく見たぃナ☆
>>345さん、またみんなの前でチソチソ出してくださいね☆

**デフォルトの名無しさん** · 2023/05/02(火) 15:20:08.53

Qiitaで調べものをしていたらRustを広めたいというユーザーを
見かけたのですが実のあるRustの記事がありません

ここにいらっしゃるのですか？

**デフォルトの名無しさん** · 2023/05/02(火) 16:34:54.41

Rustはアマチュアがいじいじするだけの言語だから

**デフォルトの名無しさん** · 2023/05/02(火) 17:29:28.03

Rustや情報科学みたいなものは、完全に自分の教養のためと思って勉強してるけど・・・・・
いつまで経っても実用の域に届かない

**デフォルトの名無しさん** · 2023/05/02(火) 17:34:42.24

R&D関係者と交流があるだけの人ってアマチュア？

**デフォルトの名無しさん** · 2023/05/02(火) 17:49:30.32

アマチュアがあーでもないこーでもないと
持て余したヒマでいじくり回した結果
しょうもないポエムを生み出すだけ

この言語そのものというより
この言語を取り巻く状況はずっとこう

**デフォルトの名無しさん** · 2023/05/02(火) 19:13:07.37

Linux 6.3.1のtokeiしました

https://i.imgur.com/1xgblDP.png

**デフォルトの名無しさん** · 2023/05/02(火) 19:48:58.54

YouTube で有名な雑食系エンジニア・KENTA が、
初心者に推奨するキャリアパスは、Ruby on Rails → Go のみ

Rust, Elixir は普及のキャズムを超えなかった。
オワコン認定した言語は、Scala, PHP

米国年収でも、Rails, AWS Solution Architect が13万ドル

Ruby, Elixir : 9.3 万ドル
Go : 8.9
Rust : 8.7

多くの言語 : 6.5～7

PHP : 5
Dart : 4.4

日本では、バックエンドの求人倍率が数倍で、
フロントが0.5倍と、10倍の開きがある。
フロントは供給過剰で、低価格競争になっている

欲しい人材は、Rails, Linux, Docker, AWS が出来る香具師。
つまり、ウェブサービスを作れる香具師

Railsは、作者のDHH が言うように、バックエンド技術者がフロントも兼ねるから、
バック/フロントの打ち合わせコストが掛からないのが強み

その代わり、あまりCSS を知らないので、デザイン性に欠ける。
Bootstrap, Tailwind などが多い

つまり、これが文系の低学歴でも、簡単に高収入を得られる方法。チート職業。
だから皆、月千円のKENTAの初心者向けRailsサロンへ入る。稼げるから

**デフォルトの名無しさん** · 2023/05/02(火) 20:03:17.56

>>341,345
sudu-rsとsudo(original)のtokeiしました
LOCが違い過ぎて機能的に同等とは思えませんが誰か確認してください
https://i.imgur.com/wqUfNLQ.png