Working on Darklang’s package manager - currently a tad stuck on some stupid technical stuff, then looking forward to quite a bit of (hopefully) uninterrupted focus work :)
This is more of a meta-level note but: this was my first post to lobste.rs – Paul had been posting Darklang updates here for a while, but I kinda questioned whether it was worth it. The site seems small, relative to others, and it seemed odd to post to it in combination with twitter/reddit/etc.
But I was wrong - while the other social medias have been just quick likes/retweets/reposts/kudos, the most engaging feedback has been here, and I appreciate y’all taking the time to read and chat about the posts for a few minutes. Also, browsing through the things that are posted here, it feels like it overlaps a lot with my interests. Anyway, thanks!
Please don’t take any of those .dark files as the intended syntax of Darklang. There’s a lot of overlap, but we’ve been very limited by the fact that our old parser is a wrapper around F#‘s parser – we’re still filling out our tree-sitter -based parser to a point where we can delete the F#-based one, and then morph the syntax how we want. Totally agreed that nesting there is terrible.
I tried Darklang a while ago, and it seemed neat, but not really powerful enough to be useful to me at the time. I really like the idea of it, but I think it’s a bit too ambitious. The new direction is much more realistic, but I’m still skeptical. It seems like it’s trying to do all of:
New functional programming language
An IDE
A deploy-less platform to host and run code
AI driven development
more?
Today all of these have independent solutions, with many good options within each, developed by thousands of developers. Replacing all of this with a single solution sounds implausible without a similar investment in time.
Even if all of these problems were solved, I don’t think we will ever see wide adoption for two reasons:
It’s a functional language - those have not gained super wide adoption compared to procedural languages.
It’s not open source - most successful projects in recent years have been open source and not proprietary (I.E. starting as BSD/GPL, and only later changing to something like BSL after they’re already successful).
I’m not trying to be negative - if it finds a niche that would make me super happy. I want solutions to all the problems they’re trying to solve, and I love that people are working to improve how we build and ship software. Maybe I’m just being too pessimistic…
yeah, the website definitely needs work. We spent most of 2023 just coding, and only re-did the website somewhat recently, so there’s a lot of catching up to do to improve the content.
I think that now that darklang is trying to position itself as a more general purpose language rather than the way to develop within their cloud service, it really needs to address the question of what it offers over other ML languages head-on, in detailed “why darklang rather than ocaml” and “why darklang rather than F#” webpages.
also as a webdev language I would have liked to see something closer to opa, a full stack language that seamlessly integrated a compile-to-js part, or at the very least a web framework like phoenix. if it’s just targeting API-only web services (forgive me if that’s not the case, it’s what I gathered from a brief skim of the page) it has a ton of competition, most recently gleam if you really want an ML language, most of which have more contributors and more community.
I do wish darklang well; I love ML languages and love seeing more work in the space, but on the other hand the overall demand for ML is low enough that it really needs to sell itself better to existing enthusiasts. selling to non-ML people is a much harder task, and I’m not sure even rescript is managing that too well.
For what it’s worth, we’re just as committed to our cloud service. As stated, we expect it to be most used runtime still. We’re just building out the CLI runtime right now, so that got a bit more attention.
The questions of “why darklang rather than F#” and such remain the same answer: with Darklang, you can just code, without dealing infra or deploys, and you get the power of trace-driven debugging.
Thanks! Yeah, the homepage definitely needs work. It’s hard to capture it all, and I’m not traditionally a front-end dev, so working on the site usually comes in waves. That said, once we (soon) port darklang.com to be written in darklang, iteration on it should be much faster, and we can fill out the content that way too :)
if there’s anything in particular in that post that struck a chord, let me know – it’s good to know what feels exciting/interesting about darklang to other folks.
i think the main bit is to have it emphasised that this is not an attempt at a walled garden or lock-in, but offering people the option to just write a bit of code and have it running in the cloud immediately
I have been eyeing this project for a while. The reasons for going in a new direction are pretty much the reasons why I never tried it, so I’m excited!
But it does feel a little sad. Darklang was supposed to be this revolutionary thing that fundamentally changes the industry, but instead the industry forced Darklang to change. I look forward to a day where software development truly looks nothing like the old way, rather than just incremental improvements on editing text files and compiling over and over.
A point of clarification here - in Darklang-next you’re editing text, but not in .dark files or something. It’s all stored in a big ol’ blob of stuff, centralized and available from everywhere.
Does darklang have anything to offer there that unison hasn’t already been doing? I’m not trying to be mean, I’m just noticing that unison also occupies this niche and has been at it for longer. Maybe dark-the-cloud-platform could even be based on unison, to not reinvent the wheel :-)
Darklang I guess was never all-in on the structure-editing revolution, but bringing about that revolution is my primary focus and I will not be so easily dissuaded. If you’re interested, come drop in the BABLR discord! https://discord.gg/NfMNyYN6cX
The point of Darklang isn’t to reinvent a development environment - it’s to remove the accidental complexity that has grown in software development.
I find this to be an interesting point, and I agree. There are two things that can be conflated:
(1) Software is hard to create because the UI for entering code is difficult. For example, if I am authoring some unstructured YAML file, it’s easy to make mistakes.
Also maybe I have to push to a server to test if the code is correct. (Actually I’m not sure if this is really a UI issue, I think it falls in the second category …)
(2) Software is hard because there is accidental complexity
In tools. IMO the most common symptom of this is that there are too many moving parts, some of which don’t need to be there. Maybe you find yourself debugging some problem with say Docker on Ubuntu vs. Docker on Debian, and you didn’t need to use Docker at all. (To be clear, I use Docker right now, because it does provide a lot of value, but I’d like to move off of it)
Needing a cloud service to test code seems like an architectural problem with the tools. It might remove “complexity” if you avoided tools that lean on this way of working.
These problems can maybe bleed into each other, but I do think it’s worth thinking about them separately.
For UI, what I want is something fast / predictable / stable, though people have different preferences.
For code complexity, the main issue I have is frameworks, e.g. when they want to “own” the main loop. You often have to work around them.
The YAML case is kinda interesting because it’s two problems related to the same system – it has an error-prone syntax, AND you test it by a round trip to the cloud. It could be one or the other, but it’s both.
On an unrelated note, I wonder if renaming Darklang to something else makes sense at this point, or in the future. I like the new focus on open-ness and integration, and it seems like quite a different project now. The language has syntax too! :)
appreciate the thoughts!
A point of clarification: I’d say the project is largely the same – we just dropped our editor in favor of a fancy LSP, and have an additional runtime. Darklang is still a tool for building backends seamlessly, including deploylessness.
Working on Darklang’s package manager - currently a tad stuck on some stupid technical stuff, then looking forward to quite a bit of (hopefully) uninterrupted focus work :)
This is more of a meta-level note but: this was my first post to lobste.rs – Paul had been posting Darklang updates here for a while, but I kinda questioned whether it was worth it. The site seems small, relative to others, and it seemed odd to post to it in combination with twitter/reddit/etc.
But I was wrong - while the other social medias have been just quick likes/retweets/reposts/kudos, the most engaging feedback has been here, and I appreciate y’all taking the time to read and chat about the posts for a few minutes. Also, browsing through the things that are posted here, it feels like it overlaps a lot with my interests. Anyway, thanks!
Minor comment on the language itself. I would prefer the Python’s “Flat is better than nested”. In Darklang we see:
In the result the overall code appears too idented.
Please don’t take any of those .dark files as the intended syntax of Darklang. There’s a lot of overlap, but we’ve been very limited by the fact that our old parser is a wrapper around F#‘s parser – we’re still filling out our tree-sitter -based parser to a point where we can delete the F#-based one, and then morph the syntax how we want. Totally agreed that nesting there is terrible.
I tried Darklang a while ago, and it seemed neat, but not really powerful enough to be useful to me at the time. I really like the idea of it, but I think it’s a bit too ambitious. The new direction is much more realistic, but I’m still skeptical. It seems like it’s trying to do all of:
Today all of these have independent solutions, with many good options within each, developed by thousands of developers. Replacing all of this with a single solution sounds implausible without a similar investment in time.
Even if all of these problems were solved, I don’t think we will ever see wide adoption for two reasons:
I’m not trying to be negative - if it finds a niche that would make me super happy. I want solutions to all the problems they’re trying to solve, and I love that people are working to improve how we build and ship software. Maybe I’m just being too pessimistic…
that’s changing soon - see notes here: https://blog.darklang.com/an-overdue-status-update/#licensing-and-sustainability
AGPL is something cloud providers without copyright ownership won’t touch with a ten-lawyer-long pole, but it lets honest actors fork.
for what it’s worth, we’ve already been all three of these for years. not with a lot of traction, but it’s been working!
Appreciate your reply – not taken as negative at all!
The top level of the site doesn’t explain what a darklang is, but it does link to another blog post saying they’ve gone “all in on AI”.
yeah, the website definitely needs work. We spent most of 2023 just coding, and only re-did the website somewhat recently, so there’s a lot of catching up to do to improve the content.
I think that now that darklang is trying to position itself as a more general purpose language rather than the way to develop within their cloud service, it really needs to address the question of what it offers over other ML languages head-on, in detailed “why darklang rather than ocaml” and “why darklang rather than F#” webpages.
also as a webdev language I would have liked to see something closer to opa, a full stack language that seamlessly integrated a compile-to-js part, or at the very least a web framework like phoenix. if it’s just targeting API-only web services (forgive me if that’s not the case, it’s what I gathered from a brief skim of the page) it has a ton of competition, most recently gleam if you really want an ML language, most of which have more contributors and more community.
I do wish darklang well; I love ML languages and love seeing more work in the space, but on the other hand the overall demand for ML is low enough that it really needs to sell itself better to existing enthusiasts. selling to non-ML people is a much harder task, and I’m not sure even rescript is managing that too well.
For what it’s worth, we’re just as committed to our cloud service. As stated, we expect it to be most used runtime still. We’re just building out the CLI runtime right now, so that got a bit more attention.
The questions of “why darklang rather than F#” and such remain the same answer: with Darklang, you can just code, without dealing infra or deploys, and you get the power of trace-driven debugging.
Nah, HTML stuff too! I go more into that on my related personal post: https://stachu.net/im-really-excited-about-darklang/
that post does a much better job of selling darklang than the homepage does :)
Thanks! Yeah, the homepage definitely needs work. It’s hard to capture it all, and I’m not traditionally a front-end dev, so working on the site usually comes in waves. That said, once we (soon) port darklang.com to be written in darklang, iteration on it should be much faster, and we can fill out the content that way too :)
if there’s anything in particular in that post that struck a chord, let me know – it’s good to know what feels exciting/interesting about darklang to other folks.
i think the main bit is to have it emphasised that this is not an attempt at a walled garden or lock-in, but offering people the option to just write a bit of code and have it running in the cloud immediately
I have been eyeing this project for a while. The reasons for going in a new direction are pretty much the reasons why I never tried it, so I’m excited!
But it does feel a little sad. Darklang was supposed to be this revolutionary thing that fundamentally changes the industry, but instead the industry forced Darklang to change. I look forward to a day where software development truly looks nothing like the old way, rather than just incremental improvements on editing text files and compiling over and over.
A point of clarification here - in Darklang-next you’re editing text, but not in .dark files or something. It’s all stored in a big ol’ blob of stuff, centralized and available from everywhere.
Does darklang have anything to offer there that unison hasn’t already been doing? I’m not trying to be mean, I’m just noticing that unison also occupies this niche and has been at it for longer. Maybe dark-the-cloud-platform could even be based on unison, to not reinvent the wheel :-)
Darklang I guess was never all-in on the structure-editing revolution, but bringing about that revolution is my primary focus and I will not be so easily dissuaded. If you’re interested, come drop in the BABLR discord! https://discord.gg/NfMNyYN6cX
On removing the structured editor:
I find this to be an interesting point, and I agree. There are two things that can be conflated:
(1) Software is hard to create because the UI for entering code is difficult. For example, if I am authoring some unstructured YAML file, it’s easy to make mistakes.
Also maybe I have to push to a server to test if the code is correct. (Actually I’m not sure if this is really a UI issue, I think it falls in the second category …)
(2) Software is hard because there is accidental complexity
These problems can maybe bleed into each other, but I do think it’s worth thinking about them separately.
The YAML case is kinda interesting because it’s two problems related to the same system – it has an error-prone syntax, AND you test it by a round trip to the cloud. It could be one or the other, but it’s both.
On an unrelated note, I wonder if renaming Darklang to something else makes sense at this point, or in the future. I like the new focus on open-ness and integration, and it seems like quite a different project now. The language has syntax too! :)
appreciate the thoughts! A point of clarification: I’d say the project is largely the same – we just dropped our editor in favor of a fancy LSP, and have an additional runtime. Darklang is still a tool for building backends seamlessly, including deploylessness.