Version: 2022.03.02
//> using scala "3.2.1" | |
//> using lib "com.monovore::decline-effect::2.4.1" | |
//> using lib "co.fs2::fs2-io::3.4.0" | |
//> using packaging.output "mkString" | |
//> using platform "scala-native" | |
//> using nativeMode "release-fast" | |
//> using nativeGc "none" | |
import cats.effect.* | |
import cats.effect.std.* |
Think of all the arguments you've heard as to why static typing is desirable — every single one of those arguments applies equally well to using types to represent error conditions.
An odd thing I’ve observed about the Scala community is how many of its members believe that a) a language with a sophisticated static type system is very valuable; and b) that using types for error handling is basically a waste of time. If static types are useful—and if you like Scala, presumably you think they are—then using them to represent error conditions is also useful.
Here's a little secret of functional programming: errors aren't some special thing that operate under a different set of rules to everything else. Yes, there are a set of common patterns we group under the loose heading "error handling", but fundamentally we're just dealing with more values. Values that can have types associated with them. There's absolutely no reason why the benefits of static ty
The set
lines
- These lines deliberately cause your script to fail. Wait, what? Believe me, this is a good thing.
- With these settings, certain common errors will cause the script to immediately fail, explicitly and loudly. Otherwise, you can get hidden bugs that are discovered only when they blow up in production.
set -euxo pipefail
is short for:
set -e
set -u
Some of these practices might be based on wrong assumptions and I'm not aware of it, so I would appreciate any feedback.
-
avoiding some dependency conflicts:
- install sbt-explicit-dependencies globally in your
~/.sbt/{0.13,1.0}/plugins/plugins.sbt
- run
undeclaredCompileDependencies
and make the obvious missing dependencies explicit by adding them tolibraryDependencies
of each sub-project - (optionally) run
unusedCompileDependencies
and remove some obvious unused libraries. This has false positives, so; reload; Test/compile
after each change and ultimately run all tests to see that it didn't break anything - (optionally) add
undeclaredCompileDependenciesTest
to the CI pipeline, so that it will fail if you have some undeclared dependencies
- install sbt-explicit-dependencies globally in your
-
keeping dependencies up to date and resolving conflicts:
- install sbt-updates globally in your `~/.sbt/{0.13,1.0}/plugins/plugins.
package fpmax | |
import scala.util.Try | |
import scala.io.StdIn.readLine | |
object App0 { | |
def main: Unit = { | |
println("What is your name?") | |
val name = readLine() |
There exist several DI frameworks / libraries
in the Scala
ecosystem. But the more functional code you write the more you'll realize there's no need to use any of them.
A few of the most claimed benefits are the following:
- Dependency Injection.
- Life cycle management.
- Dependency graph rewriting.
Europe
- SkinFlint : Price comparison site which has some nice filtering options per switch type etc. Searches for offers in UK, Germany, Poland and Austria
- mykeyboard.eu : Keyboards, keycaps and accessories. Based in Belgium.
- candykeys.com : European Store selling Vortex, Leopold, KBP, Anne Pro keyboards, keycap sets and components (ISO + ANSI). Based in Germany, ships to EU.
- falba.tech : custom wooden bamboo cases, and some acrylic and carbon ones. Switch packs (65 browns at 48EUR). Other parts for the GH60, Atreus, ErgoDox. Also Microcontrollers, diodes, leds etc.
- 42keebs.eu - Mostly PCBs, tools and accessories. Located in Czech Republic.
- KEYGEM : Switches, Keycaps, lubes, cables, DIY kits and deskmats. Based in Germany, ships to the EU and worldwide.
- [Eloquent Clicks - Custom Mechanical Keyboard Store](https://www.eloquen