2025-01-04
Rustのわからんポイント
過去に何個か一人でCLIツールを作ったことがある。そのときに雰囲気で乗り越えてしまいストレスの少ない綺麗な書き方を知りたかった概念をあげる。
- エラーハンドリング
- 参照周りの型変換
- 特にパターンマッチやforループ、関数定義で
&
記号を書く構文特有の意味があるときがよくわからない
- 特にパターンマッチやforループ、関数定義で
- ライフタイム
- 実用的に我々はどんな塩梅で書くのが良いかとか、誰が所有するのが良いかを判断するためのベストプラクティスを持っていない
- トレイトの勘所
- ユーザ定義型に機能を実装するときに、どういうインターフェースを持たせるか迷う。どのようなトレイトを実装するかを決められない。クライアントとしての標準を知らないのでサーバとして何を提供するか、常識をもとに判断できない
深夜にAIに仕事をどれくらい奪われるか考えたときのメモ
要件を定めてそれを保証する仕事がソフトウェアエンジニアの仕事になるだろう。それだと単発の仕事か。進み方を把握して、それを促進する作りにする必要はあるはず。
プログラムの開発(状態や環境に反応するソフトウェアの開発)自体は生成AIによって簡単になった。要求や要件を実現することしかまだ生成AIのブラックボックスに入れられていない。要求や要件の整理の道具として生成AIを利用してはいるが、
これからは生成したプログラムに対して保証された機能の制限が大事になってくるだろう。プロダクション環境で動くプログラムを見る人間は減り、その代わりにソフトウェア検証、パーミッションの制限で安全性を保証したり、デモで振る舞いを確認する未来がくるだろう。ソフトウェアを実装するコストが低くなり、つまりソースコードに向き合う機会が減り、コードの振る舞いを静的に理解しなくなっていく。あるいは言語を高級にするだろうか。言語にどんな性質があると幸せ?
生成して良い言語に良い性質を持たせることはありそうなアプローチ。
続き
仕事は確かにたくさん奪われそうだけど、契約をデザインして(うまくそれを表現することを含む!)プログラムを作り上げる営みは楽しいからずっと続けると思う。