次世代言語議論スレ[Go Rust Scala Haskell]第5世代 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
いざ、語ろうぞ。
スレタイ超過のため、一部省略。
その他もウェルカム。
前スレ
次世代言語議論スレ[Go Rust Kotlin Scala]第4世代
http://mevius.2ch.net/test/read.cgi/tech/1492631007/ .net coreはまだプロダクションで使うのは怖いだろ
仮にそこ乗り越えたとしても、C#だと結局開発はVS最強なんだから窓開発になる >>711
もう1年以上経つし、そろそろ.NET Standard2.0も出るこの時期に何言ってんだか
素直に知りませんでしたでいいよ 見事にオープンソースとクラウドの時代を代表するリーダーの一人として転身を果たしたMS
存在感を失い続けるIBMとオラクル
そう考えるとJavaは疫病神なのではないか >>715
Fullの.NET FrameworkやMono、.NET Coreがそれぞれ実装すべきAPIを定めたもの >>716
こないだのPaketの件といい、.NET CoreからFullの.NET Frameworkの一方的な切り捨てと言い、コミュニティをないがしろにしてちょいちょい炎上してるけどな こういう妄信タイプがいるから
環境依存言語は嫌なんだよ。 今じゃもう.NETを忌避するほうが逆に宗教みたいになってるよな .NETはまだまだ環境の問題もあるからともかく、
MSだからという理由でMSのプロダクトが開発者に嫌われることは少なくなったね
マカーがMS製のエディタでMS製の言語でプログラミングしてそれをMSのクラウドプラットフォーム上でホストされてるLinuxへデプロイするとか 一昔前ならあり得ない未来だった Monoで動いているものは結構色々あるはず
例えば3DGameEngineのUnityはC#で開発できるけど裏でMonoが動いてる
マルチプラットフォームな開発環境であるXamarinもMonoを使ってる。
知らないうちに.Netは大半のプラットフォームで動くように。 完全マカー依存のスーウィフトはどうなりましたか(小声) .NETはLLVMつかってネイティブ化する計画なかったのか 実際のところ.Netを選ぶメリットって何かあるのかな?
マルチプラットフォームならtypescriptとelectron、もしくはreact nativeで良い気がするけど。 現行、LLVMの使用はLinux、Macのみらしいが原理としてLLVMが動くすべてのOSでネイティブコンパイルできるのでは?
実際動かしてないし間違えてるかも。
性能を強化した「.NET Core 1.1」が公開 2016年11月21日
米Microsoftは11月16日、「.NET Core 1.1」を公開した。性能が強化されたほか、対応するLinuxディストリビューションも拡大した。
最新版では対応するディストリビューションを拡大し、Linux Mint 18、OpenSUSE 42.1、macOS 10.12、Windows Server 2016で利用できるようになった。
macOS 10.12とWindows Server 2016については、.NET Core 1.0も利用できる。
Linux向け、Mac向けでは、CoreCLRをClang/LLVMでコンパイルするため、次のリリースでClang版のPGOをサポートする予定としている。
https://mag.osdn.jp/16/11/21/154500 まあ実際使ってみると右往左往することになるわけだが。
「互換性」あるってセールストークに馬鹿みたいに引っかかりすぎなんだよ。 >>728
それは環境によるだろ…
すぐ一纏めに考えるのは愚かな事 こういう流れらしい。
.NET Coreとは? 2017年6月6日
.NET Coreがリリースされて約1年経ち、ようやくビルドツールも正式版としてリリースされるに至った。
本連載記事では、「Linuxを中心にクロスプラットフォームで開発できる.NET Core」という視点で、開発の方法を説明していきたい。
.NET Coreの歴史
Windows上でのみ動作する.NET Frameworkは、2002年に最初に登場して以来、バージョンアップを重ねてきた。
それに対し、Windows・Linux・macOSで動作するクロスプラットフォームな.NET Coreが発表されたのが、2014年11月12日のことである。
このとき、今までWindowsのみをサポート対象としてきた.NETが、LinuxやmacOSもサポート対象としたことに加えて、最初からGitHubでオープンソースとして公開されたことにも驚きがあった。
クロスプラットフォームを動作環境とすることに関しては、Monoプロジェクトという先人がいた。
Monoプロジェクトは.NET Frameworkの互換環境をLinuxやmacOSを含めたスマートフォンOSにすることを目標としており、その中にはGUIフレームワークも含まれている。
Monoプロジェクトは現在、Xamarin社が開発・サポートをしており、スマートフォン向けのクロスプラットフォーム開発環境であるXamarinブランドの製品を提供している。
そのXamarin社が、2016年にMicrosoft社に買収されて今に至っている。
Monoが.NET Frameworkそのものと互換性のある環境を目指していることに対し、.NET Coreは.NET Frameworkのサブセットとなる機能をクロスプラットフォームで提供することを目標としたわけである。
そして、.NET Coreの発表から約1年後の2015年11月5日にRed Hat社がMicrosoft社と協力し、Red Hat Enterprise Linux上での.NETのサポートを発表した。
.NET Coreの特徴はいくつか挙げられるが、ここでは特に「クロスプラットフォーム」「オープンソース」「軽量」「フレキシブル」の4点について強調したい。
http://www.buildinsider.net/language/dotnetcore/01 南シナ海に中国が基地作ってるよね。
だいたいそんな感想 >>728
Javaも同じだけどね。
お陰で一度書けばどこでも動くって宣伝文句も、一度書けばどこでもテストが必要って揶揄されて久しい。
HTMLも然り。
実はHTML5+JavaScriptのが動的言語な分タチが悪いっていう。
>>726
TypeScriptもMS製ですよ。
VS Code出したし、.net Standerd出たしってなると、VC#のマルチプラットフォーム化が始まりそうな予感はするが。
(MonoでC#のマルチプラットフォーム化はしてるけど、C#の良さはやはりIDEであるVSあってこそ) typescriptがMs製なのは知ってるよ。
そして素晴らしいのはtsserverを同梱してること。
言語自体にリファクタリングや定義箇所への参照機能等ideに必要な機能を同梱させたんだよね。
この仕様をlanguage server protocolとして標準化しようとしてるのも素晴しい。
ide側で言語仕様を把握する必要がなくなり、上記のプロトコルを解釈する機構を用意しておけばいい。 ぜひともlanguage server protocolを言語側で用意するのを必須にしてほしい。
新興言語ほど補完機能が弱いことが多いから。goの補完が効くようになったのもここ二年くらいからだったし。 マルチプラットフォームの夢も分かるけど、現実的じゃないんだよね。。。
一個のOSでさえバージョン違いで互換性崩れるのに、それを複数とか。
現実的にはテストの都合でプラットフォームもバージョンもグッと絞らないと死ねる。 MSはLinuxの技術者が食いついてきたらLinuxがクソになってきたので独自拡張LinuxまたはWindowsのみのサポートにしますって言って利益をあげるんだろ
知ってるんだから >>730
これアレじゃね?
競合しそうな会社を買って手中におさめて
コントロールするか飼い殺しにするかっていう
いつものMSじゃね?
少なくとも
>Monoプロジェクトは.NET Frameworkの互換環境をLinuxやmacOSを含めたスマートフォンOSにすることを目標としており、
>その中にはGUIフレームワークも含まれている。
の部分はもはや怪しいというか
.NET Coreで行きたいんでしょ?MSは linuxでVS使わせてくれればマルチプラットフォームなんてどうでもいい 次世代言語ってなんなんだ?
Cの次世代言語がC++だと言われれば納得できる
c++の次世代言語がjavaだと言われればちょっと首を傾げながら納得する
javaやc#などの次世代言語が Go Rust Scala Haskellだと言われたら
全く納得できない そりゃそうだ
次世代というなら、シェアをひっくり返すかトントンぐらいまで行かないと
次世代とは言えない
というか、そういう状況にならないと
業界が何となく全体的に次世代に移った、とは言えない
なら次世代とは何なんだ、「世代」とは何なんだ
来もしないであろう架空の未来のことを
「次世代」と言っても仕方がないではないか
C++の次世代という触れ込みだったD言語は言語仕様的にはそうかもしれないが
全然普及しなかったからC++の次世代だ!っつってもふ〜んって感じだし
そんな「世代」は来なかった、って感じ 結局はJava、C#、C++などの現世代の王道言語が順当にバージョンアップして
移行が行われたら、その地点が「次世代」って事になる 互換性のためだけのレガシー構文が積み重なるわ不自然な拡張方法になるわ
で最終的にperl5みたいな「これでなければなんでもいい」になるんですね? 構造化プログラミング -> オブジェクト指向 って進化は基本的に
制約をきつくしていく傾向だよね
だから次世代はもっときつくなる。
多分参照型の消滅が次世代の考え方になるのかなと思う。
次世代っていうか関数型の話だけど。
参照型って結局ポインタ型つまり機械語にかなりよった概念だと思う。
これのせいで値の比較とかが難しくなる
インスタンスの内容が同じなのに == で評価したら不一致。みたいな。
参照型って結局メモリ節約のシンプルな解決方法にすぎない。
Immutable.jsとかみてると内部構造をメモリ節約できる仕組みにして隠蔽するとこで表向きは値型にしてる。こういうことができるんだから全部値型で構わない。 >>745
perlは役に立つぞ
役に立つという条件さえクリアすればなんでもいいという単純な時代もあったんだろう
今は役に立つだけでは不自然と判明したから更に複雑な条件が追加されていくだろう 俺はもうscript系の言語はbashとpythonでいいわ。 >>745
そこである程度整理したら perl6 になったんだけども・・・ シェルスクリプト系はカーネルにフリーライドしているくせに
そのことを全く気に病む様子がない
Java系は自己完結とかOSを作りたいとか自分自身をコンパイルしたいとか煩悩が多い 未だにペェ〜ルとかいう真性糞ゴミをひり出してる糞製造器は死ね
死ね >>750
いろんなものに手を広げずにシンプルな仕様だけを用意していた方が
結局互換性が高いってことだね。 Mono(.NET)と、.NET Coreの用途の違いは、すでに100%.NET環境が移植できていれば.NET Coreの出番はないはずだが。
そうではない環境では、その環境を構築なしに移植できるってことか。
C#のコードをLLVMのアセンブラに翻訳したらあとは既存LLVMに丸投げできるから、移植コストは低く共通化できる。 \______ _______________________/
○
O モワモワ
o
∧_∧! ハッ! / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
___( ゜∀゜)_ < という夢を見たんだ
| 〃( つ つ | \________
|\ ⌒⌒⌒⌒⌒⌒\
| \^ ⌒ ⌒ \
\ |⌒⌒⌒⌒⌒⌒|
\ |.________| >>754
.NET CoreはCLR自体をアプリに同梱するように作られていて、AOTコンパイルではない
LLVM対応もJITをLLVMで実装しようというものに過ぎず、あくまでコンパイルはJIT
Coreは基本的にWebサーバー用だから少々起動に時間がかかろうが全く問題にならない こんなのでてきた
Microsoft、C++技術で.NET Core 2の高速化実現 [2017/07/22]
Microsoftは7月20日(米国時間)、.NET Core 2.0で採用されている高速化技術「PGO (Profile-Guided Optimization )」について伝えた。
この技術はC++コンパイラでより最適化されたコードを生成するために使われているネイティブコンパイラ技術。
.NET Core 2.0にも同様の技術が適用されており、すべてのユーザは特定の処理をすることなくこの高速化技術の恩恵を受けていると説明している。
http://n.mynv.jp/news/2017/07/22/096/images/001l.jpg
http://n.mynv.jp/news/2017/07/22/096/images/002l.jpg
http://news.mynavi.jp/news/2017/07/22/096/
Microsoft、LLVMベースの.NET/CoreCLRコンパイラLLILCを発表
2015年5月6日
.NET FoundationがLLILCという新しいプロジェクトのリリースを発表した。
このプロジェクトはもともとMicrosoftによるもので、.NET Coreのための新しいLLVMベースのネイティブコードコンパイラを提供することを目的としている。
これによって「CoreCLRが移植されていてLLVMがターゲットとしているプラットフォーム上で」.NETプログラムを動かせるようになる。
LLILCのロードマップによると、Install-Time JITコンパイラが次のターゲットだ。「これは生成されたコードを、
1つのアプリケーションの複数の呼び出しの間で、または1つのアセンブリセットを共有する複数のプロセスの間で共有できるようにする」。LLILCプロジェクトでは、Ahead-Of-Timeコンパイラの実装も検討している。
https://www.infoq.com/jp/news/2015/05/microsoft-llilc-llvm-compiler >>742
世間で言われてる分類で言えば全部第3世代言語だからな
他でドヤ顔で言ったら恥ずかしいぞ >>742
世間で言われてる分類で言えば全部第3世代言語だからな
他でドヤ顔で言ったら恥ずかしいぞ
第4世代はユーザが使う言語
JavaはC++--って言われるくらいで先進性よりも普及を重視してたんだろ
今はもう滅茶苦茶だが
でC++++でC#と 次世代はサービスインテグレーションのための超高レベル言語だろうな
ドメインスペシャリストと開発者の間の垣根を無くすことと、強力なサービス連携がポイントだと思う >>759
そういう意味不明などやりかたされてもwwww
このスレでは誰もそんなくくりの話はしてない
第四世代言語(4GL)がなぜ次世代なんだかわからん
4GL
https://ja.wikipedia.org/wiki/4GL
SQL、R言語、RPG-IIの話なんて誰もしてない でもまぁ方向性としてはありかと。
結局プログラミング言語ってツールなわけだから
何かに特化したほうが仕事はやりやすくなる。
DB設計したらwebAPIの定義と処理が自動実装されるようなDSLとか欲しい。
golangのgoaとかAPI設計からGoのコードを自動設定するから近いっちゃ近いけど
DB周りとの連携はまだイマイチかなと。 >>761
一般的な意味でないから個人で勝手に決める以外ないだろって意味なんだが
難しかったか 自動でコード出力する系は嫌い
改造するの面倒だし
マクロみたいなのが好き Excelからコードを自動生成するPHPのプロジェクトがあったなそういえば コード生成系は出力先が機械だから手加減しない感じがあるからね。。 でもgoaは割ときれいなコード書いてくれるから、結構勉強になるし、生成ファイルとは別ファイルにして動作をカスタマイズする前提だから、
マクロとそんなに変わらないと思う。
マクロよりマジック感が減るから処理を追いやすいし コード出力ってそのあと追記とかするの?
戻れなくないか
いっそバイナリ吐いてくれた方がよくないか 糞バカペチプァにそんな知能あるわけないだろ
やつら、次に食べる飯と寝ることくらいしか頭に入らない小頭症のガイジだからね >>768
根本的に一から勉強し直したほうがいいぞ
>>769
追記どころかバージョン管理からも外すよね普通 >>769
それじゃ混ぜて最適化できないし
APIの公開非公開の制御もできないじゃん
そらGPLとか仕事じゃないなら関係ないかもしれないけどさあ >>771
いや流石にソースか出力どっちかはバージョン管理に入れるだろ
CIしてたらコンパイル通らなくなる まあいろいろな環境でも動かしたいとかいう理由で出力したソースを
コミットすることもあるけど、あんまりいいことないよ。。おすすめしない。 >>769
もちろん生成コードとは別ファイルにカスタマイズコードを書くよ。
だからgitの管理対象外にするのが普通。
ただ、俺はあえて管理対象にしてるけどね。設計変更したときに自動生成コードがどんな変更をしたかわかりやすい。
マクロ系だとこういう部分が隠蔽されてると考えることができる。
デコレータとかもそうだよね。
goはジェネリクスとかマクロがない代わりにコード生成を推奨してる言語と言えるね。
最初は後退した言語だと思ったけど
コード生成と衝突しない書き方ができるから、マクロとかで裏でどういうコードが生成されているかを把握できる言語と考えれば悪くないなと感じてる。 phpバカにしまくる奴が疑問。
言語としてはまあボロボロだけどnginxとphp-fpmより安定したサーバ書けるの?って聞くと黙ったり、
過去、ひどいコード書いたとか、ひどいコードの保守したとしか考えられん。 nginxとphp-fpmより安定したサーバ書けるの?という質問が意味不明で黙るしかないよw 実用に耐えてないじゃん?みたいな話。
Goのサーバも見たことあるし、ErlangもElixirもあるけど、ずーっと誰かが推してるウェブベースのアプリって見たことねえなあ、ってのが
>>770を見て>>776を書いた所以。
脈絡ないのは認める。すまん。 >>781
その辺はAPIやワーカーの実装に使用されるケースがほとんどだろ
PHPとは競合しない >>782
そうでもないよ。普通にいわゆるSSIみたいな形で動的なコンテンツ差し込むサーバも見たことあるし、
逆にPHPでも1ファイル1機能のAPIサーバと静的htmlの組み合わせも見たことある。
後者とは競合すると思うんだが。 nginxが実用に耐えない…?
普通につかってるが… 前スレ
918 :あ :2017/05/31(水) 11:10:55.99 ID:dc+IbjjD
>>916
子供作るときに一通りそういう気質があるか調べてもらったが、幸いながらアスペではなかったぞ。
残念ながら多動はあった。 >>784
逆。nginxやphp-fpmは信用に足りるが、
個別にウェブサーバ立てるような言語は結局nginxやらtraefikやらのバックエンドに立てんじゃん?みたいな話。
>>786
だから何なんだ…(笑)
それをもってしてもちゃんと働いとるぞ。役職付きで。 まるでphpなら、それらがいらないかのような口ぶり >>790
リバースプロキシは要るだろうが、その裏に立てるのもphp-fpmなりなんなりの、それなりに枯れたもので、スクラッチせんで良いでしょ。 他の言語が優れてるのも認めるし、phpがポンコツなのも認めるが、
それ以上に自分で書いたサーバはあてにならん。 そりゃ君がPHPなんか使ってるからだろう
スクラッチといったって既存のライブラリを使うわけだし、
そのライブラリがnginxに比べて枯れてないことが大きな問題になるほどHTTPサーバーなんて高度なもんじゃないぞ? あと、今時は静的コンテンツの配信やパスベースのルーティング、SSLなど
Webサーバーの多くの機能をクラウドプラットフォームに任せてしまうから、アプリから独立したWebサーバーの必要性は低下している
もちろんガイジの主張においてnginxがクラウドプラットフォームに置き換わっただけであることは認めるけどね まあPHPを安易にバカにする奴はエアプログラマだとは思うわ
使われてるだけあって書いてくれって言われることあるし、
書いてみりゃわかるが小規模なら生産性高いからな実際
Wordpressカスタムで済ませられる案件も多いし >>793
俺自身はphpを使うことがある、くらいよ。
既存のライブラリなんて余計に使えないだろ。いろんな意味で。
>>794
それはわかる。GAE/goをタダで使ってる身としては効率的だし、インフラのコストや安定性は桁違い。 >>796
GAE/goってそんなに使うの。
DBが独自になるのが気になるんだが phpは人口が多くて趣味やデザイナから来た奴が多いのかレベルが低い
他の言語知らないって奴もよくいる
なのでphpの仕事はあまりしたくない >>798
なるほど。そういう考えもあるのか。
Goだったら少なくともプログラマーになりたい人が使ってる感じかな。 仕事でGoつかえって言われたら苦痛だな
もっと自由にさせてくれって思う >>797
めっちゃ安い。めっちゃ早い。
永続化考えたら少しめんどくさいから、リクエストに対して即結果が出せるようなものを数珠つなぎにして出せるようなものにしてるよ。
>>798
それはよくあるな。
あと、外注が海外に投げるとホントにひどいのが出てきたりする。 >>798の文脈でいうならGoの仕事は悪くないと思うけどな
少なくとも秀丸で書いてFFFTPでデプロイするような奴はその職場にはいないだろう >>802
すごいな2003年辺りで時間が止まってそう。 typescriptをメインに据えてる会社とかないかな。
正直typescriptであればサーバサイドjsもありな気がする。 >>801
> 永続化考えたら少しめんどくさいから、
> リクエストに対して即結果が出せるようなものを数珠つなぎにして出せるようなものにしてるよ。
もう少し具体的に話せない?。web+dbみたいな用途では使ってないってこと? まあ go は書いててつまらんからって理由で却下されたことがある職場の話は
聞いたことあるな。
面白くても糞品質だったら無意味だとは思うがな。 >>806
goってつまんないかな。
俺は最初にハマったときはシンプルな構文に抑えようという心意気に感動したけどな。
例えばclassとstruct。コレってどっちかでいいよなってずっと思ってて
goはstructに絞ってくれて、コレだっ!って思った。
後構文規約問題とか。コレって最新の言語rustとかswiftとか全然気にしてないけど
goはちゃんと解決してるんだよなぁ。
あとgoroutineとか。スレッドモデルの操作ってPHPでやろうとすると凄くめんどくさくて最初にgoに触ったきっかけになった ■ このスレッドは過去ログ倉庫に格納されています