次世代言語Part7[Go Rust Swift Kotlin TypeScript]
■ このスレッドは過去ログ倉庫に格納されています
文字数制限きついので改題
スレタイ以外の言語もok
前スレ
次世代言語議論スレ[Rust Kotlin Haskell]第6世代
http://mevius.5ch.net/test/read.cgi/tech/1503924817/ >>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のコンパイルを通せるとも思えないので端から試す気ゼロだろうけど… 選ばれた人しかコンパイラ通せない言語とかそれプログラミング言語って言えないよね >>109
そこは知ってるけど全然補完が効かないんだけど。rust使いは
しょぼいエディターで頑張る感じ?
TypeScriptはplaygroundから補完が効きまくって楽しい。 AltJSであるtsとRustのブラウザ上で動くplaygroundの機能差を語りたかったの?マジで?
Rustサゲしてる人はこの程度ってレッテル貼っていいの? 単にプロダクト開発のスキルの違いだな
MSの開発環境チームのメンバーはHelloWorldの代わりにインテリセンス実装するんだろう >>112
単純にPlaygroundの質からして違うってだけの話だろ
その程度もみとめられないよかよ なぜrustの対抗馬にTypeScriptが挙がるのかまるで理解できない
用途が全然違うだろ…… WebAssemblyが期待されてるから、あながち間違いでもない >>113
ほんとMSってそういう所は笑えるくらいすごいよな
Rust開発者たちも見習ってほしい
一応rustもコード補完にrlsとかいうヤツあるけどなんかまだいまいちなんだよな。
vscodeにrust(rls)っていうエクテンション入れて使ってるんだけど、
クロージャ書いてるときは補完が効かないのは俺だけ?
あとlint?(エラー・警告を赤・緑の下線で表示してくれるやつ)が
時々なんの前触れもなく急に無反応になるんだけどそれも俺だけ? 少人数のMS社員が片手間でVSCode作ってみたら一瞬で天下獲れちゃいましたというチート集団
MSがRust推せば余裕でGo潰してベターC++の定番を奪えるだろうな 片手間ってことはないし、エディタ作成なんてのは人数増やせばいいものでもない。
まあチート軍団ってのは確かだけど。
しかし Rust とか c++ みたいに教条主義的な言語ってやっぱ信者が湧くね。
わかりやすくていいとは思うけど。 片手間とか余裕とか、良い子は絶対に真似してはいけない情報ばっかり教えるんだよな
そんなところに信者を集めたら怠け者の集団ができそうだ >>36じゃないけど、雑に平衡木(AA木)Cで実装してみた。
つってもWikipediaのまるコピだが。
#include <stdio.h>
#include <stdlib.h>
typedef struct tree {
int value;
struct tree* left;
struct tree* right;
int level;
} tree_t;
int level(tree_t* t) {
if (t == NULL) {
return 0;
}
return t->level;
}
tree_t* leftEnd(tree_t* t) {
if (t == NULL) {
return t;
} else if (t->left == NULL) {
return t;
} else {
return leftEnd(t->left);
}
}
(続く) tree_t* rightEnd(tree_t* t) {
if (t == NULL) {
return t;
} else if (t->right == NULL) {
return t;
} else {
return rightEnd(t->right);
}
}
tree_t* skew(tree_t* t) {
if (t == NULL) {
return t;
} else if (t->left == NULL) {
return t;
} else if (t->left->level != t->level) {
return t;
}
tree_t* l = t->left;
t->left = l->right;
l->right = t;
return l;
}
(まだ続く) tree_t* split(tree_t* t) {
if (t == NULL) {
return t;
} else if (t->right == NULL) {
return t;
} else if (t->right->right == NULL) {
return t;
} else if (t->level != t->right->right->level) {
return t;
}
tree_t* r = t->right;
t->right = r->left;
r->left = t;
r->level += 1;
return r;
}
(続く) tree_t* decreaseLevel(tree_t* t) {
if (t == NULL) {
return t;
}
int ll = level(t->left);
int rl = level(t->right);
int expectedLv;
if (ll < rl) {
expectedLv = ll + 1;
} else {
expectedLv = rl + 1;
}
if (expectedLv < t->level) {
t->level = expectedLv;
if (t->right != NULL) {
if (expectedLv < t->right->level) {
t->right->level = expectedLv;
}
}
}
return t;
} tree_t* insertTree(tree_t* t, int v) {
if (t == NULL) {
t = malloc(sizeof(tree_t));
t->value = v;
t->left = NULL;
t->right = NULL;
t->level = 1;
} else if (v > t->value) {
t->right = insertTree(t->right, v);
} else {
t->left = insertTree(t->left, v);
}
t = skew(t);
t = split(t);
return t;
}
肝心の関数まで遠いなほんと tree_t* removeTree(tree_t* t, int v) {
if (t == NULL) { return t; }
else if (v == t->value) {
if (t->left == NULL && t->right == NULL) {
free(t);
return NULL;
} else if (t->left == NULL) {
tree_t* e = leftEnd(t->right);
int succ = e->value;
t->right = removeTree(t->right, succ);
t->value = succ;
} else {
tree_t* e = rightEnd(t->left);
int pred = e->value;
t->left = removeTree(t->left, pred);
t->value = pred;
}
} else if (v > t->value) { t->right = removeTree(t->right, v); }
else { t->left = removeTree(t->left, v); }
t = decreaseLevel(t);
t = skew(t);
t->right = skew(t->right);
if (t->right != NULL) {
t->right->right = skew(t->right->right);
}
t = split(t);
t->right = split(t->right);
return t;
}
おしまい。 まじこんなクソコードに何レスもついやしてすまん。 改めて書いてみて思ったが、平衡木って平衡保つための操作がポインタのつけかえ多くて
確かにRustにはキツそうだなとか思ったり
データコピーなし縛りで実装するのはRust歴1週間の自分には無理そうだ Rust 的にはそんなに派手に持ち主変えるな、もしくはコピーを使えって感覚なんだろう。
そういうのは上のレイヤーだったら正しいと思うけど、アルゴリズムなコードの場合は
ちと厳しいかもしれん。
付け替えが頻繁に発生する構造の場合は
int parent[]; int right[]; int left[];
みたいな配列実装しろてな記事は見た事なるな。
直感的ではないけど速度は出るし、まあ慣れてる奴からすればどっちも一緒といえば一緒かな。 そういう、どうしても生ポインタごそごそつけかえる必要がある基幹アルゴリズムは、unsafeでくるんでやれって感じなのかね
実際この平衡木の実体が複数スレッドから独立に操作されるとか考えると割と困る gitみたいに、古いデータを消去することなく
しかも変更のない部分はいちいちコピーしないアルゴリズムを考えるんだ
そうすれば古い方のデータに別スレッドから安全にアクセスできるよ 結局たかが赤黒木すらRustでは書けないって認識でいいの?
ほんとプログラミング言語名乗るなよ >>131
その認識は間違いだけど正解を無料で教えてくれるボランティアが足りないね
GNUみたいなボランティアがいっぱいいないとプログラミング言語を名乗れないのが現実 Rustの問題は後発のくせにIDE連携が弱すぎる。
KotlinとかSwiftとか後発の言語は大概IDEと一緒に提供してるから
最初から補完がきっちり効く。
Goも昔はイマイチだったけど改善してるから許せる。
TypeScriptは言語そのものにIDE連携のための機能をたっぷり盛り込んでいるから
見習ってほしいって話。
初学者程IDE連携が必要だからな。言語仕様が優れてていても
ツールとして使い勝手が良くなきゃ使わんよ。
それにRustの立ち位置って
OS開発とブラウザ開発くらいしかメリットが思い浮かばんのだけども
CLIならGoだし
WebならPHPとかRubyとかGoとか乱立状態だし
WEBのクライアントサイドならTypeScriptだし
スマホならKotlinかSwiftかObjC
このどこにRustが入り込むの? そもそもC++があまり成功してないから改善するためにRustがある
C/C++と合計して考えるとJavaより上だけど合計しなければC++は成功してないよ C++が成功してないwwwwwwwwwww
どこの平行宇宙ですかwwwwwwwwwwwwwwwww まあ c++ がうまくいってればこんなに言語がたくさんできることはなかっただろうね。
c++ の存在意義は今や高級な機能をどれだけランタイム速度落とさずに入れられるのかの
実験場って位置づけかな。 C++は完璧な言語だとか口が割けても言えないのは間違いないが、Rustなんて言語ですらない汚物使うくらいならC++使うわなあ ID:KYsAJ7k0のコードのRust版まだー? TSは手段と目的がたまに入れ替わるのが見てるとちょっもモヤモヤするな。
C#が最近もう一度好きになってきた。 >>138
まあまあ今ごろコンパイラに怒られてる頃だしもうちょっと待ってやろうぜwwwwww cに名前空間とラムダとattribute((cleanup))が入るだけでもだいぶ助かるのに。
なんでcの規格のバージョンアップは遅いんだ?
c++みたく3年毎にしてくれたらいいのに。 >>142
あそこモジラの工作員しかいねえし
Rustが言語ですらないただの汚物って正しい認識を共有できる人がちゃんといるのは素晴らしいと思う >>143
C++みたく闇鍋状態にしたくないからだろ。 rustをそこまで毛嫌いする必要もないと思うけどな
rustのメモリオーナーシップモデルとかコードの改善に貢献するという話もあるし
ちょっと気にはなってる。 rustアンチって同一人物だろ
コンパイル通らなくてイライラしてるんだね^^
コテ付けて、どうぞ rustは何がそんなに駄目なんだろ
そこ迄言われると学びたくなってくる >>149
他の言語にはない所有権システムが原因で学習コストが高い
使いこなせば強力だけどとても難しい機能
それで使いこなせてない人が「コンパイル通らない」って発狂してる
例えると、初めてHaskell言語触る人が「変数に代入出来ないから何も出来ない!Haskellは欠陥言語!」って言ってるような物 rustのコンパイルを通せない低級汚グラマーが
嫉妬で腐してるだけだろ
腐ってるのはテメーの言語センスだろってね ■ このスレッドは過去ログ倉庫に格納されています