verttii

I had no idea the IT consultant salaries were higher in Stockholm compared to London. What kind of rates would an IT consultant be expected to pull in Sweden?

Haskell absolutely lacks the soft documentation needed to attract new people. Just about every library could use a "mini tutorial" in their README, at the very least, to allow even novices to quickly bootstrap them and start getting productive without having to understand all the underlying concepts.

Isn't Software Transactional Memory more for concurrency than parallel computing though?

Interestingly, the docs for Flutter are comprehensive and overall just really excellent.

Maybe they shifted focus to that in the past years.

Thanks!

It's typical in statically typed functional languages to match against Algebraic data type value constructors. These ADTs have a fixed amount of variants, which makes it suitable to do a clean pattern match.

ADTs don't exist in OOP. It gets more complicated to do matches against classes whose abstractions are not really decomposable so easily.

It is, from top to bottom.

You got any links to share on this? I'm doing a bit of academic study on the subject of pattern matching in OOP.

You mean that guards + destructuring would effectively be the same as pattern matching in function's params? Pattern matching would allow matching against more complex data structures more comfortably though.

My point was rather that that's where Elixir excels.

Throughput is always a compromise with latency in garbage collectors and schedulers.

Elixir prioritizes low consistent latency with its garbage collector and preemptive scheduling. Whereas many other systems, such as Haskell's GHC compiler/runtime prioritize high throughput instead for better computational performance.

All the computations have to run inside a process in Elixir. Erlang's platform constrains each process so that any single process cannot hog all the resources available. Therefore, you need to split the computation to many processes when you do CPU intensive work. And processes carry message passing overhead, leading to reduced maximum throughput.

Something like lots of small messages with minimal processing (think: chat) over a bunch of network connections sounds like the ideal sweet spot for Elixir.

Fair enough, I should've put it more general like "distributed computing". Something that does networking stuff and prioritizes low latency instead of high throughput.

I actually have a similar experience. This is basically due to having no type system, at least the problems we've encountered.

It really depends where you're coming from. If you're from the enterprise world I'd expect you'll find the ecosystem limited for anything else than web related, maybe even for enterprise web integrations. If you're coming from something even more niche (for web) like Haskell you'll think the ecosystem is flourishing.

Libraries are generally of good quality and reasonably well documented. The community is very energetic and supportive. Moreover, there's an exceptional range of libraries and solutions available for certain problem domains in which the Erlang platform excels such as distributed concurrency and soft real-time applications in general.

If the problems you work on fall outside of the web sphere Elixir is not a good fit generally.

Elchemy too which is based on Elm.

That was also the first thing I was looking for in the docs. I mean how it ties to the Erlang OTP. It's the reason why anyone would use Erlang's platform after all.

It takes like a few days to pick up and you can easily be productive from day 1. Dart's been around for some 8 years already, I'd assume Flutter bites the dust sooner than Dart will.

Wow this looks interesting, I don't know why it has slipped right past me so far.

My experience is similar with yours. With React Native I had to fight just about everything on Android just to get everything working bearably. Hell, even some things like the profiler didn't work in Android when I was writing RN.

For now I'll stick to Flutter, it has simply awesome tooling. Everything just works. Dart, while not my favorite language, is also no more difficult than typescript to grasp, and they're inherently similar.

My experience with Flutter is that you need a lot less native code than you do with React Native.

However, the hands down best part is the tooling. Unlike on react native everything just works on Flutter. It doesn't feel nearly as fragile.

Is it really? Got no exposure to C++ but the rabbit hole goes pretty deep with Haskell.

True, but the problem is that any production ready library you come across uses some pretty advanced type magic that you have to learn to understand. At least to some extent.

Servant, the currently dominant API library/framework alone is already based on type level programming.

There's also some work pushing Haskell to perform better (more like Elixir) in networking/concurrency applications: http://www.well-typed.com/blog/2019/10/nonmoving-gc-merge/

I used to have the same wish as you but then I just decided to pick up Haskell. Haskell's hard part really is the type system. It's also what ultimately enables you to write very high abstraction level type safe code that does exactly what it's expected to do.

Btw you may want to keep an eye on this: https://wende.github.io/elchemy/

Honestly, I wish this would get more traction, it seems like an awesome intersection between type safety and practicality.

As someone mostly writing functional languages I'm always having a hard time writing decent functional code in Python. There's almost no facilities to support modern functional programming so it just doesn't feel idiomatic in Python.

Or a weapon.

Aren't Python's lambdas expressions while JS's arrow functions are not?

That's not how you would persist to the database. Processes (Erlang VM threads) have mailboxes that process messages (like records to be saved to db) in a queue. Everything is built around message passing, each process just handles its own narrow job.

What are you building?

Japan seems to be completing civil engineering projects pretty fast compared to almost any other nation. Maybe there's something to be learned from there?

But Typescript is not a "typed language", rather a "language with types". Because of having to maintain JS compatibility it lacks the inherent type safety that other similar languages like Dart provide.