次世代言語15 Go Rust Swift Kotlin TypeScript
■ このスレッドは過去ログ倉庫に格納されています
Crystalってpythonに対するnimのruby版という認識なんだけど間違ってるかしら webのものだがrustを採用するよう上司を説得するのに四苦八苦してる
自分が分かることしかやりたくないオタンコナスめ >>4 ちょっとでもいいから自分で書いて説得材料に加えた方がいいよ。先行者がいるかいないかで全然印象が変わるから
使う言語も作るサービスも新しかったら上司も二の足も踏むよ >>5
書いてるしプロダクトに組み込んでるよ
もっと広く使いたいってはなしさね rust使える連中集めるか、僕が一生このプログラムのメンテしますって念書でも書けばいいんじゃね smalltalk由来の?
実装コストの割にちょっと手間が減るだけだから、広まるとは思えないなぁ。。。
あれば便利だけど、拘る程でも無いし。
設計段階で良く使うのを前半に持って来れば現状でもデフォルトの値で省けるし。 >>14
広まるどころか既にPython、C#、Scala、Swift、Kotlin、Nimなどに名前付き引数が存在する 名前付き引数はあったほうが良いけどな。
tsとかjsでもobject使って名前付き引数っぽくはかける 引数の数が3つ以上になったら名前付き引数を使ったほうが良いけどな。 >>14
>smalltalk由来の?
うわーキモいなーw アホみたいに引数が多いWin32APIとか呼ぶときは欲しくなる Smalltalkの名前付き引数って引数の順番入れ替えられないってマジ?
ガチでウンコじゃん オプション引数が2つ以上になるなら欲しくなるね。
まぁ連想配列を渡せればそれでもいいんだが型安全でない。
そういう意味でTypeScript最強。 >>4
悪いけど趣味でRust書いてる俺ですら
webものでRust採用するなんて言われたら全力で却下するわ 当然異論あるのは承知の上で、
オプション引数が必要だと思ったときはすでにAPI設計が失敗してるって思うのだが
具体的にオプション引数でないとできないことってなんだろう webでrust、なんでダメなんだ?
active recordが無いから? 単純にasyncまわりが動乱期で、
今書いても近いうちに書き直しになるのが目に見えてるから>webに導入するの反対
あとはRust使うくらい性能追及しなきゃいけない部分なんて
webでそこまであるか?というのもある
>>29のバカでも書けるに近いかもしれんが、
Goで困る用途がそこまで思い付かない
渋の配信回りみたいな部分で欲しいのは分かる てかgoで本格的なアプリ書いてみりゃチャンネル使ってもまだまだ複雑になるってことに気づくわ。
言語の瑣末ごとに時間食ってる余裕はないと感じるようになる。 >>32
pixiv Sketchのライブ機能とかいうやつのバックエンドがRustで書かれてるんだと >>33
ピクシブのシブか
ぼくはjavaやgoで書くくらいならrustで書くけど、馬鹿に合わせなきゃいけないなら仕方ないな 別にrustで全て書き換えてもらっても構わんが?
https://github.com/kubernetes/kubernetes
やれるもんなやらやってみろや。 Javaで書くくらいならGoで書く
C++で書くくらいならRustで書く
は分かるんだ
Goで書くくらいならRustで書くと言えるほど
プログラミングスキルに自信はないな
豪語できる実力と後任育てる覚悟があるならいいんじゃないかなとしか言えん 難しいの意味によると思うけど、例えば予測しきれないGCのほうが難しくない?
みんな作ってるものも求められるものも違うから一概には言えないけどさ
そういう意味では、馬鹿に合わせるってのは言い過ぎだった、ごめん >>27
オプション引数という機構が無くてもやりようはあるという話なら理解できるが、
設計の失敗というのはピンとこないな。どういうこと? >>37
GCの挙動予測しなきゃいけないくらいシビアに作らなきゃいけないものなら確かにRustで書く
ただ単なるWebのAPIサーバとかでそんなシビアに作るか?という話
例に挙げたpixiv Sketch Liveはエンコーディングが絡むからGoでは確かに辛い >>38
一言でいうなら後付けの建て増しに見えるから、かな?
初めからオプションによって色々変わる設計ならビルダーパターンなり構造体を引数に渡すなり
設計段階からオプション引数が不要なように書いてると思うんだ
ただ単なる偏見な気もする それ複雑さがビルダーの初期化に移るだけだろ
記述量でみるならオプション引数の方が簡潔 1つ2つくらいなら確かにそうだけど、
その流れで気づいた10個越えてたってパターン複数回見てるから、
オプション引数使うより初めからいくつ増えてもいい設計にした方がいいのでは?と思う
もちろん思考停止で増やした奴が一番悪いのは知ってるが 10個になったってビルダーよりオプション引数のほうが簡潔でしょ
何言ってんの? 初めから完璧に設計なんてできないんだから、備えておくこと自体ナンセンスだよ
初めの設計が破綻したらdeprecatedにマークして、その時点で最適なインターフェースを作ればいいじゃん rust 2018 editionが標準になったな
書き換えるのに2時間くらいかかったわ Javaだと1週間かかっていた機能追加が、Kotlin移行後は2〜3日でできるようになりました。
――工数が半分以下に減ってるんですね……! Android版Yahoo!ニュースではまだJavaを使っている部分もあるかと思いますが、今後Kotlinへ完全移行する予定はあるのでしょうか?
https://employment.en-japan.com/engineerhub/entry/2018/12/07/110000 設計見直したのが大きいってな
Androidならコトリン一択だろうけど そこはGoogleらしいね。
ただ、鯖ならもっと良い言語あるだろってのはあるし、Goにも言えるけど鯖から外の用途がGoogleの言語は伸びないのよね。
GoもGUIライブラリ弱いし。
自社に関係する用途以外に関心が無いっぽいのがね。。。
オープンソースって元からそういう所あるけど、仮にもGoogleがバックアップしてるのに。
MSも似た様なものだけど、関係する分野自体が手広いからライブラリも充実する。 javaのトランスパイラだならサーバも書けるけど
新規で書くのにコトリン選んでたら指差して笑う GUIはFlutterでやるんかね
C#の層をねらっているようにもみえる >>59
気の毒なことにコトリンを選ぶ現場はあるたいなんだ
潜在的にはjavaのが圧倒的に多いだろうけど jvm使うかどうかなら分かるけど
javaかkotlinかって些事じゃね 選べるのにわざわざjvmに縛られるスカポンタンがいるってこと >>61
そうだなあ。Javaしかできないと言ってる人にいきなりやらせてすぐにできるようになったらその人はかなり良いプログラマである可能性があるということはわかる。
何ヵ月やってもダメっぽい場合は他の事も多分ダメでプログラマ向きの人ではないから他の仕事に移すかクビの方向で検討。 ここ的には基本Go
もっと性能予測や速度が必要ならRustって感じか? kotlin触った後にdart触るとセミコロンがうっとうしいな
次世代言語にセミコロン不要だわ ■C#
list.ForEach( e => {
Console.WriteLine(e);
});
■Java
list.forEach( e -> {
System.out.print(e);
});
■Rust
list.for_each(|e| {
println!("{}", e);
});
■Dart
list.forEach( (e) {
print(e);
}); ■JavaScript
list.forEach( e => {
print(e)
})
■Groovy
list.forEach { e ->
print(e)
}
■Kotlin
list.forEach { e ->
print(e)
}
■Swift
list.forEach { e in
print(e)
} ■Go
※筋力でforループ
セミコロンもだけど末尾ラムダの場合に括弧減らせる方が俺は好きだな >>73
Rustのノイズの多さが目立つな
Dartもアロー的なものがない分締まりがない印象 ■Smalltalk
list do: [:e |
Transcript cr; show: e printString
] >>75
goのforは他の言語のforeachと大して差があるとは思えんが 色々調べてお疲れだと思うけど、そのラムダ式を変数に代入した場合を書いてみるといい
ちゃんと色々考えて機能追加したのか、それとも流行りに乗っかっただけなのかが分かるから >>81
主眼がラムダ構文だったから
>>82
そこを書いて自分の考えを出してこうぜ
俺も連投の割には>>75の最後の行が言いたかっただけだし >>83
俺わかっちゃってます風の文句しか言えないガイジに、自分の考えなんてあるわけないだろ
こういうやつは流行りに乗っかっただけのマウントが取りたいだけのキョロ充以下のゴミ虫なんだよ ラムダを渡すのがポイントなわけね。なら、「作ればある」って感じか。
type anySlice []interface{}
func (this anySlice) forEach(f func(i interface{}) {
for _, e := range this {
f(e)
}
}
list.forEach(func(e interface{}) {
fmt.Println(e)
} そもそもラムダ式を変数に代入とか普通しないのでは
型推論が台無しになるでしょ 普通の関数型言語の型推論 ( HM型推論 ) なら
ラムダ式を変数に代入 ( 束縛 ) しても正常に型が付く ベクトル計算,統計,数値解析など
Python,R
ブラウザ上
JavaScript
トランスパイラ
TypeScript,Dart,Kotlin
WebAssembly
(多すぎ省略)
アプリ,サービス
コンパイル
C#,Java,Scala,Kotlin,Swift,Objective-C,Dart,Go
スクリプト
Ruby,Perl,PHP
JSフレームワーク使用(Node,React/Native,Electronなど)
JavaScript,TypeScript
ミドルウェア,ドライバ
C,C++,Rust,Go
適応領域/縄張り的な観点で人気言語から列挙、異論は認める ハードウェアを使う計算処理のDSLとも言えるようなPython,Rの領域は
他が入り込めそうにない
TypeScriptはJavaScriptの上位互換性がかなりの強みになっているが
ネイティブコールは他に頼る必要がある
.NET Native, Substrate VM, Kotlin/Native, Dart など
VM型だったものがLLVM等を利用し、
FFIを持つだけでなくネイティブのバイナリを生成出来るようになっている
ある程度用途や領域の前提が無いと比較は難しいだろう
ビルド関連,エコシステムも実際上は言語選定に含まれる
もちろん題材としては構文(型システムなど含む)の優劣のみ比較するのでも良いと思うが >>83
渡す必要もないのにラムダ渡さないとダメですか。。。(震え声)
mapM (\e -> print e) list 流石にラムダは書けるのに関数は渡せないなんてクソ言語は無いだろwww
無いよね?
list.forEach(print) 広告がめっちゃ悪さするけどいつからマルウェア配布してたんだ? >>73
>>76
>>77
rustはもうちょっと簡潔にはなる
iter.for_each(|e| println!("{}", e)) 1引数1ステートメント前提での省略書くのは
実用はともかく比較のセンスは悪いと思う・・・ ■ このスレッドは過去ログ倉庫に格納されています