次世代言語18 Go Rust Elixir Kotlin TypeScript
■ このスレッドは過去ログ倉庫に格納されています
スレタイ以外の言語もok
前スレ
次世代言語17 Go Rust Kotlin TypeScript Julia
https://mevius.5ch.net/test/read.cgi/tech/1567602619/ まあc言語のライブラリ管理はそんな簡単じゃないがな。
低レイヤー触るとどうしてもそうなる。 PythonがC FFI側に投げてるライブラリのバージョンの複雑さは結局ユーザじゃなくてメンテナがコスト払ってるだけな部分もあるからな…… >>574,575
そんな低レイヤーうんぬんなど些細な話だ
そもそも2系から3系への移行ではPython本体やCライブラリだけでなく、
あまたの2系ライブラリのメンテナが膨大なコストを払っているのだから…
「後方互換性の断絶」とはそうゆうものだ
Python利用者はそうした神の決定に逆らうことは許されない
神の行いは絶対であり、聖書PEPを疑ってはならない 2のメンテは終了しただろ。何言ってんだこの馬鹿は。 最新の3.8ですらJavaにすら劣るゴミという事実 一方で単一の言語処理系に過去バージョン互換をさせるとそれ自身の複雑さが極端に増すのは間違いない訳で
結局どこかしらでコストは払ってるんだよ
この辺はいくら次世代のいい感じの言語が出ようとも変わらないと思う んなあたりまえのこといわれても、でっ?ていう。
最適な互換性の維持具合についてなんか意見でもあるなら言えばいいけど
なんも考えてなさげだな。 Pythonには2と3があるから駄目
そしてPythonをJavaに置き換えることを意識した時点で
Javaもその駄目なグループのメンバーになったようなもの
GCがある言語は多分みんな駄目になってしまう >>578
ここは「次世代言語に憧れるレガシー言語労働者の愚痴スレ」だから >GCがある言語は多分みんな駄目になってしまう
なんの根拠もなく現状を全く無視したことを平然とのたまう精神はどこからきてるんだろうか。
こういう輩が好みそうなのはrustですかね。 そうだね
なんの根拠もないものは全く無視されて当然
その精神がある限り、古い仕様は無視されて互換性が無くなる 静的型付け言語(typescript)の設計を学ぶためには、HaskellとF♯どっちが向いてるんだろう。 TypeScriptの設計を学ぶならTypeScript以外に無いだろ javaScriptの数値は浮動小数点数だけなんたな NumberとBigIntの二種類あるよ。
かつてNumberしかなかったのは、
JS作ってるほうも「JSで数値計算?そんなやつおらへんやろ〜」って感じだったんだと思う。
実際はそんなことはなかったという歴史は知っての通り。 昔から知ってるやつからすると
ホームページ上で動的にデザイン変えるための言語だよなそもそもは TypeScript、普通にトップクラスに書きやすいから困る
json 扱うなら TypeScript さいつよ JavaScriptでも、ビット演算は32bit符号付き整数に対する演算と決められてるので、
直接32bit整数の値を作れはしなくても、内部的にそのような型は存在はしてるはず
JavaScriptではビット演算はオペランドをこの32bit整数に暗黙的に型変換してから
実行するので、これを利用してNumber型を"整数型"に変換できる
a = Math.PI | 0
a == 3 // --> true
実際、JavaScriptにトランスパイルされるAltJSのPureScriptではInt型があるけど、
PSからコンパイルされたJS見てみると、Intは|0で実装されてるのがわかる。 asm.jsと言うのものがあってだな・・・
元々誰も使ってなかった上にwasmの登場で完全にいらない子になったけど int型の有無で言語を2つ以上作る世代は早く終わってほしい
ライブラリを追加するだけですむようにしてくれ >>599
むしろ要る子だったからwasmに進化したんだが
分けて考えるのはナンセンス >>602
https://github.com/WebAssembly/design/blob/12ee148fb5cfa33331dbffadae06752b1759a7bf/HighLevelGoals.md
> WebAssembly High-Level Design Goals
> 4. Design v.1 as a Minimum Viable Product: basically what you can do with asm.js.
これが出発点だからな
そのレスはかなり間抜け 優秀つってもしょせんC++で作られたプログラムだろ?C++褒め称えろよ 出発点だったら何なんだよ
すべてのC言語プログラマはBCPLを崇め奉らなきゃいけないのか?
どっちが間抜けだよ ?
V8はC++で作られてるでしょ?
CコンパイラはBCPLで書かれてるの?
違うでしょ?大抵CかC++で書かれてるでしょ?
何で書かれてるかと何が先祖かの区別つかないとか、頭大丈夫?w でもアセンブラとC++にはマクロがあるから
文字列指向というか
asm.jsもテキスト形式だな ももも、文字列指向www
マクロがあったらw
文w字w列w指w向www
Rustもマクロがあるから
文w字w列w指w向www IDEも予測入力もなかった時代に入力を補完するオーパーツ的な存在がマクロ
引数があれば補完後のどこかに挿入されたりする コンパイル前にできる処理をコンパイル・実行時にやらない defineマクロみたいなのは純粋な文字列置換
lisp系とか高級になるとトークンを受け取ってどのような構文木を作って返すかプログラマーが操作できる処理 lispのマクロと関数の違いに対する理解が浅そう。 フォトジェニックマクロとか言うやつでしょ?ぼく知ってるよ スレタイにJulia入れなかったのはつまりそういうことか Rust触ってみたいんだけど逆に悪いところってなに?
いいところしか聞かないから聞きたい >>622
Rust使ってると変な人にからまれるから、やめといた方がいい 読んで字のごとく
何をやってもつっかかる
できるはずのことができない コミュニティーがことごとく都合の悪いことをなかったことにしている。
そんなに悪いとこがねーならとっくに他の言語を置き換えてるだろうに。 安全教信者がうるさいって印象はある
でも言語自体はよくできてると思うわ
Let's EncryptのやらかしもRustなら防げたんだろうし 防げるわけねーだろ。。
結局低レイヤーの配列のインデックスに演算が必要な場合はunsafeだしな。
そういうところで嘘を表に出さないようなことやってるから信用がない。 C++はユーザーに数十年間検査され欠陥が大量に見つかったがほとんど直さない
Rustはそもそも検査されてないので直すところもない
あとは正しい方を選ぶだけの簡単な作業 欠陥は誰かが騒ぐからググればすぐに出てくるので
実害はない。そこを避ければいいだけ。
普通、迂回策も書いてある。 ほら、やっぱり基礎的な文法すら見てないような奴にからまれてる 少なくともピューと吹けば壊れるPHPより良い言語であることは疑いようのないTru >>627
なんで何もわかってないのに偉そうにしちゃうん? インフラに疎いんだけど、
デプロイ(CD)ってどのファイル転送プロトコル使われることが多いの? GoogleのPWA推しはなんなんや……
File APIじゃサンドボックスからファイルシステム一切アクセスできない
試験運用中のNative File System API試したらinput type=“file”とできることかわらなくてマジクソ
パスすら取得できないって始まる前から終わってますやん
PWAとかいうその幻想をぶち殺す ローカルファイルをやめて全部サーバーにおかせようって魂胆
ま、クロウムブックだとかグーグルのネットストレージサービスの促進には役だつわな
当然、巨大ファイルをしょっちゅうガリガリやるようなアプリにはまるで使えない ウェブ、ローカルストレージ APIとか明らかにiOS/Androidしか考えてないよな
アプリの設定やデータだけキャッシュできればいいならそらそうか……
wasmはブラウザアクセス時にホストからダウンロードして実行とかMSのClickOnceを思い出すわ懐かしい
そしてwasmもサンドボックスの制約から逃れられないから恩恵受けるのゲームだけなんじゃなかろうか Googleは自分のサービス繁栄のことしか考えてないからな
合理的なエコシステムなんて糞くらえよ >>651
C99 の大部分は改悪、C89 こそ正義! >>654
C99 の C++ 互換でない仕様は基本的に害悪 >>654
C99 と互換でない C++ の仕様が害悪なのでは?
ボブは訝しんだ >>622
Rustは、有る意味では普通の「手続き型言語」の枠組みを超えてしまっているため、
通常のプログラミング言語の代わりに使うことはほぼ出来ないことが最大の欠点。
関数言語以外ではどの言語でもほぼ共通である所の変数の代入の概念がRustでは
変更になってしまっている。 >>642
ファイルシステムに関しては、本当にサンドボックスの外に出られ無い事が
大問題ではあるが、Wasmは雰囲気だけはnativeアプリ見たいには出来る。
ダウンロード時間を含めて起動も速い:
https://yutakaaoki.github.io/demo1/index.html >>98
KotlinとSwiftは、それぞれ、ほぼ AndroidとiOS専用なのに対し、DartとFlutterと組み合わせは、マルチプラットフォームであることが違うことは違う。 >>96
Dartは、Javaにも似ているが、初期のころのC++に似ている気がした。
原始的なC++から、型を明示した宣言を省略したような感じ。
C#やSwiftには便利さの点で負けると思うし、確かにJavaにすら負けているかもね。 >>24
Rustは、厳格すぎて余計なことに気を取られたりタイプ量が多すぎてむしろC++より生産性は下がりそうだ。
生産性という意味では、C#やJavaの方が上だろう。 >>659
結局wasmの売りってホストにデプロイされたバイトコードが如何なる環境でもChromium上で実行可能かつネイティブと迫る速度であるってことだからやっぱターゲットはゲームやモバイルアプリなんだよな
そうなると最近アナウンスされたReactNative for Windows/Macとはベクトルが違うからやっぱクロスプラットフォームって幻想だよな
実際アプリもネイティブで書いた方がメンテしやすいからなみんなネイティブで書いてるもんな それはwasmじゃなくてwasiでやろうとしてることでしょ? >>664
wasiなんてあるのか知らなかったわサンクス
node.jsでも試験的に実装されてて実際に動作するみたいやな
現状ファイルアクセスだけみたいやがネットワーク接続もできるようになるみたいやしnode.jsでwasiがサポートされてるなら完全なクロスプラットフォームが実現しそうやな ぼくもwasiって知らんかった。このスレたまたま開いてよかった Wasm : ブラウザで動かす。バックエンドのJSのcanvasなどを使うことで
グラフィックも使え、GUIも可能。原則、nativeファイルシステムが使えない。
wasi : Wasmを使うがブラウザ外で動かし、今のところCUI専用。native ファイル
システムが使えるので、サーバーサイドの node.jsやJavaの置き換えや
組み込みに向いているらしい。 webの流れ早過ぎ
業務で触ってないと追いつける気がしない wasiの変なサイトにアクセスしたら勝手にインストールされて
激重なるの?情報も抜かれる? >>667
他にも、
Wasmer, Wasmerio(Wasmer I/O ?), Wasmtime など色々出てきている。 >>669
そんなことは無い。
すべてはブラウザのセキュリティーモデルの中で動いているので、
原則的に今までどおりのセキュリティーレベル。
というのは、結局、Wasmで出来ることはJSでできることと変わりが無いため、
JSでどう書いてもできないことは、Wasmでもできないから。
Wasmの大きな利点は、JS以外の言語が使えることで、プログラムが開発し易くなること。
たとえば、JSだと間違いになかなか気づかない箇所でもC++だとコンパイラが発見してくれ、protected属性をつけていれば、他のclassからのアクセス制御なども出来て、保護したい変数に不用意にアクセスできなく出来たりする。 DOS攻撃すると逆にハッカー側がダメージ負う方法ってない?
例えばレスポンスで巨大なファイル送りつけるとか(多分レスポンス受け取らないから意味なさそう) ネットを利用するとお金がかかるようにすればいいのに
なんでネットすぐタダにしてしまうん ■ このスレッドは過去ログ倉庫に格納されています