次世代言語18 Go Rust Elixir Kotlin TypeScript
レス数が900を超えています。1000を超えると表示できなくなるよ。
スレタイ以外の言語もok
前スレ
次世代言語17 Go Rust Kotlin TypeScript Julia
https://mevius.5ch.net/test/read.cgi/tech/1567602619/ >>806
型推論できるのは冗長性があるからで
冗長性にもいい面悪い面がある
悪い面は変更に弱くなる
あっちかえたらこっちもってね
rustはそのへんバランスとろうとしている
効果はさておき
そのへんまで考察しないと浅いよ >>819
普段C++触るけど同じ型指定なのに二通りの書き方あるのはC++の悪いところだと思う
Cの資産引き継ごうとしててC++特有のカオスによりしてる C/C++ は typedef した型を区別出来れば良かったのにな 別のclasssにすれば区別できるお、
intと同じ振る舞いをするがintと区別されるclass、みたいなやつは必要に駆られてたまに作る C++は最悪templateで筋肉解決できるけどCでtypedefを別の型にしちゃうとインターフェイス相応のものもderiveマクロ相応のものもそもそもないし、組み込み型のオペレーター群を指定する方法もないから記述がべろべろになってしまうんだよな
C++はそれと統一性をもたせざるを得なかったから現状がある
良しか悪しきかは知らん 型なんて屁みたいなもんでガチャガチャ言ってる入口さん
どんだけ効率的に書けて実行出来るか焦点はforeach と食わすリストよ
動的なリストでも分岐無くすとかキャッシュ乗り鬼効率な凄いのをくれ その屁みたいなもんが無くなったらNumPyやCythonの無いPythonのようなもので
それはもうウンコやん phpはシンタックスがゴミ
(そもそもなんだよ $ -> => って...)
パッケージ管理もゴミ
ログ出力の見やすさもデバッグのしやすさもゴミ
バージョン乱立
フレームワーク乱立
土台の言語仕様自体がゴミなの棚に上げて
コーディング規約の強要
やることなすこと全部他言語の猿真似
動的片付けの癖にプリミティブ型がメソッドや属性すら
持ってない
JavaやRailsやJavaScriptはいい加減糞PHPを
著作権侵害で訴えろや
消えうせろ、潰れちまえパクリウンコゴミ溜め言語が >>828
で?君はPHPで書かれたプロダクトより良いプロダクトを持っておりゅかね?? Rubyは
次世代の日本を担う素晴らしい言語
Railsは、流行りのWebサイトでほとんど使われてる。
Qiitaも、Rails
最近流行ってた、質問箱も、Rails
雇われから脱出し、マックザッカバーグを目指すならRails一択!!!!!!! phpもそうだしエクセルもそうなんだけど、濫用するヤツが増えると悪評が一気に増える
もしかしたらm4がphp並みに嫌われる世界もあったかもしれないと思う
言語の適用範囲を高めるためには、抽象度の高い概念を基本とした方が良い。できるなら数学的に議論可能なレベルで マックザッカーバーグを目指すから、
Facebookに倣ってPHPにするは! FacebookほどPHP憎んでそうな企業もないと思うが
HackやらReactやら なんでReact??
そもそもフロント技術だし、しかもフレームワークだし、ベースがJSだからPHPと全然違う
PHPは糞言語なのは間違いないけど論点違うだろ じゃあ尚更PHPとの比較は外した方がいいな
関数型、immutableってJSがESで取り込んでいった方針だから ちなみにザッカーバーグのfacebookはrubyもrailsも全く関係ない。
安定のrubyガイジ妄想クオリティ。 Railsで作られたサイトは、山ほどあるけど、Laravelで作られた有名なサイトは、少ない。
というか、見たことない。
Laravel使いは、誰も使わないサービスを量産してお金を稼ぐ負の存在。。。!?
技術だけじゃなく、ビジネスで勝負したいならRails一択!!!!! 人はパンのみにて生くるにあらずという名セリフを知らないのかよ ZOZO は、Laravel
レールは続く】 Ruby on Rails Part21 【これからも
https://medaka.5ch.net/test/read.cgi/php/1545146635/103
世界を驚かせた、表示速度が異常なサイトも、Rails 製だった!
https://dev.to/ Goだとクリティカルになる場合だけRustを使う、あとは面倒なだけだから(マークアップ以外は)絶滅して無問題、わりとマジで wasmて使用言語混ぜて分割コンパイルとか出来るん? >>844
Wasmはマシン語に相当するものなので、Wasm自体には使用言語に関する混合に関して何の制限も無い。
ただし、nativeアプリの場合と同じで、C言語の関数を通じてお互いに呼び出しあうなどは必要。
なお、今のところ、最低限マシン語とC言語の仕組みに関して知識がないと難しい。
(最低、アドレスやポインタについての理解がいる。) >>845
例えば、LLVMをバックエンドに持つコンパイラであって、LLVMの中の
%struct.XXXX のアラインメントのとり方が同じであって、かつ、
export、importする関数がC言語のインターフェースを持っているならば、
Wasm用のリンカでリンクが可能。
この条件を満たさない場合、リンクするのは難しいが、以下のようにすれば、
実行段階でお互いに関数を呼び出しあうことが出来る。
・それぞれの言語処理系でリンクを行って、*.wasm ファイルを作る。
これらは、「Module」と呼ばれる。
・ModuleをWasmとして機能させるには、JSでInstace化を行う。
・この際に、それぞれの関数名を import すれば、お互いに関数を呼び出しあうことが可能。
・この場合、文字列や配列の様なものにアクセスし合いたい場合、ポインタ値がJSレベルでは
単なる整数値になるので、それを、Memory と呼ばれる線形メモリーの ArrayBufferの
アドレス値とすることで、可能。 そらそうやろ
何個言語あってプログラマ何人おると思ってるねん TypeScriptで質問なんだけど、全く新しい型を導入する方法ってあるのかな?
構文がわからないから疑似コードで書くけど、
typedef X; // Xという新しい型を定義
function makeX<T> (t T): X { /* ... */ }
// makeXで作られた値以外を渡したらいつもコンパイルエラー
function soSomethingWithX( x: X ) :void { /* ... */ }
こういうことがしたいんだけど… TypeScript は構造的部分型だから無理
type Nekko = {
name: string
age: number
}
type Inu = {
name: string
age: number
}
これらは同じ扱いになる
っていう話?
それとも makeX 以外で X を作れなくしたいという話?
別に X を満たせば、 makeX 以外が X 作ってもよくない?
makeX が作った X と、makeX 以外が作った X が別物なのであれば、
それらは別の型だろう 型の表現力が低くて嫌だねそれ。0以上の数を表す型とか作れないじゃん >>847
erlang かな
むしろ全て機能を並列処理で書くしか無い割り切りというか >>847
スクリプト言語ではないが、GPGPU 用のC言語に似た言語は、そもそも
最初から並列処理を前提にしている。 >>860
プロパティが一致しなければ別の型になるので、
piotrwitek/utility-types の nominal type 使うなどして、自分で識別子を与えればできる
JavaScriptというカオスな言語・膨大な資産を利用するには、仕方ない面もある 並列処理などお前らが書く必要はない。
ライブラリを使え。 erlangtって、堅牢かもしれんが縛りがきつくて決して簡単だとは思えないが。 Objective-C → Swift や Java → Kotlin
と同じ感じで Erlang → Elixir がある >>864
やっぱりPureScriptでAffがナンバーワン! いや文法がどうとかじゃなくて、データを一切共有しないアクターモデル自体がね。 並列処理は、データベース管理システムで結合したマルチプロセスでほとんどの場合十分だろ、って思ってしまう
局所的な高速化だったらライブラリ使えになっちゃうし >>867
JSは自前でWorker使った並列処理書かないと
並列化はされてないんじゃないの? zig/zen/c2にはCの壁は崩せんかなぁ
いい感じではあるけどいい感じから更に上回って採用するほどではないという cの壁崩す前にcの前に散っていった言語の特徴でもまとめておいた方がよっぽど前向きだよ。 UNIXにしろWindowsにしろOSのAPIがCの関数だから
アプリもCで書くのが一番自然になる 正論も何もnativeでABI準拠できればいいのであって
cである必然性はない システムコールだけが言語選択の基準
って思考から脱却しろ
あほらし アセンブリでマウント取る爺様方がだいたい鬼籍に入って次はCでマウント取る爺様方の時代になった感じやね C#からCのAPI呼ぶとき
構造体とか配列のポインタとか面倒だな・・・ Cベースはむしろマシなんだよほとんどの言語でFFIあるし
問題は処理系依存マシマシのC++ベースAPI/ABI >>888
C#のFFIはかなり良い方だろ
C側でラッパーを一切書くことなくC#から呼び出せる
何より、トラブルの元になりがちな変なコードジェネレータの類がなくて、宣言した通りに正しく素直に動くってのが素晴らしい
そのストレスフリーさに比べたら、C#側で関数や構造体の宣言を書き直さなきゃいけないのは余裕で受け入れられる冗長性だと思う 別にcで書けって話でなくて、cのそういう側面くらい常識として知っとけって
だけなのに、なんかコンプレックス刺激されちゃう奴がいるのな。 >>891
C がわかる、てだけでドヤるのも大概だけれども
それよりももっと性質が悪いのは C がわからないコンプをこじらせているやつ 次スレは「次世代言語を夢見るレガシー言語労働者達のマウンティング合戦スレ」に改題で 標準ライブラリが豊富な言語ってC++, Javaとかになるの? Cの非標準ライブラリまとめ言語
と言われたくない人達 .NETも標準ライブラリ豊富だろ
つか、今時スレが言語スレだが言語だけで語る滑稽さ
次世代言語というより、標準ライブラリも含めた次世代環境がほしい 最近の言語はどれも環境そろってるだろ。
適当なインストーラーとライブラリ管理はあるし。
ビルド通らねー糞が!とかもだいぶ減った。 rustはpythonがらみでエラー出てビルド通らなかった。
本気だして調べる気力もなく、関連ファイル削除して男友達と焼肉食いに行った。
わざわざ男友達と書いたのは、女友達なんかいないからだ。 >>905
わざわざどうでもいいつまらないことを書き込むところが女友達のいない原因だろう >>907
rust自身のビルドが、Pythonに依存しているって話じゃない? Pythonはいいぞ
Makefileより読みやすく
Python自身のビルドはLLVMのビルドより10倍か100倍速い 型が無いんじゃなくて型を差別してないのさ
どんな型が来ても受け入れるおおらかさがある 動的な型なだけだな。
ネストした構造をループ処理するときなんかは確かに楽なことも多い。 強い動的型付けだし型アノテーションだいぶ充実してきたしでだいぶマシだと思うけどなぁ
弱い動的型付けと同一視するのは誤りの元だし、漸進的型付けの存在を無視するのもまた評価を誤りかねないですよ Pythonの型アノテーションは実際には全くと言っても差し支えないほど使われていないから無視して問題ない
そろそろ後付け静的型の代表的成功例であるTypeScriptと何が違ったのかを真剣に議論すべき時期にきてる TypeScriptの方が使いやすい型システムしてるのわかる >>902
C#は多いけど標準かって言われるとな・・・
C/C++も「標準」に拘ると何もできないω レス数が900を超えています。1000を超えると表示できなくなるよ。