次世代言語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 Javaerには無理だよ
試しにGoを導入したとしてもやっぱJavaの方がいいやってなって還る 乗り換え
Java、Kotlin、PHP、Ruby、Python → Go
C/C++ → Rust マルチコア主流になってきたし仕事でRust使いたいけど依存フレームワークやらパイプラインがC++まみれなのでたぶん無理だ... マルチスレッドになると rust の利点ほぼなくなるがな
所有権のナニをどうしたところでいつ消えるかも分からなくなり
c++同様arcに頼るのみになる ＞所有権のナニをどうしたところでいつ消えるかも分からなくなり
？
Rustでは競合は起こらないし参照の寿命も保証されるよ AltPythonだかPostPythonはJuliaとかNimじゃねーの？ JuliaとかNimはWEB開発できるほど万能な言語なの？ WEB開発したいと思えない点ではPythonと同じだな Juliaって計算に強いって触れ込みでwebやろうとは思わないな NimはCのほかにJSアウトプットも出来るからwebいける そんな意味不明なもん使うぐらいなら
最初からcかjavascriptで書くわ >>214
typescriptさんディスってんじゃねーぞこら >>221
Dartは、クロスプラットフォームなGUI
フレームワークを引き連れて、息吹き返して来たので怖い。
Flutter/Fuchsiaを気にかけてないやつは、アンテナの感度ひくすぎると思う。 >>220
実はNimが最強ぽいけど、マイナー過ぎて誰も相手にしてくれないね Goってなんで流行ってんの？
機能無くしすぎて100年前の言語みたいになってるじゃんｗ
全然googleぽくないんだけど、
逆に新しいのかな？ GoのGoはGoogleのGoではなくて
SimpleでGoという諺に掛けてるんだよ
公式くらい読めバカが Goって大丈夫なの？
将来、仕事あるなら勉強するけど Goはコンテナと相性良いから流行ってるんではないかな。言語的にはどうなのかわからん。2がきたら色々良くなりそう だからさ、SimpleでGoなんだよ、わからんのか？バカが？ GoがGoogleらしくなかったらDartなんてどうなってしまうんや でもまぁもちろんGoogleとも掛けてるだろうけどね 会議で決められたなら「偶然、GoogleのGoでもあるし、それでいこう」
ってなるのが自然じゃないかｗ Basicだってbeginner's all-purpose symbolic instruction codeだけど別にbasic(基本的な)と掛けてるのを否定してないじゃん つまりSimpleにGoogleだからGoってことね >>229
というより、コンテナを必要としないんだよ
大抵のアプリにおいてコンテナによる抽象化は過剰であり面倒臭いだけ
Goはほとんどのアプリ開発者にとって程良い抽象化とポータビリティを実現している でもさすがにGoは機能絞りすぎてダメ言語だろｗ
アホでも使えるようにしたのかな アスペってダブルミーニングを嫌うよね
意味は１：１じゃなきゃ気が済まないみたいな あのさぁ
俺は初代次世代言語スレからいる重鎮なんだけど
お前らとは格が違うのだが >>238
プログラムは書かれることより読まれることのほうが多いというけど、それ以上に多いのは使われること
TCOの削減を考えるとき、最も重要なのは運用性だ
Goは言語としてはカスだが運用性は確かに優れている goはgoroutineとinterfaceがいいねぇ。それ以外はあまりぱっとしないけど。 メソッドの概念がJavaScriptのprototypeになんとなく似てるよね Flutterの環境構築しただけだけどDartには官能性感じる Goはあのケン・トンプソンがかかわってるところがめちゃくちゃポイントが高い レジェンドがかかわってるからいい言語だとは言い切れないが
ケンが関わったC言語とGO言語がここめでメジャーなのは羨ましい
以前のGoの内部アセンブラはケン・トンプソンが書いたと言う話らしい 権威にひれ伏す典型的糞バカ中世ジャップランド土人
一生アメップのケツ穴でも舐めてな >>238
世の中の大半がアホだから、Goのアプローチは正しいと思うわ 馬鹿には使えないよGoは
結局は自分でなんでも実装しなきゃならなくなるから Goは例外なくしたのに代数的データ型とパターンマッチがないのでエラー処理が地獄 >>252
インターフェイスと型アサーションとswitchしかないから、網羅度も何もない状態だしね。
インターフェイスを後出しできるからだろうけど。 Goのエラー処理が地獄って思ってる人は
例外のパラドックスに陥っている いや実際に地獄って声が大きいから次バージョンでどうにかしようって動きになってるのでは？ >>256
それでも例外よりは幾分マシだと思うけどね
Go2で幾分マシから大分マシになった
例外は大域ジャンプなのでgotoと同じかそれ以上にキツイ
正しく使えば例外も決して悪くはないんだけど
簡単に握りつぶせるからバカが使うとアレほど凶悪なものはない
そして悲しいことに世の中はバカの方が多い
だからバカでも使えるGoが流行ったんだよ
エラーハンドリングに関してはRustのやり方が一番良い errで帰ってくるのはゆるそう。
if err != nil をひたすら書くのはタルい。
タルいだけだけど。 配列のインデックスが範囲外みたいなエラーは例外でもエラー戻り値でも返して欲しくないな
即座に死んでコア吐いてくれていい オートブインデエックスエラーくらいタイペチェックでエラーをディテイクトしてディベロップメントにサブミットアイウォンと >>258
Go2のプロポーザル見たか？
あれはまさに On Error Goto の復活 COBOLならエラーチェックとロギングをこのように簡潔に行える
COMPUTE Z = X / Y
ON SIZE ERROR
DISPLAY “ERROR"
END-COMPUTE >>264
ギャベージライクなスィンタックスだ
ヨウシュドダイ 適当にまとめてみた
カテゴライズも含めて異論とかあったらよろしく
ホビー言語
HSP
殿堂入り言語(普遍的)
C、アセンブラ
時代追従言語(ポジションは普遍的だが言語仕様が今後も大幅に更新されそう)
C++、C#、JavaScript、PHP
衰退言語(減少傾向)
Java、COBOL、Ruby、Swift(クロス開発主流化のため)
オワコン言語
VB、Objective-C、Perl
始まらなかった言語
D、Delphi
今流行りの言語(増加傾向)
Go、Kotlin、TypeScript、Python
次世代言語(まだ一般では流行ってないし流行らないかも知れない)
Rust、Nim、Dart、Julia >>263
流し読みだけど見たよ
VBA&VB6のOn Error Gotoとは全然別物だろ
Go2のhandle&checkはdeferに近い感じで悪くないものだと思うけど(特別良くもないけど)
マジメには読んでないし、他言語のエラーハンドリング手法のどれとも
あまり似てないからどこかに落とし穴がありそうで不安ではあるが…
例えば、defer文の中でcheckキーワードを使用するとどうなるのか？とか
戻り値の最後がerror型じゃない関数に対してcheckキーワードを使用した場合はどうなるのか？とか
コンパイルエラー？それとも最後の型がerror型じゃなくてもhandleでキャッチ出来ちゃう？後者なら嫌だな 実際いくつ言語覚えりゃ良いんだろうな
経験言語とか答えるのバカらしくなってきた WebAssemblyってこれからぼちぼち開発ターゲットになってくるんかな C/C++、C#、Java、PHP、Ruby、Python
ここまではできて当たり前
当然使えるのを前提にされてる このスレを見てる様な言語マニアならあとGoとRustが必須かな？ってくらいじゃない？ 最低（必要）でもｺﾚぐらいは
読んだり書いたりできないといけない
必要 → c/c++、sql、shell script（sed、awk等でのｺﾏﾝﾄﾞﾗｲﾝによる編集含む）、javascript
pascal（擬似ｺｰﾄﾞを読んだり書いたりするために必要）、
BNF（文書を読んだり書いたりするために必要）
html、css
なおよし → java、c#、fortran、algol、lisp
ｵﾌﾟｼｮﾅﾙ → python、cobol、perl、vb、php、ruby （右へいくほど不要でどうでもいい） SQLが使えるっていうのにも結構個人によって格差あるよね PHP7を現代的な書き方で使えればまあいいんじゃないの 40代クラスのSQL使えますおじさんのSQLはマジで害悪
いっそ消えてほしい >>280
元の仕様が糞なのに
利用者増やすために理念もなく継ぎ足しパクった糞仕様の糞糞アン糞の山
今さら糞ペチパーが型安全とか語ってて糞が出る サブクエリとかJOINとかEXISTSとかCASE WHENとか使えない人がORMなんていう害悪を生み出したんだろうなってのはたまに思う >>285
おっ 糞バカデカSQLでキャストしまくりおじさんか？
そのスロークエリまた若手に笑われてたぞ いやいや対象のテーブル持ってきてプログラム内でマッチングするよりもINNER JOINでマッチングして絞り込んでから持ってきた方が遥かにコスト下がるからさ
あとEXISTSとか使った事ない？ 知恵遅れは実行計画の見方も分からないからな
ﾒｸﾗで巨大なSQL書く ORMをバカにして良いのは全部ストアドプロシージャで頑張るマンだけだぞ。いいな？ 複雑さの方向性による
SQLを駆使して複雑なリレーションをスマートに処理できる人は尊敬する
迷惑なSQLおじさんは帳票や画面項目とDBのマッピングをSQLで済ませようとしてCASEだらけの壮大な糞を垂れるんだよ c++ は utf-8、utf-16、utf-32 のユニコードリテラルと
対応するキャラクタ型が仕様に追加されたのが地味に便利 SQLが得意ですおじさんって、だいたい全てのSQLアンチパターンを踏み抜いてく
死んでくれねえかな >>289
今時ストアドなんて使うの？
あんなの製作者本人しか読めないようなのばっかりだから後の保守を考えるなら使わない方がいい
>>290
ケース文の結果を出力に使おうとは思わんけどORDER BYとかGROUP BYの対象にするときはあるな ORMってJOINできるんじゃないの
entity framework は普通にできる >>295
EntityFrameworkのJOINっていまだに慣れないんだよなあ ORM使ってJOIN使わずN+1問題仕込むのは百歩譲って良いとしても、
トランザクションやロックが意識できてなくて一貫性崩れてる不具合見つけたときは
ORMは害悪！ってなった ORMとQueryBuilderの区別もつかんアホども >>297
こういうガイジがSQLわかってる俺ケッケーしてるかと思うと笑える
殺してやるから表でろよ F#に入門してみたけどクソ使いやすいなこれ
関数型らしさと実用性を極めて高いレベルで両立してる
記述を大胆に省略できるのに、類推を阻害するような理不尽なシンタックスエラーに遭遇することもない
Scalaが生きてた頃はライバル扱いされてたようだが、あんなもんF#に比べたらはっきり言って便所の落書き以下
リリース後の紆余曲折なしにこのレベルをいきなり世に出せるって、設計した奴頭良すぎで恐怖すら覚える ORMは低学歴知恵遅れの底辺ﾄﾞｶﾀ用か
このｽﾚみててよくわかったわ ■ このスレッドは過去ログ倉庫に格納されています
