次世代言語26 TypeScript Swift Go Kotlin Nim

**デフォルトの名無しさん** · 2022/06/21(火) 09:27:46.30

スレタイ（順番はRedMonk準拠）以外の言語もok

※　Rustは現世代最強言語なので除外します

前スレ

次世代言語25 TypeScript Swift Go Kotlin Rust Nim
https://mevius.5ch.net/test/read.cgi/tech/1650185555/

**デフォルトの名無しさん** · 2022/07/21(木) 13:47:41.33

色んな言語をやってきてRustが特に難しいとは思わなかった
むしろ便利さと書きやすさで気に入った
他の言語より抽象化されてる感じが良いね
そこが頭の弱い人には逆に難しく感じるのかも

**デフォルトの名無しさん** · 2022/07/21(木) 13:53:10.37

>>167
C/C++はごく最近は抽象的な扱いのものの導入も増えつつあるけど
元がダメだからボロ屋の上に建て増し違法建築みたいになっちゃってる
基礎がしっかりしているRustはその点でも良いね

**デフォルトの名無しさん** · 2022/07/21(木) 14:00:17.21

C++はmove semanticsの建て増し感が特に厳しいな
後付するならあれしかなかったのは分かるけど
そこがちゃんとしてるというだけでもRustの方が楽に感じる

**デフォルトの名無しさん** · 2022/07/21(木) 14:02:26.54

RustのC++との相互運用性を改善する方向性で頑張ってくれたらよかったのにな
C++の保守専用言語なんか普及するわけないじゃん

**デフォルトの名無しさん** · 2022/07/21(木) 14:11:46.30

>>171
Carbonを新たな開発で使うことはないだろうからC++の保守専用言語という表現いいね

**デフォルトの名無しさん** · 2022/07/21(木) 14:57:52.79

>>168
>色んな言語をやってきてRustが特に難しいとは思わなかった
参考までにやってきた色んな言語を列挙してもらえるかな？

**デフォルトの名無しさん** · 2022/07/21(木) 15:55:40.07

>>166
「CとC++」な。
両方それなりに使えないとRustきついだろ。

**デフォルトの名無しさん** · 2022/07/21(木) 16:06:53.27

そんなにシステムプログラミング言語が必要な事をやってるの？

私の場合は、Pythonでほとんど困らなくて、偶に.net系くらいなもんだから、Rustの話が続いても別世界の話過ぎて、付いていない…

**デフォルトの名無しさん** · 2022/07/21(木) 16:25:46.06

>>174
ぶっちゃけ全然きつくないよ
どの辺がきついと思うのか逆に知りたい

**デフォルトの名無しさん** · 2022/07/21(木) 16:28:02.22

こういう奴が一番危険なんだよな。。実際仕事すると洒落にならんことし始める。

**デフォルトの名無しさん** · 2022/07/21(木) 17:45:24.11

メモリやらリソース管理、分散処理の課題をRust以上まともに解決してない言語だと、次世代って感じしないなぁ。

柔軟さ動的さに極振りだったRubyや、関数型のパラダイムを持ち込んだHaskellとかもなんか新しさがあったわけで。

**デフォルトの名無しさん** · 2022/07/21(木) 18:05:35.14

rubyは目新しさというよりは
perlよりマシっていう感じだったよね実際は
perlよりマシだしOOPLを自称してるし
イテレータがあるしで
（当初は内部イテレータがあるのをウリにしてた記憶）
「ザ・ちょうどそういうの欲しかってん言語」って感じ

**デフォルトの名無しさん** · 2022/07/21(木) 18:09:56.47

Rustわからんって言ってる人ってスタックとヒープを理解してない
せめてメモリのレイアウトぐらい理解しとこうよ

**デフォルトの名無しさん** · 2022/07/21(木) 18:22:38.41

>>180
スタックとヒープの違いやメモリ解放とOSへ返却が違う位は分かるけれど、私にはRustは過剰で難しい。

**デフォルトの名無しさん** · 2022/07/21(木) 18:37:11.06

>>181
わからんならとりあえずヒープは忘れて全部スタックに乗せるというのが良いと思うよ
スタックをつかって所有権を移動させていくプログラミングすれば不要なコピーは起きないし
効率も良い

**デフォルトの名無しさん** · 2022/07/21(木) 18:50:15.74

>元がダメだからボロ屋の上に建て増し違法建築みたいになっちゃってる

まあ同意は出来るが
「C/C++を*まとも*に使える」
という意味の捉え方によるな
違法建築になってるのは「*まとも*に使えてない」人のコード

**デフォルトの名無しさん** · 2022/07/21(木) 18:52:26.12

>>183
やっぱりc++のダメな部分を削ったsmart c++欲しいな。

**デフォルトの名無しさん** · 2022/07/21(木) 18:54:02.97

>>180-181
結局そいういうのC/C++で勉強する訳で
Rust理解するためにC/C++の勉強が必須なら
C/C++でええやんって話に戻る

**デフォルトの名無しさん** · 2022/07/21(木) 19:14:35.47

C/C++をやればスタックとヒープの概念が身につくのであればRustをやってそれらが身につかない理由もないと思うが

**デフォルトの名無しさん** · 2022/07/21(木) 19:18:49.81

>>184
それがRustの狙いでは？

**デフォルトの名無しさん** · 2022/07/21(木) 19:19:07.93

>>185
遠回りになるがそこから始めるのもありかもな
メモリ関連はそれなりの失敗経験がないと体で理解できないから

Cでクソでかい構造体をスタックに置いてしまって
スタックオーバーフロー起こしてシステム停止したり
C++でコピーコンストラクタの実装ミスって
ダングリングポインタ作ってシステム停止したり
デストラクタでdelete忘れてメモリリーク起こして
システム停止したり
それなりの地獄を味わってる俺が言うんだ間違いない

**デフォルトの名無しさん** · 2022/07/21(木) 19:44:43.35

趣味プログラミングならどんどん変なことしてクラッシュさせれば良いけど
業務ならもっと安全を期したいなぁ

**デフォルトの名無しさん** · 2022/07/21(木) 19:52:05.48

> それなりの地獄

かわいい地獄でつねｗ

**デフォルトの名無しさん** · 2022/07/21(木) 19:54:55.78

C/C++のよくある業務ってやっぱり組み込み？
それかゲーム開発？

**デフォルトの名無しさん** · 2022/07/21(木) 20:25:53.32

無料で答える業務はない

**デフォルトの名無しさん** · 2022/07/21(木) 20:54:05.56

>>175
Pythonは約10倍くらい遅い
メモリも喰う
ガベージコレクションもある
まともな並行並列プログラミングが大変
Pythonは小さなバッチ的スクリプトの範囲でのみ使うのが正解

**デフォルトの名無しさん** · 2022/07/21(木) 21:04:39.89

>>191
スマホの課金ゲームのバックグランド鯖の開発とかもあるよ

**デフォルトの名無しさん** · 2022/07/21(木) 22:23:39.66

PythonやJavaScript書くときはでかいアロケーションの有無くらいしか意識しないけど
C#やSwift書くときはvalue typeとreference typeの使い分けがあるからスタックとヒープもそれなりに意識する
Goの場合は気になるところでescape analysis

**デフォルトの名無しさん** · 2022/07/21(木) 23:33:08.48

三角関数や薬剤師の存在を意識してる人は大体が
「コスト」を強く意識した方がメリットが大きいと思い込んで意識している

**デフォルトの名無しさん** · 2022/07/21(木) 23:43:19.63

自分でも何を書いてるのか理解できてなさそう
思い込んで意識するというのも意味不明

**デフォルトの名無しさん** · 2022/07/21(木) 23:53:17.15

>>195
PythonやRubyやJavaScriptなどのオモチャ言語しか使ったことのない人だけがスタックとヒープを意識しないわけか

**デフォルトの名無しさん** · 2022/07/22(金) 06:54:41.09

コンピューターの動作を隠蔽すればオモチャに近づくのなら究極的にはアセンブラ以外は全てオモチャなのではないだろうか

**デフォルトの名無しさん** · 2022/07/22(金) 07:02:16.68

アセンブラはスタックやメモリーにアクセスするプログラムを書かされる。
Cはメモリーにアクセスするプリグラムを書かされる。

Javaはスタックもメモリーも意識する必要がない。
すなわちJavaが最も優れている。

**デフォルトの名無しさん** · 2022/07/22(金) 07:23:24.99

>>199
メモリについてもそれ以外についても
抽象度が高い方がプログラミングしやすい
アセンブラよりもスタックとヒープというメモリについての抽象化をした言語の方が扱いやすい

一方で過度の抽象化は実用性を失う
例えばメモリとローカルディスクとネット上のディスクを全て統合して一つの巨大なメモリ空間に抽象化すると
巨大なメモリ空間を扱う極一部の用途を除いて過度の抽象化となってしまい速度差があるものは別々のままの方が好ましい

スタックとヒープを意識せずに済むPythonやRubyやJavaScriptなどの言語も同様な面がある
スタックとヒープには速度差があるため速さを重視する用途から見ると過渡の抽象化といえる
速さを重視せず意識しない用途をオモチャ用途と呼ぶならばPythonやRubyやJavaScriptはオモチャ用途すなわちオモチャ言語とも言えないことはない

**デフォルトの名無しさん** · 2022/07/22(金) 08:16:15.80

>>187
サブセットが欲しいのであって、併用できないのは要らん。

**デフォルトの名無しさん** · 2022/07/22(金) 08:17:52.69

おもちゃ程度の事しかしないので、おもちゃ言語で困ってないんだよね。

Rustが、安全で効率良い速いって言われても、書き捨てのPythonでも10秒程度で処理が終わってしまうようなものだと、わざわざRustでってならないさ。

システムプログラミング向け次世代と、もっと緩いおもちゃ向け次世代みたいな感じに分けないと、話が噛み合わない気がする。

**デフォルトの名無しさん** · 2022/07/22(金) 09:02:33.80

>>198
動的言語コンプレックス恥ずかしい

**デフォルトの名無しさん** · 2022/07/22(金) 09:15:01.41

>>202
ダメな部分を使わなきゃいいだけじゃね？
間違って使うというならチェックツール作ればいい

**デフォルトの名無しさん** · 2022/07/22(金) 09:57:43.45

だからOS、ドライバとかの低レイヤーとWebみたいなのを分けて考えるべきだろ

何でもかんでもRustとはならない
適材適所

**デフォルトの名無しさん** · 2022/07/22(金) 10:34:06.65

コンパイル時のメタプログラミングを駆使すると実行時の電気代が安いんよ
ランニングコストを情報隠蔽とはならない

**デフォルトの名無しさん** · 2022/07/22(金) 11:20:36.22

>>202,205
どちらも一理ある

>>203
>システムプログラミング向け次世代と、もっと緩いおもちゃ向け次世代みたいな感じに分けないと、話が噛み合わない気がする。
一種と二種みたいなもんだな

**デフォルトの名無しさん** · 2022/07/22(金) 11:22:08.43

>>207
SDGsという言葉は胡散臭くて嫌いだが
SDGsの観点から言っても良質のコードを描くことは絶対地球に優しいよな

**デフォルトの名無しさん** · 2022/07/22(金) 11:39:15.65

Cのプリプロセッサの存在自体が納得できない人のために
マクロ言語ではなく型システムなら納得できるだろうとなったのがC++
コンパイラではなくインタプリタに近い方式なら前処理が無くなるだろうとなったのがPython

**デフォルトの名無しさん** · 2022/07/22(金) 11:45:23.20

>>205
それを他人に強制できる、標準orデファクトとして確立したものが欲しい、ということだよ。
コーティングスタンダードでもいいんだけど、独自に作るのは重たいし、教育するのも大変だから、出来合いのものが欲しいところ。

**デフォルトの名無しさん** · 2022/07/22(金) 11:59:28.82

>>211
>それを他人に強制できる、標準orデファクトとして確立したものが欲しい、ということだよ。
くだらない理由だな。お前の人集めが酷いだけだろ。

**デフォルトの名無しさん** · 2022/07/22(金) 12:21:12.21

>>207
メタプログラミング駆使しなくても静的に書けば実行時の電気代が安くなる

そう、COBOLならね

**デフォルトの名無しさん** · 2022/07/22(金) 12:23:13.63

>>212
コストとか単価を気にしない富豪はうらやましいですなぁ。

**デフォルトの名無しさん** · 2022/07/22(金) 12:46:18.43

>>167
＞その通り
＞で結局C/C++でええやんという話に戻る

お前の後輩の中のダメな奴にコード書かせてもそう言えるのか？

**デフォルトの名無しさん** · 2022/07/22(金) 12:47:04.23

>>211
適当なリポジトリからclang-tidy等の静的検証ツールのルール設定をパクってくるとかはどうですか

**デフォルトの名無しさん** · 2022/07/22(金) 13:32:14.29

趣味のコミュニティなら駄目なコードはどんどん捨てる富豪になれば問題ないけど
趣味じゃない場合は貧乏というかケチになる

**デフォルトの名無しさん** · 2022/07/22(金) 14:03:33.19

>>211
だからチェックツール作れよ
CIでチェック通らなきゃビルド不可にしときゃいいだけだろ

**デフォルトの名無しさん** · 2022/07/22(金) 14:30:36.22

いやケチるなら余計に人は選べよ。

**デフォルトの名無しさん** · 2022/07/22(金) 15:07:10.50

>>207
サーバーコスト(クラウドコスト)を考えると使う言語を変えることで速さと省メモリにより数倍～十数倍差が出るのは大きいもんな
あとは避けられる実行時エラー(例外含む)をできる限りコンパイル時に静的に解決したいわけだろ
ならばRustがベストチョイス

**デフォルトの名無しさん** · 2022/07/22(金) 15:17:47.41

>>206
むしろWebはRustむけ

**デフォルトの名無しさん** · 2022/07/22(金) 17:13:14.54

Webという括り方が雑すぎる

**デフォルトの名無しさん** · 2022/07/22(金) 17:45:58.45

どうせあれとあれを区別出来てないんだろうな

**デフォルトの名無しさん** · 2022/07/22(金) 18:08:11.96

そのうち、HTMLやCSSのコーダーが、Rustで書き始めるわけか。
テスト工数は減らなさそうだし、制作費上がりそうで嫌だなぁ。

**デフォルトの名無しさん** · 2022/07/22(金) 18:24:55.78

>>221
こちらもWeb関係でRustを使っている

**デフォルトの名無しさん** · 2022/07/22(金) 18:31:07.28

アルゴリズムとデータ(構造)を区別するのやめようって言い始めた人も悪いのだよ

**デフォルトの名無しさん** · 2022/07/22(金) 19:46:38.86

型推論がモダンなら、動作推論でスタックヒープ最適化ぐらいあって良いのではないか

**デフォルトの名無しさん** · 2022/07/22(金) 21:07:06.38

>>227
そう、Goならね

**デフォルトの名無しさん** · 2022/07/23(土) 00:56:36.98

>>228
コンパイル時になるべく静的に解決して実行時の負荷をゼロもしくは可能な限り少なくしたいのに
Goはその真逆で実行時の負荷が大きい(ランタイムがデカい)から好ましくない

**デフォルトの名無しさん** · 2022/07/23(土) 07:49:46.21

もしかして、Rust製のWordpressみたいなCMSあったりします？

**デフォルトの名無しさん** · 2022/07/23(土) 08:34:42.30

こういう奴に限ってロクなアルゴリズム書いてない、遅いうえに負荷だらけなのはお前のせい

**デフォルトの名無しさん** · 2022/07/23(土) 08:45:37.01

>>229
で、それをWebに適用したがる理由は？
なんのメリットがあんの？

**デフォルトの名無しさん** · 2022/07/23(土) 09:08:24.13

なくはないが、1要素に過ぎない
そういうやつに限って実行環境について無頓着で、クソ巨大なコンテナイメージ作ったりするし

**デフォルトの名無しさん** · 2022/07/23(土) 09:12:35.67

IOバウンドが主体の現代プログラムで積極的にRustを採用したがる理由がわからない
OSやドライバみたいな低レイヤーならわかる

**デフォルトの名無しさん** · 2022/07/23(土) 09:30:42.73

>>234
単一のリクエストの処理についてはその通りだけど、
1ノードで同時に処理するリクエストが増えていけばCPUまたはメモリが上限に達してスケールアウトが必要になる
つまりCPUやメモリの消費を削減することでノード数を少なくでき、コストを抑えられる
まあ現実にはDBや人件費の方が金かかるから大した効果はないんだからね

**デフォルトの名無しさん** · 2022/07/23(土) 10:35:13.77

>>234
IOバウンドが現代プログラムの主体というのはさすがに特定分野しか見てなさ過ぎ

**デフォルトの名無しさん** · 2022/07/23(土) 11:04:56.52

最近覚えたIOバウンドって言葉を使ってみたかったんだろうな
って感想しかない

**デフォルトの名無しさん** · 2022/07/23(土) 11:22:01.68

>>235
NodeやGoに比べて何%効率がいいの？なんかデータある？

**デフォルトの名無しさん** · 2022/07/23(土) 11:24:44.12

このスレにいるなんでもかんでもRustにしろおじさんはRust使ってる日本の企業是非あげてほしい

**デフォルトの名無しさん** · 2022/07/23(土) 11:37:34.85

MirakurunとMirakcとか見ればわかるけどメモリ効率が劇的にRustは優れてるけどCPUは大して変わらない
そこにコストをかけるモチベーションがどこまであるかって話じゃないの、録画サーバーはラズパイとか低スペPCで動かすっていうモチベーションがある

Rust推しの人はなんで実行コストのばかり話をして開発効率を軽視するのか？OS開発以外で企業で使われることはほとんどないだろうね。

**デフォルトの名無しさん** · 2022/07/23(土) 11:37:55.41

>>238
その2つを同列に並べるなよ
RustとGoの差よりNodeとGoの差のほうがはるかに大きいぞ

**デフォルトの名無しさん** · 2022/07/23(土) 11:39:54.42

>>239
ボッチの自宅開発者にそういうの求めるのは酷

**デフォルトの名無しさん** · 2022/07/23(土) 11:50:03.97

>>240
実行コストは情報隠蔽ができない高水準のスペック
だが開発コストは隠蔽できるので
低レイヤーの事情をいちいち考慮して右往左往したくないんじゃないかな

**デフォルトの名無しさん** · 2022/07/23(土) 11:56:58.24

>>240
開発効率の話は客観的な比較難しいのでは
なんか良い指標ある？

**デフォルトの名無しさん** · 2022/07/23(土) 12:26:01.80

>>244
普通にIPAが白書出してるよ
残念ながらRustは主要開発言語には入ってないけど
https://www.ipa.go.jp/ikc/publish/whitepaper_dl.html

**デフォルトの名無しさん** · 2022/07/23(土) 12:54:16.63

>>245
それ見ると指標はFPかSLOCだけ
しかも両方とも主開発言語による有意な差はないという結論

調査方法を考えれば当たり前の結論だけどね

**デフォルトの名無しさん** · 2022/07/23(土) 12:56:45.10

そもそもIPAが土方のやり方を推奨してるのが問題

**デフォルトの名無しさん** · 2022/07/23(土) 13:05:43.74

主観的にはRustはかなり開発効率高い
言語そのものもいいし周辺のエコシステムもいい
学習コストなんて二束三文だし

**デフォルトの名無しさん** · 2022/07/23(土) 13:09:35.85

ScalaやHaskellでも同じこと言ってた

**デフォルトの名無しさん** · 2022/07/23(土) 13:14:10.92

他の言語で、初期化と代入の違いを学習したコスト
初期化時には参照カウントが2以上にならないという事実を認識するコスト

こういうのはRustの学習コストにはあたらない

**デフォルトの名無しさん** · 2022/07/23(土) 14:13:31.48

今更な話じゃなく次世代言語の話してくれ。

**デフォルトの名無しさん** · 2022/07/23(土) 14:30:45.45

現状Rustはライブラリの選択と学習と継続的な監査のコストが著しく高い
速度やリソース面でそれを補って余りあるメリットがあるようなシステムにしか採用されない

言語だけでみればライフタイム周りの煩雑さがある分だけC#よりもやや面倒という程度

**デフォルトの名無しさん** · 2022/07/23(土) 14:41:37.43

rustが向いてるのは明らかにミドルウェア層だわな。
アプリ層で使おうとするとかまともに仕事で使ったことない奴の戯言でしかないわ。

**デフォルトの名無しさん** · 2022/07/23(土) 14:51:11.37

>>246
> しかも両方とも主開発言語による有意な差はないという結論
どこをどう読んだらそんなアホな結論に達するんだ？
https://i.imgur.com/OQpwGw9.jpg

**デフォルトの名無しさん** · 2022/07/23(土) 15:00:55.50

むしろメモリ効率こそ現代の言語で重要なんだぞ？
CPUの性能は頭打ちというのを知らず？
機械学習みたいな行列演算するなら別だが普通のシステムプログラミングやWebアプリ、組み込みみたいな要件ではコアのパフォーマンスなど無意味

スクリプト言語みたいなGCコテコテの言語が速いことは絶対にない
現代のメモリアーキテクチャを知ってればあんなに参照を作りまくって
オブジェクトに触りまくって速いわけない
それはGoも同じ
現にGoは遅い
現代の言語での要件はスタックとヒープをプログラマが明確に意識でき
かつメモリ管理を安全にできる
これができているのは今のところRustのみ

**デフォルトの名無しさん** · 2022/07/23(土) 15:14:50.07

>>255
DockerとかKubernetesとかコンテナ技術を活用してマシンのリソースを有効活用するって流れになってるのはそうだけど
Rustで置き換えるってのは聞いたことがないな

> スクリプト言語みたいなGCコテコテの言語が速いことは絶対にない
それはIO待ちがほとんどないCPU処理が主体なプログラムでの話じゃない？
Goは適当に並行処理書いても極力処理がブロックしないように動作するけど
Rustは中断ポイントを自分で記述する必要があるから注意して書かないとGoより遅いなんてことはザラにある

このスレッドにあるベンチマークとか見ればいかにGoが優秀であるかがわかる
https://www.reddit.com/r/rust/comments/lg0a7b/benchmarking_tokio_tasks_and_goroutines/

IO待ち主体のプログラムはいかにブロックせずに処理するかが大事なのであってメモリ効率がボトルネックになることはないわ

**デフォルトの名無しさん** · 2022/07/23(土) 15:31:18.71

>>255
そういう特定のユースケースの話をしてるわけじゃないよ
そりゃベンチマークによって速かったり遅かったり
特定のエッジケースで速かったり遅かったりはあるでしょう

もっと数学的かつ抽象的に考えよう
ヒープにオブジェクトが1000個あります
しかしそのうち本当にヒープに乗せる必要があるオブジェクトが100個しかありませんでした
本来ヒープに100個しか必要のないオブジェクトなのに無駄な
ヒープアクセスが900個も起きてしまう
これをメモリ効率が悪いという
Goでもこれは起きうる
もちろんそれが*起きないように*書くこともできなくはないが
エスケープ解析などをしないとわからないし非常に難しいでしょう
しかしrustではこのようなことは起きない

**デフォルトの名無しさん** · 2022/07/23(土) 15:31:55.55

レス番間違えた

**デフォルトの名無しさん** · 2022/07/23(土) 15:40:38.68

自演失敗お

**デフォルトの名無しさん** · 2022/07/23(土) 16:04:31.85

>>257
> 無駄なヒープアクセスが900個も起きてしまう
> これをメモリ効率が悪いという
お前はまず用語をちゃんと使えるようになってから出直してこい

**デフォルトの名無しさん** · 2022/07/23(土) 16:08:37.49

>>260
よくわからない
何が間違ってるの？

**デフォルトの名無しさん** · 2022/07/23(土) 16:14:43.93

>>252
ライブラリの選択コストが低い言語ってのは標準ライブラリがでかい言語のこと？

**デフォルトの名無しさん** · 2022/07/23(土) 16:22:30.56

>>261
アクセス回数の話なら実行効率
メモリー効率は必要とされるメモリーの量

**デフォルトの名無しさん** · 2022/07/23(土) 16:33:12.53

自演rust狂信者の圧倒的な敗北.....
Rc<T>で無駄なメモリアクセスが起きてることを分かってない。参照カウントで、かなり無駄なカウントアップ・ダウンが現実に起きてるし非効率。
エスケープ解析なんぞでわかるのはほんの一部、goでメモリアクセスが遅めに見えるのは、goroutine間の変数への排他制御が無いからだしGCのせいでもない
古典的なメニーコアを素直に活用できない言語では起きない事を同じ土俵で無理に比べようとしている
確かにgoやrustがstructを使って、javaのようにobjectではないのはメモリー効率を考えているけど、ピープなんちゃらの説明はホントに
分かってないアホの説明。GCで掃除される対象の変数へのアクセスのことを言いたいのだと思うけど、そんなのアクセスするかはGCアルゴリズム次第だ
1回でいいから参照カウントの欠点を調べてこい

**デフォルトの名無しさん** · 2022/07/23(土) 16:47:16.76

AndroidアプリをKotlinベースで作っているんですが、
一定時間スマホ操作ができなくなるような機能を作りたいのですが、どうやればできますかね？
いわゆるデジタルデトックスアプリみたいに、一定時間画面を覆って操作できなくなるアプリ
（バックグラウンド写ったりしないやつ）を想定してます

**デフォルトの名無しさん** · 2022/07/23(土) 17:07:56.92

>>263
無駄なヒープアロケーションが900あるって書いてあるやん
>>257の文章は気持ち悪いけど
そういうことは起きうるよねとは思うよ

**デフォルトの名無しさん** · 2022/07/23(土) 17:11:14.32

>>265
セキュリティ的に問題があるから無理
何もできないホームアプリを作って設定するくらいじゃないかな
それでも抜け道を完全に防ぐことはできないと思う
奥の手としては、バックグラウンドサービスでマルチスレッドで無駄な計算をぶん回して使用に耐えないくらい重くすればいい

**デフォルトの名無しさん** · 2022/07/23(土) 17:30:04.86

>>266
> 無駄なヒープアロケーションが900あるって書いてあるやん
お前プログラマに向いてないだろ...
書いてあるのは
> 無駄なヒープアクセスが900個も起きてしまう
な