I'm not convinced. The authors cite sources of complexity that are mostly domain-specific artifacts of web development, yet make pretty broad claims about a fundamental advancement in language design. Maybe the authors have some insight about these pain points, but it certainly doesn't seem necessary to create a whole new language to solve them, especially as frameworks such as gRPC have already (at least partially) solved one of these supposed fundamental issues without replacing the base programming language.
I am not convinced either. Getting a language off the ground is a 10 year affair, don't think its possible for a funded company to bring up a new language unless they are targeting some niche where full scale programmability is not a requirement.
It might just transpile into something else, doesn’t necessarily need to be completely from scratch. Their documentation is pretty opaque though as others have mentioned so who knows.
It's simple if you know people with deep pockets -- and there was this mantra of invest in the team for awhile; not sure if that's still really a thing.
in theory having an online code editor that makes deployments and handles the infrastructure for you sounds good and from this i can see the logical deduction that this platform would save costs and simplify processes. But they are most likely not technical and as such don’t understand that code is written the way it is due to the many variations between projects.
Come use our proprietary system, we built it in the dark without embracing customers, hope we don't fail now that it's public, and launch your startup on it so we can make deployments easier.
#STUPID-IDEA
Go use Netlify.com if you want a serverless solution that you can deploy on trivially.
The language design better be exquisite to draw in early adopters. And then it better grow fast to achieve feature parity with all the other server languages.
In high school, I think I worked for a company that has prior art on deployless software. We wrote php and perl directly on the prod server with vi through putty. No deploy necessary!
Well, with compiled languages and multiple servers it does get a bit more complex.
But yes, these online editor products have been created before and afaik they rarely get significant traction. Yet, even a small user base might make it profitable, so it does make sense, and hence these companies.
> Well, with compiled languages and multiple servers it does get a bit more complex.
Compiling (and basically anything) can be done as a cgi script (https://github.com/RhysU/c99sh), I bet you could go a long way with that on a network drive or with an rsync daemon.
Dark founder here. Many people remember writing directly on the server quite fondly, because it had a great turnaround. But we stopped doing it because it wasn't safe. Dark makes it safe [1], so you can start doing it again.
I only tried it once, and the technology was pretty flaky at the time. I don't think it really went anywhere.
The focus was on the fact that you could have multiple people editing a single codebase at once, rather than on doing it in production. Indeed, you wouldn't have to do it in production, you could work on a shared development image. That was definitely a very interesting sensation, having a whole team working in a single space; like pairing but much more so. Lots of calling out to other programmers to ask them what they thought, or to suggest something. You could all work on parts of an idea at once, so you could try things out quickly. But there was so much overhead in making sure you didn't tread on each others' toes.
This doesn't seem to be the emphasis in Dark at all. In fact, i don't know what Dark's story about collaboration is. It seems to be much more about the instant deployment, and all sorts of sci-fi tooling to make that safe.
Beause everything is integrated, compiled code roughly means deployed code, they need strong, sound type system and many constructs are not allowed because the way it runs. I don't think there is a way to use threads for example because concurrency is handled above you.
I think importing something (require/import) is referring to deployed code. They blur the line between saved and deployed code. You need to have dedicated language+runtime to support such a different model.
I think their model is roughly - stateless functions only (context/state arrives as input), references (require/import) resolve to hash of ast they import; this hash is deployment "address" of function. In that sense all code is static/immutable/saved/deployed. Every time you import something, you're importing rpc wrapper, ie: 'foo = require('foo')` becomes `Foo = require(hashOf(astOf('foo')))`. I don't know if any of this is correct because there's no documentation, I don't know how they handle things like restarts or is it possible or not to have more than one deployed instances.
I’m admittedly biased (early Parse employee, but not there by shutdown). Which part was a “fiasco”? As far as turndowns go I thought it was pretty damned fair: one year notice, a live data migration pipeline to self-hosted mongo, and an open source server implementation with a free license. Facebook even paid employees to continue working on the OSS components for a while till the community became so abusive that they moved elsewhere. The only thing I think could have been smoother is if Parse appIds were indicated by subdomain rather than header, which would have allowed switching over without client code changes and minimal cost to Facebook.
And does Dark even have the same sort of risk? It says your code runs on Google Cloud, which sounds like you get to walk away with your own backend if they shut down. Parse considered AWS an implementation detail, not a feature.
The fiasco was not on Parse's end but it was ours for locking ourselves into their platform.
The sunset window was indeed fair and as you described they provided a clear migration path to self-hosted mongo and eventually the open source server.
The main problem was the vendor lock-in where our code base was completely tied to their platform and the migration which cost a lot of developer/ops time was forced upon us. Instead of improving our product we had to spend our time and money on the migration to the open source server that was still in its infancy.
After running the open source Parse server for a while which was not without its issues we decided to rewrite the product in Java/Spring/Postgres and now we are free from the lock-in. If AWS decides to quit we can move it over to Azure or GCP without too much problems.
My original comment was not a stab at Parse but a word of warning for choosing BaaS services. Parse allowed us to ship an MVP that turned into a V1 in very little time. But that productivity came with a hidden cost. A cost that nearly killed the company.
Currently there is very little known about the Dark platform and language. From what I see it looks a lot like a next-generation Parse or Firebase and I am very cautious about adopting something like that again.
Thanks for the clarification. I’ve seen a shift to BaaSes that have a core of open source and self-hostable architecture that are wrapped in vendor-specific hosting that can improve performance, reliability, simplification/integration, and extra ancillary toys. See Kubernetes vs GKE.
This reminds me a lot of the Salesforce Apex platform where the language, runtime, datamodel, hosting and all infra is part of one package.
But Salesforce has a very specific niche, this seems to be for general purpose web dev and I’m pretty sure it will be a hard time getting people to switch.
It sounds pretty cool until the point where you read something like: "Deployment is risky because you’ve only tested on your own machine, and now you need to run the same code on many different machines, to serve (millions of) users." Which makes it seem like they don't even know about the existence of Docker; making me doubt most of what they'll try to sell us.
Don't get me wrong, I understand where you're coming from and what your goals are; it'll be grand if Dark can deliver on its promises. I just don't understand why that particular statement on deployment had to be included, as it makes it sound like you're solving a problem with an existing solution.
Unfortunately when you do press, you're at the mercy of whatever gets quoted and sometimes things that are kinda irrelevant get picked up. That's definitely not the thing we wanted as the lead. Our blog post on it was different: https://medium.com/darklang/dark-announces-3-5m-in-seed-fina...
That's a fair point. Regardless of my current impression, I'll have to try it out first hand in order to form a proper opinion, so looking forward to the public release. Good luck!
> If you build your application in Dark’s language inside of Dark’s editor, the reward is you can deploy it automatically on Dark’s infrastructure on Google Cloud Platform without worrying about all of the typical underlying deployment tasks.
> ... Ellen Chisa, CEO and co-founder at the company, admits that the Dark approach requires learning to use her company’s toolset, but she says the trade-off is worth it because everything has been carefully designed to work in tandem.
So this “deployless” method is really you just offset the deploying mechanism and control (probably to varying degrees) to a third party that’s dependent on another third party. I don’t buy that. There are so many tools that make web application deployment simple and easy without constraining what tools you get to use and what platform you get to run it on.
I’d have to look more at the project itself, but just reading that article I have a number of concerns/questions with this idea. I would be interested in who they are trying to market this to. One size fits all sounds great in theory, but rarely ever works out well in practice.
Agreed. It only sounds maybe 1 step removed from where aws lambda’s are now. You fiddle with the code in the lambda IDE, and submit for deployment. Is this really that much different?
Lambda is the antithesis of frictionless development, most of your life is invested in figuring out the Lambda way to do things, just like App Engine before it
"I just need to run this function every 10 minutes"
.. (3 blog posts later)
.. (1 lunch break later)
.. (5 Git commits across 3 repos containing a mix of CloudFormation, CloudWatch and Terraform, 3 new IAM policies and 12 S3 buckets with completely unmemorable names)
.. 5pm, oh shit, I haven't actually written the function yet
DETA[0] is a scalable 'cloud computer' built out of a set of managed services and SDKs that removes time spent by you and your team on infra configuration, security, and maintenance.
I hate acronyms so much :'(. To anyone reading this, please write the full term at least once before using an obscure acronym. It's a pain to decipher, creates confusion, and results in miscommunication. I have no idea what DETA is for and google doesn't help at all. My best guess is "Deployment Estimate Time of Arrival", which doesn't make any sense...
Isn't that what people in this thread are speaking against? It may abstract something away, but with the downsides of learning this new (probably leaky) abstraction, increased third-party reliance, more magic, etc.
We believe people tend to opt for the less complex solution over time. This evolution happens slowly and may upset many people but in the end, simplicity wins. Caching, SQL, Load Balancers didn't exist a few decades ago and now we spend months of our limited time trying to tame the cloud machine.
Don't get me wrong, I'm a lover of (complex) systems, but not everybody needs them/can maintain them.
"Multi-level storage system having a buffer store with variable mapping modes" (1972) mentions caching. The term doesn't require explanation in the paper so was obviously in reasonably wide use already https://patents.google.com/patent/US3820078A/en
Dark founder here. Yes, completely agree with this. To a certain extent, Dark is aimed at being what lambda/serverless should have been.
The thing that frustrates me about Lambda (and really all of AWS) is that we're just dealing with a bit of code and bit of data. Even in 1999 when I had just started coding I could write something that runs every 10 minutes. But now it's super challenging. Why is it so hard to take a request, munge it, send it somewhere, and then respond to it. That should be trivial! (and in Dark, it is)
You think what they should have been was making people use a custom unproven language and a completely different text editor? Why would anyone want to eliminate their choice in two areas that have been commoditized so well?
I think they actually do much more, they go really deep, it's like your project is huge ast, deployed when saved/compiled/typechecked, it's like big, persisted ast tree; i think this is how they store things - as ast, ast deltas, there are no text files at all. I'm not even sure if you can save your sourcecode if it doesn't compile. Compiled (and "locked") code means deployed code. I don't know how they do deployment of single code as multiple instances - maybe they don't support it at all? ie. everything is stateless with context comming in as input? I don't know. Everything seems "dark" about this project (no reference, no examples, no playground, your code belongs to them, can't use git etc.). But it's interesting, will keep an eye open for this one.
This is the right approach to do this kind of stuff!
The problem with dark is that it's a language and it's 'hidden and proprietary' - unfortunately, it's too dark to know what it actually is so we can't but assume. I hope I'm wrong and it's less of a language and more of an editor.
I'm working on a similar sideproject where you define your data in a tree-like shape then generate stuff from that with events in between. Kind of AST but more of an Architecture Syntax Tree.
The advantages are exactly what you said and dark claims - compiled code is deployed code, otherwise it is just a data tree.
This enables automatic versioning, caching, generation and provides a better UX for development where your types are infered, your tests obvious, your errors are clear as a day and you basically can't fuck up.
Most times I've worked with Lambda (or other competing cloud functions) it's been difficult or infeasible to run my function locally. Which means I can now ONLY test my code manually after a minute or so of deploy time.
Separate from anything else about Dark, it appears to fundamentally avoid that problem.
With Azure Functions, the runtime[1] is open source, and the development tooling for VSCode makes it easy to run them locally [2], starting up in a few seconds. You pass in your database keys etc as environmental variables, and it integrates nicely with the IoT Hub tooling so you can debug the whole device sends message -> function gets hit flow in one window.
However, I have had this break in places before, and not really been able to figure out why from what is going on under the hood, needing to restart various parts to get it working. Checking the contents of the database is annoyingly manual, requiring a seperate GUI only tool[3] and hitting the refresh button a lot, a "watch" window would be much nicer. Profiling once deployed is also difficult, I ended up having to inject timestamps at various different places to try and measure end to end latency.
If Dark can give better tooling for debugging once deployed, it would be a definite advantage.
I've done a fair number of Azure Functions - mostly triggered from messages on storage queues and running locally under Visual Studio they mostly run fine with an occasional glitch where the function won't trigger - easy enough to stop it and run again. I don't find it a huge problem though.
> offset the deploying mechanism and control (probably to varying degrees) to a third party that’s dependent on another third party
This sounds exactly like working inside any big company, and all that pre-canned infrastructure is a huge benefit to any project
It will be interesting to see what they've built in the cold light of day, and whether it delivers. I'm apparently not nearly as pessimistic as others on this thread
For small things you don’t want to think about or tiny/solo teams, I could see a use case for this. But the product has to be really, __really__, fantastic for bigger groups to consider the control trade off.
I’m not bashing on the product, I’m heavily apprehensive of the model for the situations I’m involved in. I can say with certainty it’d never make its way into my current place of employment for several reasons.
The game is never to target the big teams. But make the development leaner for coming generation and smaller teams that they basically own the complete idea. This dependency play is what Google always does. Create the infrastructure, let others do the hardwork. Though I am skeptical too of the efficiency of the tradeoffs.
Pre-canned infrastructure is generally fine, this requires you use their programming language and their text editor. The article and website make no mention of if your code is stored in version control you can mirror, or if there are any plans to open source it (it appears to be a complete black box, which is fitting for a product called Dark). You also rely on their infrastructure, so it truly is putting all your eggs in the basket of a single startup.
They try to mislead saying that the only downside is learning a new language. Every good programmer loves to learn a new language. The actual, real downside is license/lock-in/ownership.
...Their website is hosted on Medium, not gitlab/hub. I rest my case.
I think that's the future. Perhaps not exactly Dark itself since we know nothing about it but a toolset that integrates all moving parts from current computation and information engineering and sets them in a well coupled system. Reinvent the wheel at higher levels.
I've been coding since I was a kid, for about 33 years. I actually think they are right about all of this stuff.
Including the part about combining everything together into a holistic solution.
It sounds like a terrific idea. Unfortunately most people seem to hate good ideas. Especially if they represent a significant change from the status quo.
And programmers are afraid to touch anything that's "easy" or moves away from colorful text representing complex obscure systems -- because sadly that is actually the only definition of programming that has stuck. And if there isn't enough of that stuff, programmers are worried they may be mistaken for users.
But maybe even though its a structured editor that makes things easier, it will still look like code and "count" psychologically as programming.
Anyway maybe it will actually become popular. Who knows. Good luck.
I think that is a consequence of "culture" being an important deciding factor in software engineering decisions. Culture causes a company to value "agile development" over "waterfall" or "strong-typing" over "weak-typing" without having solid definitions or objective arguments backing their reasons. I would like to see the day when culture is no longer a deciding factor in my work, but I don't think it's coming. People don't share foundational beliefs, and even if they did, the gap between reasoning from their foundational beliefs to their base programming beliefs is vast. Even if we all simultaneously underwent a shared spiritual experience that transformed all our foundational beliefs to a shared common set, we'd still need to reason our way upward to beliefs about programming, and that would be fraught with error. So even in a field as black and white (or red and black, if that's your preference) as programming, we will still have arguments, there will always be naysayers, we'll have conservatives who refuse to stop practicing COBOL, progressives wasting time on Frilly-BottomJavascriptContainerLib-2.0, and we'll all still be wasting time trying to get Intellij to build in our dev environment properly.
Did you had any experience with "low code" platforms? It is all easy until you hit that one case where it stops beeing easy. The same with image oriented languages. Maybe a lot of projects will profit from such solution, but for such projects that can be done "low code" you don't need developers. There has to be culture shift. If you need developers to operate your "low code", "low infrastructure", as business person you are doing something wrong.
While I also long for more powerful frameworks / libs that lighten the burden of infrastructure code and other boiler plate code having it all dominated by one company, specially a small startup is a grave problem for adoption.
I think representing programs as text is the simplest form of programs that can be used by humans and computers.
And that's why is has stuck.
Okay good. I was feeling so confused because I could have sworn I saw them posting like a year ago about paying a few early startups to dogfood the Dark platform as it was being developed.
I said this last time I read about it and I'll say it again because all I keep reading are puff-pieces with nothing to back it up, it sounds like a convoluted version of Geocities, funded by a seed round from Russ Hanneman.
I've played with some early betas of Dark and I must say being deployless may make a good headline, but there are many more-exciting features. There's visual programming, a concise OCaml-style language, a unique pub-sub mechanism baked right in, and integrated database support. It's a really fresh approach.
> deployless may make a good headline, but there are many more-exciting features. There's visual programming, a concise OCaml-style language, a unique pub-sub mechanism baked right in, and integrated database support.
So, everything that is currently delivered in the real world by technologies like OutSystems, which have an enterprise customer base, 1-click deploys, and that you can actually try for free.
No lunch is free, the small plan is a single dev and max 100 users. Which means, once you go have 101 customers you'll have to charge users at minimum 62,5$/mo just to cover expenses.
I'm not saying that's not cheap for what you get, but the "free" constraints are there.
Hi! Let me push back slightly on "visual programming". Dark looks and feels like writing textual code. There are some built-in visualizations, especially around code organization and infrastructure, but it's much more like coding in python in vscode than using Github actions.
I am doubtful. My view of the future of software engineering is that developers will be better equipped to handle _more_ complexity, not _less_. And we all know what happens when there's black boxes. Not to mention you're locked in to a particular editor and language.
Imagine this, but with any editor or language of your liking, and the option to go deeper into the machine if things go awry. Wait, isn't that how things are right now?
> Infrastructure is time consuming and difficult, especially as services start to scale.
It doesn't have to be, and it's particularly easy when you're starting out. Most of the time it's just premature optimization. When services start to scale, maybe you can invest a little more effort into this area, too, so why use Dark?
Per another article, the editor doesn’t even allow syntax errors. Seems like they have a tight pipeline built around AST manipulation, which is actually novel. I’m not sure I understand why that took a new language though.
Disallowing some side-effects?
Ensuring all valid code follows their rules?
Avoiding being dragged along by other languages authors’ changes?
Something to do with the deployment pipeline, which implies a runtime requirement?
They really need a good bottom-up example showing what Dark is and why it is different from ssh-ing into a production server and fiddle with some php-scripts.
They write about feature flags, non-text code and a fully integrated environment. So what they are trying to do is different however these ideas has been around for some time (Smalltalk/Self/some databases) but have been not been adapted by the industry of practical software development.
Probably because the implementation was never really good enough.
Radical approach - they flip the whole thing upside down. The biggest challange is not new language or ide per-se imho - but detachment from git, this has implications ie. it seems open-source hostile (you can't use it for open-source code, or am I wrong?); what about libraries?
Technically very interesting.
Practically I'm not sure it'll fly, at any complexity project development means in big part playing around locally before pushing ideas up. On dark platform the code seems to be in compiled = deployed state only, or am I wrong? What about documentation, how is testing done, benchmarking, integration tests, if the system goes crazy, is there a way to actually stop it? What about recovery from backups? Reverting to past history code? After reverting is the new code still available so it can be fixed before next deployment?
The scope they're claiming is gigantic, they must be taking compromises somewhere. There's no way is all unicorns and rainbows.
However if they manage to execute it well, the potential is huge - they can create marketplace for libraries/services, they can become appstore+github+aws in one for execution-ready solutions (libraries, services etc), which could be huge.
Wolfram does something similar. Salesforce as well. Dark seems similar but for webdev, it's like serverless/lambda v10.
this strikes me to be odd: why is a SCM all that important? even more important than a language and the ecosystem or as a vendor login already mentioned by several posters?
> The scope they're claiming is gigantic, they must be taking compromises somewhere. There's no way is all unicorns and rainbows.
There's two ways we deal with the gigantic scope:
- do the most important stuff to validate our concepts first, and don't do the other stuff yet. Then people who will tolerate the missing stuff can build on it now, and people who can't deal with today's risk may be happy with the lesser risk that comes in a year from now*
- it's actually easier to build this gigantic scope when it's all tied together. Building an editor that only works for Dark code is far easier than making something like VSCode that needs to support everything.
[*] FYI: right now we don't have testing, benchmarking, integration tests. We do run/monitor the system to control it going crazy (an on-call rotation, pagerduty, escalation, etc). Users can revert to old versions of code. We have a backup of all data stored (though it isn't yet easy to use and needs manual intervention, though we do test the backups frequently).
Before you jump from thinking a specific feature is wrong, to asserting the whole project is a waste of time: please take a moment to consider where your broad assertion might be wrong.
In the words of Sam Altman: "it's easy/fun to say every new startup you hear about is bad. you will usually be right. you will never be successful."
I'd really like to be positive about it, because there's an interesting concept hiding inside, but... They neither let me play with it, not address the very basically questions I'd ask. It's purely marketing material for a product at this point.
They talk for example about all the great save-is-deploy things and first-class feature flags and I'm still waiting to know how do I not destroy the production database with one typo and how does staging isolation work in this environment. And how do you revert changes? Again, feature flips they talk about are not it.
Founder here. This is fair. Dark is still quite early, and while we're talking about it, it's currently got a lot of sharp and ugly parts that we want to tidy up before we go public.
Happy to answer questions on it though - I answered tons of questions about it in the last HN thread.
Some specifics around your questions:
- it would take more than a type to destroy the production DB. You'd need to type DB::deleteAll, then run it (which you'll need to do as an explicit action, either click the "run this function" button, or enable the feature flag to users). We'll eventually have backups so you can undo, but we don't yet.
- staging isolation: there aren't infra questions here since we run the infra. But we'll probably allow DB clones so you can test this sort of thing.
- reverting: That depends on exactly when you want to revert. If you've made a new flag and you want to not do that anymore, just change the flag condition to "false". You can then cancel the flag, or iterate on it. If you instead want to go back to a previous point in time, we've saved every version and you'll be able to pick from them.
With the staging/deletion, I meant a scenario like this: I'm working on some feature which deletes an item I own. But in a delete condition I put "or" instead of "and" (in a non-obvious place) and the function will delete all records instead when it's run.
In the current development model, this will be caught by:
- me testing it locally (then fixing it and reloading test db)
- maybe reviews
- potentially CI/CD
But with what I understand about Dark, this will be close to auto-published on save, and the first person to try the code will delete all entries from a live table/collection.
Backups are ok, but not a solution in this case (you can't just roll back money transactions for example), and the downtime is not great. What system in Dark prevents this from happening in the first place?
> this will be close to auto-published on save, and the first person to try the code will delete all entries from a live table/collection.
Ah, that's not how it works. I think you're thinking that you edit code in your editor and then there's this super dangerous deploy. That's not it at all.
When you make new code you open a feature flag. The feature flag doesn't run until you're ready to run it. We haven't dealt with the delicate case, but I'm imagining that we'll let you put a clone of the DB in so that you can test it.
And you can have code reviews and tests and so on while the feature flag is open. Think of it like a branch.
I guess this is to be expected. HN is totally not the target audience for this. A closed, proprietary coding system is bound to be scrutinized by a site that has “hacker” in its name.
No idea what that tweet is meant to say though. People who are critical about startups are never successful? Really? You can easily argue for the opposite.
Agreed. Most of the tone here is definitely way too cynical.
The most legit feedback is probably around the proprietary language. Not because learning a new language is that bad, but that a "feature" of most languages is the ecosystem of libraries & frameworks around it. It's possible that Dark is going to be open source one day, because I don't know how they'd build everything themselves.
We (using general "we" here) spent so much time convincing developer that version control is good, reviewable changes are good, automated CI is good, and editing directly on the servers is bad. This was not because of some abstract ideas, but because of practical lessons about how to maintain long-lived applications.
And now there is a startup which says "let's edit directly on the servers, automated CI is not needed -- the code will always be correct, and we will add version control in the future.. maybe..."
I have a hunch that Dark won't generalise well. It might be good for making simple data-backed web applications. But a business of any nontrivial size has more than just simple data-backed web applications.
Do you use Dark for part of your business, and traditional tech for the rest, in which case you now have the problem of integrating your traditional stuff with Dark's black-box infrastructure?
Or do you build an MVP on Dark, then migrate on to traditional tech when you grow, in which case you now have the problem of migrating your entire business?
Or do you bet that Dark will pull more rabbits out of their hat, and you won't need to migrate?
Or do you use micro service architectures where some of your services (eg ML training) runs on dedicated/specialized hardware and traditional event/request based business logic can be written more quickly and only moved to Dark incrementally?
173 comments
[ 3.8 ms ] story [ 87.1 ms ] threadDark raised 3.5 million USD from eight funds, which is under half a million each; maybe that amount is so small that a VC will invest it just for fun?
This is an absurd approach.
Come use our proprietary system, we built it in the dark without embracing customers, hope we don't fail now that it's public, and launch your startup on it so we can make deployments easier.
#STUPID-IDEA
Go use Netlify.com if you want a serverless solution that you can deploy on trivially.
The language design better be exquisite to draw in early adopters. And then it better grow fast to achieve feature parity with all the other server languages.
What's old is new again I guess.
We actually did have Visual Studio installed in at least one test server
But yes, these online editor products have been created before and afaik they rarely get significant traction. Yet, even a small user base might make it profitable, so it does make sense, and hence these companies.
Compiling (and basically anything) can be done as a cgi script (https://github.com/RhysU/c99sh), I bet you could go a long way with that on a network drive or with an rsync daemon.
[1] https://medium.com/darklang/how-dark-deploys-code-in-50ms-77...
The focus was on the fact that you could have multiple people editing a single codebase at once, rather than on doing it in production. Indeed, you wouldn't have to do it in production, you could work on a shared development image. That was definitely a very interesting sensation, having a whole team working in a single space; like pairing but much more so. Lots of calling out to other programmers to ask them what they thought, or to suggest something. You could all work on parts of an idea at once, so you could try things out quickly. But there was so much overhead in making sure you didn't tread on each others' toes.
This doesn't seem to be the emphasis in Dark at all. In fact, i don't know what Dark's story about collaboration is. It seems to be much more about the instant deployment, and all sorts of sci-fi tooling to make that safe.
Seriously, if you quint, it sounds like "cPanel + integrated PHP editor for cloud era".
I think importing something (require/import) is referring to deployed code. They blur the line between saved and deployed code. You need to have dedicated language+runtime to support such a different model.
I think their model is roughly - stateless functions only (context/state arrives as input), references (require/import) resolve to hash of ast they import; this hash is deployment "address" of function. In that sense all code is static/immutable/saved/deployed. Every time you import something, you're importing rpc wrapper, ie: 'foo = require('foo')` becomes `Foo = require(hashOf(astOf('foo')))`. I don't know if any of this is correct because there's no documentation, I don't know how they handle things like restarts or is it possible or not to have more than one deployed instances.
And does Dark even have the same sort of risk? It says your code runs on Google Cloud, which sounds like you get to walk away with your own backend if they shut down. Parse considered AWS an implementation detail, not a feature.
The sunset window was indeed fair and as you described they provided a clear migration path to self-hosted mongo and eventually the open source server.
The main problem was the vendor lock-in where our code base was completely tied to their platform and the migration which cost a lot of developer/ops time was forced upon us. Instead of improving our product we had to spend our time and money on the migration to the open source server that was still in its infancy.
After running the open source Parse server for a while which was not without its issues we decided to rewrite the product in Java/Spring/Postgres and now we are free from the lock-in. If AWS decides to quit we can move it over to Azure or GCP without too much problems.
My original comment was not a stab at Parse but a word of warning for choosing BaaS services. Parse allowed us to ship an MVP that turned into a V1 in very little time. But that productivity came with a hidden cost. A cost that nearly killed the company.
Currently there is very little known about the Dark platform and language. From what I see it looks a lot like a next-generation Parse or Firebase and I am very cautious about adopting something like that again.
Has anyone seen what the language or editor looks like?
But Salesforce has a very specific niche, this seems to be for general purpose web dev and I’m pretty sure it will be a hard time getting people to switch.
Microsoft used to pitch their CRM in the same way as an "XRM".
> ... Ellen Chisa, CEO and co-founder at the company, admits that the Dark approach requires learning to use her company’s toolset, but she says the trade-off is worth it because everything has been carefully designed to work in tandem.
So this “deployless” method is really you just offset the deploying mechanism and control (probably to varying degrees) to a third party that’s dependent on another third party. I don’t buy that. There are so many tools that make web application deployment simple and easy without constraining what tools you get to use and what platform you get to run it on.
I’d have to look more at the project itself, but just reading that article I have a number of concerns/questions with this idea. I would be interested in who they are trying to market this to. One size fits all sounds great in theory, but rarely ever works out well in practice.
"I just need to run this function every 10 minutes"
.. (3 blog posts later)
.. (1 lunch break later)
.. (5 Git commits across 3 repos containing a mix of CloudFormation, CloudWatch and Terraform, 3 new IAM policies and 12 S3 buckets with completely unmemorable names)
.. 5pm, oh shit, I haven't actually written the function yet
Happy to elaborate more if you're interested.
[0]https://deta.sh/
Sorry for the rant.
Isn't that what people in this thread are speaking against? It may abstract something away, but with the downsides of learning this new (probably leaky) abstraction, increased third-party reliance, more magic, etc.
Don't get me wrong, I'm a lover of (complex) systems, but not everybody needs them/can maintain them.
Edit: couple => few
Edit: Regarding your edit to "few", 40-50 years (at least) isn't a few.
"Sequel: A structured English Query language" (1975) https://dl.acm.org/citation.cfm?id=811515
"Vertical Migration for Performance Enhancement in Layered Hardware/Firmware/Software Systems" (1978) describes how to do live/live migrations behind load balancers. https://www.computer.org/csdl/magazine/co/1978/05/01646957/1...
All of these technologies is way older than you think.
The thing that frustrates me about Lambda (and really all of AWS) is that we're just dealing with a bit of code and bit of data. Even in 1999 when I had just started coding I could write something that runs every 10 minutes. But now it's super challenging. Why is it so hard to take a request, munge it, send it somewhere, and then respond to it. That should be trivial! (and in Dark, it is)
The problem with dark is that it's a language and it's 'hidden and proprietary' - unfortunately, it's too dark to know what it actually is so we can't but assume. I hope I'm wrong and it's less of a language and more of an editor.
I'm working on a similar sideproject where you define your data in a tree-like shape then generate stuff from that with events in between. Kind of AST but more of an Architecture Syntax Tree. The advantages are exactly what you said and dark claims - compiled code is deployed code, otherwise it is just a data tree.
This enables automatic versioning, caching, generation and provides a better UX for development where your types are infered, your tests obvious, your errors are clear as a day and you basically can't fuck up.
Separate from anything else about Dark, it appears to fundamentally avoid that problem.
However, I have had this break in places before, and not really been able to figure out why from what is going on under the hood, needing to restart various parts to get it working. Checking the contents of the database is annoyingly manual, requiring a seperate GUI only tool[3] and hitting the refresh button a lot, a "watch" window would be much nicer. Profiling once deployed is also difficult, I ended up having to inject timestamps at various different places to try and measure end to end latency.
If Dark can give better tooling for debugging once deployed, it would be a definite advantage.
[1] https://github.com/Azure/azure-functions-host [2] https://docs.microsoft.com/en-us/azure/azure-functions/funct... [3] https://azure.microsoft.com/en-in/pricing/details/data-explo...
To find out the surprising fact that Azure IoT makes no promises about maximum latency at all, not even a "soft" guarantee without SLA penalties.
[0] https://docs.aws.amazon.com/serverless-application-model/lat...
This sounds exactly like working inside any big company, and all that pre-canned infrastructure is a huge benefit to any project
It will be interesting to see what they've built in the cold light of day, and whether it delivers. I'm apparently not nearly as pessimistic as others on this thread
I’m not bashing on the product, I’m heavily apprehensive of the model for the situations I’m involved in. I can say with certainty it’d never make its way into my current place of employment for several reasons.
I guess I’n with the pessimistic people. I just cannot see it ending well.
It is a closed invite-only product.
They try to mislead saying that the only downside is learning a new language. Every good programmer loves to learn a new language. The actual, real downside is license/lock-in/ownership.
...Their website is hosted on Medium, not gitlab/hub. I rest my case.
> Every good programmer loves to learn a new language.
Er... no. I am still seeing new ways to leverage C after 40 years on it. Creating a new language is the ultimate self-indulgence.
“Everything completely different and proprietary and we don’t have any actual real life examples”
Including the part about combining everything together into a holistic solution.
It sounds like a terrific idea. Unfortunately most people seem to hate good ideas. Especially if they represent a significant change from the status quo.
And programmers are afraid to touch anything that's "easy" or moves away from colorful text representing complex obscure systems -- because sadly that is actually the only definition of programming that has stuck. And if there isn't enough of that stuff, programmers are worried they may be mistaken for users.
But maybe even though its a structured editor that makes things easier, it will still look like code and "count" psychologically as programming.
Anyway maybe it will actually become popular. Who knows. Good luck.
I think representing programs as text is the simplest form of programs that can be used by humans and computers. And that's why is has stuck.
So, everything that is currently delivered in the real world by technologies like OutSystems, which have an enterprise customer base, 1-click deploys, and that you can actually try for free.
No lunch is free, the small plan is a single dev and max 100 users. Which means, once you go have 101 customers you'll have to charge users at minimum 62,5$/mo just to cover expenses.
I'm not saying that's not cheap for what you get, but the "free" constraints are there.
Imagine this, but with any editor or language of your liking, and the option to go deeper into the machine if things go awry. Wait, isn't that how things are right now?
> Infrastructure is time consuming and difficult, especially as services start to scale.
It doesn't have to be, and it's particularly easy when you're starting out. Most of the time it's just premature optimization. When services start to scale, maybe you can invest a little more effort into this area, too, so why use Dark?
Disallowing some side-effects? Ensuring all valid code follows their rules? Avoiding being dragged along by other languages authors’ changes? Something to do with the deployment pipeline, which implies a runtime requirement?
They write about feature flags, non-text code and a fully integrated environment. So what they are trying to do is different however these ideas has been around for some time (Smalltalk/Self/some databases) but have been not been adapted by the industry of practical software development.
Probably because the implementation was never really good enough.
Technically very interesting.
Practically I'm not sure it'll fly, at any complexity project development means in big part playing around locally before pushing ideas up. On dark platform the code seems to be in compiled = deployed state only, or am I wrong? What about documentation, how is testing done, benchmarking, integration tests, if the system goes crazy, is there a way to actually stop it? What about recovery from backups? Reverting to past history code? After reverting is the new code still available so it can be fixed before next deployment?
The scope they're claiming is gigantic, they must be taking compromises somewhere. There's no way is all unicorns and rainbows.
However if they manage to execute it well, the potential is huge - they can create marketplace for libraries/services, they can become appstore+github+aws in one for execution-ready solutions (libraries, services etc), which could be huge.
Wolfram does something similar. Salesforce as well. Dark seems similar but for webdev, it's like serverless/lambda v10.
this strikes me to be odd: why is a SCM all that important? even more important than a language and the ecosystem or as a vendor login already mentioned by several posters?
It's a central integration point for many workflows these days: code review, CI/CD, issue tracking, code quality metrics etc.
If you don't use a standard SCM, you'll have to either do without those tools, or build an integration yourself.
There's two ways we deal with the gigantic scope:
- do the most important stuff to validate our concepts first, and don't do the other stuff yet. Then people who will tolerate the missing stuff can build on it now, and people who can't deal with today's risk may be happy with the lesser risk that comes in a year from now*
- it's actually easier to build this gigantic scope when it's all tied together. Building an editor that only works for Dark code is far easier than making something like VSCode that needs to support everything.
[*] FYI: right now we don't have testing, benchmarking, integration tests. We do run/monitor the system to control it going crazy (an on-call rotation, pagerduty, escalation, etc). Users can revert to old versions of code. We have a backup of all data stored (though it isn't yet easy to use and needs manual intervention, though we do test the backups frequently).
Before you jump from thinking a specific feature is wrong, to asserting the whole project is a waste of time: please take a moment to consider where your broad assertion might be wrong.
In the words of Sam Altman: "it's easy/fun to say every new startup you hear about is bad. you will usually be right. you will never be successful."
https://twitter.com/sama/status/571733273996488704
They talk for example about all the great save-is-deploy things and first-class feature flags and I'm still waiting to know how do I not destroy the production database with one typo and how does staging isolation work in this environment. And how do you revert changes? Again, feature flips they talk about are not it.
Happy to answer questions on it though - I answered tons of questions about it in the last HN thread.
Some specifics around your questions:
- it would take more than a type to destroy the production DB. You'd need to type DB::deleteAll, then run it (which you'll need to do as an explicit action, either click the "run this function" button, or enable the feature flag to users). We'll eventually have backups so you can undo, but we don't yet.
- staging isolation: there aren't infra questions here since we run the infra. But we'll probably allow DB clones so you can test this sort of thing.
- reverting: That depends on exactly when you want to revert. If you've made a new flag and you want to not do that anymore, just change the flag condition to "false". You can then cancel the flag, or iterate on it. If you instead want to go back to a previous point in time, we've saved every version and you'll be able to pick from them.
With the staging/deletion, I meant a scenario like this: I'm working on some feature which deletes an item I own. But in a delete condition I put "or" instead of "and" (in a non-obvious place) and the function will delete all records instead when it's run.
In the current development model, this will be caught by:
- me testing it locally (then fixing it and reloading test db)
- maybe reviews
- potentially CI/CD
But with what I understand about Dark, this will be close to auto-published on save, and the first person to try the code will delete all entries from a live table/collection.
Backups are ok, but not a solution in this case (you can't just roll back money transactions for example), and the downtime is not great. What system in Dark prevents this from happening in the first place?
Ah, that's not how it works. I think you're thinking that you edit code in your editor and then there's this super dangerous deploy. That's not it at all.
When you make new code you open a feature flag. The feature flag doesn't run until you're ready to run it. We haven't dealt with the delicate case, but I'm imagining that we'll let you put a clone of the DB in so that you can test it.
And you can have code reviews and tests and so on while the feature flag is open. Think of it like a branch.
No idea what that tweet is meant to say though. People who are critical about startups are never successful? Really? You can easily argue for the opposite.
If 95% of things fail, you'll be correct 95% of the time by calling each thing a failure.
But you'll never be in the 5% yourself. (sure, an exaggeration to say you'll never be successful, but such is 140 characters)
(Agree with your points re audience. I'd hope people can differentiate between things they don't use and things that are useless)
The most legit feedback is probably around the proprietary language. Not because learning a new language is that bad, but that a "feature" of most languages is the ecosystem of libraries & frameworks around it. It's possible that Dark is going to be open source one day, because I don't know how they'd build everything themselves.
And now there is a startup which says "let's edit directly on the servers, automated CI is not needed -- the code will always be correct, and we will add version control in the future.. maybe..."
How do you think people will react to this?
Do you use Dark for part of your business, and traditional tech for the rest, in which case you now have the problem of integrating your traditional stuff with Dark's black-box infrastructure?
Or do you build an MVP on Dark, then migrate on to traditional tech when you grow, in which case you now have the problem of migrating your entire business?
Or do you bet that Dark will pull more rabbits out of their hat, and you won't need to migrate?