I'm excited about Darklang
stachu.net
stachu.net
Things have changed now. People have started realizing the problems with such approaches. As soon as you grow beyond the experimental stage, you start running into more issues than what these solutions claim to solve. It's cool to create a simple backend without writing code/less-code, but what if you want to incorporate an integration? caching? mail-server? background jobs?
I am old enough to remember Meteor.js, too. A JS framework that raises millions and it was about writing real-time applications with a single codebase. It met the same fate. Felt into oblivion in a few years after the initial hype.
Pardon my pessimistic take, but I see no future for a different language taking off, no matter how high-level primitives it offers. The network effects are too hard to overcome. And honestly, a language, even if mediocre, can implement the same thing via libraries.
scnr
The hype is over, but as of today I‘d still say it’s the most powerful JS framework all around.
If my cloud provider starts to get strange I can switch or just spin up my own.
If open source maintainers drop their projects I can fork.
If some for pay software gets greedy, I’ll replace it.
With Dark it looks as if my work is their hostage, unless I miss read the license of “Dark Core”.
So yes, the license you read is a reason why I wouldn't touch it either, but hopefully a bit further down the line the licensing situation will change substantially and we can both update our opinions then.
> I have a few 'static' websites that I'm paying nearly $700/year for [...] and I doubt any of them are getting much traffic
how come? I know it's easy to lose track of dev tooling expenses, but this is beyond imaginable to me
Zero interest rate architecture is a term I've loosely coined to represent software and infrastructure with some combination of:
* A general level of complexity far in excess of what's necessary to get the job done.
* Lots of expensive SaaS, often multiple pieces of it chained together in complex work flows. E.g. git commit to Github triggers build at service X and deployment to service Y authenticated by service Z and fronted by yet another thing and with logs sent to Datadog and... and... and... and...
* Despite the use of expensive SaaS the system still requires a lot of babysitting and manual administration, negating the point of using SaaS. Using expensive SaaS makes zero sense, full stop, unless it is saving you enough time and cognitive load to more than pay for itself.
Any static web site that costs more than $5/month kinda falls in this category for me. I picked on Vercel because JAMstack often fits these criteria.
I've seen companies spending thousands or even tens of thousands of dollars a month hosting static web sites. These could have been built on one workstation using a container or a VM and deployed at any static hosting service, but instead you have this complicated gitops workflow with multiple interlocking expensive services. The whole thing has dizzying complexity, tons of moving parts, breaks all the time, and costs a fortune.
The goal guiding these designs seems to be a desire to avoid doing things in house. In-house things are complicated and ad-hoc and expensive. So instead of doing things in-house you jam together a bunch of services... which ends up being complicated and ad-hoc and even more expensive. When it comes to complexity you've just moved the peas around on the plate, and you're spending more.
I call it zero interest rate architecture because the absurd cost of this stuff wasn't a big deal when VC money was basically free. "Just grow as fast as possible. You can optimize later."
More specific example: It's good to tone down vision statements in places people are spending their first 10 seconds with you.
The home page has the leading pitch as 37 no statements, and the "no's" are frequently scary/puzzling
ex. one of many of this class: no git? Uhhh, I'm guessing you don't mean 'no version control'. I assume I have to edit _something_ at _some_ point. And I would like it under version control...and I think anyone would...so what's going on?
By no git we definitely don't mean no version control.
So what does it mean?
Is the goal as much lock-in as possible or do you see benefits that I'm missing? I prefer the unix philosophy and like to setup my own toolbox so I'm not the target audience, I'm just curious.
Do you actually _like_ git? Or is it just good enough to get by?
Do you like having to git pull and git push and set up remotes and such? Or would something more integrated into your language and team and setup be nicer?
I think git is great, and better than many other options, but I don't think it's optimal. And it's not integrated with a larger system optimally.
Besides, while you do edit Darklang code in a text editor, it's not (WIP[1]) saved just in text files on disk. When you save, the code is automatically synced, available to you (and your team) immediately (with feature flagging and other tools to help make sure you don't "merge" incomplete/bad/broken stuff).
I absolutely understand the hesitancy, and concerns about vendor lock-in. We're doing our best to not lock users in, including working towards nice ways to "export" all of your dark stuff to another language/etc, using AI, if you so choose to bail.
[1] with minor extension, a text editor may work upon 'virtual' text files / workspaces, and when you save those, cool things happens. (yes, this is a bit hand-wavey, but we're just a few folks at this point and doing our best to make it less hand-wavey, soon :) )
I get the feeling that Darklang is intended more as a platform than a language is that correct?
Shortly before I got a job at Google in Boston, I was still living in my dying steeltown and beautiful hometown Buffalo, NY.
I was absolutely _over the moon_ that a combined juicery/bar/Indian food/sandwich shoppe/bakery was opening nearby.
It never opened
In retrospect, with age, it would have been horrible[^1], and my friends were gently teasing me about my excitement were right.
Lets say the owner did have a series of specialists or a transformative way to pull of fusing these: they would have frustrated the small portion of the vast majority willing to engage by saying "hold on, it'll be awesome and totally will have all of those foods"
[^1] it wasn't a food hall, picture the size of maybe a mcdonald's and a half. even if you had a series of specialists for each of those, there wasn't enough room for a tandoor, grill, real juicer, deli, etc. etc.
I was a big fan of Darklang at one point. It really is 10x easier to use for simple stuff.
Reading their recent update, it sounds like they’re aware of the issues. I’m still skeptical that it needs to be a new language.
I will never understand why something like this cannot be just a library. They'll make their claims and pleas, but general purpose languages are general purpose languages and can do anything
Can anyone expand on the differences between the projects (beyond the license)?
"no cruft: no build systems, no null, no exception handling, no ORMs, no OOP, no inheritence hierarchies, no async/await, no compilation, no dev environments, no dependency hell, no packaging, no git, no github, no devops: no yaml, no config files, no docker, no containers, no kubernetes, no ci/cd pipelines, no terraform, no orchestrating, no infrastructure: no sql, no nosql, no connection poolers, no sharding, no indexes, no servers, no serverless, no networking, no load balancers, no 200 cloud services, no kafka, no memcached, no unix, no OSes"
May I feed back that using your valuable first impressions time to hit me with a large list of what your language isn't is completely useless to me. I never assumed that "Darklang" would be "sharding" or "containers" in the first place. (Yes, I get the point, but I hope you get mine too.)
I don't even know how to suggest an improvement. I see that Darklang seems to be excited about some FP buzzwords, but for example citing "Option" types as your number two feature is actually very unappealing, not because it's a bad feature, but because a compelling language pitch ought to have a dozen things more unique to stick in front of that. I can get Option types all over the place and adjoin them to even more languages reasonably.
I recommend using that valuable space to demonstrate what is most unique about the language. To give you more concrete guidance and elaborate on that, you're looking for things that are true of as few other languages as possible. Option types, for instance, don't score terribly well on that metric. I get the sense that "easy deployment to the cloud" may score well, though. I'm not sure what "Copilot integration" is but there's a hint of something unique there you might want to bring out. "Self-updating exe" supported at the language level would definitely be unusual. (I've seen libraries for it but if you don't have an OTP-like sense of restarting services gracefully updating is generally violent; language-level built-on-day-1 support for graceful updates would be legitimately unique.) "Has record types" is not. Not a good first feature.
To give you something else to pitch, as well as any other burgeoning language designers, another important aspect to a language is what I was alluding to with the self-updating exe point, which is that even if your language itself isn't very unique, you can build features into your standard library and set the pattern for the rest of the community to build things that other languages can do, but don't, because the pattern was missing and the community diverged too far, too quickly. I've written before about how Go's io.Reader/io.Writer is very nice to use, but it isn't about the language features at all: https://news.ycombinator.com/item?id=28368080 It's not just about langauge features, you can also pitch the patterns you want to establish early. The Erlang community is another good example; many langauges could theoretically have "applications" like it does and run multiple applications in a single process, but the Erlang community expects people to package applications up that way and be able to start as many as they like in one OS process with "application:start".
There's a rich vein of unique value propositions to pitch in the standard library of a new language that is underutilized by other language pitches right now. And it's a strong pitch; generally this stuff gets nearly set in store in the first 5-10 years of a language and the opportunity to fix it diminishes rapidly, to the point that it is literally easier to bring up a new language than fix the old one.
I'll be honest, I did the same and at first thought Darklang was a troll project along the lines of https://github.com/kelseyhightower/nocode.
Either this is one hell of a project that is taking on all problems (and will consequently fail), or this pitch is misguided. The majority of what is listed there have nothing to do with languages.
The website, admittedly, needs a lot of work. We spent all of 2023 forking the project and having our heads down coding. Only at the end of year did we resurface to create a new homepage and stuff. So, it's a bit thin, and needs revisions. Personally I've kinda been punting that until we rewrite the site in darklang, but clearly many people are not appreciating the content on the site, so maybe that punting was a bad choice.
Appreciate the other ideas too -- responding to a bunch of comments now but will circle back to read this comment and process it fully. Cheers.
I'd love to be excited about Darklang but I don't even know what kind of context I would find it exciting in. I'm a web developer - does it even touch the domain of my projects?
Yeah -- my history is all with web dev. APIs, server- and client-side rendered HTML. Web-RTC. Http Clients. all that jazz. Your use definitely fits - in the meantime, before the site updates are done, I implore you to review the status update linked in the main post, watch the video embedded, and try out darklang-classic to get a feel. If you want a deeper peek in to our code (well, a snapshot from a bit over a year ago), the first few minutes of https://stachu.net/darklang-for-fsharp-devs might be useful.
The vision seemed to be something like Render.com (abstracted infra) plus a new language plus a new IDE.
The project is doomed.
This is absolutely the right move. SoTA LLMs are so good at code that for a devtool startup to be leveraging anything else is lunacy.
I've been slowing crawling out of this mindset but it's been a long journey.
Maybe it's OK that software / the industry means less. Maybe death just puts things into perspective? At least, that feels like a component to me. Maybe I should have spent less time coding and more time calling him.
Not sure if this applies to you, but at least for me: One thought that's helped is remembering it was my mom who pushed me to pursue computer science. I think she'd want me to rediscover the passion I used to have, even though, like you're alluding to, I've learned that it has to be done in moderation.
https://blog.paulbiggar.com/i-cant-sleep/
Overall I would stick to a normal language like Python over what this project is. It’s too ambitious for one person and it has all this other hair on it.
"At this point, the Darklang team is composed of Paul (the founder), myself (Stachu), and Feriel. As of the start of the year, Paul has stepped away to focus on Tech for Palestine. While focused on TFP, he continues to act as an advisor for Darklang as much as he has the capacity for."
These violent warriors challenging status quo and established norms: Only if they were obedient decent appropriate conformists, my world would be so much nicer.
Nah, it isn't. The same way it isn't strange that Google and Microsoft CEOs repeatedly visit Israel and praise its occupying forces for its "innovations" and "resilience" due to the "unique challenges" their neighbors pose (pay no attention to the oppression), making the desert bloom (pay no attention to the graveyards), providing them with opportunities to invest in the Startup Nation. If not, how many times have you felt "less likely to embrace" software from these companies?
> makes me less likely to embrace
Completely at ease with actual genocidal rhetoric on Israeli tech twitter (see tweets by PHP's creator Zeev Suraski or by OpenAI's Tal Broda, for example), but a banner for freedom... that's a step too far.
Astonishing how things nauseatingly repulsive don't offend but seemingly innocuous things do. Says a lot.
I'd say that Darklang-classic is ready enough for small projects, esp any web APIs. I've used it successfully for a good chunk of projects. That said, it's an imperfect solution, as outlined by the post on the main Darklang blog.
Darklang-next definitely isn't ready yet. I think I'll be porting the vast majority of _my_ code to Darklang by the end of the year, if not months earlier, but you know, software estimates. I'll do my best to keep in touch writing more posts with status updates.
All the best to you!
> This one seems to be inspired by F#.
Inspired by OCaml, to be pedantically correct.
It was pitched as an alternative standard library with the same API on Frontend (Reason or Bucklescript) and Backend (OCaml). That was before ReScript and before Darklang.