次世代言語10[Rust Swift TypeScript Dart]

**デフォルトの名無しさん** · 2018/04/25(水) 07:02:27.60

スレタイ以外の言語もok

前スレ
次世代言語9[Haskell Rust Kotlin TypeScript Dart]
http://mevius.5ch.net/test/read.cgi/tech/1520298555/

**デフォルトの名無しさん** · 2018/04/25(水) 08:23:02.74

お疲れ様。
立たないから、不安になってた。
ラスト駆け足にして申し訳ない。

**デフォルトの名無しさん** · 2018/04/25(水) 09:28:23.07

乙。だがDartを次世代言語としちゃうのはどうも。内部文字コード今どきUTF16だし。

**デフォルトの名無しさん** · 2018/04/25(水) 10:14:22.33

次世代言語は内部コードも次世代なのかね

**デフォルトの名無しさん** · 2018/04/25(水) 10:51:14.42

たてなかった俺が言う権利はないのは承知の上で
いい加減Rust外そうぜ。まだ言語としての体をなしてない

**デフォルトの名無しさん** · 2018/04/25(水) 11:54:04.59

そもそもスレタイに言語が入ってるから変な事になるんだと俺も思ってる。
取り払ったら？と何度か言ってきたけど、残したい派はどういう主張で残したいの？

**デフォルトの名無しさん** · 2018/04/25(水) 13:31:48.01

>>5
FirefoxやDropboxじゃ既に実用言語として使われてる。
OSでさえも(あくまで実験用だが)Redoxが作られてる。
"impl trait"もそろそろstableになるし、もう必要な機能はほとんど揃ってるだろ？
何が「言語としての体をなしていない」だよ。いい加減しつこいぞ。

**デフォルトの名無しさん** · 2018/04/25(水) 13:41:49.73

rustのメモリオーナーシップモデルを誰かわかりやすく説明頼む。

**デフォルトの名無しさん** · 2018/04/25(水) 13:43:57.34

>>4
当然のようにutf8じゃ無いの。goはそうだし。
他の言語はどうなん？rustとか

**デフォルトの名無しさん** · 2018/04/25(水) 13:44:00.31

>>3
他の内部文字コード決まってる言語ではどんなの使ってるの？

**デフォルトの名無しさん** · 2018/04/25(水) 13:47:47.63

>>9
goのutf8ってのはソースコードじゃなくて内部もそうなの？

**デフォルトの名無しさん** · 2018/04/25(水) 14:18:31.99

内部コードはJava,Swiftみたいに適宜切り替えしてくれたり
Rubyみたいに任意指定できる方が次世代感ある

**デフォルトの名無しさん** · 2018/04/25(水) 14:19:20.11

内部コードは次世代言語の条件なのか

**デフォルトの名無しさん** · 2018/04/25(水) 14:39:38.40

jsがutf16だとは聞いた。dartがutf16なのはjsに引きづられた形なんかな。

**デフォルトの名無しさん** · 2018/04/25(水) 17:34:00.77

>>12
javaって切り替えるの？utf16だと思ってた

**デフォルトの名無しさん** · 2018/04/25(水) 19:53:51.72

>>7
全然揃ってねえよ
NLLとかnever typeとかないからクソみたいな回避テク使わないとコンパイル通らないだろ

**デフォルトの名無しさん** · 2018/04/25(水) 20:33:25.95

Java9からStringはLatin1/UTF16を切り替えて使うようになってるね

**デフォルトの名無しさん** · 2018/04/25(水) 21:11:17.40

String<UTF8>
String<UTF16>
これでいい
ゼロコスト抽象化以外の解決策を誰も答えられない

**デフォルトの名無しさん** · 2018/04/25(水) 22:36:19.51

>>16
まあ、NLLを有効にしないと面倒な回避が必要になるケースは確かに存在するけど、
「面倒」というだけで「解決できない問題」というのは存在しないし、NLLが欲しくなるケース
自体も「時々」程度で「いつも」ではないので、「それがないと絶対に困る」って程ではない。
それに「クソみたいな回避テク」とか大袈裟に言ってるが、
せいぜい1~3行程度の少しばかり直感的ではないコードが増える程度。
never typeに関してもunreachable!マクロは使えるんだからそれほど問題にはならない。
「言語としての体をなしていない」ってのはあまりにも大袈裟すぎる。
どっちもnightlyでは既に使えるんだから多分そのうちstable化されるだろうし。

**デフォルトの名無しさん** · 2018/04/26(木) 00:22:35.41

>>8
一つのインスタンスを指す変数を二つ以上にしないようにする。
スコープの外にある変数のメンバなどにスコープの内側の変数を代入させない。
（スコープが外れたらインスタンスは解放するルールで統一するため。）

基本はこんなとこ。
これでメモリ開放のタイミングについて困ることが減る。

**デフォルトの名無しさん** · 2018/04/26(木) 06:42:47.13

>>20
結構コードに制約が大きそう。
これって幸せになりそうな制約になる？
いまいちピンとこなくて、、、

**デフォルトの名無しさん** · 2018/04/26(木) 08:51:52.99

>>21
メモリ管理にGCが要らない、かな。
直接の生産性へのメリットよりも、コンパイル結果が正しくて速くて省メモリな事のメリットの方が大きいかと。

**デフォルトの名無しさん** · 2018/04/26(木) 09:07:01.95

実際には大して速くもなければ省メモリでもないけどねRust
もっとコンパイラ頑張れよ

**デフォルトの名無しさん** · 2018/04/26(木) 09:35:53.93

>>23
C++と張り合えるレベルでGoよりは全然速いし省メモリ。
コンパイラもまだ改善の余地がある。ポテンシャルとしては十分だろ。

**デフォルトの名無しさん** · 2018/04/26(木) 09:38:23.42

RustでもDでもなんでもいいからさっさとC++を駆逐してくれ

**デフォルトの名無しさん** · 2018/04/26(木) 09:50:30.78

Rustの人
コードは面倒になるがオーバーヘッド無しでオーナーシップがどうのこうの

c++の人
遅くてもいいところは楽して shared_ptr で済ませとくか

**デフォルトの名無しさん** · 2018/04/26(木) 14:05:39.94

>>24
もしかして小さいメモリしか乗っていないような組み込み系でrustが活躍する可能性がある？
メモリオーナーシップモデルはswift5 or 6で乗ると聞いてるし、それでiOSアプリの省メモリ化が進んだらかなりすげーってなりそう。

でも、ロジックの書き方に制約が強そうで、
それがコードの見通しに寄与するなら良いんだけど、そもそも学習コストがヤバそう。