次世代言語29 TypeScript Swift Go Kotlin Rust Nim
■ このスレッドは過去ログ倉庫に格納されています
スレタイ以外の言語もok 前スレ 次世代言語28 TypeScript Swift Go Kotlin Rust Nim https://mevius.5ch.net/test/read.cgi/tech/1661739736/ 汎用機とかでファイル名の最大長が短くて拡張子使わないケースとかはあるわな >>671 javaは拡張子やフォルダー構成も決まってたような気がするけど言語仕様なのか単なる開発環境の決め事なのかはよく知らん 俺様がベーシックやってた頃は拡張子なんて無かったぞ 誰か説明しろよ 最近読んだC++コードの拡張子がc++だったのはたまげたな c++は .cpp .cc .cxx .c++ .C .hpp .hh .H とか節操無さすぎ。 その点Rustは統一されてて安心安全 ついでにメモリも安心安全 c言語は UNIX という OSを実装するために作られたものだから ファイルシステムとは表裏一体だったという歴史は捨てようがない 派生した言語や OS も色々引きずっている 拡張子なんてもんはいつからできたんだよ 誰か調べてこい >>681 もうC++の話はいいのか?w C言語では *.[cC], *.[hH] でない処理系は見たことないな 拡張子の文化が広まったのは、 8ビットマイコン時代にCP/Mが普及したのがキッカケで CP/M→MS-DOS→windows の系譜で定着したのだろう 当初は、アセンブリ言語のソースや実行ファイルを拡張子で区別したが 高水準言語(高級言語)が次第に移植された 拡張子の由来 https://ja.wikipedia.org/wiki/%E6%8B%A1%E5%BC%B5%E5%AD%90#%E6%8B%A1%E5%BC%B5%E5%AD%90%E3%81%AE%E7%94%B1%E6%9D%A5 拡張子は、もともとはDECのオペレーティングシステム (OS) 、たとえば、TOPS-10、OS/8やRT-11に利用されていた。 その後、CP/Mでも採用された。CP/Mのファイル名は8+3バイトの構成になっており、後ろの3バイトが拡張子と呼ばれた。 さらにCP/Mと互換性を取るため、MS-DOSやOS/2、Windowsなどに受け継がれた。現在のWindowsでは3バイトの制限はない。 そりゃ、K&Rの時代から .c .hが有ったにしても DECのミニコンを庶民はそうそう導入できない そりゃ当然、コンピュータを使っている人への普及の話だろ。使ってもいない人に普及するわけはないが。 >>689 UNIXとCの話は先に書いたから、 次にマイコン時代の浸透と拡散の話に進めたけど、早かったか それらの前、BCPL等の時代に拡張子やファイルの概念があったのかは調査中だ 簡単過ぎるから未解決のまま放置される問題というのがある アクセルとブレーキどうやって区別するのかとか 拡張子を何にするかとか >>691 ナルセのワンペダルで解決しているよ。 (日産のパチもんじゃないので注意) >>691 優先度低いためにいつまでたっても解決されない問題とかあるわ。 本来なら時間経過とともに優先度は上げるべきなんだよな。 ホントに困ってたら優先順位上げるだろ ずっと低いままと言う事はたいして困ってないってこと >>694 追加機能とか便利になる機能とかは困ってるわけじゃないからなぁ。 やっぱりヘッダーファイルができた C言語あたりから拡張子が必要になったんじゃないか それまではソースファイル一つとオブジェクトファイル一つで データは外から読んで、外に書き出すものだったから そもそもwikipediaをソースにしちゃうひとってω >>675 .N88 とか .BAS より古いのか >>699 .inc はまだしも .m はみたことないな >>700 Csave命令に拡張子はなかった 何冊か確認した 80年代のキッズ向けゲームプログラミングの本だ Siv3DやDXライブラリ等のゲーム制作用のフレームワークを使用したくてC++に初めて手を出そうと思うのですが 世の中の風潮がC++での新規開発はナンセンスでありC++を代替する言語(主にRust?)を選択すべきとあるようです 正直C++もRustも構文が複雑ですぐに忘れそうなので、NimかZigが良さそうと感じました Zigは安定版がまだまだ先なので採用できませんがNimが流行っていないのは何か致命的な欠点があるからでしょうか ゲーム作りたいならunityかc++じゃないの?rustはいずれ台頭するかも知れないけど今はまだ成熟してない気がする。 >>705 Unity等のゲームエンジンは使用せずプログラミング言語(GCは無しか軽めのやつ)でいきたいです C++のフレームワークは最悪DLL化すればよいので、読みやすくコンパイルや実行速度が速い言語が良いです 総合するとNimが最有力かなと思いました Nimがなぜこんなにも流行っていないのか不思議でなりません C++が嫌、Unityも嫌って趣味でするなら何でもいいけど もし仕事ならそれは無理があるw 普通にフレームワーク使えば良くないか? こだわりがあるわけでもないみたいだし Nimは別に致命的な欠陥があるとかではないんだろうけど わざわざ使う理由もないんだよな 構文が好きな人はいるだろうけど結局個人の好みなので みんなで移行するほどの動機にはならない レスどうもです ひとまずC++でいこうと思います C++20とかで昔よりは書きやすく見やすくなっている気がしますし 何より日本語の参考情報・コミュニティが多いのが長期的に見れば問題発生時に助かるはず IT土方を目指すならRust 趣味や個人でやるんならNim ゲームそのものを作るのはUnity/UE/cocos2dのいずれか又は全部で、それぞれの1stターゲットの言語を使ってやりつつ、エンジン自作はC++でやればいいと思う 一応Rustもこないだ見たらwindows-rsでDirectX 12も書けるしXamlも食えるようになってたのでナシではない Windows以外のプラットフォーム向けなら何個かVulkanラッパーあるし いずれにせよ修羅の道だけど >>706 ネイティブコンパイラじゃなくトランスレーターだから。 過去トランスレーターで流行ったのはTypescriptしかない。 >>716 初期のC++もトランスレーターだったから流行らない原因をトランスレーターと言うのはちょっと違うと思うな ゲームでは、Unity 以外は無理 特に、C++ なんて10年以上は掛かる >>717 それはMicrosoftが開発言語に採用したからだ。 >>721 それならますますトランスレーター関係ないだろw nim言語は普通にコンパイルして使う場合には ネティブコードコンパイラと違いはない nim c -d:danger -d:strip hello.nim でバイナリの実行コードができるので。 イケてない最大の理由は名前 kotlinとかnimとか名前がダサい 響きが野暮ったい >>726 >>727 俺もそう思う。 初めて見た時なんで錆?って思ったわ。 ゴタクはいいよ なんでnimが流行ってないかお前らも考えろよ おおかたロゴかマスコットキャラがキモかったんじゃねーの 流行ってない泡沫言語なんて山のようにあるんだから考えるだけ無駄。 流行っている理由ならまだしも。 まあ流行自体が目的でない限り、真の目的のために流行を犠牲にするのはごく普通の手段でしょ 対価を一円たりとも支払わない方針のほうが珍しい CNET Japan: グーグル、Rustで書かれたセキュアなOS「KataOS」を発表. http://japan.cnet.com/article/35194751/ >>735 > このOSは、デスクトップPCやスマートフォン向けではなく、モノのインターネット(IoT)、おそらくはスマートホームを対象としたものだ。 >>739 グーグルがRustで本格的にOSつくりだしたことで、Rustの覇権が決定的なものとなった Google Researchだから論文出して飽きたら終わりだよ ハードを遠隔操作するOSは飽きるんじゃなくてハードが規制される 言語は規制されないから終わらない >>741 RTOSだとRustの制約がきつすぎて他の言語と変わらなくなりそうだと思うがね。 特にAliasing XOR Mutabilityをマルチスレッドで有効活用するのはキツイんじゃね?Mutex、RwLock、Atomicの管理で破綻しそうだし、熟成するまでせっかちなGoogleが我慢できるとも思えん。 Rustが覇権取ってくれるのは一向に構わんがはよ流行れよとw いつまで同じこといってんのよ~って感じやな Goが下火になってきてるのはいいことやとは思う はよGoを滅ぼしてくれよRustさんよぉ Rustも流行らないよ borrow checkerが厳しすぎる >>745 用途が全然違うのになぜ比較したがるのか RustはCとC++の代替言語な そりゃあどんな物でもお金と交換できると思ってるならなんでも比較できると思うだろう >>745 Webサービスに使うならGoで良いんじゃない? GCあっても誤差レベルだし ライブラリも豊富だから作りやすいでしょう 非同期ランタイムとか面倒なこともないし >>749 >GCあっても誤差レベルだし これマジで言ってる?w Rustが覇権を握った世界でもCは使われるんじゃないの? 小さなプログラムでもRustが上なのか? >>751 メモリの開放処理が不要なツールとかだと、明示的にメモリ解放サボれるCが有利なケース作れたりするんかな。 そんなケースで勝てなくてもいいとは思うけど。 >>749 正直Webサービスって別にGoじゃなくてもいいよね感半端ない JavaでもRubyでもC#でもいいし Goの利点なんて全然ないわ Goルーチンなんて全然いらんし >>754 でもISUCONでは一番人気だしスケールしやすく簡単にかけて可読性がよくパフォーマンスが出るのは事実なのでは? Goが一番輝くのはDockerやKubernetesで使われてるようにクラウド関連の周辺ツールやバックエンドだな CockroachDBやTiDBで使われてるように、その気になればDBみたいなプログラムにも適している Rustはとっつきにくさがあるからここまで流行らないだろうね、そもそもGCが気になるケースってのは非常に稀だしOS開発ぐらいでしかまず使われないだろう GCも当然進化しているわけだからJavaとかと比べてGoの停止時間は圧倒的に短いし、ある程度書き方を工夫することでスタックヒープにわける制御もできる だからほとんどGCが問題になることもない あくまでもRustはCを置き換える言語だね >>755 でもいらねーんだよ JavaやらのGCだってどんどん進化してるし 別にGoじゃなくてもDocker、k8sでスケールできるし Goじゃなきゃ非機能要件を満たせないなんてことまずねーんだよ それにエラー処理が糞だからなぁ >>756 エラー処理がクソってのもお前の感想でしかない 例外の方がクソって考えてる人もそれなりにいるわけなんでね 俺からしたらGoよりJavaの方が終わってる点が圧倒的に多いと思ってるでね 俺はISUCONで一番Goが使われててJavaなんて誰も使ってないっていうデータを示してるわけだが お前の感想なんか誰も聞いてないよ スケールできるってのはあくまでも効率よくって話な ISUCON12の初期実装でもGoとJavaでは5倍ほど差があったとのことだし、同じように実装しても普通に差が出るんだから 当然効率よくスケールできるという話になるわけ >>758 いやー、Goのエラー処理は適当やってると問題起きた時につらいんだよね。スタックトレース付けてなかったりすると、どこで問題起きてるかがわからない。 スタックトレースをエラー処理に組み込んでないってのが、JVM言語やってた人間からすると信じがたい。 軽量スレッドを使った並行並列処理する上で例外は相性が悪いからオミットされて代わりに値として扱ってるってのがまずあるね Goが作られた最大の理由は効率よくマルチコアを利用するってのだし Nodeみたいにシングルスレッドなのであれば例外も扱えることができるが これを両立してる言語は存在しないね 実際、D言語にはGCがあるけど、LLVMを使ってるLDCでコンパイルすれば C++にかなり近い実行速度になるし、GCはそんなに遅くない気はする >>759 Javaの場合はフレームワークもそれなりに重いからね >>754 別に書き換える必要はないと思うよ 新規で始めるならGoとかRust使った方が面白いのではないかと言うこと そもそもJavaとWebって相性が悪い なぜならオブジェクト指向とWebの相性がそもそも悪いから アホがOOPを意識して書くとオーバーエンジリアリングになりがちで、基本的に手続型の方が適してる Spring Bootとか重厚すぎて終わってる OOPが向いてるのはGUIとか public static void mainとかアホじゃねーの public static final int countdown 違うと思う 相性が悪いわけではなかった 「今後必要になるプログラミング言語」を見てみると当時javaがどう思われていたのかが分かる >>756 「でも」の意味がわからなすぎて草 「Goじゃなきゃ非機能要件を満たせない」なんて、その言語がチューリング完全じゃないみたいじゃん 極論過ぎて言いたいことがぼやけてるぞ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる