次世代言語26 TypeScript Swift Go Kotlin Nim

**デフォルトの名無しさん** · 2022/06/21(火) 09:27:46.30

スレタイ（順番はRedMonk準拠）以外の言語もok

※　Rustは現世代最強言語なので除外します

前スレ

次世代言語25 TypeScript Swift Go Kotlin Rust Nim
https://mevius.5ch.net/test/read.cgi/tech/1650185555/

**デフォルトの名無しさん** · 2022/06/21(火) 09:44:18.82

文字列の変数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/06/21(火) 12:56:04.76

オーバーロードが無いと、

例えばライブラリ無いからシステムコール利用する便利ラッパー機能を提供しようとする。例えばソケット関係のAPIをまとめたやつとか。
で socket(2)の場合、
第3引数なんていつも0しか使わないからと第2引数までを取るAPIとして公開、後になって第3引数必要になった(例えばSCTP利用)ってなった場合、オーバーロードできないとAPI変える必要あるじゃん。

**デフォルトの名無しさん** · 2022/06/21(火) 13:12:00.12

>>3
プログラムを書いたことのないキチガイだな
socketの第3引数はgetaddrinfoで得たai_protocolを引き渡すのが常識
あるいはgetaddrinfoを使わないならばgetprotobynameの結果を引き渡すものだ
まともなコードを書けないからそんな意味不明な主張になる

**デフォルトの名無しさん** · 2022/06/21(火) 13:15:46.21

必要なら変えればいいじゃん

**デフォルトの名無しさん** · 2022/06/21(火) 14:09:10.86

なんでオーバーロードが無いCでうまくやっている例を挙げてオーバーロードの必要性を主張しようと思ったんだろう

**デフォルトの名無しさん** · 2022/06/21(火) 17:22:04.63

　　　　　　　　　　　　　　　　　　　　 /　　,.----―‐､ヽ. ＼
　　　　　　　／　　　　　　　　　　　 /　　ヽ　　　　　ヽヽ､_ヽ
　　　　　／　　　　　　　　　_,.-‐''"　　　　ヽ　　　　　　ヽ　 `ヽ
　　　　／　　　　　　　 _,,.-‐'"　　　　　　　ヽ　　　　　　ヽ　　ヽ
　　　 /　　　　　　_,.-'"　　　　　　　　　　　　ヽ　　　　　　ヽ　　ヽ
　　 /　　　　_,.-‐'"　　　　　　　　　　　　　　　i!　　　　　　i! ..＿　i
　人＿,.-‐"　　　　　　　　　_,,... _;;.::='' ＼　　 i!　　　　　 i!/　　 >'
　/　　　　　　　　　　 _,,..-''_,.-‐''"　　　　　入 /＿＿＿__/　 ,.イ'
　|　,.-ヽ、　　　 _,.-'"_,.-　‐┬:.:ｧ‐──┬: :ｧ= ┬─―-|ヾ　 r i!
　|/　　　ヽ..　,.-'"　 r　 |/　,L:厶＼_, 　 |: /　_／二│ / |　　.|　|
　i　　　　　ヽ |　　　|;　　〃￣｀ヾ　　 |/　　〃￣｀∨　i　　 |　|ヽ
　i!　　　　　ヽ |　　 .|　　 {{　　　 }}　　　　 {{ 　　 }}　 {　　|　| |　　　　　また新スレだ！いつもいつも！
　|　　　　　　i　|　　 |　　ゞ' ==彡　　　　ゞ ==彡　 l　　|　| | 　　　　　　1000にも届かないで！！わたしを弄んで！！
　ヽ　　　　　 |　| 　　|!　　ヽヽ　　　　　　　　　　　　ヽヽ l　　|　| i!
　ヽ、　　　　|　 |　　 |　　　　　/⌒¨¨¨¨¨¨¨¨¨⌒ヽ　　 /　　|　i/
　　ヽ、　　 /　ヽ　　ヽ、　　｛　　　　　　　　　丿　 /　／,! ,i!
　　　ヾ`ヽｰ'　　　`ヽ､　　`ヽ､　　　　　　ｪ-―‐-く　　/ ./　/
　　　　｀`―､_　　　　 ` ‐､_　 ` ー--／　　＿_　`ヽ/ ./ /
　　　　　　　　｀ﾞﾞ‐-､　　　　ﾞ`ｰ､.._／　　i'"　　`ヽ　　/,/

**デフォルトの名無しさん** · 2022/06/21(火) 18:27:05.65

>>4
あくまでも例なのに的外れな回答だな。
fcntlでもいいわ。あれは第2引数によって第3引数の型が変わる。

>>6
うまくいってねーから。
だから閉じる時はcloseなのに開く時はopenじゃなくてsocketって別の名前になってんじゃん。
思考力無さすぎ。

**デフォルトの名無しさん** · 2022/06/21(火) 18:45:23.25

例がアカンわそれ
オーバーロードがある言語でもオーバーロードすべき時とメソッドを分けるべき時が当然ある
fcntlなんかはオーバーロードを考えるより先に分割を検討すべきものだから議論がとっちらかる

**デフォルトの名無しさん** · 2022/06/21(火) 18:55:56.41

>>9
＞例がアカンわそれ
＞オーバーロードがある言語でもオーバーロードすべき時とメソッドを分けるべき時が当然ある

当たり前だろ

**デフォルトの名無しさん** · 2022/06/21(火) 18:56:25.10

>>8
いまさらで申し訳ないんですが
s/ライブラリ無いから/ライブラリ内から/
ですか？

**デフォルトの名無しさん** · 2022/06/21(火) 19:00:59.44

求めてるのはオーバーロードじゃなくてデフォルト引数だね

**デフォルトの名無しさん** · 2022/06/21(火) 19:02:06.03

オーバーロードできるからと、いつもオーバーロードするわけではない。
だがオーバーロードが適切な場合はオーバーロードできたほうが良い。
単にそれだけ。
原理主義者になるな。

**デフォルトの名無しさん** · 2022/06/21(火) 19:15:17.39

>>11
ライブラリ無いから薄いラッパーを作って提供するんだと思った。
知らんけど。

**デフォルトの名無しさん** · 2022/06/21(火) 19:19:23.26

オーバーロードは関数を値として持とうとしたときに関数の実体を取得するのがくそほど面倒臭かった記憶

**デフォルトの名無しさん** · 2022/06/21(火) 19:34:47.92

オーバーロードの追加はAPIの変更に含まれますか？

**デフォルトの名無しさん** · 2022/06/21(火) 19:36:24.38

ジェネリクス以外でわざわざ同じ関数名使う必然性がないわな。

**デフォルトの名無しさん** · 2022/06/21(火) 19:39:33.13

Objective-Cの関数名って長かったよなあ（遠い目）

**デフォルトの名無しさん** · 2022/06/21(火) 19:45:56.46

オーバーロードの有無で使用する言語を選ぶ人っているのか？
いないなら些末な議論

**デフォルトの名無しさん** · 2022/06/21(火) 20:30:16.16

>>8
よく考えてから反論の例を挙げよう
fcntlこそオーバーロードに不向きだろ
まずfcntlの引数は代数的データ型になっていることを理解できるか？

つまりRustならばそれはenumなので例えばこんな風に解決される
enum FcntlArgs {
F_GETFL,
F_SETFL(O_Flag),
F_DUPFD(FileDescriptor),
F_SETLK(Flock),
...
}
これでlibcインタフェースよりもシンプルかつ分かりやすく間違いなく表現できる

関数の引数はもちろんfdとこのFcntlArgsの2つに固定される
fn fnctl(fd: FileDescriptor, args: FcntlArgs) -> Result<FcntlReturn, Error>
と戻り値も様々なものが返るからenum FcntlReturnを用意すればミス防止になるだろう
エラーもそのenumに混ぜる手もあるがここでは分けて汎用的にResultとしている

その場合の使い方はこんな感じのコードになるだろう
if let O_Flag(o) = fcntl(fd, F_GETFL)? {
o |= O_NONBLOCK;
fcntl(fd, F_SETFL(o))?;
}

**デフォルトの名無しさん** · 2022/06/21(火) 21:43:34.03

>>15
関数を値として持つ場合は関数シグニチャ的なものを型として使うので
その時点でどのオーバーロード用か明確になってるよ

**デフォルトの名無しさん** · 2022/06/21(火) 21:57:39.81

>>19
>オーバーロードの有無で使用する言語を選ぶ人っているのか？
ドカタは低脳、ゆとり、基地外でも大歓迎な職業なもんだから、
へんな奴が多い。そして、5chのム板に来る奴にはそれの重度な奴が多い。
そんな奴(重度の基地系)だと些細なことでも異常ににこだわる(超粘着する)のが普通なんだよ。
で、俺的にはオーバーロード必死な人が使っている言語(メイン言語)が何なのか興味あるが

**デフォルトの名無しさん** · 2022/06/21(火) 22:00:18.48

>>20
wrapper APIとして公開するならそれぞれ別のメソッドにすべきでしょ
メソッドという概念がなかった頃の遺物をそのまま使う必要ない

**デフォルトの名無しさん** · 2022/06/21(火) 22:24:10.62

>>13
オーバーロードの使い道は型違いのサポートとオプション引数のサポートの2つ
前者はジェネリック後者はオプション引数が言語機能にあればオーバーロードがなくても困らない

**デフォルトの名無しさん** · 2022/06/21(火) 22:33:00.05

>>23
別のメソッドにしなくても
もし使用ミスがあればコンパイル時エラーとなるため>>20の仕様でも全く問題ない

そしてこの手法はRustでは常套
例えばHTTPのメソッドはGETやPOSTやDELETEなど39種類が定められているが
Rustでは39種類のメソッド関数を用意せず今回の例のようにenumに39種類を並べて用いている
今回のfcntlでも大量のメソッド関数を作るのは好ましくないと考える

さらに今回は>>8がオーバーロードがない場合は関数を分けてfcntl_getfl()やfcntl_setfl()などと大量に作らざるを得なくなる例として持ち出してきた流れ
だからオーバーロードなんか無くてもfcntl()一つで済むことを示した
そしてこれは汎用的な手法である

**デフォルトの名無しさん** · 2022/06/21(火) 22:52:38.19

相手にしたら負け
学習しましょう

**デフォルトの名無しさん** · 2022/06/21(火) 23:20:14.77

オーバーロードが無いと嫌だ嫌だな人はオーバーロードを変態にした
C++の可変引数テンプレート(可変長ジェネリクス引数)のようなものが実は欲しいってことなんじゃないのか

**デフォルトの名無しさん** · 2022/06/21(火) 23:42:15.69

新しく作る前提ならfcntlみたいに責務の異なる複数の処理は
1つの関数ではなく1つのクラスやモジュールにまとめたほうがいいのは間違いない

ただ既存APIのラッパーなら使いやすい形にAPIを変更した方がいいケースもあれば
既存と同じ感覚で使える形に留めたほうがいいケースもあるから
分割がいいかどうかはケースバイケース

**デフォルトの名無しさん** · 2022/06/22(水) 00:47:54.76

結局>>2の例も>>20の例も
元は「オーバーロードのないRustは一つの関数名にできずに多数の関数名を必要とする！」攻撃から始まったのに
結果はRustの方が一つの関数で対応できちゃっていて不思議

**デフォルトの名無しさん** · 2022/06/22(水) 01:52:24.75

ここまですべてスレタイにない言語の話題

**デフォルトの名無しさん** · 2022/06/22(水) 03:03:24.75

>>27
なるほどこういうことか

template <class ... Ts, class U> U do_anything(Ts ...);

**デフォルトの名無しさん** · 2022/06/22(水) 07:15:40.26

>>29
Rustはtraitを用いたジェネリクスやenumなど便利で強力な機構を備えているため
具体的な現実の問題のほとんどはオーバーロードを使わずともそれらを用いてもっと良い解決を取ることが出来てしまう

**デフォルトの名無しさん** · 2022/06/22(水) 08:41:50.14

幼稚園児の発想だね

**デフォルトの名無しさん** · 2022/06/22(水) 08:59:15.48

nim ってどうよ？

**デフォルトの名無しさん** · 2022/06/22(水) 10:00:29.78

>>34
かなりいいよ

**デフォルトの名無しさん** · 2022/06/22(水) 10:53:23.20

flutter で dart だろ。Swift UIとか覚える気ない、というかApple終わってるし

**デフォルトの名無しさん** · 2022/06/22(水) 11:56:08.73

nimダウンロードできない。
なぜか、消える。ノートンが削除してるの？

**デフォルトの名無しさん** · 2022/06/22(水) 12:27:18.00

>>37
この文面からして明らかにプログラミング向いてなさそう

**デフォルトの名無しさん** · 2022/06/22(水) 17:58:01.91

GUIフレームワークがついてる言語が少ないので嫌だな

**デフォルトの名無しさん** · 2022/06/22(水) 23:42:43.21

ノートンなどアンチウイルスソフトが必ず隔離や削除する、インストールの際はインストール先を例外にする必要があります
全部誤判定なんだがアンチウイルスソフトの会社は殿様商売だな

**デフォルトの名無しさん** · 2022/06/24(金) 13:42:32.48

>>40
ここまで日本語不自由だと生きるのつらそう

**デフォルトの名無しさん** · 2022/06/24(金) 19:59:44.23

【IT】世界中のIT技術者から愛されているプログラミング言語　3位は「Clojure」、2位は「Elixir」　1位は？ [田杉山脈★]
https://egg.5ch.net/test/read.cgi/bizplus/1656048302/

スレタイはこの上位といれかえたら？

**デフォルトの名無しさん** · 2022/06/24(金) 20:12:58.51

ClojureもElixirもいいけど次世代かって聞かれるとう～ん
なんだろうね次世代って

**デフォルトの名無しさん** · 2022/06/25(土) 09:52:11.80

>>42
毎年恒例の1位となってるな

＞世界中のIT技術者から愛されているプログラミング言語はなにか。
＞プログラミング関連のQ&Aサイト「Stack Overflow」を運営する米Stack Exchangeが
＞そのような調査結果を発表した。
＞各言語の「Loved」（愛している）と「Dreaded」（恐れている）の比率で
＞Lovedが最も高かったのは「Rust」（86.73％）で7年連続で1位になった。
＞回答数は7万1467件。

**デフォルトの名無しさん** · 2022/06/25(土) 12:36:15.24

>>44
なんかもうネタみたいになってるけどこれってアメリカンジョークなのか？

Rustは自分では使いたくないかな
仕事でコーディングしてる人が使ってくれたらいい

**デフォルトの名無しさん** · 2022/06/25(土) 15:33:06.41

食わず嫌いだったけど
使うようになってRustが最もコーティングしやすいプログラミング言語だとわかった

**デフォルトの名無しさん** · 2022/06/25(土) 17:07:59.40

どのへんがとは全く言わない、糞言語Rustアゲおじさん

**デフォルトの名無しさん** · 2022/06/25(土) 17:31:49.13

どういうレベルの人か察してやれ

**デフォルトの名無しさん** · 2022/06/25(土) 20:40:59.84

次世代って響きは良いけど従来の言語の穴を塞いだ発展型の方が好まれそうと感じる
でもその結果C++とかObjective-Cが生まれたと思うとその考えも合ってるんだか自信がない

**デフォルトの名無しさん** · 2022/06/27(月) 14:02:27.16

その意味合いでいうなら
v言語が宣伝してる内容を全部まともに実装できたら次世代と言っていいんじゃないすかね

**デフォルトの名無しさん** · 2022/06/27(月) 14:24:04.88

もっといい言語ないかな～

**デフォルトの名無しさん** · 2022/06/27(月) 14:25:31.64

過去にない新たなパラダイムを開く言語こそ次世代言語
それが何かは知らんが

**デフォルトの名無しさん** · 2022/06/27(月) 16:35:25.69

YouTube で有名な雑食系エンジニア・KENTA が、既に結論を言ってる。
文系のキャリアパスは、Ruby on Rails → Go のみ

Rust, Elixir は普及のキャズムを越えなかった。
越えたのはGo だけ

いつも思うけど、Stack Overflow にいる香具師は、プロじゃないと思う。
転職に適さない

53 · 2022/06/27(月) 16:50:49.51

AWS Lambda のデフォルト言語は、
Node.js, Python, Ruby,
Java, Go,
PowerShell, C#

Rust, Elixir, PHP は入っていない。
カスタムコンテナを作るしかない

でも、Elixirは5千万プロセスが、130GB ぐらいのメモリ使用量らしいから、
32GBでも、1千万プロセスぐらい動くかも

IoT で、Nerves には期待している。
Ruby on Rails の本を書いている、黒田努の本も出たし

**デフォルトの名無しさん** · 2022/06/27(月) 17:13:12.52

GoはLambdaの新しいAL2環境においては単なるカスタムランタイム扱いに格下げされており、Rustとの違いは無くなっている
キチガイに触るつもりはないが他の人への情報提供として

**デフォルトの名無しさん** · 2022/06/27(月) 17:20:17.54

Erlang系の話題も少ないけどGleamとかどうよ
程々にホットだけどフレームワークはまだできてない、現状はそんな感じ
BEAMで動いて型が付いてて開発が動いてるってだけで機能として珍しい所はあんまり無いんだけどさ
そんな関数型関数型しい仕様でもないしギークが喜ぶリッチな型があるわけでもない
あとはjsがこないだ吐けるようになった

**デフォルトの名無しさん** · 2022/06/27(月) 17:41:40.73

未だにKENTAのゴミ動画を当てにしてるやつが湧くのか

**デフォルトの名無しさん** · 2022/06/27(月) 20:09:14.72

本人でしょｗ

**デフォルトの名無しさん** · 2022/06/27(月) 21:32:09.95

>>55
rustとの違いがないってことはRAIIパターン使えるようになるの？

**デフォルトの名無しさん** · 2022/06/27(月) 22:04:16.27

>>59
全然関係ない
AWS Lambdaでの実行環境の話

**デフォルトの名無しさん** · 2022/06/28(火) 14:36:14.98

Rust is coming to Linux, says Torvalds
https://cloud7.news/linux/rust-is-coming-to-linux-says-torvalds/

Torvalds also announced some changes he plans to implement into Linux soon.
Most significantly, the open-source programming language, Rust might be included in the next release. Torvalds stated that Rust will be introduced in a limited way.

**デフォルトの名無しさん** · 2022/06/28(火) 15:53:32.16

>>61
きたーーーーーーーーーーー

53 · 2022/06/29(水) 18:00:11.30

KENTA の天敵・モローも、遂にRuby on Rails のキャリア相談までやり出したw

2020年には、Railsはオワコンと言っていたが、
Railsの仕事が増えたため、急きょRailsに鞍替えw
主張が、KENTAと全く同じになったw

【2022年版】Ruby on Railsの将来性
www.youtube.com/watch?v=YWKxh3KoNsY

スタートアップ企業の第一選択肢で、リモートワークも多い。
給料450～500万円、業務委託は月50～60万円

データベース設計、React, TypeScript も勉強すると良い

キャリアパスは、
Rails → Go, SRE、エンジニアリング・マネージャー

53 · 2022/06/29(水) 18:08:23.13

今までのモローの主張は、

KENTA がRuby on Rails サロンをやる目的は、
ポートフォリオを作るための学習期間が長いので、
サロンに長期間入ってもらって、KENTAがもうかるので、Railsを勧めている

Railsはオワコンなので、サロンに入っても、仕事は減っていく一方と言ってたのに、
今じゃ、KENTAと全く同じ事を言ってるw

**デフォルトの名無しさん** · 2022/06/29(水) 18:15:54.85

Linux開発にRustで掛かれたコードが解禁された

しかし
Cで書かれたものを置き換えることはしない
APIを変えることはしない

**デフォルトの名無しさん** · 2022/06/29(水) 22:16:42.10

相変わらず三流ユーチューバーを引き合いに出すやついるのな

**デフォルトの名無しさん** · 2022/07/01(金) 21:34:11.78

>>65
どこでも同じシンプルな結論が出てるな
・既存のものを書き換えるのは無意味
・新たに作るものはRust一択

**デフォルトの名無しさん** · 2022/07/01(金) 21:52:53.35

あまりにも既存コードが膨大だからね
長らくあらゆる環境で機能してたコードをリプレイスするほどまでのメリットはないだろう

もし仮にそこまでメリットあるんだったら、即刻世界中からC/C++のコードを絶滅させてほしいわ

**デフォルトの名無しさん** · 2022/07/02(土) 07:56:01.10

誰もリプレイスするべき、なんて言ってないよ

**デフォルトの名無しさん** · 2022/07/02(土) 09:01:16.19

そうやってCOBOLのコードが維持それ続けてるんだよなぁ

**デフォルトの名無しさん** · 2022/07/14(木) 20:22:39.85

COBOLを舐めてはいけない
そもそも基本的に動的アロケーションをしないから、メモリ管理に関してはRustなんかに比べても信頼性が無茶苦茶高い

**デフォルトの名無しさん** · 2022/07/15(金) 08:41:12.46

>>71
でDATA DIVISIONが半分を占める悪夢のようなコードが蔓延するんですね

**デフォルトの名無しさん** · 2022/07/16(土) 02:22:35.47

BunはZigで実装してるのか
なかなか尖ってていいじゃないの
https://zenn.dev/k41531/articles/dbedb88f06898a

**デフォルトの名無しさん** · 2022/07/16(土) 07:08:19.77

rustじゃ駄目だったのかなあ

**デフォルトの名無しさん** · 2022/07/16(土) 07:25:23.59

多様性があった方が良いんじゃないの？

**デフォルトの名無しさん** · 2022/07/16(土) 12:38:54.49

Zigなかなかおもしろいね
エラーハンドリングがSwift風で好感が持てた

**デフォルトの名無しさん** · 2022/07/17(日) 00:52:05.19

Zigやるわ

**デフォルトの名無しさん** · 2022/07/17(日) 01:03:33.43

Rustの終わりの始まり

**デフォルトの名無しさん** · 2022/07/17(日) 01:25:06.31

Rustは安全性と高速性と書きやすさの両立を実現した
ZigはC++と同じで安全性は保証しない
Rustに対しては相対的にZigのメリットは無い
C/C++で書くよりはZigの方がおすすめではある

**デフォルトの名無しさん** · 2022/07/17(日) 02:03:08.49

Zenはどう？

**デフォルトの名無しさん** · 2022/07/17(日) 02:05:03.30

Zig軽く見たけどメモリ管理自前なのがキツいな
ここまでむき出しにするかー

**デフォルトの名無しさん** · 2022/07/17(日) 02:45:01.72

zigはそのままCのコンパイラになってかつクロスコンパイルが簡単ってのが良いね
既存のCプロジェクトのコンパイラをzigに置き換えるだけでもメリットがあるし、そうなると徐々にソースもzigに置き換えたくなってきそう

**デフォルトの名無しさん** · 2022/07/17(日) 03:42:19.20

>>80
だいぶ前にZigのパクリって言われてたな
今はどうなんだろ

**デフォルトの名無しさん** · 2022/07/17(日) 09:19:07.01

>>74
rust実装ならdenoがあるし
nodejs代替ならdenoが本命だし

**デフォルトの名無しさん** · 2022/07/17(日) 11:37:18.91

流行るかどうかは別にしてZigはスレタイに相応しい言語だな

今のスレタイはNimを除いて全て現世代の言語になっちゃったから

**デフォルトの名無しさん** · 2022/07/17(日) 11:47:40.57

TypeScript、Swift、Go、Kotlinはとっくに普通の言語で、
これから新規プロジェクトやるならその辺の言語しか触らなくてもおかしくないね、ってレベルでもう一般的

**デフォルトの名無しさん** · 2022/07/17(日) 11:50:14.03

>>1
typescript swift go kotlin は十分メジャーだから次スレからは外すように

**デフォルトの名無しさん** · 2022/07/17(日) 14:04:28.95

まだ普及してなくて気になっているのはZig, Nim, V, Valeくらいかな

**デフォルトの名無しさん** · 2022/07/17(日) 14:14:11.96

Zig触ってるとRustの所有権ってめちゃくちゃ優れた概念だったんだなと実感できるね

**デフォルトの名無しさん** · 2022/07/17(日) 15:07:20.14

従来のプログラミング言語と違って革命的に新たな概念をもたらした次世代言語はRustだと思うのですが
どうしてスレタイに入れないのですか？

**デフォルトの名無しさん** · 2022/07/17(日) 15:35:25.31

次世代言語ではなくすでに現世代の覇権言語だから

**デフォルトの名無しさん** · 2022/07/17(日) 16:35:29.89

C++0xのパクリだからでは？

**デフォルトの名無しさん** · 2022/07/17(日) 17:26:25.41

安全性の保証を実現したC並みの高速な言語はRustしかない

**デフォルトの名無しさん** · 2022/07/17(日) 17:42:03.18

もし今までC/C++でシステム開発をしてきた会社で
モダンなシステムプログラミング言語が試用されるとしたら
それはRustではなくZigもしくはNimだろう

**デフォルトの名無しさん** · 2022/07/17(日) 18:00:29.39

>>94
それらは本質的にはC/C++と変わらないから採用するところはほとんど無いと思われます
もしその分野で新たな言語を採用するとしたら採用に意味のあるRustとなるでしょう

**デフォルトの名無しさん** · 2022/07/17(日) 18:36:18.24

数名のプロジェクトで、納期も緩ければあるかもね。

**デフォルトの名無しさん** · 2022/07/17(日) 18:51:09.61

>>95
CとC++の欠点は安全性だけだと思ってる？

**デフォルトの名無しさん** · 2022/07/17(日) 18:56:55.96

NimはともかくZigはまだ1.0でもないから会社で使える感じはしないけどな
将来的にCの代替としては期待している

**デフォルトの名無しさん** · 2022/07/17(日) 19:06:00.51

そもそもRustの利点と宣伝されてるものって、C++20のコンセプトを簡易的に実装したものでは？

**デフォルトの名無しさん** · 2022/07/17(日) 19:13:13.63

Rustの話しかしねーなお前ら

**デフォルトの名無しさん** · 2022/07/17(日) 19:48:29.77

**デフォルトの名無しさん** · 2022/07/17(日) 21:24:39.01

Rustでもこんな感じで書いてもいいのよ

use std::io::{self, Write};
fn main() {
let mut stdout = io::stdout().lock();
stdout.write_all(b"hello world").unwrap();
}

**デフォルトの名無しさん** · 2022/07/17(日) 21:44:39.47

>>101
(1) Cのprintfと同じ機能がRustのprint!であり分かりやすく使いやすい
(2) Rustでも色々な指定は可能
(3) プログラミング言語毎に様々な書き方がなされている中では些細な話

**デフォルトの名無しさん** · 2022/07/17(日) 22:16:39.96

>>102
そこは>>101の例に合わせてformat指定

let mut stdout = std::io::stdout().lock();
write!(stdout, "Hello, {}!\n", "world")?;

**デフォルトの名無しさん** · 2022/07/17(日) 22:23:33.10

>>101
これってフォーマット指示と引数があっているかのチェックはいつ行われるの？

**デフォルトの名無しさん** · 2022/07/17(日) 22:26:33.06

Zigだけどやっぱスコープ抜けた時に一斉に不要なメモリ解放する機構ぐらいは欲しいなあ
そういうのないよね？

Obj-Cにおけるautoreleasepoolとかv8におけるHandleScopeみたいなやつ

**デフォルトの名無しさん** · 2022/07/17(日) 22:33:23.76

>>102
ありがとうございます

import java.io.*;
class Ideone {
public static void main (String[] args) {
final PrintStream out = (new java.util.Random()).nextBoolean() ? System.out : System.err;
out.printf("Hello, %s!\n", "world");
}
}
JavaのIOまわりはすこ

**デフォルトの名無しさん** · 2022/07/18(月) 00:06:45.58

>>87
俺的には最初のリリースから10年経っているのはもう次世代とは言えない
って感じなんだよな。

>>96
数名でも初心者に毛が生えた程度のレベルの奴(どかた)でも良いプロジェクトじゃないと駄目だろ
メジャーなC++ですら日本ではスキルのある奴がそろわないんだからな

>>99
逆じゃないのか
Rustの制約をC++でも簡易で良いから欲しいって感じでC++20でようやくコンセプトとして導入じゃないのか
ジェネリクスには制約は必須なのにC++では長い間導入されていなかったからな

**デフォルトの名無しさん** · 2022/07/18(月) 00:50:41.17

Zigの特徴はCよりも未定義動作を増やすことでコンパイラによる最適化を過激にできて場合によってはCよりも高速になることを狙う点
つまり未定義動作を無くすことで安全と高速を両立させるRustとは真逆の戦略を採っていること

**デフォルトの名無しさん** · 2022/07/18(月) 01:42:15.77

>>109
UBの種類はさすがにCより少ないよ

**デフォルトの名無しさん** · 2022/07/18(月) 06:06:03.85

>>109
お前、未定義動作の意味わかってないだろ...

**デフォルトの名無しさん** · 2022/07/18(月) 06:17:28.08

未定義動作によりコンパイラが最適化を進められる話
https://cpplover.blogspot.com/2014/06/old-new-thing.html

**デフォルトの名無しさん** · 2022/07/18(月) 07:01:28.61

マジキチかよw

**デフォルトの名無しさん** · 2022/07/18(月) 08:19:25.09

Rust信者ってこんなに低脳なん？w
ヤバっ...

**デフォルトの名無しさん** · 2022/07/18(月) 11:04:54.36

てかcにもdefer入るしそれで良くね？

**デフォルトの名無しさん** · 2022/07/18(月) 11:21:45.49

そもそもC/C++がまともに使えない低能のための言語がRustですし

**デフォルトの名無しさん** · 2022/07/18(月) 11:36:06.98

>>95
zigはそう言えなくもないがnimはちゃうやろ。少しはググれよ。
ただまぁ、c/c++からの移行ではrust一強な感はある。

**デフォルトの名無しさん** · 2022/07/18(月) 11:40:31.18

>>115
決定したの？

**デフォルトの名無しさん** · 2022/07/18(月) 15:04:52.06

僕は職業プログラマーじゃないんで
新しいBASICたるswiftとswift playgroundでいいです。
ちょっと数学的解析するのに使ったらすげぇ楽だこれ
ちにゃ〜

**デフォルトの名無しさん** · 2022/07/18(月) 16:31:30.05

>>119
Mathematicaとかmaxmaとか使ったほうがいいんじゃない

**デフォルトの名無しさん** · 2022/07/18(月) 23:29:01.81

>>108
ジェネリクスとRustのトレイトによる制約の相性の良さは感動した
Rustはよく考えられて設計されていると

**デフォルトの名無しさん** · 2022/07/19(火) 00:44:59.22

よく考えて設計したがためにtraitにasync fnを定義するためにGATsが必要で
コンパイラにSATソルバーを入れる必要が出てきてたりして大変そう

**デフォルトの名無しさん** · 2022/07/19(火) 09:36:36.78

タイトルにRustが無いのに、こいつらは文字も読めなければ知性すらない。そりゃ嫌われるわな

**デフォルトの名無しさん** · 2022/07/19(火) 22:42:59.43

比較としてrustが出るならいいが、単独で出されると何だかなぁ感があるよな。

**デフォルトの名無しさん** · 2022/07/20(水) 01:23:22.22

Google？の新言語
https://github.com/carbon-language/carbon-lang

**デフォルトの名無しさん** · 2022/07/20(水) 01:33:59.92

>>125
C++から移行しやすい後継言語ということか
Rustを参考にライフタイムも検討中みたい

C++の既存コードって膨大だし、本当にシームレスにC++から移行できるなら有用そう

**デフォルトの名無しさん** · 2022/07/20(水) 01:40:05.72

>>122
GATsがnightlyで使えるようなので試してみたが非常に強力だな
Rustに欠けていた土台部分の穴を埋めて様々な機能の大きな基盤となる感じだ

>>125
画期的なものを期待して見たら単なるAltC++でズッコケた

**デフォルトの名無しさん** · 2022/07/20(水) 10:38:59.85

>>125
なんでCarbonとかにするかなぁ
Macのやつと間違えるやん

**デフォルトの名無しさん** · 2022/07/20(水) 13:53:08.57

名前は置いておいてついに決定版の言語が出たか
Rustの次の言語だなこれは

**デフォルトの名無しさん** · 2022/07/20(水) 14:18:06.41

見たところZigのC++版ってとこかな

**デフォルトの名無しさん** · 2022/07/20(水) 14:18:06.52

Rsutは死産だったな

**デフォルトの名無しさん** · 2022/07/20(水) 14:36:18.32

Nim言語ならC++の関数だけでなくテンレート関数/クラスを呼び出せる機能があり、std::vectorやstd::stringを使うことも可能。
compileプラグマを使えばC++のコードをコンパイルしてリンクできる。
emitプラグマ使えばNimのコードの中にC++コードを入れることができる。
Nim言語はC++言語を生成してからgcc/clang/vcc等のC++コンパイラを呼び出して実行ファイルを生成するからC++と簡単に連帯できる。

**デフォルトの名無しさん** · 2022/07/20(水) 15:42:59.72

Nimはもっと評価されて良いと思う

**デフォルトの名無しさん** · 2022/07/20(水) 16:04:11.13

Goはオワコンということでよろしいか？

**デフォルトの名無しさん** · 2022/07/20(水) 16:15:14.40

なんでセミコロンありなの？

**デフォルトの名無しさん** · 2022/07/20(水) 17:02:44.97

開発者の趣味

**デフォルトの名無しさん** · 2022/07/20(水) 18:42:51.78

GC言語　GCによる自動メモリ解放
Rust　即時の自動メモリ解放
C/C++/Carbon(現在0.1)　自動メモリ解放ではない

**デフォルトの名無しさん** · 2022/07/20(水) 19:19:34.59

>>137
Rustはスタックに積んでいる＆生ポインタが無いから自動回収されるだけ。c/c++と一緒。
そんなことよりもスタック重視で基本は何でもスタックということを強調したほうがRustらしさの説明になるだろ。

**デフォルトの名無しさん** · 2022/07/20(水) 20:40:05.79

Rustはあらゆる面で安全と高速を両立する抽象化を実現した言語
Carbonのドキュメントを見ると目標はそこでなくRustの領分に入って来ていないでしょう

**デフォルトの名無しさん** · 2022/07/20(水) 20:43:23.04

ほとんどのシステムプログラミング言語と呼ばれるものは変数がスタックに確保されるかヒープに確保するかはコントロールできるはず。
ただし可変長な配列や文字列型はヒープにデータを格納される。
違いはヒープに変数を確保したときに手動で解放する手法、スコープ抜けたら解放する手法、参照カウンタが0になったら解放する手法、GCを使う手法などがあるところ。（valeのgenerational referencesというのもあるけど）
Nim言語でもrefがついてないobjectはスタックに置かれるしRustでもBoxやRc使えばヒープに確保されるしC++でもscoped_ptr使えば参照カウンタでヒープが管理される。
基本的に変数はスタックに確保して、どうしても必要であれば(一つのオブジェクトを複数の変数から参照したい、OOPしたいなど)ヒープを確保するという感じの書き方になると思うけど。

**デフォルトの名無しさん** · 2022/07/20(水) 20:52:32.44

Rustでは自動的に安全に即座にメモリ解放される
ここが重要なポイント
だからRustは高速と安全を両立させることができている
それに加えてRustではメモリ競合なども完全に防止する

**デフォルトの名無しさん** · 2022/07/20(水) 21:03:41.80

そしてCarbonの目標文書を読んでもその目標は書かれていない
つまりRustの本質と競合する言語ではない

**デフォルトの名無しさん** · 2022/07/21(木) 00:23:47.84

変数をヒープに確保するという言い方はなんか気持ち悪いな

**デフォルトの名無しさん** · 2022/07/21(木) 00:34:40.13

結局CarbonはC++の変種に過ぎないのか
新たなプロジェクトではRustを利用する流れは変わりそうにないな
Carbon採用の動機や利点が全くない

**デフォルトの名無しさん** · 2022/07/21(木) 00:49:33.21

Googleが推してるのではなくGoogle社員のプロジェクトやからね

**デフォルトの名無しさん** · 2022/07/21(木) 00:50:32.86

なんでそんな必死なん？

**デフォルトの名無しさん** · 2022/07/21(木) 01:20:47.87

将来的にはcarbon freeにしたいという自虐ネタを込めた命名

**デフォルトの名無しさん** · 2022/07/21(木) 01:25:08.23

人によりけりだけど、一つのプログラミング言語を学習してそれをずっと使いつづけたい、他の言語の勉強したくないという人は多い。
Rustは比較的学習コストが高め。
もし他のプログラミング言語がメジャーになったりもっと優れたプログラミング言語が現れると苦労してRustを勉強した努力が無駄になってしまう。
だから新しい言語の話題がでるとRustを苦労して勉強した努力が無駄になってしまうという恐怖感が生まれて必死に否定するんじゃないかと。

異なるプログラミング言語間でも似た所はあるし、新しい言語を学ぶときにRust言語を学んだ経験が全く無駄になることはないだろうと思うけど。

**デフォルトの名無しさん** · 2022/07/21(木) 01:25:42.94

Carbonでオブジェクトをヒープに確保するのどうやるの？
なんかよーわからん
ドキュメントがなさすぎる
流石にまだこれを使うのは難しいな

**デフォルトの名無しさん** · 2022/07/21(木) 01:34:26.10

Rustの欠点として可変参照の扱いがC/C++互換をかなり難しくしてるんだよな
既存プロジェクトとのinteropにおいては無視できないケースが多い
特にGoogleなどの大企業は
その結果生まれたのがCarbon

**デフォルトの名無しさん** · 2022/07/21(木) 01:56:23.59

Carbon本家もRustが使えるならRustを使えと言っている
でかいC++プロジェクト抱えてる人が使うものだよね
https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md#why-not-rust

**デフォルトの名無しさん** · 2022/07/21(木) 02:05:12.80

>>148
Rustが出現して以来これだけ時間が経過しても
Rustが実現した『高速と安全の両立』を満たす他の言語が出てこなかった
その結果が大手IT各社による共同でのRustへの支援表明とRust Foundation設立
そしてC++を拒否していたLinux開発陣営までもがRust採用発表
つまり既にこの業界では雌雄が決している

**デフォルトの名無しさん** · 2022/07/21(木) 02:06:50.27

>>148
次に学習コストが高いといっても
他との大きな違いは所有権とライフタイムだけでありその概念は一日あれば誰でも理解できる
そして後は具体的にコードを書いて身につけてくのも他の概念と同じ
さらにRustが実現した『高速と安全の両立』のためには所有権とライフタイムによるのが最も適切とわかってきた
つまりRust以外に両立を満たす言語が出てきても学習必須の概念となる
同時にそれは画期的な発明がなされない限りRustの二番煎じの言語しか出現しないことを意味する

**デフォルトの名無しさん** · 2022/07/21(木) 02:13:15.45

>>150
データ競合安全性に関しては誰が考えても可変参照の不可変参照との区別が必要となる
むしろその区別をはっきりさせてこなかったために従来の言語はデータ競合の入りうる隙きを許してきた
過渡的には既存の安全でないものと組み合わせる時に扱いが大変だとしても
最終的には可能な限り全て安全なもので組み立てていくことになろう

**デフォルトの名無しさん** · 2022/07/21(木) 02:17:23.88

>>148
現状Rustが初めての言語って人は少ないから
最初に学んだ言語を使い続ける人はrustユーザーの中ではかなり少数派なのでは

**デフォルトの名無しさん** · 2022/07/21(木) 02:41:33.10

>>142
> Rustの本質と競合する言語ではない
>>152
> この業界ではすでに雌雄が決している

どっちやねん

**デフォルトの名無しさん** · 2022/07/21(木) 04:57:34.89

ifの条件のとこ括弧必要なのかよ！

**デフォルトの名無しさん** · 2022/07/21(木) 05:28:59.67

>>156
Rustが実現してる安全と高速性の両立をCarbonが提供するわけではないみたいだから競合しないね
CarbonのFAQ >>151 にもRustが使えるならばRustを使った方が良いと書かれているね
だから雌雄は決していると言っても過言ではないかも

**デフォルトの名無しさん** · 2022/07/21(木) 06:11:50.65

恐らくCarbonはRustのいいところだけを抽出した感じだな
CarbonのほうがC++やTypeScriptに近いのでRustよりも馴染むだろう
Carbon派とRust派で分かれそうだ

**デフォルトの名無しさん** · 2022/07/21(木) 06:23:11.04

>>159
嘘ついたらダメよ
Carbonはあくまでも既存C++遺産のため限定のもの
そしてRustのいいところは何もサポートしていない
だからCarbonの公式FAQ >>151 でもRustが使えるならばRustを使った方が良いと明記されてるね

**デフォルトの名無しさん** · 2022/07/21(木) 08:20:01.30

C++の後継目指すプログラミング言語「Carbon Language」、Googleの技術者が実験的公開。C++は技術的負債で改良が困難と
https://www.publickey1.jp/blog/22/ccarbon_languagegooglec.html

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

>>153
おまえ所有権理解できてなくて恥かいてたやんww
誰でも一日で理解できる概念やのにwww

**デフォルトの名無しさん** · 2022/07/21(木) 11:18:14.67

所有権どころかシャローコピーとディープコピーの違いも知らずにRust通を気取ってるアタオカさんだからRustスレでは鼻つまみもの

**デフォルトの名無しさん** · 2022/07/21(木) 11:19:06.12

キモキモRustマン、ワッショイワッショイはRustスレでやれ。二度と来んな

**デフォルトの名無しさん** · 2022/07/21(木) 12:02:23.44

Rustスレ民が学習して構ってもらえなくなっちゃったから来てるんでしょ

**デフォルトの名無しさん** · 2022/07/21(木) 13:04:30.75

ここ以外でもツイッターとかでやたらRust難しいと印象操作しようとしてるやついるよな
C/C++をまともに書いたこと有ればたいして難しくもないのに

**デフォルトの名無しさん** · 2022/07/21(木) 13:47:25.39

>C/C++をまともに書いたこと有ればたいして難しくもない

その通り
で結局C/C++でええやんという話に戻る

**デフォルトの名無しさん** · 2022/07/21(木) 13:47:41.33

色んな言語をやってきてRustが特に難しいとは思わなかった
むしろ便利さと書きやすさで気に入った
他の言語より抽象化されてる感じが良いね
そこが頭の弱い人には逆に難しく感じるのかも

**デフォルトの名無しさん** · 2022/07/21(木) 13:53:10.37

>>167
C/C++はごく最近は抽象的な扱いのものの導入も増えつつあるけど
元がダメだからボロ屋の上に建て増し違法建築みたいになっちゃってる
基礎がしっかりしているRustはその点でも良いね

**デフォルトの名無しさん** · 2022/07/21(木) 14:00:17.21

C++はmove semanticsの建て増し感が特に厳しいな
後付するならあれしかなかったのは分かるけど
そこがちゃんとしてるというだけでもRustの方が楽に感じる

**デフォルトの名無しさん** · 2022/07/21(木) 14:02:26.54

RustのC++との相互運用性を改善する方向性で頑張ってくれたらよかったのにな
C++の保守専用言語なんか普及するわけないじゃん

**デフォルトの名無しさん** · 2022/07/21(木) 14:11:46.30

>>171
Carbonを新たな開発で使うことはないだろうからC++の保守専用言語という表現いいね

**デフォルトの名無しさん** · 2022/07/21(木) 14:57:52.79

>>168
>色んな言語をやってきてRustが特に難しいとは思わなかった
参考までにやってきた色んな言語を列挙してもらえるかな？

**デフォルトの名無しさん** · 2022/07/21(木) 15:55:40.07

>>166
「CとC++」な。
両方それなりに使えないとRustきついだろ。

**デフォルトの名無しさん** · 2022/07/21(木) 16:06:53.27

そんなにシステムプログラミング言語が必要な事をやってるの？

私の場合は、Pythonでほとんど困らなくて、偶に.net系くらいなもんだから、Rustの話が続いても別世界の話過ぎて、付いていない…

**デフォルトの名無しさん** · 2022/07/21(木) 16:25:46.06

>>174
ぶっちゃけ全然きつくないよ
どの辺がきついと思うのか逆に知りたい

**デフォルトの名無しさん** · 2022/07/21(木) 16:28:02.22

こういう奴が一番危険なんだよな。。実際仕事すると洒落にならんことし始める。

**デフォルトの名無しさん** · 2022/07/21(木) 17:45:24.11

メモリやらリソース管理、分散処理の課題をRust以上まともに解決してない言語だと、次世代って感じしないなぁ。

柔軟さ動的さに極振りだったRubyや、関数型のパラダイムを持ち込んだHaskellとかもなんか新しさがあったわけで。

**デフォルトの名無しさん** · 2022/07/21(木) 18:05:35.14

rubyは目新しさというよりは
perlよりマシっていう感じだったよね実際は
perlよりマシだしOOPLを自称してるし
イテレータがあるしで
（当初は内部イテレータがあるのをウリにしてた記憶）
「ザ・ちょうどそういうの欲しかってん言語」って感じ

**デフォルトの名無しさん** · 2022/07/21(木) 18:09:56.47

Rustわからんって言ってる人ってスタックとヒープを理解してない
せめてメモリのレイアウトぐらい理解しとこうよ

**デフォルトの名無しさん** · 2022/07/21(木) 18:22:38.41

>>180
スタックとヒープの違いやメモリ解放とOSへ返却が違う位は分かるけれど、私にはRustは過剰で難しい。

**デフォルトの名無しさん** · 2022/07/21(木) 18:37:11.06

>>181
わからんならとりあえずヒープは忘れて全部スタックに乗せるというのが良いと思うよ
スタックをつかって所有権を移動させていくプログラミングすれば不要なコピーは起きないし
効率も良い

**デフォルトの名無しさん** · 2022/07/21(木) 18:50:15.74

>元がダメだからボロ屋の上に建て増し違法建築みたいになっちゃってる

まあ同意は出来るが
「C/C++を*まとも*に使える」
という意味の捉え方によるな
違法建築になってるのは「*まとも*に使えてない」人のコード

**デフォルトの名無しさん** · 2022/07/21(木) 18:52:26.12

>>183
やっぱりc++のダメな部分を削ったsmart c++欲しいな。

**デフォルトの名無しさん** · 2022/07/21(木) 18:54:02.97

>>180-181
結局そいういうのC/C++で勉強する訳で
Rust理解するためにC/C++の勉強が必須なら
C/C++でええやんって話に戻る

**デフォルトの名無しさん** · 2022/07/21(木) 19:14:35.47

C/C++をやればスタックとヒープの概念が身につくのであればRustをやってそれらが身につかない理由もないと思うが

**デフォルトの名無しさん** · 2022/07/21(木) 19:18:49.81

>>184
それがRustの狙いでは？

**デフォルトの名無しさん** · 2022/07/21(木) 19:19:07.93

>>185
遠回りになるがそこから始めるのもありかもな
メモリ関連はそれなりの失敗経験がないと体で理解できないから

Cでクソでかい構造体をスタックに置いてしまって
スタックオーバーフロー起こしてシステム停止したり
C++でコピーコンストラクタの実装ミスって
ダングリングポインタ作ってシステム停止したり
デストラクタでdelete忘れてメモリリーク起こして
システム停止したり
それなりの地獄を味わってる俺が言うんだ間違いない

**デフォルトの名無しさん** · 2022/07/21(木) 19:44:43.35

趣味プログラミングならどんどん変なことしてクラッシュさせれば良いけど
業務ならもっと安全を期したいなぁ

**デフォルトの名無しさん** · 2022/07/21(木) 19:52:05.48

> それなりの地獄

かわいい地獄でつねｗ

**デフォルトの名無しさん** · 2022/07/21(木) 19:54:55.78

C/C++のよくある業務ってやっぱり組み込み？
それかゲーム開発？

**デフォルトの名無しさん** · 2022/07/21(木) 20:25:53.32

無料で答える業務はない

**デフォルトの名無しさん** · 2022/07/21(木) 20:54:05.56

>>175
Pythonは約10倍くらい遅い
メモリも喰う
ガベージコレクションもある
まともな並行並列プログラミングが大変
Pythonは小さなバッチ的スクリプトの範囲でのみ使うのが正解

**デフォルトの名無しさん** · 2022/07/21(木) 21:04:39.89

>>191
スマホの課金ゲームのバックグランド鯖の開発とかもあるよ

**デフォルトの名無しさん** · 2022/07/21(木) 22:23:39.66

PythonやJavaScript書くときはでかいアロケーションの有無くらいしか意識しないけど
C#やSwift書くときはvalue typeとreference typeの使い分けがあるからスタックとヒープもそれなりに意識する
Goの場合は気になるところでescape analysis

**デフォルトの名無しさん** · 2022/07/21(木) 23:33:08.48

三角関数や薬剤師の存在を意識してる人は大体が
「コスト」を強く意識した方がメリットが大きいと思い込んで意識している

**デフォルトの名無しさん** · 2022/07/21(木) 23:43:19.63

自分でも何を書いてるのか理解できてなさそう
思い込んで意識するというのも意味不明

**デフォルトの名無しさん** · 2022/07/21(木) 23:53:17.15

>>195
PythonやRubyやJavaScriptなどのオモチャ言語しか使ったことのない人だけがスタックとヒープを意識しないわけか

**デフォルトの名無しさん** · 2022/07/22(金) 06:54:41.09

コンピューターの動作を隠蔽すればオモチャに近づくのなら究極的にはアセンブラ以外は全てオモチャなのではないだろうか

**デフォルトの名無しさん** · 2022/07/22(金) 07:02:16.68

アセンブラはスタックやメモリーにアクセスするプログラムを書かされる。
Cはメモリーにアクセスするプリグラムを書かされる。

Javaはスタックもメモリーも意識する必要がない。
すなわちJavaが最も優れている。