次世代言語12 Go Rust Swift Kotlin TypeScript
レス数が950を超えています。1000を超えると書き込みができなくなります。
スレタイ以外の言語もok
前スレ
次世代言語11[Rust Swift TypeScript Dart]
https://mevius.5ch.net/test/read.cgi/tech/1528037607/ chapelを誰かレビューしてください。気になってるけど試してないんだ >>848
アロケータを変えたいという意味で聞いてるのなら一応可能だったはず。
「一応」っていうのは確かNightly(不安定版)だったはずってのと
使ったこと無いから正直俺もよく分かってないって意味。
因みにデフォルトのアロケータはjemallocだよ。 >>840
最初から漸進的型付とかバカちゃうか
型無し糞言語だからしょうがなく漸進的型付と型推論入れて糞をごまかしてるのに
最初から糞丸出しの糞とか糞以外の何糞なんだ? UNKOLANGwwwwwwwwwwwwwwwwwwwwwwwwwwww
バカじゃねwwwwwwwwwwwwwwwwwwバーカバカwwwwwwwwwwwwwwww 型無しを見下すのも選民思想のようなものだな
HaskellやRustはこいつの手口に学んだのだろう でも型のない言語で作られたプロジェクトの9割がゴミだったわ
PHP 5系とかほんと酷かった サーバーがゴミ
スマホを見習うべき
修理するより10割捨てて買い換えろ 最初は型ありで、動的言語台頭してきて、
それがまた型ありのほうが良いってなった。
繰り返してるのかな?
また、将来動的言語の方が良いってならないか? 動的と静的が合体したのがあればいいんだがな(´・ω・`) 型推論が進化するとむしろ人間が下手に型を書くと推論の邪魔になるから最小限しか書かなくなるようになる >>860
動的型付け+型ヒンティングがそれだろう。TypeScriptが理想に近いと思う。 >>859
多分君が言ってる「型」ってのは、文字列、整数、浮動小数点とか構造体の事じゃね?
初期に普及したCPUアーキテクチャでは、そういった原始的型の実現が重要だった。
ソフトウェの組み方が、プロセス指向、データ指向、オブジェクト指向、メッセージ指向と拡張されるに連れて、必要な型も拡張されてきた。
で、現在「型」って一般的に言ってるのはオブジェクト指向用なんだが、その一方でC言語の入門編では古代の型を教えるから、大抵の人は混乱してしまう。 動的にも静的にも良いところはあるんだし、一概にどうとは言えんだろう。
動的型言語に慣れてるやつに言わせれば、コンパイラに指摘されるまでエラーに気づかないのは甘え、テスト不足、みたいな極論になるぞ。
オブジェクト指向もずいぶんアラン・ケイが考えたものと乖離してる気はするしな。
smalltalkは放置するとして、erlangみたいなメッセージ志向の言語はもう少しあっても良いと思う。 コンパイル通れば安全!IDEが全部教えてくれる!
これぞ最強モダン開発 我が社ではサーバ側をrustでリプレイスし始めた
今のところ楽しい >>870
どの言語からRustにリプレースしてるの? php, java(or kotlin), c(apache module), nginx(lua module), python, ruby
など一通り
負荷の高いところからちょっとずつだけど、phpのは一つ終わった 弊社ちっぽけな会社なもので、ランニングコストを抑えて価格で勝負しないとやってゆけないのです rust案件として俺を雇ってくれない?
仕事なら勉強しそう。TypeScriptなら仕事で使っとります 最終的にどれくらい改善されたのか気になるから教えてほしい 自分達の稼働コストは無視か
典型的なダメベンチャーだな オープンソースのようにコストを公開する習慣がないから
高いという証拠も安いという証拠もない
だから無視されるんだ >>877
仕事じゃなくても勉強しないと!
>>878
元のコードの良し悪しについて無視するならば、phpのシステムはcpu時間が1/2、メモリ1/50、レイテンシ1/2、スループット3倍になった
>>879
無視してないよ まあまさか月額百万以下とか言わないと信じてるけど、
動画配信のような本質的に高負荷な事業を除けば、クラウド費用が問題になるのはそもそもビジネスとして成立してないやろ
もしそんな状況なんだったらコスト削減なんかよりピボットして開発に金使うべきだわ サーバを維持&増強するコストが半分になると考えればアリじゃないの? >>883
なんの金額?
>>884
なんの金額?
>>885
アリアリだよ >>886
クラウド費用を元々いくらだったのをいくらに削減できたかに決まってるでしょ
金額ね >>887
オンプレだからそういう計算はできないなあ
ちゃんとペイするからそう心配しないでよ >>890
だったらクラウドに移行するか、データセンターに運用丸投げするのが先じゃね
手間も含めたらよっぽどコスト削減になると思うけど >>892
ここでアピっとけば誰かがビジネスチャンスだと思ってもっととっつきやすい本執筆してくれるんじゃないかっていうなんかそういうのだよ >>893
そんなことはないんだけど、残念ながら納得いただけるだけの材料を提供することはできないからなあ 単純に自分の金が欲しいという話ではないんだよな
自分だけでなくみんなが金を欲しがって欲しいという話だから面倒臭い 今出向してるベンチャーで工数が3倍になるのを覚悟してでも社内システムの開発用言語を関数型にしようとしてる。
最初はHaskell+elmだったけど、エコシステムが腐っているという理由によりScala+elmに変わった。rustは最初から除外されてた。学習コストが半端ないという理由により。
(まともに使えるのに2ヶ月かかる) Scalaって最近微妙によくきくな
昔いろいろ入れすぎて一瞬でオワコン化したって聞いたが Rustのコードを書くと借用チェッカにコテンパンにされて工数かかる、とでも思ってんのかねぇ。
実際は真面目に設計してりゃそこまで問題でもなかろうに。 Scalaで生き残ってるのはSparkだけだよ
Sparkがビジネスで受け入れられ始めた頃にKotlinやDottyで無茶苦茶になってアーリーアダプタが一斉に引き揚げ、負債として残っちゃった コンパイルと言えばTypeScriptってめっちゃエラー出てるのにちゃんとjsファイル生成されるのには笑う >>900
> 工数が3倍になるのを覚悟してでも社内システムの開発用言語を関数型にしようとしてる
これはなんで? 声の大きい関数型信者がいただけでしょ
社内システムだとビジネス観点の統制もないだろうし
俺も社内向けの仕事するときは毎回新しい言語使ってるぞ まあ、社内システムっていつでもごちゃごちゃになるもんだし、本当にできるなら関数型にすればテストは楽だね。
俺が作ってたシステムは、言語は関数型ではないけど、何が何でもキュー処理システムが処理する結果が正で、それ以外の書き込み許してなかったから、ジャーナルを流し直すとデグレてないかテストができるよ。
業種の問題なんだろうけど。売ってるシステムも、キュー処理システムだけが書き込み出来るようになってる。
非同期対応とかも、もともと非同期を前提にしてたから何も困らんし、キュー処理システムは処理ロジックとして何でも呼び出せるからモックにしようが本番にしようがなんとでもなったな。
変な言語で出来てるけど、どんな言語に持ってっても移植できると思うわ。 意識高い系のエンジニアに対してビジネスサイドによる適切な方向付けができてないと、
こうやって誰も求めていない非機能要件を勝手に創造してオナニーを始めるんだよな 工数3倍というのは学習コストを加味してると思う。仕事で勉強していいとか羨ましい。
elixirも話題になったけど、結局erlangに精通する必要性が出るから除外された。 >>908
すべての変更処理はイベントとしてキューイングして処理するようにしたってことかね? Elixirは関数型として見ると微妙なんだよなぁ。
F#から借りてきたパイプライン演算子はなんでああなっちゃったんだろうか。
あれじゃただのUFCSなんだからドットにしとけばよかったのに。 >>911
そうそう。
売り物の方が、監査証跡と全データの変更履歴が必須だから。
社内システムにも持ってきてるが、今まで事故ったのは入力ミスに赤伝切らずにDB書き換えた事由来ばっかり。 俺も初めて任されたwebアプリケーションスタートアップでJSF選んだの後悔してるから変えたいわ >>900
Haskellのエコシステム、そんなにひどいのか。
具体的にはどういう所がダメなんだ?
確かにScalaはなんとなく良い感じなのは同意。 他言語なら他のインストール方法試すなりコード弄るなりで対処しようがある感じだがhaskellはあかんわ。。 >>907
自分のプロジェクトで使って最後までメンテするんなら別にいいと思うが
人のライブラリに無理やり突っ込んで人を実験台にしてくる輩は死ねと思う。 >>867
>動的型言語に慣れてるやつに言わせれば、コンパイラに指摘されるまでエラーに気づかないのは甘え、テスト不足、みたいな極論になるぞ。
そんな奴見た覚えはないが、新人君みたいなテスト=単体のインターフェーステストって認識なのかもね。 >>918
「関数型」と言ってる奴にとってはHaskell自体が実験台でしょ
パラダイムの方に興味があるということは実装のメンテナンスは期待できない でも今どきピュー(P)と吹けば(H)壊れる(P)ウンポコペチプー選ぶガイジよりはマシだろ >>921
別に自分で実験する分にはいいと思うが
メンテナンス性も含めてそのパラダイムが有効か検証しないと意味ないだろ。
今時メンテナンス性を考慮しない言語なんてありえんわ。 HaskellはCのライブラリをいくらでも取り入れるのでCが分からないと地獄
「全部自動化すればCが分からなくても問題ない」という説を信じたら地獄
一方、JavaやJavaScriptは鎖国のようなことをやってCを使わないようにした
この問題についてはパラダイムは関係ない Googleは当初Dartでやろうとしてた事にはTypeScript採用したんじゃなかったっけ? >>928
haskellの評価順序とcの評価順序のバインディング考えるだけでも頭痛くなるわ。
そこに特有の最適化仕の把握しとかないと使えんだろうし、そんなもん普通のプログラマが使えるか。
>一方、JavaやJavaScriptは鎖国のようなことをやってCを使わないようにした
javascriptは知らんがjavaもc呼び出しはやるだろ。メモリモデルの違いで苦労はするがcの他からの呼び出しやすさはやっぱすげーと思う。 機械学習がPythonになったのは、JavaでCを呼び出していいのか躊躇したからだと思うよ >>931
個人的にはdeeplearningの層を明示的に静的型付で表現するのがあんまり相性良くないから
と思ってるけど。javascriptでもある程度ライブラリ出し始めたところ考えるとそうかなと思う。 マルチプラットフォーム実装を前提とするライブラリならともかく
アプリ側からC呼ぶとか何のためのJVMか分からんがな pythonは読みやすさからサンプルコードとしてよく使われていたのが
そのまま使われ続けただけ。 何のためのjvmというが現実にはcのコードをポートする方が楽だからな
jvm が使えないプラットフォームにも対応できるし >>937
コレクションもまともに扱えない言語は遠慮します
>>430,431 RustはWebAssemblyを生成できるって点には魅力あるんだけどな >>930
>haskellの評価順序とcの評価順序のバインディング考えるだけでも頭痛くなるわ。
どうせIOモナれば先行評価だろ。 そうなるわな
アプリを作らない言語は生産性がないと言われて作ってみたら
○○を作りたいだけの言語は汎用性がないと言われる >>936
そりゃ極論かまってちゃんはどんな世界にも居るだろ。 レス数が950を超えています。1000を超えると書き込みができなくなります。