Dark Blog

Not sure I'd want to be writing services I depend on in a language whose priority is ease of prototyping.

In his post, Real problems with functional languages [0], Paul Biggar creates a false dichotomy: static types help us to write correct programs while dynamic types let us prototype faster. Dark wants to be able to do both.

I believe Haskell allows us to reject outright incorrect programs sooner and allows us to prototype things faster due to its types and inference engine. I don't really see how Haskell is poor as a prototyping language. From experience it's better than dynamic languages as it has allowed me to focus on logic and domain problems instead of mucking up my code with brittle run-time and equality checks... and then chasing down bugs I've made for myself.

No where is it mentioned what type system Dark is using. Will Dark allow a program to be deployed that it cannot reason about? What about higher-kinded types and polymorphism? Does it enforce termination or is bottom a type in every kind? Does the type system enforce linearity in usage? Quotient types? Row types?

This looks like a cool project but I don't think I'd use it for anything without knowing more about how it works.

[0] https://medium.com/darklang/real-problems-with-functional-languages-efe668c5264a

This is a really interesting take on the Silver Bullet argument - Brooks is right that big gains in productivity are only gained by reducing accidental complexity but he was wrong about how much accidental complexity there still is to reduce.

I think most Software Engineers probably suffer from some cognitive bias in trying to estimate exactly how much accidental complexity exists that could be eventually removed. We tend to think about incremental improvements to tools and processes rather than thinking at a higher level about improving the overall process of translating business requirements into working software. Even with much better tooling and languages (i.e. #F, Git, AWS, etc) there's still a lot of fat that could be trimmed.

I'm excited to see what the wold of low-code will do to our current assumptions about how much accidental complexity there actually is. Maybe projects like Dark[1] could actually achieve the order-of-magnitude gains that Brooks was convinced wouldn't be possible. Sure, there's no panacea, but maybe we're round the corner from a genuine "Silver Bullet" in the sense that Brooks actually meant.

[1] - https://medium.com/darklang/the-design-of-dark-59f5d38e52d2

> Instead it tells you exactly what errors can happen at every point in your code. Once you have your initial prototype/algorithm figured out, you can use that information to handle all the edge cases.

While I can't say much about Dark (the available blog posts [1] are shallow), I do think that the automation may be one key aspect of future programming languages. For example, when I'm thinking about gradual typing I don't only want to mix the hodge-podge unitype and actual types but also convert the former to the latter, and a large portion of the process can be automated in various ways (for example, one can track the typical runtime types that unityped variables have; the programmer can solidify compile-time types using that fact).

[1] https://medium.com/darklang

I don't get it. I tried to find out anything about what Dark is, how it works, or what it looks like and found almost nothing. They make claims like "holistic programming language" but don't show me what they mean. The What is Dark[1] blog post makes a lot of claims, but I've seen these claims made many times and they rarely live up to the hype. They don't show me how they plan to meet these claims or what it looks like. Finally, their marketing focus is on deployment, but honestly, deployment really has never been the biggest pain point for me. Sure, it can be a headache, but its nowhere near as much work as actually writing the applications themselves. I'm not convinced.

[1] https://medium.com/darklang/the-design-of-dark-59f5d38e52d2