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

**デフォルトの名無しさん** · 2022/08/29(月) 11:22:16.48

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2022/08/29(月) 13:57:56.66

>>1 乙

>>980 次スレ立ててね

**デフォルトの名無しさん** · 2022/08/29(月) 17:39:40.63

文字列の変数sが与えられた時に
変数a (符号付き32bit整数)、
変数b (符号なし64bit整数)、
変数c (64bit浮動小数点数)へそれぞれ変換するコード

【Rust】
let s: &str = "12345";
let a: i32 = s.parse()?;
let b: u64 = s.parse()?;
let c: f64 = s.parse()?;

【Kotlin】
val s: String = "12345"
val a: Int = s.toInt()
val b: ULong = s.toULong()
val c: Double = s.toDouble()

【Swift】
let s: String = "12345"
let a: Int32 = Int32(s)!
let b: Uint64 = Uint64(s)!
let c: Double = Double(s)!

【Go】
var s string = "12345"
var err error
var a int32
a, err = strconv.ParseInt(s, 10, 32)
var b uint64
b, err = strconv.ParseUint(s, 10, 64)
var c float64
c, err = strconv.ParseFloat(s, 64)

**デフォルトの名無しさん** · 2022/08/29(月) 18:02:10.99

KotlinやSwiftは型推論できるやろ
それにパースとキャストは違うぞ

**デフォルトの名無しさん** · 2022/08/29(月) 18:41:59.28

全然書き込みが無いけど

ypeScript Swift Go Kotlin Rust Nimって、需要も人気も無いの？

**デフォルトの名無しさん** · 2022/08/29(月) 18:50:03.71

>>4
今どきのプログラミング言語はいずれも型推論が賢いね
昔は型推論が無いか弱くて
変数の型宣言が不要というだけで動的型付け言語のメリットされていた時代もあった

**デフォルトの名無しさん** · 2022/08/29(月) 19:09:28.15

次世代言語と言われる

TypeScript も Swift も Go も Kotlin も Rust も Nim ←これらの言語を全然知らない、

昭和の時代から IT関連業で働き、稼いでいた者には、居場所が無いから別の職種に転業すべきかなぁ

**デフォルトの名無しさん** · 2022/08/29(月) 19:33:16.23

>>7
TS、Go、Kotlinはいたるところで使われてるから、すでに現行言語では？

**デフォルトの名無しさん** · 2022/08/29(月) 19:46:28.38

AWSがプログラミング言語「Rust」を使っている理由
https://japan.zdnet.com/article/35183866/

Amazon Web Services（AWS）は、同社のエンジニアたちがプログラミング言語「Rust」を
使っている大きな理由として、エネルギー効率の高さを挙げる。
AWSは早くからRustを採用し、GoogleやMicrosoftとともにRust Foundationの創設にも携わった。
現在もRustの普及に熱心に取り組んでいる。

AWSのソフトウェアエンジニアで、Rustの普及に取り組む、
Shane Miller氏と主任エンジニアのCarl Lerche氏の投稿によれば、
Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく、
PythonやJavaよりもはるかに「エネルギー効率に優れている」という。
Amazonは、2025年までにデータセンターの100％を再生エネルギーでまかなうという目標を掲げ、
データセンターの環境負荷の軽減に取り組んでいる。
Rustの採用はその一翼を担うという。

Rustで構築されたAWSサービスの例としては、
コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
「Amazon Simple Storage Service（S3）」「Amazon Elastic Compute Cloud（EC2）」、
コンテンツ配信ネットワーク「Amazon CloudFront」、
LinuxベースのコンテナーOS「Bottlerocket」がある。

「CやRustが他の言語よりもエネルギー効率に優れていることに驚きはない。
衝撃的なのは、その違いの大きさだ。CとRustを広範に採用すれば、
控えめに見積もってもコンピュートに使用されるエネルギーの量を50％削減できる可能性がある」と
Miller氏は述べ、その根拠として、C、GoogleのGo、Lua、Python、Ruby、Fortranなどをはじめとする
複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。

**デフォルトの名無しさん** · 2022/08/29(月) 20:29:24.84

>>8

そういった系統の言語は、
業務で使用した事が無いから知りませんね。

**デフォルトの名無しさん** · 2022/08/29(月) 20:37:11.19

>>9

Lambdaといえば、Common Lisp だな。

LISP - Lambda Functions

**デフォルトの名無しさん** · 2022/08/30(火) 08:16:39.53

>>9
AWSていつのまに会社になったの？

**デフォルトの名無しさん** · 2022/08/30(火) 09:39:41.83

文末がセミコロンで終わらない言語は流行らない

**デフォルトの名無しさん** · 2022/08/30(火) 09:45:30.28

>>13
それなー

**デフォルトの名無しさん** · 2022/08/30(火) 09:52:15.23

Pythonはセミコロン非推奨だが。

**デフォルトの名無しさん** · 2022/08/30(火) 12:29:02.78

matzは構文に人間が寄り添うのではなく構文解析を言語が頑張るべき的なことを言ってたけど、現実は構文は厳格にしてformatterやlnterが曖昧さのないコードに導いてやるのが正解になってきたね。

人間なんてどこまでも適当な事をやらかせるんだから、それを実行時にうまく解釈してやるのは無理筋。

**デフォルトの名無しさん** · 2022/08/30(火) 12:39:56.18

>>16
構文の厳格さもformatterもlinterも関係ないじゃんw
頭悪過ぎる

**デフォルトの名無しさん** · 2022/08/31(水) 00:25:17.21

Pythonは当初の頓珍漢な理想を捨ててpython2を見捨てなかったのがえらいんだよ

**デフォルトの名無しさん** · 2022/08/31(水) 16:57:16.44

Rustを自分には向いてないと言った（恐らく本人は批判したつもりはない）一生懸命にmatzを叩くRust新興カルトが気持ちわる杉る....
CやC++でバリバリ書いてる人に所有権チェックなんて邪魔すぎるし、配列境界チェックだって速度が出ない足を引っ張る機能にしか見えないだろ
今は固定範囲の配列アクセスのチェックなんかは省略してるかもしれんが、恐らくそんな事はない（全てに係るから安全だと大口する）

**デフォルトの名無しさん** · 2022/08/31(水) 18:05:12.54

matzは静的型付け言語は
変数に型定義を書きまくるのが面倒くさい
というようなとこを言ってて
型推論とか知ってるくせにそれは
無いんじゃねと思ったな

**デフォルトの名無しさん** · 2022/08/31(水) 18:25:03.72

CやC++で困ってない人に無理にrustを勧めてくる人は相手しなくて良いよ

**デフォルトの名無しさん** · 2022/08/31(水) 18:30:28.99

matzのおかげでプログラミング文化が進化したのはのは間違いない
RustもRuby文化のいい面をかなり受け継いでいる

**デフォルトの名無しさん** · 2022/08/31(水) 18:32:18.02

>>19
所有権チェックって何？
そんな用語も概念も存在しない

配列境界チェックは
例えばインデックス値をforでループに回したとしても
最適化によりforでのチェックだけになり
インデックスを使った配列やスライスへのアクセス時に再びチェックすることはない
つまりC言語と同じになる

>>21
困ってる困っていないの問題ではない
回避策が確立されたのに欠陥言語を使い続けるか否かの問題
人間は必ずミスを起こしうる、との結論が出ていて
大手IT企業も挙ってRustを採用している

**デフォルトの名無しさん** · 2022/08/31(水) 18:35:01.88

>>23
Rustこそが銀の弾丸って主張かな？

**デフォルトの名無しさん** · 2022/08/31(水) 18:36:59.70

みんな所有権所有権言うけど、初学者がひっかかりがちなのって借用の方では
所有権というとRAIIの方を連想してしまうけど
C++でmove使いこなしてた人ならRustの所有権ではひっかからないだろうし、他の言語でもtry-with-resourcesとか類似の概念あるよね

**デフォルトの名無しさん** · 2022/08/31(水) 18:55:37.66

うちの会社にもPHPで困ってないからと言いながらゴミを作り続けるおっさんいるわ

**デフォルトの名無しさん** · 2022/08/31(水) 19:25:46.59

>>26
そういうおっさんが業務の阻害要因になってるならなんとかした方が良いけど
掲示板上でどういう問題抱えてるかすら分からない相手に闇雲に勧めるのとは全然違うよね

**デフォルトの名無しさん** · 2022/08/31(水) 19:48:33.02

>>26
PHPは>>9の記事の観点からはエネルギー効率の悪い劣った言語かもしれないが
C/C++が現実に大量のセキュリティの穴も含むメモリ管理バグを引き起こし続けている危険な欠陥言語である点とは大きな開きがある

**デフォルトの名無しさん** · 2022/08/31(水) 19:56:05.14

>>27
おっさん自身は問題を理解できてないってことを言ってるんだよ

**デフォルトの名無しさん** · 2022/08/31(水) 19:56:39.74

どんなに優れたプログラマーでもミスをするしバグも作るって考え方は大事だと思うけどな

**デフォルトの名無しさん** · 2022/08/31(水) 19:58:59.48

#define new old
で、全て解決では？

**デフォルトの名無しさん** · 2022/08/31(水) 20:04:50.79

でもウェブサイトの9割はPHPで出来てると言うからなあ。

**デフォルトの名無しさん** · 2022/08/31(水) 20:33:48.91

PHPを馬鹿にするやつにその資格はない
PHPの作者を馬鹿にするやつにその資格はない
PHPよりも作者よりも糞なやつが鏡すら見ずに薄ら笑ってる

**デフォルトの名無しさん** · 2022/08/31(水) 20:38:28.28

>>26
ゴミって言ってもそれでお金稼いでいる訳じゃなくて？

**デフォルトの名無しさん** · 2022/08/31(水) 20:55:36.71

>>24
んなこと言ってねーだろ。
ミスリードすんな。

**デフォルトの名無しさん** · 2022/08/31(水) 21:00:04.57

Haskellが見向きもされなくなったら、Rustの宣伝が増えたな。

**デフォルトの名無しさん** · 2022/08/31(水) 21:11:47.88

>>36
宣伝？
例えば>>9の記事はクラウドのシェアトップであるAWSがそのサービス提供にRustを使って構築しているという現実の話
着実に様々なインフラがRustベースへと置き換わっていく現実の一つ

**デフォルトの名無しさん** · 2022/08/31(水) 21:22:47.94

Rust(笑)　時代はJavaだから

求人倍率はなんと21.8倍　「Java」を求める企業が絶えない理由とは
https://atmarkit.itmedia.co.jp/ait/articles/2208/31/news049.html

**デフォルトの名無しさん** · 2022/08/31(水) 21:28:47.20

限られた情報から善と悪を判断できない人達が
まだ公開されていないクソどうでもいいデータを欲しがる

**デフォルトの名無しさん** · 2022/08/31(水) 22:11:23.35

オラクルに丸め込まれた会社本当にかわいそう

**デフォルトの名無しさん** · 2022/08/31(水) 22:21:51.07

今日Helidonなるものを初めて知ったわ
オラクル足掻いてるよねー

**デフォルトの名無しさん** · 2022/08/31(水) 23:06:38.28

rustは死産だったんだよ
このスレで頑張ってるのは水子供養みたいなもん

**デフォルトの名無しさん** · 2022/08/31(水) 23:15:56.00

Facebook、開発言語に「Rust」採用　Javaからも移行
https://www.itmedia.co.jp/news/articles/2107/28/news152.html

Rustを用いることで、どのような利点があるのか。
Facebookは記事の中で次の4つの項目を挙げています。

①Rustのasync/awaitシンタックスは、非同期のコードをとてもスムーズに記述できますし、
Rustは複雑な並行処理の詳細を正しく理解するのに役立ちます。
BuckのJavaの計算を一つ一つ並行処理に移行するのは数カ月に及ぶ困難な作業でしたし、
シングルスレッドの大きなボトルネックがまだ存在しています。

②Rustには、開発をより簡単で楽しいものにしてくれる多くの高レベルな言語機能があります。
それらはenum、パターンマッチング、trait、手続き型マクロなどで、
Rustの開発者の多くに愛されています。

③Rust はメモリの割り当てをより細かく制御することができます。
ガベージコレクションのある言語では、たとえジェネレーショナルコレクションであっても、
Buckが行うようなインクリメンタルな演算に対応するのは困難です。

④Rustは高性能です。
Rustに移植することで劇的な性能向上を私たちは見てきました。

**デフォルトの名無しさん** · 2022/08/31(水) 23:21:00.54

>>35
いやいやC++で書かれたプログラムは無条件にRustで置き換えられるって主張は銀の弾丸って言ってるのと同じでしょ

**デフォルトの名無しさん** · 2022/09/01(木) 00:44:24.52

善行を勧めることと、善行が必勝法であると主張することを区別する必要がある

**デフォルトの名無しさん** · 2022/09/01(木) 07:30:51.13

>>23
「最適化によりforでのチェックだけになり・・・つまりC言語と同じになる」
はい、明確すぎる嘘、Cは普通処理系によりけりだが通常は配列境界のチェックなんてしません。あほかｗなにが、つまりだｗ
必死すぎるのがほんと痛々しい

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

所有権を邪魔だと思ってる奴のC++コードは読みたくねえな
一緒に仕事したくねえ……

**デフォルトの名無しさん** · 2022/09/01(木) 07:51:48.00

>>46
インデックス値でforループを回すとあるから
C言語でもループ1回に付き必ず1回のインデックス値の境界比較が必ず入るよ
境界チェック無しでforを回したら無限ループになる

**デフォルトの名無しさん** · 2022/09/01(木) 07:57:15.00

>>48
Cって、配列のインデックスアクセスに境界チェックとか無くて、プログラマに委ねられているのかと思ってた。Cも意外に安全性を気にしているんだね。

**デフォルトの名無しさん** · 2022/09/01(木) 08:33:34.02

>>38
javaのフレームワークって何使ってるの？

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

>>44
その通り
条件を絞って
予めRustに移植することを意識して描かれたC++のソースのみ自動変換出来る
なら正しいかも知れない

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

>>44 追加
ちなみに漏れは
「Rustに移植することを意識して描かれたC++のソース」
ならC++のままでええやん？的な立場

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

>>48 はCを知らない素人以下

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

>>49
たぶん間違って読解してる。
良くも悪くも日本語って主語省略しちゃうからね。

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

>>53
え？
>>48で合ってるだろ
インデックスforループは境界比較しないと止まらん

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

>>55
配列のインデックスチェックってここではモダンな言語は配列外にアクセスすると実行時エラーになるということを言ってるんだよ
Cはエラーじゃなく未定義だから何が起こるかわからん

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

実行時じゃないわ
コンパイルエラーね

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

いや動的配列ならやっぱ実行時か
どっちにしてもCみたいに変更しちゃいけないところを変更して暴走しないってこと

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

>>56
元の話は>>23だからインデックス値のforループ
C言語でも他でもfor文で境界チェックが必ず入る

配列アクセス時はまた別の問題
Cならばチェックしないがfor文でチェック済なので安全上の問題なし
Rustならばチェックするがfor文でチェック済なので最適化によりここでのチェックは消えて問題なし

結果としてCでもRustでも同じ生成コードとなる

**デフォルトの名無しさん** · 2022/09/01(木) 10:23:52.21

>>59
動的配列のランダムアクセス時にC言語では入らない境界チェックが入るな

**デフォルトの名無しさん** · 2022/09/01(木) 10:30:39.30

>>59
日本語で説明するよりコードと生成されるアセンブリ見せた方がわかりやすいのでは

**デフォルトの名無しさん** · 2022/09/01(木) 10:31:44.69

forループの例では同じ生成コードとなるが
範囲内かどうか不明なインデックス値がやってきてそれで配列をアクセスする場合は違いが出る

C/C++
プログラマーの自己責任で境界チェックを手動でしなければならない
忘れたときは未定義動作となりうるため危険

Rust含むその他の言語
プログラマーは気にせずとも自動的に境界チェックされるため安全