Scala の trait と Rust の trait は微妙に使い方が異なる、とよく質問を受けます。たしかに、使い心地は微妙に異なるかもしれません。Scala はオブジェクト指向を中心に設計された言語ですが、Rust はそれを中心に設計されているとは言えません*1。こういった言語設計の差が、trait の使い心地の違いを生み出していると私は思っています。 両者の trait には、共通した特徴もあります。共通した処理をまとめあげるという意味では同じ目的をもっているといえますし、また、「犬は動物である」「猫は動物である」の共通性を示すことで、共通したものをひとまとめに処理しきることもまた可能です。 Scala には implicit という強力な機能が存在します。これは柔軟でスケーラブルなソフトウェアデザインを可能にする Scala の特徴のひとつです。非常にすばらしい機能です。この機能

Javaな人から見ると、「Scalaって難しい」ってイメージがありますね。俺も最初はそう思ってました。今もですけど。 で、考えてみたんですが、何が難しいって考え方・イディオムになじみがないのが原因かと思ったんです。 ここでは、俺が今までScalaをやってきて得た考え方を紹介します。「Scalaをちょっとやってみたんだけど、とっつきにくくて…」と思われている方は、ぜひご一読ください。 参考資料: Scala入門 - Scalaで書きはじめたJava使い向け - Scala勉強会＠東北 Dropbox - 404 神は言われた。「リストあれ。」 Lisperは、リストをどう作るかをまず考えるらしいです。適切なリストが出来たら、プログラムはもうできたも同然だと。同じ考え方は、Scalaでも通用すると思います。 大まかに、こんな流れで考えてます。(リストは最初から与えられることもあるでしょう) 「

Scalaで開発をしていると様々な場面で Collection を使うことがあると思うが、Collection と言ってもScalaには多くの種類のクラスが存在する。 しかも、その種類はかなり多いうえに分類も大変だ。 まず、mutable　なのか imutable。 さらに IndexedSec　なのか LinearSec なのかでまったく用途や使い方が違う。 私自身もそうだが、Java から来た人は覚えること多く結構戸惑ってしまうのではないだろうか。 ・scala.collection.immutable パッケージ内の全てのコレクション ・scala.collection.mutable パッケージ内の全てのコレクション 上記の各クラスのメソッドの種類や内容を紹介している記事やブログは多いのだが、どのクラスをどの場合に使えばいいのか、どういった用途にあっているかをまとめた内容が見当たら

こういう人は、あとあと処理が詰まったり理解できない挙動が起きたりして困るので注意。 よくわからないけどコンパイル時に怒られるので import scala.concurrent.ExecutionContext.Implicits.global を書いている Future.apply は 「スレッドを立ち上げて非同期に実行する」と理解している 特に何も考えず Future 内で Thread.sleep をしている ExecutionContextとは Future#mapやFuture.applyにimplicitパラメータとして要求される*1ExecutionContextって何なのか？ 何か渡さないといけないからとりあえず import scala.concurrent.ExecutionContext.Implicits.global と書いている人もいるんじゃないだろうか。 Ex

先日のScala Days 2019の基調講演などでも触れられた通り、いよいよDottyあらためScala 3のリリースが近づいて来ました。既にScala 3の仕様のかなりの部分は、Dottyとしてユーザが利用できる状態になっています。この記事では、Scala Daysでの講演スライドおよびDottyに関する各種資料を元に、Scala 3の新機能や変更点について紹介します。 あいさつ Scala 3について Dottyとは Scala 3の新機能 Top level definitions Creator applications Multiversal equalities Extension methods Enums Implicitの見直し Type classes # 2019年9月30日追記: Implicit conversions Implicit function typ

Scalaでnullを使っていいのは小学生までだよねー、というのは冗談ですが、Scala文化圏ではnullを使わないのが原則です（いくつか例外はありますが）。代わりに出てくるのがOption型です。しかし、Scalaでは困ったことにnullを返すJavaのメソッドを呼び出さなければいけない場面がたくさんあります。 たとえば、以下のようなコードを書かなければいけない場面にはしばしば遭遇します。 val javaMap: java.util.Map[String, String] = javaObject.getMapping() val value: String = javaMap.get(key) // 型注釈はあえて付けている if(value != null) { ... } else { ... } さて、ここで困るのが、javaMap.get(key)はkeyに対応する値が入って

"Scala Future" で検索して出てくるFutureの解説は、Scala公式サイトのドキュメントを除いて大体こんな感じで紹介されてることが多い。 import scala.concurrent._ import ExecutionContext.Implicits.global Future { Thread.sleep(1000) println("hoge") } println("fuga") //-> // fuga // hoge こういうFuture.applyにThread.sleepやIOのblockingをする例って非常に悪いと思っている。まるで、Futureでsleepするのが普通のコードっぽく見えるじゃん。違うの、単に説明の時に楽だからsleepしてるだけなの。説明コードが短くてすむの。ちょっと使ってるだけ。プロダクトコードでsleepするのやめろ。うわあ！！

ちょっと今日は疲れてるので、表題の件について、簡単に書いてみる。私の経験上、型クラスにおける、最も多い誤解は、(Javaとかにおける）インタフェースのようなもの、というもので、これはかなり多くの人にみられるように思う。 まず、そもそも、何故そういう勘違いが生まれたかを考えてみると、「インスタンス」「メソッド」といったオブジェクト指向言語にもある用語が使われていること、また、両者とも「操作の集合を提供する」という特徴があるためではないかと思う。しかし、根本的な違いがある。一番大きなものは、型クラスは（一般的には）レシーバ（thisといってもselfといってもなんでもいいが）とそれに付随する状態が基本的に存在しない、という点だ。 この点について、Scalaの標準ライブラリにおいて、両者の違いを説明するのに格好の例がある。OrderingとOrderedだ。混乱を避けるために先に説明しておくと、

今日はScalaの例外処理について解説しますよ。 基本 - try,catch,finally 例外処理の基本は、try,catch,finallyです。これはJavaと同じですね。 ただし、Scalaでのtry,catch,finallyは値を生成します。つまり、実行されたブロックの値が評価されます。 scala> val n = try{ "99".toInt } catch { case e:Exception => -99 } n: Int = 99 scala> val n = try{ "foo".toInt } catch { case e:Exception => -99 } n: Int = -99 上記のように、catch節には "case e:Exception => ..."のようなパターンマッチを書くことで、対応する例外の型に応じて補足することができます。try,

今日は、ScalaのOptionの使い方について解説しますよ。OptionはScala使いにとってはなくてはならないものです。これを覚えてしまうと他の言語でもOptionを作りたくなる、かもしれない? Optionってなに? Option型は、値があるかないか分からない状態を表すものです。「Maybeモナド」とか言ってしまうとアレですがまぁそんなようなものらしいです。 Optionの定義 まずは、Optionの定義から見てみましょう。Option型は、抽象クラスOption[+A]と、Option[A]を継承して値がある場合のSome[+A]型とNoneオブジェクトがあります。 Option - Scala Standard Library API (Scaladoc) 2.10.0-20120530-022829-8d38079ab4 - scala.Option // Optionの抽

Scalaには、PartialFunctionというものがあります。 直訳すると部分関数ですが、これはなにかっていうと「特定の引数に対しては結果を返すけど、結果を返せない引数もあるような中途半端な関数」です。 どうやって使うのん? まぁ、ちょっと例を見てましょうや。PartialFunctionであるfooPfは、引数が"foo"だったら"bar"を返して、"foo"以外は知らんというてきとーな関数です。 scala> val fooPf:PartialFunction[String,String] = { case "foo" => "bar" } fooPf: PartialFunction[String,String] = <function1> scala> fooPf("foo") res5: String = bar scala> fooPf("hoge") scala.Mat

Scala に挑戦してみました。 Mojolicious でアプリケーションをつくってみた① - yujiro's blog で作ったのと同じメモ帳アプリケーションをScalaとPlayframeworkを使い作ってみました。 結構時間かかりました。難しかった。 ソースコードは以下にあります。 github.com 一応、機能的には ログイン機能 belongsTo, hasMany, manyToMany アソシエーション ページング Form（バリデーション有り） などあるので、これを見れば一通りのことはできるんじゃないかと思います！ 環境、バージョン OS : Ubuntu14.04 言語 : Scala-2.11.11 （scalaenv） Framework : PlayFramework 2.5 DB : MySQL 5.5 ORM : Skinny-ORM エディタ : Vi

こんにちは、池田です。 Scalaを学習する際や関数の挙動、動作を確認したいときに、REPLを活用しているかと思いますが 上のようにREPLでimportできないライブラリを使えるようにしたい時にどうするればいいのか？ ご存知でしょうか？ 僕はこのようにREPLでimportできないライブラリ(libraryDependenciesが必要なライブラリ)を使う方法を知らず 不自由な思いをしていたので紹介します。 1.REPLを使う2つの方法 2. Scalaコマンドについて 3. sbt consoleについて 4.それぞれのユースケース 1.REPLを使う2つの方法 まずREPLを使うときに2つの方法があります。 scalaコマンド を使う方法とsbt consoleを使う方法です。 ※Ammonite REPLという通常のREPLよりもより豊かなシェル環境を提供する代替REPLもあります

はじめに こんばんは！ 突然ですが、 Scala における fold と foldLeft はほとんど同じものだ！と思っていませんか？ また、Scala の Option#fold メソッドを使って、何か不自然に思ったことはありませんか？ 先に結論を述べますと、 fold メソッドと foldLeft メソッドは異なります（もちろん foldRight とも違いますよ！）。 「ちょっとだけ挙動に差が…」的な違いではなく、根本的に違います。 たまたま、 List#fold と List#foldLeft が（例外的に）似たような定義で、かつ（例外的に）似たような挙動をするため、誤った通説（全てのfold≒foldLeft）があったりなかったりするようです。少なくとも僕は、Scala を書くようになってからある一定の期間、全ての fold と foldLeft は同じものだと考えていました。

利用方法はとても簡単で、カリー化された第一引数にアキュームレータの初期値を渡し、第二引数に関数を渡します。 List(1, 2, 3, 4).foldLeft(0) { (acc, x) => acc + x } // -> 10 "abcd".foldRight(Nil : List[Int]) { (x, acc) => x :: acc } // -> List(97, 98, 99, 100) コレクションAPIに定義されているほとんどのメソッドは、 foldLeft か foldRight を用いて実装することができます。上記の foldLeft のコード例などは、 sum (総和) 関数そのものですね。 さて、それぞれの特徴を比較すると真っ先に目につくのが、foldLeft はスタックセーフな高階関数で、foldRight はそうではない、という点だと思います。それじゃあ、 f