次世代言語Part7[Go Rust Swift Kotlin TypeScript]
■ このスレッドは過去ログ倉庫に格納されています
文字数制限きついので改題
スレタイ以外の言語もok
前スレ
次世代言語議論スレ[Rust Kotlin Haskell]第6世代
http://mevius.5ch.net/test/read.cgi/tech/1503924817/ >>9
型が決まってれば動的言語だろうと補完できるでしょ >>10
JSDocに型を書いてないコードとかあったら発狂したくならない?
仕事じゃ周りのアホどもが書いてくれないからよくにあるんだけど >>9
最初にコード補完をIDEに組み込んだのは動的言語 >>14
バカいうんじゃないSmalltalkに決まっとるがな >>16
何を調べるにしてもウィキペ情報は参考程度に留めておいたほうがいいよ
ご多分に漏れずこの件に関しても間違っていてちょっとググっただけでも
少なくとも1980年代にはコンテキストを考慮した補完機能を有するAliceというPascalのIDEが出ていることがわかる
http://www.atarimagazines.com/v6n2/Alice.html
だから動的言語が初かの真偽はともかくVBがしかも1990年代にもなってから「最初」ということはあり得ない 動的か静的かよりも暗黙に型変換するのかしないのかのが重要。 typescriptの凄さってIDEの機能言語に組み込んだことだよな。
リファクタリングの機能を言語に用意してるから、
どのエディターでも使える。 >>16
>>18
Wikipediaが間違ってるんじゃなくてお前らの読み方が間違ってるだけだろ
最初にコード補完をIDEに組み込んだのはVBなんて事どこにも書いてない >>11
JSDocとコード補完と何か関係あるの? 折角の補完機能ガン無視してVimで書いててすまん
Vimに補完つけると重いんだよな Jedi-vimとか謎に重くならん?
あれ?そうでもない? >>20
MSは昔からやってるけどね
MSにとって目新しいのは、コンパイラ及びエディタをコード補完やリファクタリングに対応させるためのオープンなプロトコルを策定したこと
これほど早い段階でそのレベルにまで達するのはMSにしかできないこと 誰だよ未だにプログラミング言語未満のRustをスレタイにいれてるやつ
ハロワ以上のプログラムをことごとくコンパイル弾く欠陥品、言語としての体をなしていない 晩酌してたのとRest APIと混ざったんだよ
めちゃめちゃ使ってるっちゅーの >>33
ほい
enum Tree<T> {
Leaf(T),
Node(Box<Tree<T>>, Box<Tree<T>>),
} まあそれが一番素直な実装だね。
問題は循環するかもなグラフの場合。持ち主が曖昧になるから。 >>34
データ構造定義だけ書かれてもな
それに対して余計なアロケーション発生させずにappendとdelete実装してみてくれよ
できるもんなら 問題はTypeScriptに対して競合としてflowがあることだよな。
Reactを使うのにTypeScript使っててすごく便利なんだけどReactがflow押ししそうで怖い。 >>36
まずはCかC++でお前の言う無駄なアロケーションのないappendとdelete付きの木構造とやらを書け。
そしたらそれをRustで書き直してやるよ。 >>37
Web系に言語は作れないってのはさすがにCoffeeやDartで世間に理解されたと信じたい >>20
IDEの機能を言語に組み込むぐらい、LISPもSmalltalkもとっくの昔にやってるじゃん。 おまえらが次世代と呼んでいる機能のほとんどが60年代の再発明だなw >>37
うちの案件フロウ使ってるわ
最初の技術選定でクソ馬鹿野郎が生JS選択したせい
しかも途中で辞職、いやいなくなってくれてせいせいしたが
んで、どうしようもないから後付けでフロウ
クソみたいな生JSに後から挿入れられるのはメリットだわな
ライブラリの対応はゴミだけど >>41
まあそういうところもあるけど、Rust なんかはだいぶ機能を整理した方かなとは思うよ。
実際に作って使ってみるとボローイングの解決しづらさがよくわかるってのはある。
理論と実践は繰り返してなんぼ。 >>42
Typescriptも該当ディレクトリ内にXXXX.d.ts(XXXは生jsのファイル名)を置くだけで
型が付与できるけどな。しかも生jsの箇所をいじらずに。
どっちがいいかは何とも言えないが。 jsというかTypeScriptを使ってるんだけど。async-awaitマジでいいわ
と思ったが例えばclassのコンストラクタをasync対応してくれたらな〜って思うわ
初期化時に非同期関数使いたいと詰む。 >>46
c#でずいぶんお世話になってるから嬉しいわ >>46
わざわざasyncのinitializeメソッド作るの馬鹿らしいよな、仕方ないんだけど >>46
constructor() {
(async () => {
await this.hogeAsync();
})();
}
インスタンス作成側ではawait newとかできないけど、分かってて使えば
今のとここれで特に問題ないわ。 >>50
非同期関数がそのクラスの生成タイミングで終わる保証無いだろ。
大概ストレージとかネットワークアクセスしてるわけだし。
それで事足りてんの?マジで? >>9
使ってみたらわかるが、ちょっと頭おかしいレベルで補完効くぞ。
関数の型が、「Date | "不正日付" | "演算不能"」と、stringの中身まできちんと出してきたときにはびっくりした。 コンストラクタ非同期にしたい時は>>51の言ってる問題があるから、値をセットするだけのprivate constructor準備してpublicは別に公開したほうがいい
例↓
class Hoge{
private constructor(public foo:string){}
async create():Promise<Hoge>{
const foo=await asyncFunction();
return new Hoge(foo);
}
} LisperはSmalltalker以上にめんどくさいぞやめとけ >>43
> 理論と実践は繰り返してなんぼ。
同意 その通り
テキストエディタで打ったコードにこそ温もりがある
補完や静的解析なんて邪道
日本人ならPHPを使うべき >>59
日本人ならとか言うんならRuby使えよ。。。
何でPHPなんだよアホちゃうかと。。。 Elixirってダメなん?将来性ないの?
サーバーがCowboyとかいう変なやつになるからダメなのかな >>60
偽装・不正・いい加減がモットーのジャップランド土人村にとって
PHPほど相性のいい言語はない
PHPは日本人なんだよ、わかるか? >>52
それは裏でTypeScriptの型情報を再利用してる。
だから標準APIとか有名所は使える。でも自分でライブラリを作るととたんに効かなくなるぞ。 >>52の内容なら型アノテーションに頼らずとも型推論だけでいけるだろう。 >>63
将来性とかさ〜自分で判断しろや。
それともここで将来性あるとか言われたらなんも考えずにその言語使っちゃうわけ?
将来メンテされなけりゃおれがやるくらいの気概をもって言語使ってほしいわ。 >>64
それはあくまで偏見の塊の君の個人的意見だろ。
そんなこと言い出したら
「日本人はもともと職人気質の人間が多いから
使いこなすのに職人レベルの技術が求められるC++と相性がいい。
だからC++こそ日本人のための言語だ。」
なんていう、今俺が適当に作ったトンデモ論法でも通っちまうだろうが。 >>65
違うよ。自作関数の戻り値と、それが代入されてる変数のヒントに出る。
自分でライブラリ作ってもバッチリ出てくれるけど、doc書いといたら間違いは更にないな。 >>63
Elixirいいよ
将来性はコミュニティの頑張り次第
Phoenixはよく出来てる
実質的にWebアプリに用途が限定されるだろうから
このスレでは人気ない >>68
いや、日本人はPHPでしょ
空気読んで面倒臭いことはナーナーにして
今が良ければそれでよし
当事者がたんまりお金盗って無事退職した後、
年単位越しでツケ払って大騒ぎ
PHPですか?いいえ、日本です 日本の技術力ガーとか言ってたくせに
結局全部嘘ばかり
バカチョン以下やでホンマ
そりゃペチパーが闊歩しますわ >>72
多分お前よりはまともなもの作ってるとおもうわ。 PHp本当に速くなったからな
相変わらずポーリングも特殊操作でしかできないクソだけど 気に食わない奴でも合法なら許す
違法なら許さない
この優先順位を歪めるから無法地帯になるのだ >>70
Elixirってrubyに強く影響受けてる言語なんだよな。
Phoenix触ってたらRailsの匂いを感じる。
でも今は動的言語は弱い気がする。Elixir + 型 が欲しい
TypeScriptが触ってて気持ちいいからサーバサイドもJSがいい気がする。 Elixirの問題は込み入ったことやるとErlangに足突っ込まなきゃいけないことで
プロダクションコードに突っ込むには人材要求が高すぎること 結局ネットワーク系統のエラー処理は低レイヤーに突っ込んでいかないとどうにもならんよ。
抽象レイヤーでなんとかしたいって願望はわかるけどさ。 Elixir(というかBEAM=ErlangVM)の場合はプロセス復活のために型情報が必要だし
静的にしたからって型情報は省略できない C++を書きたくないんだが代替言語は今だとrustとdどっちがゆうぼ?
最近はnimと言うのが注目されてるとも聞いたが…… ジャップランド土人村企業が詐欺のために求めているのはPHPだけ! >>84
Goも弱点が多い言語だけど初期の学習コストとか考えると
rustよりGoかな。
もちろんrustもいいんだけどc++並に学習コスト高そう感ある。 Rustは言語と名乗れる水準に達してないのでGo
深くシステムに触るのには向いてないがな Goなのか……
他言語が純粋な次世代Cを目指してる中、Goは微妙に設計思想が違うイメージだからあえて外したんだが……やっぱりgoogle正義なのか >>83
c++ で何を書くつもりなの?
無理に c++ で書かなきゃならんものって最近は減ってると思うけど。 >>91
c++ で書かれたオープンソースプログラムのdllプラグイン
悲しいことにc++ 選ぶ理由なんて結局既存ソースがc++ だからの理由に尽きる…… >>90
goとか言ってる連中の言うこと本気にするなよ。
goは数年周期でバズってるだけでC++の代替なら
Dかrustって考えは間違ってないしrust理解できないやつが
こことrustスレで騒いでるだけだぞ。
Dはもう流行らんだろうが、rustは学習コストより標準ライブラリの弱さが面倒。
自分で書くか外部ライブラリに依存しまくるかで基本的なスレッドプールすら無い。
低レベル向けだから結局自分で書くならrustでいいし、それが嫌ならDでいいよ。
rustとD位の差なら正直好みの差。 >>92
ならやっぱりrustじゃない?
bindgen使えばc++のヘッダもパースしてc ffi用のglue code生成してくれる。
bindgenがどの程度まで万能かは俺もよくは知らんけど、
mozillaがfirefox quantumでservoとgeckoの橋渡しのために使ってるくらいだから
結構まともに動くんじゃないかとは思ってる。 おまんらの大好き ぷ〜えちピーーブリブリッ でも使えばええじゃろw みんなサンクス。
Goは学習コスト低いらしいから後追いでもなんとかなりそうだし、とりあえずrustで書いてみることにするわ
一刻も早くc++ が絶滅する事を祈る TypeScriptとGoを交互に触ってるけど
やっぱりnull安全な言語とそうじゃない言語の差が際立つな。
Goのほうは早速null pointerアクセスで落ちる。 c++が絶滅したら今c++で書かれてる様々なコードベースが色んな言語に分裂するんだぜ
バベルの塔 >>93
既存のまともに動いてるCコード移植しようとしてまともにコンパイルも通らなかった経験からまともな言語の水準に達してないといってるわけだが
少なくともRustでものが書けると信じこんでるお前よりはRust理解してるぞ >>100
お前が前に沸いたアンチと同一人物かどうかは分からんが、前に言った木構造をとっとと書きやがれ。
それすらできないならお前はC、C++もそもそもまともに出来てないんだから黙ってろ。
> 38
> >>36
> まずはCかC++でお前の言う無駄なアロケーションのないappendとdelete付きの木構造とやらを書け。
> そしたらそれをRustで書き直してやるよ。 >>101
まずRustの木構造をちゃんと動くように書いてから言えよ rust で木構造云々言ってる奴って、コンパイラすら通せない rust コードしか書けない奴だろ。
Cで書いてあった平衡木のライブラリを rust に移植したけど、
> それに対して余計なアロケーション発生させずにappendとdelete実装してみてくれよ
こんなん普通に出来るぞ。
Option<Node> に get_or_insert() するだけ。
かなり苦労したのは木の回転だけど、それでも rust 用に頭を使ったら、
take() して mem::swap, mem::swap, mem::swap, そして代入の 5 行で終わり。
全体を通して余計なアロケーションなんて普通に無い。
rust は学習コスト結構高いけど、初歩の初歩で躓いた落ちこぼれ>>100,>>102 とかは何を言う権利も無いよ。 Cのコードを示せないrustアンチは糞ゴミだけど、動くコードを示していない>>103も何も言えていない 自分の頭を撃ち抜くCのプログラム書いても運良く助かってる人は
Rustのコンパイル通せなくなるよね そういう、Rustのコンパイルが通らなければ危険なコードって決めつけるRust信者本当にうぜえ
Rustが言語として表現できる範囲が狭いのをごまかすための方便でしかないのに TypeScriptは本家のplaygroundを触るだけで凄さが分かるんだけど
https://www.typescriptlang.org/play/
rustってそういうのある?ちょっと試すとかできる? >>105
自分の頭というよりユーザーにデバッグのコストを転嫁して儲けてるな
運が良いというより確信犯的に >>107
ググるとかしない人?単にTypeScript宣伝したいだけ?
https://play.rust-lang.org/
もとよりゆるふわTypeScript使いがRustのコンパイルを通せるとも思えないので端から試す気ゼロだろうけど… ■ このスレッドは過去ログ倉庫に格納されています