Help us understand the problem. What is going on with this article?

Null安全な言語をめぐるエトセトラ その1 3種の「現場」

More than 3 years have passed since last update.

ちょっとポエムを。最近、null 安全 (null safety)をめぐる、かなり力の入ったエントリーが界隈の人々の間でバズっている模様。
今のところ、主には、iOS界隈の人はもはや外せない選択肢であるSwiftのnull安全な記法が話題の中心かな。

これから、各言語の年末のAdvent Calendarのかっこうのネタとなっていくのかも、と、なんとなく読み流していいたのだけれども、今腰掛け的にいるAndroid案件の現場のテストフェーズでヌルポ障害(null pointer exception)が発生中であることと、もう少し踏み込む次の案件で、PHP+Javascriptに替えて、Hack+Typescript2という、null 安全な組み合わせの採用をたまたま検討中なこともあって、ちょっと興味が出てきた。ということで、Swift、Kotlin、Typescript2 、RustなどのNull安全な言語が、どのようなシチュエーションで必要とされるのかを、ふつうの現場視点(飛び抜けてすごい人がいるわけではない現場の視点)でちら見しておきたい (...本格的な組込案件はやったことがないので、そのあたりの考察は全く欠けているのであしからず)。

nul安全とは何か、とかは、上のエントリーやその周辺エントリーを見てね。
ちょっとだけ、個人的な思いを書いておくと、こなれたNull安全な言語が普及すると多くの人が少し幸せになれると思う。昔からscala書いてて、null安全でない、ということを意識したことはなかったけれど、確かにnull安全でない書き方も普通に許容されているという意味では、scalaはnull安全な言語に分類されないのだろう...scalaの黒魔術とか良く言われてきたし、null安全なscalaのコードは読みにくかったりするんで、たしかにそうなのかも(scala3.0(?)がnull安全でより簡潔に書ける方向に舵を切ってくれるとうれしいな)。

[1]web開発の現場

ユーザーとブラウザを介してやり取りする普通のweb開発の現場では、Null安全な言語の普及はさほど進まないのではないかと思う。理由は、メジャーな言語の今風のwebフレームワークは一般的に起こりうる場合の安全な書き方についてはベストプラクティスをそれぞれに確立していて、その枠内にいる限りにおいては、ヌルポの類で苦しむことはあまりないから(むしろ、その他の問題の方が多発する)。

とはいえ、コンパイラがnull安全性をチェックしてくれるのはうれしいはず。nodejs界隈の人々がtypescript2を本格的に採用しはじめると、そこにweb開発でのnull安全のベストプラクティスが蓄積されていくのかも。
他方、null安全ではないとされる言語でもnull安全なフレームワークを作ることはできて、scalaで昔使っていたliftwebはいろいろツッコミが入っているフレームワークではあるけれど、null安全への配慮はかなり盛り込まれていて、何度も続いた改修の中で、本番稼働時にヌルポで落ちたことはなかった(はず)。当時から、「Scalaではnullを(原則)使わない」文化参考はそれなりにあって、今は、ふつうのscala使いはnullを必要がないないかぎり使わないだろう。

メジャー言語のwebフレームワークもnull安全を意識した進化を徐々に遂げていき、結果として、住み分けに落ち着くのではないかと予想。

[2]スマートフォン開発の現場

ここでは、Null安全な言語の普及が望まれている。Objective-Cからnul安全なSwiftへのシフトはまさしくその流れだし、Android開発でのnul安全なホープKotlinもまさしく流れを生み出している。

お硬い業務系アプリ開発の現場なんかでも、問題は生じている。例えば、ICカードで認証して基幹システムから情報を受取り、外出先でQRコードで読み取った情報を帳票出力するAndroidアプリをい開発...なんていかにもな業務系案件。業務系案件では、仕様書の体裁揃えなどなどいろいろと開発以外のタスクが多くある中で、ミドルウェア(デバイスドライバなど)の仕様と実装をきめ細やかにチェックする時間が取れなかったりする。そうなると、QRコード読取など、スレッド間のタイミング調整がシビアになる場合に、機種依存のヌルポが多発したりする。こうした問題を、SwiftやKotlinは軽減していけるのかもしれない。

ただ、iOSの普及はシェアは諸般の事情で頭打ちだろうし、受託業務系のJavaな開発現場で、発注主に対し次のKotlinで行きましょうと説得できる人が少なそうなところが、null安全な言語の普及の足かせになるのかも。

[3]IoT,fintech、そして、ブロックチェーン案件の現場

話は飛んで、今のときめくバズワード、IoT,fintech、そして、ブロックチェーンにまつわる案件の現場について。
このあたりは、ベストプラクティスが確立していないだけあって、状況が許せば、開発環境はなんでもありになるのではと思う。
このIoT案件はC+Null安全なnimでいきましょう、fintechアプリのクライアントはtypescript+nativescriptで書くのが1番安上がりっす、ブロックチェーンアプリといえばこれからはgoでしょ、的な。...Goは分類上、型安全な言語ではないとされるだろうけど。

IoT,fintech、あるいは、ブロックチェーンで「稼ぐ企業」が、Null安全な言語を採用した場合、それがきっかけで、いずれかのNull安全な言語が伸びるのではないかと予測。

続きは...

今、Null安全ではない言語でスマートフォン開発をやっていて、これから、null安全な言語(Hack+typescript)でweb開発をちょっとだけする。その後は、IoT+ブロックチェーンな案件をすることになりそう。ということで、上の[1]~[3]のいずれかに関する考察をしていきたい。

個人的な好みはnull安全でない、とされるscala+dartの組みあわせなので、null安全とされない言語の逆襲、的なことも書けるならば書いてみたい。
...いやでも、null安全で書きやすい言語のどれかが、ガツンと普及してほしいなとも思うよ^_^ そのきっかけは、あえて一択とするならIoT開発の現場から。

e-a-st
普段は外資の医薬系データエンジニア。
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした