> 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.
> 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
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?
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'm excited by almost everything about this. I think it could be transformational in some categories of software engineering, but I do have a big concern...
> I think the biggest downside of Dark is definitely that you’re learning a new language...
But this is not it. Learning new languages isn't that hard, and a language so well designed for an ecosystem would likely be a pleasure to use. They are probably giving this as their "big downside" because it's not actually their big downside.
The real big downside is proprietary lock-in. My tools right now are open source, developed in the open, things I can contribute to or at least understand at a fundamental level. "Python" can't go out of business, "Postgres" won't get acquihired and shut down with 30 days notice, and Docker images can run on plenty of hosting providers where there's lots of competition.
While I might bet a company on a new technology I'm not going to bet a company entirely on the whim of a company, who may pivot, get bought, shut down, raise prices, etc. Hosting is the closest I'd get to this level of lock-in, but if that changes I don't have to rewrite all of my code, reproduce business logic, and also rewrite from a high level language like Dark to something that doesn't provide any of the same primitives.
Founder here. Totally fair concern - we're not thrilled about the lock-in either because we want people to try Dark and see that it solves a problem for them. We're looking at ways to improve this - would love ideas, and will be writing up some of our ideas soon.
Around some of the specifics: we've no intention of pivoting. If we discovered that Dark had a massive opportunity to be the AirBnb for market analytics (or whatever) we would 100% ignore it and keep doing what we're doing. Around pricing, we want Dark to be super cheap. Our intent is to be "within 2x of running the same app written in Node on AWS". We saw how much people leave Heroku because of the premium pricing and we don't want that to be us.
The other stuff is valid and we're looking for ideas here. Would it solve your problem if you were able to export a mostly similar working node/python/go app from your Dark program? Would it need kubernetes configs or to run on Heroku? Would you prefer that it be semantically exactly the same but the code is ugly, or with the code having the same look-and-feel but slightly different semantics?
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.
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.
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.
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.
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..."
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.
I'm getting serious "Building Dropbox is trivial with with curlftpfs, SVN and CVS"[0] vibes from this thread.
Sure, all it provides is already technically possible with what exists - but what if the 10% they shave off turns out to be the crucial 10% that carve out a completely new area in programming? Maybe having a fully integrated development experience actually is the "retrospectively obvious" missing thing...
That said, their exclusivity-first approach whose first step essentially is full and complete vendor lock-in makes me skeptical too. I personally don't think they'll be too successful, as the model they're proposing is both uninviting to newcomers and fraught with sustainability perils for any serious long-term project. And that's just from a business perspective, I can't overstate how important I consider open technologies to be.
But I can't get rid of the "future of programming" tingling, which a few people here have alluded to as well. The "open-decentralized-interoperable" bazaar and the "monolithic-integrated" cathedral conflict is as old as time. And while zero-friction infrastructure is a nice selling point, I'm personally more interested in what's allowed by having the language, editor, and apparently the entire ecosystem be developed hand-in-hand from the first step - a lot of fancier features (smart code completion, thorough static analysis, code exploration, automatic diagramming, proper e2e testing) is hard specifically because it needs to built on top of what already exists.
Having a garden with walls this high might actually bring a lot of surprises.
While I agree with a lot of what you said I'd like to point out that Dropbox's initial customer was the common person, a non-tech savvy person who didn't want to carry USB drive around. Dark's customer base are developers in this thread, likely to be early adopters. That's my sense at least.
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.
> 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).
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?
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?
This would have appealed to me before building a rather large side project with Google Cloud's proprietary Firestore database. There are loads of drawbacks that slowly become apparent the more I build and the deeper I dig myself into that hole. I loved how quickly I was able to get something up and running, and was super excited about it at first. But as I've had to add more and more features and turn it into a real project, being limited to only the tools provided by the vendor has become a real drag. Migration, testing, debugging, is all so much more of a pain. Can't even run my application locally without an internet connection. On top of all of that, there may be pricing hikes, or the service could go away all together.
With that experience, it would be hard for me to be convinced that something like Dark would be worth the risk. With things like this, you don't always realize the drawbacks until it's too late. Now, for my side project, I'm only really stuck with the database - locking myself into a programming language and even a text editor sounds like a nightmare.
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.
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.
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.
I'm very excited about this idea and have even asked for an early access invite.
These days I don't care about being in full control of my back-end stack - I just want to build something and ship it with least hassle as possible. I don't want to deal with provisioning, infra as code, containers, orchestration, message queues, load balancing, autoscaling, build configs and sundry.
I just need a statically typed functional language in which I can do that, which Dark is - it seems to have an Elm/OCaml inspired language.
Being fully tied to their platform with no alternative to migrate away to is the least pleasant aspect of the product as it stands today. But the product isn't even public yet - it is a difficult problem space that is badly in need of innovation and simplification - and many things are yet to be figured out. I'd be charitable to that aspect and see what as an industry we can learn from what Dark is doing.
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’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.
I’ve used Dark for the backend of a mobile app (> 20k installs) during the beta, and it has been an incredible experience. Something like 30 lines of code do it all.
Dark is a game changer in my opinion for getting a prototype online as quickly as possible, or a lightweight backend - and I imagine it can and will support much more.
This seems misguided to me. How do you get people into an ecosystem like this that is totally isolated.
If I'm a startup am I going to choose a language that has no developer base and no experienced devs and no ecosystem, without git, that's closed source so I can avoid hiring some devops manpower?
It seems like only a company with a massive builtin captive audience could pull this off. This makes it feel like they are doing this to be acquired which makes the whole thing even less appealing.
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.
For the last 10 years I've been working mostly on CI and CD automation for a few projects that as part of their offering tried to automate the deployment for their clients.
In general when you try to simplify a process you increase the level of abstraction which leads to additional complexity in terms of customization and integration with third party systems and tools. Then you decide that it is a good idea to offer integration with the third party systems and tools and you increase the abstraction even more which increases the complexity even more. Also in the end you wonder if you are in the CD tools business or you are offering your core product.
It is much more productive to develop the product in mind with the tools for deployment that are already available. Unless you want to have a product and a "Services" division that configures and operates your product for the clients...
Agreed. You have to develop such that your product survives whatever is fashionable today in any case. As Joel Spolsky pointed out at some point, your architecture is not the framework you picked.
On the other hand, CD/CI needs to be an enabler and in small startup there is only so much time you can dedicate to it. Any change on this front tends to be disruptive and suck up non trivial amounts of development time. So keep it simple. Follow the principle of the least amount of surprise (for new team members if you hire them). And keep it reasonable. You are going to cut corners here one way or another. Don't obsess about that.
The Dark people seems to want you to buy into their entire stack (editor, language, saas platform, etc.). That sounds like a lot of risky unproven technology to me. Maybe use something more mainstream like heroku?
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.
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.
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.
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.
From my point of view I don’t think I could inextricably bind my projects to a third party without any recourse in case something on their side changes.
Deployment is not really a big deal nowadays, unless you work at a huge scale. But if you are working at that scale I don’t really think that you are eager to commit yourself completely to a small startup.
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?
I mean I guess. Salesforce did it with Apex and Wolfram did it with Wolframlang or whatever Steve is calling it these days. But I feel like this is a solution in search of a problem. The issue isn’t complexity or even accidental complexity. It’s that businesses usually have many competing and often conflicting needs. I can already hear the angry snort when I go to the head DBA and ask if I can use some new hosted product to replace our on prem data warehouse. It’ll never happen. And it’s not even an “old school” thing. We just have a variety of reasons why it’s a bad solution. So now we talk about setting up small web apps hosted in Dark’s cloud. How is it any better than what we have hosted in Amazon, Google, and Azure where we also have the ability to at any minute tap in to a huge market of developers? I guess then we look at this for new projects that aren’t interfacing with production stuff? In that case I guess it’s an interesting experiment. But the reality is that most corporate things (from my experience anyway) have an if it ain’t broke don’t fix it mentality and with good (often painfully learned) reasons. I’m not debating the values of this (it’s hard to since their entire site is marketing buzzwords) but I’m saying it doesn’t seem on the face of it to be a realistic problem solver. I’m very likely wrong but that’s how it feels to me.
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.
I don't get it. I tried to find out anything about what Dark is, how it works, or what it looks like and found almost nothing. They make claims like "holistic programming language" but don't show me what they mean. The What is Dark[1] blog post makes a lot of claims, but I've seen these claims made many times and they rarely live up to the hype. They don't show me how they plan to meet these claims or what it looks like. Finally, their marketing focus is on deployment, but honestly, deployment really has never been the biggest pain point for me. Sure, it can be a headache, but its nowhere near as much work as actually writing the applications themselves. I'm not convinced.
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.
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.
One question/unsolicited advice: the articles frequently mention “feature flags,” but these will cause simultaneous rollout in prod without any real testing or canary.
It seems like an experiment framework (eg whitelisted customers or IP addresses for alpha testing and percent rollouts) is a min bar for any reasonable implementation in Dark.
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.
Cofounder/CTO here. Sorry this went up when I was sleeping, so I missed the discussion. I'll answer some things through the threads but if you have any questions for me I'm here.
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?
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.
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.
mroche|6 years ago
> ... 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.
d2mw|6 years ago
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
notjesse|6 years ago
gcb0|6 years ago
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.
danpalmer|6 years ago
> I think the biggest downside of Dark is definitely that you’re learning a new language...
But this is not it. Learning new languages isn't that hard, and a language so well designed for an ecosystem would likely be a pleasure to use. They are probably giving this as their "big downside" because it's not actually their big downside.
The real big downside is proprietary lock-in. My tools right now are open source, developed in the open, things I can contribute to or at least understand at a fundamental level. "Python" can't go out of business, "Postgres" won't get acquihired and shut down with 30 days notice, and Docker images can run on plenty of hosting providers where there's lots of competition.
While I might bet a company on a new technology I'm not going to bet a company entirely on the whim of a company, who may pivot, get bought, shut down, raise prices, etc. Hosting is the closest I'd get to this level of lock-in, but if that changes I don't have to rewrite all of my code, reproduce business logic, and also rewrite from a high level language like Dark to something that doesn't provide any of the same primitives.
pbiggar|6 years ago
Around some of the specifics: we've no intention of pivoting. If we discovered that Dark had a massive opportunity to be the AirBnb for market analytics (or whatever) we would 100% ignore it and keep doing what we're doing. Around pricing, we want Dark to be super cheap. Our intent is to be "within 2x of running the same app written in Node on AWS". We saw how much people leave Heroku because of the premium pricing and we don't want that to be us.
The other stuff is valid and we're looking for ideas here. Would it solve your problem if you were able to export a mostly similar working node/python/go app from your Dark program? Would it need kubernetes configs or to run on Heroku? Would you prefer that it be semantically exactly the same but the code is ugly, or with the code having the same look-and-feel but slightly different semantics?
andr|6 years ago
jmngomes|6 years ago
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.
pbiggar|6 years ago
unknown|6 years ago
[deleted]
majkinetor|6 years ago
[deleted]
maximilianroos|6 years ago
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
viraptor|6 years ago
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.
tnolet|6 years ago
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.
theamk|6 years ago
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?
unknown|6 years ago
[deleted]
shay_ker|6 years ago
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.
Nullabillity|6 years ago
theon144|6 years ago
Sure, all it provides is already technically possible with what exists - but what if the 10% they shave off turns out to be the crucial 10% that carve out a completely new area in programming? Maybe having a fully integrated development experience actually is the "retrospectively obvious" missing thing...
That said, their exclusivity-first approach whose first step essentially is full and complete vendor lock-in makes me skeptical too. I personally don't think they'll be too successful, as the model they're proposing is both uninviting to newcomers and fraught with sustainability perils for any serious long-term project. And that's just from a business perspective, I can't overstate how important I consider open technologies to be.
But I can't get rid of the "future of programming" tingling, which a few people here have alluded to as well. The "open-decentralized-interoperable" bazaar and the "monolithic-integrated" cathedral conflict is as old as time. And while zero-friction infrastructure is a nice selling point, I'm personally more interested in what's allowed by having the language, editor, and apparently the entire ecosystem be developed hand-in-hand from the first step - a lot of fancier features (smart code completion, thorough static analysis, code exploration, automatic diagramming, proper e2e testing) is hard specifically because it needs to built on top of what already exists.
Having a garden with walls this high might actually bring a lot of surprises.
0: https://news.ycombinator.com/item?id=8863
abalaji|6 years ago
mirekrusin|6 years ago
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.
pbiggar|6 years ago
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).
verinus|6 years ago
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?
ralphstodomingo|6 years ago
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?
datpuz|6 years ago
With that experience, it would be hard for me to be convinced that something like Dark would be worth the risk. With things like this, you don't always realize the drawbacks until it's too late. Now, for my side project, I'm only really stuck with the database - locking myself into a programming language and even a text editor sounds like a nightmare.
MrLeap|6 years ago
What's old is new again I guess.
reallydontask|6 years ago
We actually did have Visual Studio installed in at least one test server
kreetx|6 years ago
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.
pbiggar|6 years ago
[1] https://medium.com/darklang/how-dark-deploys-code-in-50ms-77...
zhoujianfu|6 years ago
unknown|6 years ago
[deleted]
tnolet|6 years ago
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.
arethuza|6 years ago
Microsoft used to pitch their CRM in the same way as an "XRM".
mirekrusin|6 years ago
jasim|6 years ago
These days I don't care about being in full control of my back-end stack - I just want to build something and ship it with least hassle as possible. I don't want to deal with provisioning, infra as code, containers, orchestration, message queues, load balancing, autoscaling, build configs and sundry.
I just need a statically typed functional language in which I can do that, which Dark is - it seems to have an Elm/OCaml inspired language.
Being fully tied to their platform with no alternative to migrate away to is the least pleasant aspect of the product as it stands today. But the product isn't even public yet - it is a difficult problem space that is badly in need of innovation and simplification - and many things are yet to be figured out. I'd be charitable to that aspect and see what as an industry we can learn from what Dark is doing.
mikkom|6 years ago
Is there some information about the language somewhere? I don't seem to find any information from the site.
dman|6 years ago
ericpauley|6 years ago
pbiggar|6 years ago
vbsteven|6 years ago
inlined|6 years ago
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.
bgnm2000|6 years ago
Dark is a game changer in my opinion for getting a prototype online as quickly as possible, or a lightweight backend - and I imagine it can and will support much more.
anm89|6 years ago
If I'm a startup am I going to choose a language that has no developer base and no experienced devs and no ecosystem, without git, that's closed source so I can avoid hiring some devops manpower?
It seems like only a company with a massive builtin captive audience could pull this off. This makes it feel like they are doing this to be acquired which makes the whole thing even less appealing.
trevyn|6 years ago
kybernetikos|6 years ago
tnolet|6 years ago
“Everything completely different and proprietary and we don’t have any actual real life examples”
tiborsaas|6 years ago
StyloW|6 years ago
pbiggar|6 years ago
empath75|6 years ago
bump64|6 years ago
In general when you try to simplify a process you increase the level of abstraction which leads to additional complexity in terms of customization and integration with third party systems and tools. Then you decide that it is a good idea to offer integration with the third party systems and tools and you increase the abstraction even more which increases the complexity even more. Also in the end you wonder if you are in the CD tools business or you are offering your core product.
It is much more productive to develop the product in mind with the tools for deployment that are already available. Unless you want to have a product and a "Services" division that configures and operates your product for the clients...
jillesvangurp|6 years ago
On the other hand, CD/CI needs to be an enabler and in small startup there is only so much time you can dedicate to it. Any change on this front tends to be disruptive and suck up non trivial amounts of development time. So keep it simple. Follow the principle of the least amount of surprise (for new team members if you hire them). And keep it reasonable. You are going to cut corners here one way or another. Don't obsess about that.
The Dark people seems to want you to buy into their entire stack (editor, language, saas platform, etc.). That sounds like a lot of risky unproven technology to me. Maybe use something more mainstream like heroku?
ilaksh|6 years ago
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.
ozim|6 years ago
verinus|6 years ago
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.
bendbro|6 years ago
nudpiedo|6 years ago
tigershark|6 years ago
From my point of view I don’t think I could inextricably bind my projects to a third party without any recourse in case something on their side changes. Deployment is not really a big deal nowadays, unless you work at a huge scale. But if you are working at that scale I don’t really think that you are eager to commit yourself completely to a small startup.
twic|6 years ago
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?
inlined|6 years ago
theshadowknows|6 years ago
chvid|6 years ago
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.
dkersten|6 years ago
[1] https://medium.com/darklang/the-design-of-dark-59f5d38e52d2
maximilianroos|6 years ago
ummonk|6 years ago
mikkom|6 years ago
al2o3cr|6 years ago
twic|6 years ago
https://hellobirb.com/
(that company is an early adopter mentioned in https://medium.com/darklang/dark-announces-3-5m-in-seed-fina... )
pbiggar|6 years ago
omnimus|6 years ago
adrianN|6 years ago
mirekrusin|6 years ago
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.
duncanawoods|6 years ago
twic|6 years ago
inlined|6 years ago
It seems like an experiment framework (eg whitelisted customers or IP addresses for alpha testing and percent rollouts) is a min bar for any reasonable implementation in Dark.
pbiggar|6 years ago
etxm|6 years ago
Has anyone seen what the language or editor looks like?
pkulak|6 years ago
unfunco|6 years ago
pbiggar|6 years ago
rowanG077|6 years ago
unknown|6 years ago
[deleted]
unknown|6 years ago
[deleted]
freeone3000|6 years ago
pbiggar|6 years ago
arcturus17|6 years ago
nudpiedo|6 years ago
empath75|6 years ago
siffland|6 years ago
sorry i could not resist.
choiway|6 years ago
inlined|6 years ago
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?
shinryuu|6 years ago
twic|6 years ago
Dark 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?
arcturus17|6 years ago
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.
empath75|6 years ago
godzillabrennus|6 years ago
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.