
Darklang devlog #2: What next? - pbiggar
https://dev.to/darklang/dark-devlog-2-what-next-4pme
======
Alex3917
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.

~~~
pbiggar
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.

