Qu'est-ce qu'on pourrait faire pour nous, pour nous, de ne pas avoir cette complexité incroyable ?
Et la complexion incroyable que je vous referai est l'infrastructure.
Donc, Darker est vraiment...
Comment nous ferons de ne pas avoir de l'usage à penser à la fin de la vidéo ?
...
Hey, avant de commencer, nous aimons vous dire à notre store Merch.
Vous avez des cool Merch des DevTools FM ?
Ou même ce type de scroteur ?
Showez-vous comment près de la mètre vous êtes avec cette.
Si vous êtes un membre de notre patron, vous avez un code de discount 20%.
Maintenant, nous allons le voir dans l'épisode.
Mais, vous vous souvenez, le plus grand épisode est disponible pour nos membres de Patreon.
Hello, welcome to the DevTools FM podcast.
This is a podcast about developer tools and the people who make them.
I'm Andrew and this is my co-host, Justin.
Hey everyone, our guest today is Paul Bigger.
Paul was the founder of CircleCI and Spence's Time.
These days working on Dark, an integrated development environment for building serverless backends.
I'm sure that's not really doing Dark justice.
So Paul, I'll let you describe that better.
But before we dig into Dark, maybe you can tell our listeners a little bit more about yourself.
Thank you for having me on the podcast.
So, yeah, I'm a developer basically.
I've been a developer for about 20 years.
I did a CS degree.
I did a PhD in compilers and static analysis.
And then I mostly done startups.
So, you know, I started CircleCI.
I was the CEO there for the first four years and for kind of the first one of that.
It's writing code and the rest of it is not much writing code.
And then I've been working on Dark now for about five years.
And that, as of recently, as the last couple of years, it's been an awful lot of writing code
and just working on making the product really good for users.
Let's start with CircleCI for a little bit, because I personally have been a very avid CircleCI user.
Oh, wonderful. Thank you.
When I was at Intua, I was very gung-ho on trying to switch from Jenkins to CircleCI
because the experience is just so much better.
What prompted you to found CircleCI and was it your first startup?
It was my third startup.
The other two, having just not gone anywhere, but the experience of having done them,
kind of stood with me.
And so Circle was kind of my first startup that went anywhere,
where that really got off the bottom rung of the ladder.
I started it largely because I was working at Mozilla.
I was an engineer on the JavaScript engine.
And so all the time I'm using the tool that they had at the time,
what we would now call a CI server.
And then it kind of stopped.
And so I kind of spent a year banging my head against this thing.
And one thing in particular is that if something failed in the CI server
and worked locally on your machine, it was nothing you could do.
You could make a ticket, and then they might be able to get you access
to the server in the next few days to sort of see what went wrong.
And so one of the first things we did at Circle was we built the ability
to retry a build with SSH enabled.
So it's that sort of thing, just sort of like the experience
of using this thing is terrible.
And I think we could make something better.
Yeah, absolutely.
That retry with SSH feature was gold.
I used that many times.
Yeah, people keep building CI competitors that don't have that.
Like what do you do?
You're sure?
So you mentioned the first year of Circle
was a lot of programming and then sort of you get after that
and it's less of programming, more and more business stuff.
So what's the experience life shifting from this developer hands on,
you're just the whole team, it's just getting together to build product
to this higher level, you're now executive board member
out of the day to day product delivery.
What's that transition like?
Well, I guess it's sort of the company transition,
like the very early stages fun.
And with Circle it didn't last very long.
It was maybe six months really before we started having a decent
number of users where there's an awful lot of user discovery.
And literally six months after I wrote the first line of code,
I was spending significant portions of the day just like calling up users
and saying like what went wrong, what can we fix, what can we improve?
Will you give us money?
That sort of thing.
And then the next six months after that I largely did support.
So I was answering every sport email
and it was only then that we started to have a team.
So that transition actually wasn't too bad.
I really enjoyed the small team time.
We maybe had a year of just kind of everyone sort of figuring out
what to work on for themselves.
And then that broke down in nine people.
And then between nine and 25 people was when I was just in disarray.
I just had no idea what to do, where to spend my time.
All this sort of thing that you read about in sort of debate
like setting the culture and setting the mission.
And more obvious things like product group maps
and management structures and that sort of thing.
Part of the thing was we weren't really into some of that.
There was a lot of flat company stuff going on.
Don't do it.
But at the end of four years of that,
I was just like, I don't like this job anymore.
This being CEO of a 25, 30 person company
where the time that you're spending is like building this company.
So it's not a super fun job.
I really enjoy coding.
I really enjoy working on the product
and making improvements to the product
and things that the user facing.
And hiring sales people and drawing out a commission plan.
Do not like.
Yeah, yeah, for sure.
So now that you're no longer at Circle, do you still use it?
Yeah, I use it like literally every day.
Awesome.
Yeah.
So is Dark built upon CircleCI?
I mean, it's not built on it, but we have traditional code bases.
We have a client and a server.
And there's also a little bit of other stuff,
but that's basically it.
And so we have a mono repo and we have a CI CD pipeline for it.
And there's 11 steps.
And there's a deployment step as well.
And the kind of things that you expect in a standard sort of webby,
SAS kind of project.
Yeah, that's awesome.
So maybe we can switch over and start talking about Dark.
So Dark is a super, super exciting project.
I've followed it for a while.
So how would you exccribe Dark to someone who has never heard of it?
I'm assuming they're a voter.
Yes.
Yeah.
Because otherwise the first step is explaining what the cloud is.
So the way I really like to think about Dark is getting rid of all the bullshit
from backend development.
I don't think that I approach it from the idea of like,
oh, I've got this great idea for how software should be written.
It really came from the idea that why do we do all this bullshit?
Why do we have to deal with all this shit?
And surely there's a way of writing code that doesn't happen.
And so it's really about taking things away.
And you described earlier, it's kind of an idea for building cloud applications.
So yeah, it's not entirely wrong.
But how we approach it is like, what thing could we even build that allows us to not have this incredible complexity?
And the incredible complexity that I'm referring to is the infrastructure side of things.
So everything from spinning up more instances and kind of the serverless side of things to CXD pipelines,
to database migrations, anything where it should be obvious and instant.
And instead, we've kind of built up this legacy.
And whether that legacy is like containers or unics or IDEs and syntax and that sort of thing,
none of this stuff is actually a necessary part of coding.
The only thing that really matters for coding is that you've got input, you've got input,
you've got some computation that you want to do on it.
Those are kind of the essential things.
And we have this 50, 60 years of stuff that we've built up, layers that we keep adding stuff on top of.
And so, Darker's really, how do we build without the user having to think about any of this stuff,
the developer having to think about any of this stuff?
Yeah, that reminds me.
So back in Episode 26, we talked to the founder of, or the creator of Arc.Codes,
which is a server that's sort of like Arc.Code.
And we talked a lot about incidental complexity and how more and more paradigms are evolving
to sort of get us past that complexity and focus more directly on what is the product we're building,
not as what is all the stuff we had to duct tape together to even get to the point.
So, yeah, it's a super admirable goal and I think highly needed.
Yeah.
I think they're very much on, that is Arc.Codes is on the same page as us,
as like, yeah, we have to remove things from the, like how developers think about what they're building.
Because there's a lot of people out there who are solving this by adding more things.
And those are probably, you know, in many ways, more practical, you know, solving,
they're solving the problem today.
And I, you know, have a lot of love and an attendity for the people who are doing the,
this will not actually be really good for five years.
But we managed to remove this, this and this from it.
So, like Darkling has this theme of like shedding the past and making a new way to develop your back end services.
How does that differ from traditional methods?
Like what does writing a dark application feel like?
Yeah.
So, the, you know, I'll kind of talk about it from the way of, you know, without removing stuff.
So, one of the obvious things that we're removing is infrastructure.
So, when you set up a database in Dark, you just have the database, like, you click a button
or you use the keyboard shortcut or whatever, and then the data store is there.
And there was no, you know, there's no acquiring a server from somewhere to put it on.
There's no, you know, going to, you know, some other service and, you know, inserting a URL
for your postcards, config, whatever.
The schemas are just, you know, specified in the same language as the rest of Dark.
So, there wasn't SQL there.
When you make a request or when you make a query, you query in the Dark language,
which is the same as the rest of the language that you're using.
And it's just like, these functions are, you know, behind the scenes, they're compiled down to the SQL
that you would need.
But, you know, to the developer, it just looks like the same language.
And the things that you pull out of it are, again, the same language.
So, there's no ORM, there's no impedance mismatch between the values that you store in the database
and the values that you store in the language.
Similarly, when you're setting up a HTTP request, you're not setting up a HTTP server,
you're just adding an endpoint.
And the endpoint is directly connected to the code, and you write them in the same place.
So, there's no spinning up servers.
Yeah, I think there's a lot of serverless, right?
There's no spinning up servers.
But there's also, like, no API gateway.
There's no, you know, it's just all kind of native, the values that come in are native,
and they're in the Dark language as well.
And then, when you're writing code, you know, you want to remove the latency between
when you write code on your computer and it going into production for your users.
And so, we said, you know, that time is going to be zero.
There's, you know, there's not going to be any building containers.
There's not going to be any, like, pre-deployment steps.
It is just you write code and it's immediately in production.
And you can, and this one, I think, is one of the hardest ones,
but it's still something that we continue to work on, because you need that to be safe.
So, the language is designed in such a way that every key character you type can safely go into production
without production just having a syntax error or the server shutting down.
Or that, you know, there needs to be a way to write new code without breaking the old code.
And so, future flags are baked into the language that's baked into the editor,
they're baked into the infrastructure.
It's all kind of like designed around this zero second.
We've been calling that deploy-less, as someone coined that a couple of years ago.
And that's kind of the word that we've been using for it.
And it's just like, yeah, every key circle is straight in production.
How can that be done safely?
And so, as a result, you have no, you know, you've no CI pipelines,
you've no, like, extensive unit tests or integration tests that get to run.
There's no deployment process, like with Kubernetes or whatever.
It's just sort of like, you know, it's all built into this one environment
and it's all like cut down to the absolute minimum that it could possibly be.
Yeah, the structured editor of dark was like one of the really exciting things
that I saw in the beginning, because it's like,
that model I've wanted to take off in some way for a long time.
It's like, you know, we deal a lot with like formatters
and, you know, have flame wars over tabs versus spaces
and just all this stuff.
And it's gotten better over the years, right, with auto-formatters and stuff.
But, I mean, still, you can make mistakes
and it's like time wasted just typing characters, you know.
I mean, there's quite a number of, there's quite a lot to be said
about kind of auto-formatters and code-formatters
and how they've made the world a little bit better.
I think they, you know, if you have a repo,
you should have an auto-formatter in it,
which, of course, becomes more complex, you need to set up.
And then, you know, you have the issue that some of your users
have one version of the auto-formatter
and then some have another version,
or you need to migrate between versions of them
and there's a different formatting change.
And so now there's, you know, something throughout the code base
or there's a code base wide diff
that you need to apply to do this thing.
And the people whose branch has existed before that
can be re-based onto it.
And so this is, you know, that's the kind of thing
that we're trying to evolve.
And even, you know, very small things like code-formatters
bring in complexity.
And I totally agree that the world is better with code-formatters
rather than without it.
But even then, like, can you remove that complexity
ou can you abstract over it?
And one of the nice things,
I meant to implement this a couple of weeks ago
since we now are at a place that we can do it.
But, you know, why does every user have to indent
to the same level?
You know, like, some people like indent to,
some people like indent for,
some people like to line up the right-hand sides
of their records that they're using
or something like that, some people don't.
These should be settings for users
that they set and making the setting
shouldn't affect what it is for everyone else.
Because we store code in text
and we put that text in a Git repository
and every user has the same version of that Git repository
and pulls down the same text,
we don't really have any sort of, like, advanced stuff
and we still have to deal with kind of all this bullshit
as a result.
So is there any sort of version control built in?
So, like, I don't think it doesn't work with Git right now?
It does not work with Git.
Very much intentionally.
Git, like many things, Git is wonderful,
but also Git is very complex.
And I'm not sure that the model
that it brings to the world is super valuable.
And I think that we do a lot better without it.
So there is version control.
Version control is done.
Well, let me talk about what exists
because most of Dark is still speculative
and still is sort of designed, but it's not done.
So right now, Dark is sort of a multiplayer canvas
and it has infinite undo.
So you can undo any changes to the thing.
Where we are going with this
is that feature flags are essentially branches.
So they are checkpoints that you can go back to
to view the old code.
They provide the benefits of branches.
So if you think of feature flags as a branch, right,
you're building something in production
and so there isn't really this whole separate branch over here
where, you know, at some points,
you're going to merge that branch over the main branch.
That model doesn't really apply
when you're building in production.
Instead, what it feels more like is you have,
you know, kind of like an A,
an A, B test slash feature flag sort of thing
where you're building your branch separately
in this little box over here
and set up that thing over there.
And the language is designed to allow that
with version functions and that sort of thing.
So a lot of the things that we assign to get,
you know, long running feature branches,
diffing, history, reversion,
they look different, but they will exist.
Or in some cases do.
So I think reversion is a really good idea.
Like it's not safe to just revert something, right?
When you committed it the first time,
you probably had like a safe rollout,
but the world has changed since then.
So like going backwards is something
that you probably haven't tested.
So if you want to revert something,
you really have to put it like in a feature flag.
And, you know, if it's a hurry,
you can press the force of shit through from your button
and force it through.
But really, you want to slowly roll out that thing
to make sure that the reversion doesn't break anything as well.
And you don't want to just like, you know,
force push on to the main branch
and force that deployment date
and hope that those containers
with that version of the application work well.
Yeah, it doesn't really make sense.
So I assume there's no environments also.
Those are all just also done through this feature flagging system?
Yes, and I think, you know,
one area that we haven't fully figured out
is what to do with databases.
Like, you know, people like to have a staging version
of their database or a local version of it.
And that's something that we haven't quite figured out.
But I think a lot of long database vendors
have versions of that,
that work where you can take a snapshot, work on that.
So the model isn't necessarily that difficult.
It's just sort of like, how does it fit in with all the rest of the system?
Yeah, PlanetSkills approach,
so this is really interesting where they actually like,
has this really sophisticated schema versioning thing,
kind of a hood.
It's pretty cool.
Yeah, so we have plans around schema versioning
for the data store.
But, you know,
that's sort of separate from, you know,
we would like this data to not be corrupted
by these changes that we're trying to make.
Yeah.
Going back to, you know,
removing some of the overhead and traditional applications.
So, Dark has,
is a pretty visual environment that you're developing in.
You're generally writing code in this.
Does the canvas still exist in the new version of Dark?
The canvas still exists.
It won't fully exist in the future version,
or there will be a difference sort of paradigm,
but you will still be typing text.
Yeah.
I think that the really great thing about that is,
is you're not focused on literal text file structure.
You know, you're focused on how to organize your project
from like a hierarchical perspective.
You're just thinking like,
oh, I need an HTTP handler.
I'm just going to create one right here.
And you know, it's like the organization,
how that sort of frees you up from not having to like,
think about this like relational, like organizational stuff.
I think that's fine.
Just like, makes the mental model of just developing an app so much easier.
Yeah.
I mean, often you have something like, you know,
this directory is managed by this person,
or this team, you know, works on this repo,
and this whole team works on this repo.
And this sort of idea where,
where you're, you know, the structure of your application,
in a certain sense,
follows the structure of your, of your team or your organization.
And I think it makes a lot more sense to just accept that
from the very start,
and to design this application around it.
So, you know, as, so dark has this, this concept,
again, this bit is built,
but or at least we built a version of it wasn't good.
So, you know, it's a bit removed.
We want people to group around,
around this sort of organization.
So, you know, groups represent teams,
groups represent products,
groups represent microservices sort of,
you know, just like what I said with the,
everything kind of being in the same language,
it's, you want to use a single concept
to represent multiple things.
So, you no longer need separate repos,
separate directories, separate files.
You know, there's just one concept of separation.
And, and you can use it and sort of nest it
in multiple ways and apply permissions
at various different levels,
and not sort of thing to it.
Yeah, it's, it's really fascinating.
It's like, you know, working with Conway's law
instead of working against it.
I mean, it's, it's kind of funny that we,
we keep, you know, how much files exist to us.
And that, I mean, they exist
because there's nothing else, right?
You know, you need to store text into place
and this is the place that the text gets stored.
But then we build our editors around the files
rather than around languages.
You know, in, you know, various languages have,
you know, you can only have one class in a file
or you can have multiple classes in a file
and it's like, if you can have multiple classes,
why does the file, why, why do we have a file?
Well, because we have to, because, you know,
we've write code on Unix.
But it, you know, it doesn't really bring anything
to the, to the table.
Yeah, there are a lot of like semantics
that are just like baked into this structure
and it adds, you know, naming a file
and where the file lives and the folder structure
like has, is like communicating this thing
and it's like a part of the pattern of shaping your code.
I've been really excited by languages like Unison,
Unison Web, which is like all your codes in a database.
And instead of like, functions don't have names,
they have these globally, you know,
identifiers that are like what their actual identity are
and you can apply a label to it and just see the label.
And if you want to rename it, you can rename it,
but like, that's not a, that's the non-destructive operation
to the actual code.
Yeah.
And stuff like that is just incredibly exciting.
And I think Dart sort of like plays into that,
that model as well of like, you know,
being less tightly coupled to, you know,
you know, this base structure.
Yeah, I mean, you know,
same sort of idea, the code is started in a database,
the, it's an AST, functions are versioned,
you know, kind of, I think that the,
we agree on a lot of things.
So, Dart is a pretty expansive project,
it's its own language.
So, what are some of the challenges you've faced
building this completely new language?
A lot of the advantage of Dart comes from the fact
that we own the whole thing, right?
So, we own the editor, we own the database,
we own the infrastructure, we own the language.
And that means that the language needs to be designed
for these things.
So, a very obvious one is the language has to take
into account the existence of feature flags.
Whereas in non, you know, in a normal language,
you would use like the launch.dk,
and you know, there'd be, if saved or something like that.
But our language needs semantics for what is a feature flag
and how does it differ from and if saved.
Then, we need something like partials.
So, a partial is what you get when you backspace
over a function name until you have filled in a new
function name, right?
So, it's the sort of like the intermediate state
and that needs semantics as well.
And then, the semantics of that need to intersect
with the semantics of the feature flag.
And there's a couple of things like that,
there's four or five different things where there's a
little bit of, oh, exactly a complexity explosion
since we've managed to like shave off,
shave each of the features a little bit,
but sometimes they intersect and then they intersect
with the editor and they intersect with like the,
you know, the SQL compiler.
And so, a lot of times there's like, oh,
there's this entirely new thing that we invented.
We invented it because it needs to run in,
you know, to allow users have this deploy less environments,
but now we need to define the semantics for it
in the SQL editor or like what happens if someone
tries to save this value to a database?
What does that mean?
So, I think that's kind of like our,
you know, probably our most interesting challenge.
The other major thing is,
you know, darker cell language under development.
So, we still want to change some language semantics,
but we don't want to break anything that our users have done.
So, we need to migrate our users from old versions
of the things to new versions of the things.
And we need to figure out a way that this matrix
either don't change or that we can validate
that they don't change for any particular users.
Or we can give them some way to just like not be affected.
And that's a little bit tough.
Cool.
So, Dark has like kind of like automatic migrations built in
for old language features to new features?
Well, if they didn't, we would have to keep all the old
language features forever.
And then we would have to, you know,
every time we built another language feature,
that's another thing for it to understand.
Every time we build a new editor, it's like, oh,
what happens if, you know, the person uses version one
of records, which were, you know,
invented four years ago.
And, you know, everyone's on version three.
And what happens if they switch to version two
from version one, but they didn't switch to version two?
Yeah, it becomes a mess.
And it's similar with functions.
We like to delete old code.
We want to move people from old versions to new versions,
remove, deprecate the things from documentation.
So, we built deprecation into the language.
We built it into the standard library.
You know, the most obvious thing there is that if you,
if you've never used a function,
we will only show you the latest version of it.
So, for example, HTTP client is out version five.
We won't show you version one to four,
or zeroed four if you, if you never added it.
But, you know, we would also like to remove version zero
or version one, version two.
And so, you know, we would like to migrate you to the new versions
and we'd like to know that it's safe.
So, in a sense, part of what dark takes on board,
part of the complexity burden that gets taken on by dark,
the product, is migrating users from old versions to new versions.
And that's not always going to be easy.
Considering the language and sort of the integrated language features,
how much of the developer experience of dark
really is from the design of the language itself?
And, I mean, what other programming languages
might you compare it to?
Yeah, so dark was very much designed with
sort of developer experience in mind.
We wanted to keep it really simple.
We wanted to avoid a lot of things that we felt
were kind of wrong directions for the industry.
So, for example, inheritance.
I don't think inheritance was a good direction
for the industry to go kind of moving away from it.
As an industry, certainly, you know, languages
that are created today don't have the sort of, you know,
in-depth inheritance that's supposed to, and Java hard.
The other thing I really like is immutability.
I've been coding in immutable languages
for over 10 years now.
It's phenomenal.
Like literally every language I've used in the last decade
has been immutable, except from the right JavaScript.
So, dark is a statically typed functional language.
It is very similar to Elm.
It has some similarities to Rust.
It's a little bit to Haskell, OCaml, F-sharp,
Rescript.
You know, a lot of these languages are very similar.
Has some types, it's immutable.
And that's very much designed
because you can understand programs a lot better
if they're immutable.
So, does dark come with any type of type safety?
Like with the whole shift and code organization,
like where do I store a utils file?
Is it me just like talking serverless functions
talking back and forth to each other?
Like, how does that all work?
So, I'll address your first question.
So, type safety.
Dark is designed to be a statically typed functional language.
However, we don't actually have a type checker
and we put a lot of the type checking into the runtime,
which has problems.
So, dark will be gaining a type checker in the future
and that will be part of the editor.
So, in the same way that type checking is done
at the start of a compile,
similar, every time you press a character,
there will be a type check done
and it will be designed around this kind of language
that could be partially written sort of thing.
And there's a lot of advantages that right now,
if you want something type check,
you have to get this stuff in front of the type checking.
You can't do sort of this partial type checking.
And there's a couple of languages in academia
that have this concept called type tolls.
Hazel and...
There's another couple that are like it.
So, type checking will be built in.
So, from what I understand of dark,
you're just kind of like declaring like,
oh, here's like my get request and how that works.
Sharing code between that,
like if I want to have like just a general utility function
that I use in two routes,
is that other route represented as...
Or is that utility represented as a route
or can I just share the code in some way?
It's just functions.
So, dark is designed...
Like monorepos are...
Everyone wants a monorepos.
Monorepos are much better than anything else
than microservices.
But the reason that people move away from monorepos
have nothing to do with the fact that monorepos aren't great,
they're the fact that they don't scale particularly well
once you get to a certain size.
And so, people carve it off into teams
or they carve it off into a particular function
or they carve off something that has a different deployment velocity
or deployment frequency to something else
or whose tests take much longer
or don't change very often.
And none of those actually matter in dark.
All of those can be subsumed.
So, dark is going to be a single monorepo
for your entire company, your entire organization.
And then we can carve things off
and use groups for different organizations,
different divisions, different teams.
And, you know, there's no need for something to be like,
you have put in another route.
It's not serverless, like Lambda is serverless.
It's really just like, you know, there are functions,
there are types, they're shared across the thing,
but they're only loaded for the things
that need them to be loaded.
So, for a particular route, you know,
that route knows what it needs.
And so, the things are loaded for that.
Going back to something you talked about earlier,
so you mentioned, you know, feature flags,
being a built-in part of the language,
and having this deploy-less sort of environment
where you're putting things into production
sort of immediately and trying to do that safely,
you know, with, like, the feature flagging systems.
But, at some level,
you need to be able to validate your application,
you need to be able to ensure that, you know,
the logic that you've implemented is what you expected it to be,
or, you know, whatever.
So, how does testing work,
or validation in general, work within the dark ecosystem?
Dark has this idea of trace-driven development.
So, what that means is you,
you know, let's suppose you're building a client,
building, you know, standards, React client, let's say, right?
You build a button, you press the button,
that button then goes to the dark server, right?
And there's no endpoint for it,
so it appears in the 404s,
and you click a button, run the shortcut,
you now have an API route
for that request that you just made,
and you also have the data.
And, in fact, every time that any user
makes a request against an endpoint,
we store a trace of that data.
So, for testing, what we're probably going to do,
a couple of things, but the first of them is
we're going to take traces and tournament tests.
All right, these are the things that you typed yourself
in your editor, or in your client.
So, you know, there's a list of them,
you can go through them,
and over time, we will find ones that are interesting,
we'll find ones that are broken,
we'll, you know, apply some funky machine learning
to say this one is an important one to become a test,
and we'll allow you convert that into tests.
And because dark is immutable,
most tests are just going to be here as an input,
we expect a save foot.
For the unimmutable things, like, you know,
saving to a data store,
our analysis framework, which is what we would use for testing,
already has a built-in concept
of what you would call mocking.
So, we would have the results stored
as part of that trace,
which is kind of the same as mocks built into it.
So, then once you've got that concept, right,
you've got your inputs, you've got your mocks,
you've got your outputs,
and you've got types for the things that are coming in
and the things that are going out,
we'll add automatic closing.
So, we'll suggest things that increase code coverage,
suggest these paths that you haven't gone down before.
So, not, you know, not done yet,
and all these things exist in the real world,
but people don't really use them
because the overhead of them is so high,
but I think that the overhead of them will be really low
and dark and we'll be able to make them really
sort of usable in people's workflows.
That's a super cool idea.
Just having, like, you basically have snapshots
of all the inputs that you could possibly want
and just being like, oh, yeah, click a few boxes that,
those are the tests that I want for this.
That's a super powerful concept.
Yeah, yeah, this reminds me a little bit,
tangentially, of, there's a Rails library
out there called VCR,
which is like, oh, we'll record your inputs and outputs
and you can use those for testing.
It's like, a lot of times, in testing,
the hardest thing is getting, like,
semi-real data that, like, simulates
what the, you know, production code would simulate.
So, that's, yeah, that's, that would be super, super helpful.
Yeah, yeah.
The other thing that's sort of related to that is
you have an exception tracker in a language
or in, you know, in your infrastructure.
Maybe it's connected to your, to your logging
slash observability or whatever,
but, you know, for the most part,
there's something there that, when an exception happens,
it captures the stack trace.
That rarely feeds back into your test cases, right?
The, some of them, at some point,
had buttons that you could generate a unit test,
but, like, obviously, unit tests are kind of custom
for your framework and that sort of thing.
But, but it should, you know,
every exception you have should turn into a unit test
of some sort.
And, again, you know, exception tracking
is something that will be part of dark.
So, obviously, you know, that will feed back
into, into testing and traces.
You know, just having a small number of primitives,
there will be the same primitives
through the application.
It seems like a lot of things are built into dark right now.
One thing I read about that I don't think is quite implemented yet
is a package manager.
What are your guys' plans for a package manager
and what type of code do you think would be shared
through a package manager?
Yeah, so the obvious one is functions will be,
you know, most, like, really in dark,
everything is kind of a function.
It's a functional language.
There's not really very many other constructs in it.
The types are the other one that, you know,
your functions are going to have types,
so, you know, you're going to have some custom types,
those types are going to have to be shared as well.
And, you know, all of those are going to be versioned separately.
So, there's not going to be versions of a package.
There's going to be versions of a function
and versions of a type.
So, you might even have types that,
or you might even have functions that use to
or that take parameters up to different versions
of the same type, perhaps,
that's something, you know, that,
to help people migrate from the old version of the package
to the new version package or something like that.
So, that's an obvious one.
The other obvious one is kind of templates.
So, people, you know, if you're building a user package,
you're going to want some templates for a HTML page,
for a signup form, a password reset form,
maybe some, what do you call them,
a third party sign in, single sign on,
or, you know, social media sign on,
or whatever, you're going to need some forms for that.
So, those sort of would be put in the same,
in the same packaging thing.
The ones that get a little less traditional,
refactoring tools,
are going to be part of the package manager.
So, refactoring tools are going to be written in dark,
you're going to be able to use them in the editor,
and then you're going to be able to put them into a package.
And so, you, we want people to distribute packages
that have refactoring tools in them.
And maybe these are, these are, you know,
people have, you know, in essence,
DSLs, demand-specific languages,
you know, often that they, that they shift,
and there are, there are perhaps some static checks
that you can do on your types,
because, you know, it's not possible to have certain things,
or whatever.
Those are things that are going to be distributed
as part of it as well.
Yeah, it's really awesome.
It seems like packages are like similarly related
functionalities to groups almost, you know,
and that, given that all of this is integrated,
that the concepts have a lot of overlap, you know.
Right, right, yeah.
So, down the road, I want people to distribute
whole applications in dark.
So, I want, you know, I think that dark is a good place
to build your entire company's infrastructure in.
One of the, one of the reasons that I started dark was
I was using this application tracking system,
and kind of what I was called, recruiter box, I think.
And it was, you know, it had some problems,
so we were going to switch to lever,
and then lever had some other problems as well.
We wanted to kind of, you know, the concepts,
the workflow of this actually isn't that complicated.
We wanted to use an API,
we wanted to have access to all the things
that were happening in the API,
and we wanted to like pipe them into some custom things,
some emails, some Slack channels,
and they just didn't have integrations for this.
And, you know, kind of contemplate,
like, should we build this ourselves?
Like, no, of course not, that's ridiculous.
And I realized that we're now at this point
where writing anything yourselves,
writing your own products that you could buy instead
is almost always a bad choice
because it's, because the overhead of writing code is so high,
the overhead of like running service
and maintaining things is so high.
And so, I felt that if we've reduced that complexity enough
that people would actually be able to write tools themselves again.
And we'd be able to write our own after-contracting system.
And perhaps the people in the talent side of the company,
the recruiting side of the company would be able to,
you know, add their own custom notifications,
add their own custom toolings,
add their own custom workflows on top of that
to represent what they actually do day to day.
And, you know, perhaps it would be something where
you know, the, if the team wants a weekly report
about what's coming in,
you don't just get what the tool has built in,
you get to actually build your own stuff in it.
So, I imagine that at some point in the future,
someone will build, you know,
an after-contracting system in dark
and they will put that in the package manager
and your company will be able to install that,
will be able to contribute back to it,
will be able to, you know,
build your own custom workflows on top of it.
Et ça fait un peu de temps pour les conseils de la semaine.
Merci pour les podcasts, Paul.
C'était une conversation super intéressante
pour un futur potentiel pour la programmation.
Et j'espère...
Merci beaucoup pour votre programmation.
Je vous souhaite le meilleur et le bonheur pour votre succès.
Merci.
Paul, c'est toujours super,
vraiment, vraiment excité de voir le futur d'un dark.
C'est un projet super cool et une inspiration très grande.
Donc, oui, on va continuer à faire de bon travail.
C'est génial.
C'est génial. Merci.
Le dark est ouvert pour les contributaires
et pour les gens de l'envers,
c'est DarkMine.com
et on va aimer les gens de l'envers.
Bien, c'est tout pour cette semaine
de la part de la semaine libre.
Si vous voulez entendre la conversation,
partagez sur notre Patreon et vous êtes un membre.
Pour seulement 5$ par mois,
vous pouvez soutenir le show
et nous aider à trouver notre goal
de délivrer le contenu weekly.
Merci pour l'entendu.
Sous-titres réalisés par la communauté d'Amara.org