Earlier quoted context omitted.
Scala just seems to have an ever changing identity. Scala 3 drastically changed syntax and now they're trying to move the language from monads to effects.
Scala 3 didn't "drastically" change syntax -- most of the changes also have automatic rewrites with appropriate compiler switches. The effects story is still pretty experimental, but there's also improvements to 'effects' syntax (for-comprehensions) in "preview" for 3.7. As long as the 'effects' work will let me distinguish pure/non-pure, I'd be happy to use just that bit and stick with ZIO/TypeLevel's ecosystem... w…
We chose OCaml to write Stategraph
111–120 of 127 posts
Re: We chose OCaml to write Stategraph
#112Earlier quoted context omitted.
Scala just seems to have an ever changing identity. Scala 3 drastically changed syntax and now they're trying to move the language from monads to effects.
Perhaps the focus of the team behind the compiler has changed over the years - but there is still backwards compatibility (via TaSTy), the new syntax changes are not mandatory (for the moment) and when they do become so there will be a fully automatic (and correct) rewrite. There are new libraries exploring "direct style" but you can still use cats-effect or ZIO if you prefer. If anything, Scala has a "too much choic…
I don’t know man. I’ve been burned so many times by breaking changes. We don’t even write new Scala anymore. Everything new is Java nowadays.
Re: We chose OCaml to write Stategraph
#113Earlier quoted context omitted.
Scala just seems to have an ever changing identity. Scala 3 drastically changed syntax and now they're trying to move the language from monads to effects.
One of OCaml's outstanding, but too little mentioned, virtues is the community's commitment to extremely strong backwards compatibility guarantees.
Re: We chose OCaml to write Stategraph
#114Re: We chose OCaml to write Stategraph
#115Re: We chose OCaml to write Stategraph
#116TIL (via a rabbit hole after reading this) that a good type system removes an absurd amount of boilerplate validation code.
This is pretty much obvious for people migrated from JavaScript to TypeScript and suddenly realised that most of their unit tests can now go to a trash bin.
If you're on TS and want end-to-end type safety, I recommend you validate everything with something like Superschema and Zapatos/PgTyped. Node with 100% type safety is wonderful to work with.
Re: We chose OCaml to write Stategraph
#117Re: We chose OCaml to write Stategraph
#118All the points in the post are equally applicable to Scala too, so yes, why OCaml?
Re: We chose OCaml to write Stategraph
#119All the points in the post are equally applicable to Scala too, so yes, why OCaml?
Scala 2 is a dying language, and Scala 3 is an immature one. The ecosystem and community are also very messy, with fragmentation and witch hunts running rampant. OCaml provides same advantages, but without all the drama.
You don't have to participate.
> immature
Why? The compiler bugs are ironed out by this time. Even the most complex macros are ported.
> same advantages
I like the language but it lacks so many features that I can't be productive with it.
Re: We chose OCaml to write Stategraph
#120Earlier quoted context omitted.
Functional programming is immutable by default. TypeScript and many other typed languages don't really stop you from clobbering things, particularly with concurrency. Rust does. But immutability with GC is a lot easier to use than Rust if you don't need the performance of Rust.
That is only true since people started equating FP with Haskell. OCaml as the discussion subject on this thread, allows for mutable data structures, and I am old enough to have been taught Lisp as one possible avenue for FP.