次世代言語14 Go Rust Swift Kotlin TypeScript
■ このスレッドは過去ログ倉庫に格納されています
スレタイ以外の言語もok
前スレ
次世代言語13 Go Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1534769753/
>>1の1行目に記入
!extend:on:vvvvv:1000:512
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured Haskellにもある
ただし他の数値系型との整合性がいまいちで
ちょっと気持ち悪い感じになってる Squeak Smalltalkみたいなオモチャにもある GoとかRustで入門書的な内容を終えたら
その次って何から手を付けるべきなのかな Rails使ってた人達って今なに使ってるの？
上位互換がありそうで無くね >>105
2年前までrails使ってたけど今じゃgoでマイクロサービスだよ ライブラリにあったって自慢にならんだろう
複素数のようなあまり使わないものを組み込み型で持っている変態だから自慢になるわけで >>105
Rails使ってた人達は
Rails使ってた人達が作った型無し保守性最低のゴミの保守してるよ Goが出た時から、それまでll言語しか使ってなかったような奴らが、型付最高！Go最強！とか言い出したの相当面白い流れだったわ 気付けたんならそれはそれでもうよくない？と思う静的型穏健派 >>107
演算子オーバーロードがないから複素数を組み込みにせざるを得なかったのでは >>113
HackってPHPを静的にしたやつだよね、スピード何も変わらないんだねｗ
てっきり速くなるのかと思ってた なんかGoとRustの速度比較見てるとやたらNimってのが出てくるんだけど
これそんなに流行ってたの？ ウンコにカレー掛けたところで
カレーにはならんだろう
そういうこと >>111
その昔、ライブラリよりも組み込み型の方が良いといううぉるたんの有名な議論があって
http://www.kmonos.net/alang/d/builtin.html
昔はこのへんで複素数も含めて熱弁されてた
今のD言語はメタプログラミングが強力なんで複素数もライブラリ実装に変わったけれども >>118
この前DでComplex型使ってコンパイルしてみたら警告出たのってそういう事だったのか >>117
でもカレーにウンコ掛けると
ウンコになるよね！ Rubyは頑張って言語自体を速くしようとしてて好感が持てるけど
元がウンコすぎて焼け石に水なのが切ない
ボトルネックだけCで書く方が実用的というね >>120
つまりPHPはウンコってこと
自明だね PHPもRubyもうんこなら、
今はもうWEBのバックエンド開発ってNodejs一択なの？ >>123
大変嘆かわしい事だが現在Web上に存在しているサイトの大半はWordPressで作られてると聞いた >>123
新規開発ならありだろうけど、日本の多くの現場は既存のやつの改修でしょう。 >>126
Kotlinってやっぱデプロイする時はTomcatで回すもんなの？ >>123
糞バカ中世ジャップランド土人村のイット産業はウンコ垂れ流しのゲェジしかおらんからね
悲しいね たまに金扱うシステムでもペチプー使ってるウンコ臭いウンコ企業がおって
草生えるで
さすジャ >>133
つまりスマホ太郎とデスマ次郎ぐらいの違いか luaはそのまんま使うもんじゃないからな
ｳﾝｺｽｸﾘﾌﾟﾄ使いには使いこなせない
まずそこの認識にｽﾞﾚがあるﾜｹ 肝心のレスがあぼーんされてるが、LuaとKotlinどっちが良いか的なのかな。
お互いの良いところをパクリ合うからどれも似たり寄ったりだよ。
だから一つ覚えればどれでも使えるわけだが。
興味がある方から覚えて、限界感じたら移ればいい。
関数型や論理型は尖り過ぎて後続が少ないが、やってみて発想だけは得る物がある。
新言語の取り込む先は大体そう言う言語が元。 そう言う意味じゃRoRみたいな妄信的な先駆者がいないと広がらない。
俺自身はプログラマー諦めた口だから、お前がやれは無しね。 KotlinはAndroidあるからそこそこ広まってはいるんじゃない？ 選ばれた高貴なる民が有意義な議論をするスレだぞ
不適合者の蛆虫がレスするなゴミ Javaに載せたら金取る言われたMSがC#広めたって前例もあるし、後ろ盾が大きいのも確か。
後ろ盾が無いなら、信者の熱意次第。 luaはご飯とみそ汁
おかずは自分で作らないといけない
そこんとこをわかってないﾜｹ
食べきれないおかずをひたすら盛るのが
ｳﾝｺｽｸﾘﾌﾟﾄ
ｳﾝｺｽｸﾘﾌﾟﾄ使いがこのおかずがほしいといったら
ひたすらｳﾝｺｽｸﾘﾌﾟﾄにおかずが盛られていく
つまり、減ることはない、増える一方 スクリプトって、元々そんなもんだろ。
TwitterもFacebookも、元はスクリプトで組んで、大きくなったらコンパイラ言語に移行したし。
試作品とか小規模とか。 なんかLinuxの板にもやたら食べ物で例えるヤツ居たなぁ
そいつのカタカナは半角じゃなかったから多分別人なんだろうけど >>144
Facebookは今でもPHPじゃないの？？ Githubでさえ未だにRoR使ってるというのにFacebookときたら そら世界中のソフトウェア開発の根幹を支えるGitHubとは違って、便所の落書きやチラシが少々バグったところで何の問題もないからな
GitHubを今更全部作り直すのは事実上不可能だと思うよ なんかさ最近なんだかんだでJSが最強言語に思えてくる
TSも含めて c,javascript見てると最初はゆるく作っておけば
あとあと固くする様なツールなりトランスパイラなり出てくるってのはあるな。 Pythonでマルチタスク書こうとしてえらい目に遭った 作るよりメンテ運用のが長いんだよね
インタプリタ言語でプロトタイプ作るのは良いけど
早い目にコンパイラ言語にに寄せるべきかなと >>157
確かブラウザ上でPCのエミュレートしてそこでLinux動かしてるサイトがあったので、それが近いかな。 >>156
そう言われてみると流行りの llvm より c のコード吐く方が
既存ライブラリとのバインディング等いろんな面で楽な気がしてきた
yacc/lex みたいな Cへのトランスパイルは昔から良くあるけどやっぱり不十分なんじゃないの？ 例えば例外処理のフレームの生成なんかでは困るな
C++例外にトランスパイルしたらC++ランタイムを必要とするようになるし
longjmpでごまかして気にしないならいいけど
後はスタックや呼び出し規約関係で変なことしたい時もC言語の記述力を超えられないので困る なるほど
c じゃ call / ret その他スタック操作がコーディングできないか まずC++を使うからといって
例外処理を使わないといけないというｷﾏﾘなんかないからな
例外処理はｴﾗｰ処理をまともに書かないようなﾔﾂが
ｴﾗｰ処理を入れた気になれるというｼﾛﾓﾉだからな >スタックや呼び出し規約関係で変なことしたい時
こんなのアセンブラ埋め込む以外できんだろ。
てか普通の言語ではしないし、やったら関数の接合呼び出しのたびに気にしなきゃならなくなる。 GHCは変態呼び出しをC--使ってやってたしLLVMにも専用の呼び出し規約を実装させたぞ？ システムコールは本質的に参照透過でないためHaskellにおいては恥だろ
ドヤ顔で下劣な犯罪行為を自慢するなカス どこにシステムコールの話があるんだ
ほんと誰も言ってないことを空目して罵る馬鹿が増えたなあ >>170
llvm じゃなく c へのトランスパイルのが良いのでは？
いやそれじゃ例外等を実装しにくいね、という話をしているだけだろう。
でもまあ頑張れば setjump / longjump で実装できるのか？
誤魔化すんじゃなくwinding するコードをcで正しく吐けばいいだけだし まあhaskellの場合はそもそも再帰呼び出ししなきゃloopできないんだから
そりゃstackに細工は必要だろうが。。そりゃ逆に言語の欠陥のためだ。 >>176
tail callだけなら呼び出し規約弄る必要もないぞ。もっと別のことやってる
思い込みでわけわからんこと言う前に調べろ >>177
じゃhaskellでスタックいじくる理由ってなんかあるのか？
linux kernelだったり作るならわからんでもないが(実際gccの拡張命令バリバリ使っとる)
haskellでそれやる理由は？ 教えてクンの相手するスレじゃないぞ
とりあえず ttps://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/CallingConvention 見て
後は勝手に調べろ Goが一番将来性あると思う。
KotlinはJava離れとandroidがGo採用して消える
Swiftはiosだけで残る
Rustは一部のマニア向けに残る
GoはC/C++後継、
サーバ、クライアント、スマホ
あらゆる環境、分野ををカバーして残る
妄想です RustならともかくGoをC/C++の後継っていうのはムリムリ 学習コストとコンパイラの負担を無視して実行性能と多機能性を突き詰めるC++を
実行性能と機能を犠牲にして学習コストとコンパイラの負担を下げた真逆の思想持ったGoで代替できると思う理由が謎 >>179
実用的用途はないという現実を認められない人って哀れだね。 >>180-181
GoはC/C++じゃなくて明確にCに絞ってみるべきなんじゃないかとね 現実問題PythonどころかRubyでさえカバーできてないじゃんGo
RoRの上位互換さっさと作って >>188
組み込みとかリソース限られた環境での使用に堪えないC代替言語とかもっと無理 >>189
上位互換だと下位を完全に含まなきゃいかんのじゃないか Goが人気出て来たのはイメージサイズ的にコンテナと相性いいからと思ってるわ >>193
goがコンテナと相性いいのは、prebuiltなバイナリを突っ込めばコンテナだろうがベアメタルだろうがだいたいそのまま動くという点が大きい
そもそもそのためのコンテナじゃなかったのかという話ではあるが、
Linux丸ごとスタティックリンクしちゃえばポータブルだぜ！という、
イメージのビルドやメンテのコストを無視したインフラエンジニアの妄想オナニーに対する本質的でないワークアラウンドである goは言語的思想には似たようなのがないけど
業務でつかうjavaの乗り換え対象の第一候補にしてもいいと思う 他の言語は仕様がリッチなのでやろうと思えば平気でおかしなことが出来てしまう
データ＋アルゴリズム以外のことをやりすぎ ■ このスレッドは過去ログ倉庫に格納されています
