GoとRustの言語比較記事を書くのが流行ってるらしい
コンテキスト 私もGoとRustの比較記事書いてバズるやつやりたい — みょん (@myuon_myon) February 27, 2020 仕事でGoとRustを書いています。いずれもWebのサーバーサイドです。パフォーマンスとかほとほどって感じなので極限までチューニングしたりしません。という前提で読んでください。 Rust/Goはいずれも習得してから2年くらい書いています。書いてる量も多分そんなに変わりません。 Go なんと言っても習得難度が低いので人を選ばず書けるようになります。現状だと仕事で書くなら一番無難な選択肢だなと思っています。一方言語もエコシステムも何もかもかなりクセが強いので、Go Wayにちゃんと従うことが大事だなと思ったりします。 ジェネリクスがないことは高速なコンパイルなど利点もありますがmap,filter等を型ごとにfor文書きまくることになるのでとても手が疲
Fluxを再発明する
Haskellの2D graphics libraryを作った 作った: refluxive 与太話に興味がない人は解説まで飛んでください なにこれ 大体Haskell製Fluxベースの2Dグラフィックスライブラリ on SDLという感じの代物です。 なぜ 大変悲しいことにHaskellではゲーム用に気軽に使えるグラフィックスフレームワークがないことがよく知られているわけです。 候補としては一部のFRP系のやつ、あとDSL系のやつも少々(これは用途がかなり限定されていることが多いけど)、それと今ならElm(!)が下手すると最有力かもしれない。 一応本当に簡単な用途ではglossがそれ系を標榜しているがフレームワークではないし、真面目に使うには多々至らぬ点も多く…という感じなので困った困ったになるわけですね。 — なぜフレームワークがほしいかというとUIを一から作りたくないというのがある。私
HaskellでDIする
DI DIの重要性はここ数年で急速に高まってきている。 依存性が注入されたりとかそういうことはどうでもよくて、設計と実装を分けたい、人類はそれだけのために色々と工夫をこらし最終的にたどり着いたのがDIであったのだろう。 Haskellでも設計と実装を分けるためにDIしたいというのは自然な流れである。 ここでは型も含めて設計が実装に依存してはいけないということを要求する。 例えば設計でMySqlConnection、みたいな型が出現することも分離できていないので禁止とする。 問題点 設計を定義するときには他の言語ではインターフェイスなどの仕組みが使われることが多い。 Haskellには型システムという仕組みがあるのでこれがインターフェイス相当の機能として紹介される場合がある。 しかし型システムはインターフェイスとは違い、型を固定する仕組みがない。型クラス TypeClass a のインスタン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
