51–58 of 58 posts
Earlier quoted context omitted.
Same-process modularization should solve that problem. Splitting the architecture into separate processes means a crash in one module doesn't propagate to other modules, but the whole system still breaks down if the process is essential.
Not all bugs are crashes. It could be a copy text or price calculation.
F# secret superpower that no one has discovered for 30 years, and it will change its popularity in enterprise software.
it's secret superpower it to allow you to give up on trying your code to compile and then just to shim against some C# bindings
Earlier quoted context omitted.
it's secret superpower it to allow you to give up on trying your code to compile and then just to shim against some C# bindings
C# bindings?? F# and C# build on top of the same type system and can transparently access each other's types.
Earlier quoted context omitted.
Most of the time we do simple CRUD operations, I want this plumbing to be as straight forward as possible. Don't be patronising...
I am always confused by this wish. If the operations are simple, why the need for ORM?
The book of Hibernate is thicker than the book for SQL.
The only thing that works better in ORMs is "save". Just call save on an ORM managed object and it is saved, quite a bit harder in SQL.
> only Odin, F#, OCaml and Zig have [Tagged Unions or Discriminated Unions] The good old missing sum type story. Don't Rust, Haskell, Elm, Kotlin (with sealed classes), etc also have them?
Most languages have them, or allow them to be expressed. The name "Tagged Unions" literally comes from C.
Go does not. Java did not (maybe now with sealed types and exhausitvity checks on switch statement, but not sure if they've already landed).
Earlier quoted context omitted.
Same-process modularization should solve that problem. Splitting the architecture into separate processes means a crash in one module doesn't propagate to other modules, but the whole system still breaks down if the process is essential.
What same-process modularization does _not_ solve is independent lifecycle management. In a monolithic system your change rate often becomes tied to your slowest, most bug prone module or team. If you've some integration test that bakes some piece of important code for 48 hours, you can only make a change _everywhere_ else every 48 hours. Now sometimes folks (the Windows team famously did this) build systems which id…
If you're interested in iterative development and continuous deployment, which of course I am, it is a natural fit. It is productive in that case.
Earlier quoted context omitted.
Most languages have them, or allow them to be expressed. The name "Tagged Unions" literally comes from C.
Just having sum types is not enough: you need some level of type safety and exhaustivity checking in match/switch statements to truly benefit from them. Go does not. Java did not (maybe now with sealed types and exhausitvity checks on switch statement, but not sure if they've already landed).
Earlier quoted context omitted.
Just having sum types is not enough: you need some level of type safety and exhaustivity checking in match/switch statements to truly benefit from them. Go does not. Java did not (maybe now with sealed types and exhausitvity checks on switch statement, but not sure if they've already landed).
Java does have exhaustiveness checking on switch expressions over sealed types in the release JDK, but not switch statements (due to the requirement for backwards compatibility). I'll often find myself writing var _ = ; to get around this, a very Java idiom if ever there was one, heh
Try this:
sealed interface Shape permits Circle, Rectangle { }
record Circle(double radius) implements Shape { }
record Rectangle(double length, double width) implements Shape { }
void test() {
Shape shape = new Circle(5);
switch (shape) {
case Circle _ -> System.out.println("Circle");
case Rectangle _ -> System.out.println("Rectangle"); // Comment out this line to get an error.
}
}