verttii

Typescript's inherent problem may well be that it's rules are too lax, it allows you to circumvent them conveniently. This keeps poisoning the code base piece by piece, leaving you with a false sense of trust.

Maybe it's because of the compatibility with Javascript but it does kill Typescript's type soundness.

Edit: rephrasing

Thanks, excellent summary!

There seems to be very little promotional stuff about the runtime for server-side. What's the story with that for Swift?

I don't think many people are going to start learning Swift just to build servers with it unless the platform/runtime provides something special. Otherwise it'll stay isolated just to the current iOS devs.

But Swift has had a more specific target platform, where it wouldn't make sense to produce excessively high level generic abstractions.

Whereas a language like Haskell is happy to try some absurdly abstract concepts in the interest of promoting computer science.

Public sharing of REPLs for anyone even without an account is just awesome. Gitpod or anyone else that I know of doesn't offer this.

To be fair they're not always that easily accessible on React Native either. A lot of the times they seem to break stuff in weird ways, if they work at all.

They're inherently similar. Both highly verbose and quite object oriented. Dart is less flexible and arguably less advanced, but unlike Typescript, it's sound (as in type soundness). For a very specific target (mobile) being a bit less advanced is completely fine, it has all the abstractions needed for mobile development.

Immutability is leveraged extensively in Flutter. That said, functional programming is a struggle with Dart. Although it's not particularly well suited to Typescript either. Some specific things like async stuff are better in Dart/Flutter. As Dart adheres more strongly to classes/inheritance its facilities for that are more extensive.

Dart is perhaps more Java-ish while Typescript is more C#-ish, if that makes sense.

Flutter's strength is certainly not the language, it's the SDK/platform. It's miles ahead React Native in my experience.

Take a look at some samples to get a grasp on how it looks like: https://dart.dev/guides/language/language-tour

For the record, here is the press release about it from the Ministry of Economic Affairs and Employment of Finland: https://tem.fi/en/article/-/asset_publisher/suomi-investoi-e...

Quote from the press release: The cost of the initiative, a total of 1 679 000 euros, will be funded from the budget of the Ministry of Economic Affairs and Employment of Finland.

The course was developed quite some time ago by the University of Helsinki with their funds. It's a public university like all Finnish universities, meaning it is funded by taxes.

What's news here is the translation job to translate it to multiple European languages. It takes an additional 1,7 million € and is funded solely by the Ministry of Employment and the Economy of Finland.

I failed to find any claims of EU funding any part of the original development or this translation job. The Finnish Ministry of Employment calls this course a gift from Finland to the European Union. What's your source on this being EU funded?

A lot of Finnish taxpayers' money was spent developing it. I think it's fair to criticize its shortcomings openly.

Static types do help eliminate errors and unwanted behavior without requiring to write explicit tests to verify the same outcomes. A good static type system helps reason about the code and therefore increases productivity.

On that note, why would you consider Haskell a low productivity language? People who are well versed in it seem to find it an exceptionally productive language to work with.

Interestingly, I started off with Elixir & Elm and then moved on to Haskell. Elixir & Elm both feel like DSLs with abstraction level purposefully constrained relatively low. A lot of the concepts in those languages didn't make sense until I started picking up Haskell.

I don't really know if it's ultimately worth it or not but as a programmer I want to evolve by raising the abstraction level in my code. Haskell is the perfect platform for that.

Btw any examples of those warts in Haskell?

Why would Haskell need to be readable by people who don't know Haskell?

Stack uses cabal underneath though. What kind of issues are you running into?

Personally I love the language but struggle with all the (necessary) stuff around it. Configs, deployment, dependency management, editor setup, lint, auto-formatting... Everything feels unnecessarily painful.

Servant. It takes a while to pick it up but it's well worth the effort. You end up with an automatically documented type safe API and you can even generate client functions for other languages using Swagger based on the spec. It has excellent documentation too, the only hard part really is figuring out the handler pattern.

As for the SQL story, that's more fragmented. I'm still trying to figure out the best next step myself. I started off with Persistent & Esqueleto but now looking at BEAM, Selda and Squeal for more control over the queries.

If you use Persistent as the persistence layer, check out Matt Parsons' blog for a nice intro: https://www.parsonsmatt.org/2016/07/08/servant-persistent_up...

I'm actually coming from Elixir myself. I have to admit Haskell feels funny at times but admittedly a lot more robust.

This is a great tutorial for getting up and running fast. I started off with Spock too but grew out of it pretty quickly.

It's painful in Haskell you're learning it but feel you're not able to generate anything real for the first month(s) with it. Unfortunately, there's not many up-to-date tutorials like these available for beginners.

Great advice, I'll try these features out while prototyping on Haskell.

Agreed, I switched to Flutter from React Native. Although I don't particularly like Dart lang, everything just works way better on Flutter.

Really good stuff, is that talk uploaded anywhere?

You could and probably should promote this to the Elixir community too. Especially the OTP parts are very relevant fundamental knowledge for any Elixir dev.

This is so spot on. Asynchronous ports are troublesome in a lot of cases. That's why I don't usually do my apps in Elm.

Beyond the funding, what were the most important factors there that made you feel this way?

For example now I'm building a Servant API on Haskell. It's basically a strongly typed API that you don't need to validate with tests. You only need to test the handlers that handle business logic.

In other languages with a less sophisticated type systems I would need to build validation functions manually and obviously test them. Hell, an interpreted language might even boot up with functions that have faulty code, ultimately producing runtime errors when invoked. Haskell generally would not (because of the type system). Adding type constraints basically limits the range of possible inputs/outputs, requiring you to write far less tests.

> SO MUCH worse cost/benefit than unit testing

My experience is exactly the opposite. Using the type system is less effort, guides your development more and, in a way, provides more consistent guarantees than spending time on a wide unit test coverage.

Obviously, these things are not totally mutually exclusive though.

Operators are just functions. Learning the type system is the key. You can easily check any function's type signature in the docs once you understand how the type system works.

> it lacks a lot of features to make it useable at scale.

Can you elaborate on this?

This is an incredibly good series. Just what I've been looking for. I'm writing a Servant API myself and this really explains a lot of the fundamental concepts in plain English.

Got it thanks, good info for me!

CPU-heavy tasks may not be constrained as much on mutation as on the host VM architecture. The threading system purposefully prevents a thread from hogging all resources. And since you have to run every computation in a thread (process), there really is some overhead. As I'm sure you know, the BEAM is built for concurrency, not for parallelizing computations.

Take Haskell for example, which is also immutable but doesn't require you to spin up processes to do computations. It handles CPU intensive tasks significantly better, but is a worse choice for highly concurrent low latency soft real-time apps because of the scheduler and garbage collector mechanisms.

Edit: Btw thanks for bringing up that comparison across types issue. Never realized that. What's your solution to it? I'd write guards on functions that filter input based on types, then have a final fallback with no pattern matching that throws an error explicitly.

The point of lazy evaluation is to evaluate something only when you really need it. Not to auto-adjust the system performance wise. You can force eager evaluation in places where you want it evaluated sooner.

Personally, I think consistency is more important here because it leads to better predictability. If you don't know whether the compiler assigns something to be evaluated lazily or eagerly that could lead to a lot of nasty debugging issues.