Darklang devlog #2: What next? | Hacker News Reader

Darklang devlog #2: What next?

dev.to

2 pointspbiggar2 comments

What's the benefit of Dark being its own language, as opposed to, say, the current interface and deployment platform being used to execute a linter-enforced limited subset of Python in user code but then allowing any Python library to be used? The only reason Python is hard to learn currently is that no one explains which is the 99% that you don't actually need to know anything about, so you have beginners wasting days and weeks learning about things like frozen sets, which they'll never even see let alone need to use. And to the extent that Python is hard to read, it's because people write linters to enforce things like line length, which don't matter at all for readability, whereas no one bothers to write linters to enforce things that actually do matter for readability, like ensuring that global variables, classes, file names, etc. all have unique names.

Difficult-to-understand features of a programming language shouldn't even be 'unlocked' unless there is some sort of need demonstrated by a line profiler or whatever.

The main thing is that if Dark is it's own language, that we're freed of the legacy of whatever other language we might use, and can design something that's explicitly for our use case.

As an example, Dark has "live values" which is where at any point in your program, we show you the actual value for the expression you're on. We use "traces" for this, which means the input (usually a HTTP request) as well as saved results of every expressions.

To accomplish this, we need a language where we can mark which functions are pure, where we can instrument the runtime, and where we can play the runtime back in our editor, filling in the saved trace values.

So nothing wrong with python, but it doesn't have any of those properties.

Similarly, we want your program to deploy instantly. That means that we need a technical way to deploy in 50ms (not sure that's available in python), but we also need language features that support that (such as feature flags built in, and the ability to safely make changes to programs). Otherwise, you'd find it's super easy to break your program with a typo.

This stuff is plausible in Python and many other languages, but seems super difficult.

Reply on news.ycombinator.com