12 ms·

Dark emerges with ‘deployless’ software model

97 points by yagurastation 7y ago

dman 7y ago
The page for the language is here - https://darklang.com/ https://darklang.com/ but sadly no technical details appear to be publicly available at this time.
- ericpauley 7y ago
  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.
  - dman 7y ago
    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.
  - pram 7y ago
    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.
- pbiggar 7y ago
  We've got some stuff on our blog. See here and the links at the bottom: https://medium.com/darklang/the-design-of-dark-59f5d38e52d2 https://medium.com/darklang/the-design-of-dark-59f5d38e52d2
shinryuu 7y ago
Personally I’d be surprised if this startup is around in five years
- twic 7y ago
  Right. It sounds like a fun thing to build. But i'd love to read an honest explanation from an investor of why they funded it. 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?
  - bin0 7y ago
    Trust me, getting VC money isn't magically easier at small scales. There's a reason most businesses die under-capitalized.
    - mattbillenstein 7y ago
      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.
  - mattbillenstein 7y ago
    The founders are well-enough connected to get this sorta funding...
    - twic 7y ago
      Right, and Paul Biggar founded CircleCI before this, which has been pretty successful!
  - trilila 7y ago
    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.
deleted 7y ago
[deleted]
MrLeap 7y ago
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! What's old is new again I guess.
- reallydontask 7y ago
  My first company did this with .net, so we could have had a full IDE in production, had we wanted to. We actually did have Visual Studio installed in at least one test server
- kreetx 7y ago
  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.
  - flukus 7y ago
    > 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 https://github.com/RhysU/c99sh), I bet you could go a long way with that on a network drive or with an rsync daemon.
- deleted 7y ago
  [deleted]
- zhoujianfu 7y ago
  Wait, did you work at DreamHost?!
  - MrLeap 7y ago
    Nope, it was a COBRA administration company.
- pbiggar 7y ago
trevyn 7y ago
Should probably replace with the first-party article: https://medium.com/darklang/dark-announces-3-5m-in-seed-financing-d64af8a58c1d https://medium.com/darklang/dark-announces-3-5m-in-seed-fina...
- kybernetikos 7y ago
  That site also has the benefit that I don't have to sign my personal info over to oath and their thousands of partners to read it.
  - jmngomes 7y ago
    I use outline.com to avoid that: https://outline.com/q7MMgC https://outline.com/q7MMgC
freeone3000 7y ago
How do they make money?
- nudpiedo 7y ago
  at the moment it's clear: from investors. Later on that smells too bad like a SaaS on top of other SaaS.
- arcturus17 7y ago
  They charge you by code tokens typed. Forces you to write succinct code. Win win!
- empath75 7y ago
  You have to host with them to use it.
- pbiggar 7y ago
  Dark provides the infra, so you pay us for how much compute, storage and traffic you have (pricing is planned to be cheap, think close to AWS prices)
adrianN 7y ago
I now almost nothing about Dark, but I don't understand why it is necessary to do this with a new language and a new editor.
- twic 7y ago
  I remember doing this in Smalltalk in about 2010. Multiple editing one image, which was running live!
  - nudpiedo 7y ago
    besides second player gaming emotions, how did it turn out? was it value there aside of pair programming?
    - twic 7y ago
      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.
  - TeMPOraL 7y ago
    I remember doing this in PHP in 2007. Seriously, if you quint, it sounds like "cPanel + integrated PHP editor for cloud era".
- mirekrusin 7y ago
  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.
vbsteven 7y ago
After the Parse.com fiasco I am not touching a high-vendor lock-in BaaS ever again.
- inlined 7y ago
  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.
  - vbsteven 7y ago
    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.
etxm 7y ago
I’ve only seen self pleasure articles about this company. Has anyone seen what the language or editor looks like?
tnolet 7y ago
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.
- mirekrusin 7y ago
  Also Wolfram is similar.
- arethuza 7y ago
  Isn't the platform part of Salesforce also pitched as a general purpose application development platform? (force.com or something). Microsoft used to pitch their CRM in the same way as an "XRM".
StyloW 7y ago
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.
- empath75 7y ago
  it runs on kubernetes, so...
- pbiggar 7y ago
  Founder of Dark here. Here's a thing I wrote about docker before, that led me to create Dark. https://circleci.com/blog/its-the-future/ https://circleci.com/blog/its-the-future/
  - StyloW 7y ago
    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.
    - pbiggar 7y ago
      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-financing-d64af8a58c1d https://medium.com/darklang/dark-announces-3-5m-in-seed-fina...
      - StyloW 7y ago
        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!
mroche 7y ago
> 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.
- notjesse 7y ago
  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?
  - d2mw 7y ago
    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
    - mattbillenstein 7y ago
      haha, I've been burned by app engine too - well put.
    - 7y ago
tnolet 7y ago
The marketing reminds me of the famo.us launch. “Everything completely different and proprietary and we don’t have any actual real life examples”
- tiborsaas 7y ago
  For some reason I get the same vibe. Let's hope they learned from the famo.us case (badumtsss).
nudpiedo 7y ago
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.
ilaksh 7y ago
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.
- bendbro 7y ago
  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.
- ozim 7y ago
  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.
maximilianroos 7y ago
This is hardly "emerging from stealth". This was a blog post from February! https://medium.com/darklang/the-design-of-dark-59f5d38e52d2 https://medium.com/darklang/the-design-of-dark-59f5d38e52d2
- ummonk 7y ago
  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.
- mikkom 7y ago
  Lots of marketing hype on that article without any specifics.
unfunco 7y ago
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.
pkulak 7y ago
Is there a code sample I can read? Seems like this will all hinge on this new language.
andr 7y ago
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.
- deleted 7y ago
  [deleted]
- majkinetor 7y ago
  OMG, visual programming! Instant turn-down, it simply doesn't and can't work ever.
- jmngomes 7y ago
  > 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.
  - tmikaeld 7y ago
    "Starting at US$6,250/month (Billed Annually)" 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.
- pbiggar 7y ago
  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.
ralphstodomingo 7y ago
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?
choiway 7y ago
So it's a lame version of dot net / Azure?
- inlined 7y ago
  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?
chvid 7y ago
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.
mirekrusin 7y ago
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.
- verinus 7y ago
  detachment from git? really? 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?
  - perlgeek 7y ago
    > why is a SCM all that important? 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.
- pbiggar 7y ago
  > 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).
maximilianroos 7y ago
The tone here is _extremely_ cynical. 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 https://twitter.com/sama/status/571733273996488704
- viraptor 7y ago
  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.
  - pbiggar 7y ago
    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.
twic 7y ago
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?
- inlined 7y ago
  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?
twic 7y ago
Looks like one thing the infrastructure doesn't automate is using the right SSL certificate: https://hellobirb.com/ https://hellobirb.com/ (that company is an early adopter mentioned in https://medium.com/darklang/dark-announces-3-5m-in-seed-financing-d64af8a58c1d https://medium.com/darklang/dark-announces-3-5m-in-seed-fina... )
- omnimus 7y ago
  SSL certificate automation is the hardest part of any stack.
  - jmngomes 7y ago
    Depending on how you approach it, it can be completely automated: https://github.com/Neilpang/acme.sh https://github.com/Neilpang/acme.sh
- pbiggar 7y ago
  We're manually doing SSL at the moment, and our customer controlled the DNS. Should be fixed now.
jasim 7y ago
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.
- mikkom 7y ago
  > 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. Is there some information about the language somewhere? I don't seem to find any information from the site.
  - jasim 7y ago
    https://medium.com/darklang/real-problems-with-functional-languages-efe668c5264a https://medium.com/darklang/real-problems-with-functional-la...
tigershark 7y ago
Previous discussions with answers from the founder: https://news.ycombinator.com/item?id=19274083 https://news.ycombinator.com/item?id=19274083 https://news.ycombinator.com/item?id=20394166 https://news.ycombinator.com/item?id=20394166 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.
deleted 7y ago
[deleted]
danpalmer 7y ago
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.
- pbiggar 7y ago
  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?
  - 7y ago
anm89 7y ago
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.
bump64 7y ago
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...
- jillesvangurp 7y ago
  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?
bgnm2000 7y ago
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.
theon144 7y ago
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. 0: https://news.ycombinator.com/item?id=8863 https://news.ycombinator.com/item?id=8863
- abalaji 7y ago
  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.
siffland 7y ago
So is it a 'deployless' software model, in a 'serverless' environment¿ sorry i could not resist.
rowanG077 7y ago
similar things have been possible for years with C# in visual studio where you can deploy to azure with the click of a single button if you want to.
al2o3cr 7y ago
"Emerges" my foot, this is a marketing rollout. Code or GTFO
datpuz 7y ago
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.
pbiggar 7y ago
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.
dkersten 7y ago
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. [1] https://medium.com/darklang/the-design-of-dark-59f5d38e52d2 https://medium.com/darklang/the-design-of-dark-59f5d38e52d2
inlined 7y ago
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.
- pbiggar 7y ago
  I think that what you're calling an experiment framework is what we call feature flags.
  - inlined 7y ago
    It’s good your feature flags have the necessary...features. The same word is often used for global bools; I wish there was a better word (eg “experiment” or “experiment flags”) or documentation to brag that you’re doing more than simple flags. I’m also curious what kind of infrastructure you use to affinitize the rollout to particular customers. I’m used to that being coupled to user or device IDs, which I don’t see as a coupled feature of your stack.
theshadowknows 7y ago
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.

97 points by yagurastation 7y ago

dman 7y ago

The page for the language is here - https://darklang.com/ https://darklang.com/ but sadly no technical details appear to be publicly available at this time.

ericpauley 7y ago
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.
- dman 7y ago
  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.
- pram 7y ago
  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.
pbiggar 7y ago
We've got some stuff on our blog. See here and the links at the bottom: https://medium.com/darklang/the-design-of-dark-59f5d38e52d2 https://medium.com/darklang/the-design-of-dark-59f5d38e52d2

shinryuu 7y ago

Personally I’d be surprised if this startup is around in five years

twic 7y ago
Right. It sounds like a fun thing to build. But i'd love to read an honest explanation from an investor of why they funded it. 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?
- bin0 7y ago
  Trust me, getting VC money isn't magically easier at small scales. There's a reason most businesses die under-capitalized.
  - mattbillenstein 7y ago
    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.
- mattbillenstein 7y ago
  The founders are well-enough connected to get this sorta funding...
  - twic 7y ago
    Right, and Paul Biggar founded CircleCI before this, which has been pretty successful!
- trilila 7y ago
  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.

deleted 7y ago

[deleted]

MrLeap 7y ago

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! What's old is new again I guess.

reallydontask 7y ago
My first company did this with .net, so we could have had a full IDE in production, had we wanted to. We actually did have Visual Studio installed in at least one test server
kreetx 7y ago
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.
- flukus 7y ago
  > 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 https://github.com/RhysU/c99sh), I bet you could go a long way with that on a network drive or with an rsync daemon.
deleted 7y ago
[deleted]
zhoujianfu 7y ago
Wait, did you work at DreamHost?!
- MrLeap 7y ago
  Nope, it was a COBRA administration company.
pbiggar 7y ago

trevyn 7y ago

Should probably replace with the first-party article: https://medium.com/darklang/dark-announces-3-5m-in-seed-financing-d64af8a58c1d https://medium.com/darklang/dark-announces-3-5m-in-seed-fina...

kybernetikos 7y ago
That site also has the benefit that I don't have to sign my personal info over to oath and their thousands of partners to read it.
- jmngomes 7y ago
  I use outline.com to avoid that: https://outline.com/q7MMgC https://outline.com/q7MMgC

freeone3000 7y ago

How do they make money?

nudpiedo 7y ago
at the moment it's clear: from investors. Later on that smells too bad like a SaaS on top of other SaaS.
arcturus17 7y ago
They charge you by code tokens typed. Forces you to write succinct code. Win win!
empath75 7y ago
You have to host with them to use it.
pbiggar 7y ago
Dark provides the infra, so you pay us for how much compute, storage and traffic you have (pricing is planned to be cheap, think close to AWS prices)

adrianN 7y ago

I now almost nothing about Dark, but I don't understand why it is necessary to do this with a new language and a new editor.

twic 7y ago
I remember doing this in Smalltalk in about 2010. Multiple editing one image, which was running live!
- nudpiedo 7y ago
  besides second player gaming emotions, how did it turn out? was it value there aside of pair programming?
  - twic 7y ago
    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.
- TeMPOraL 7y ago
  I remember doing this in PHP in 2007. Seriously, if you quint, it sounds like "cPanel + integrated PHP editor for cloud era".
mirekrusin 7y ago
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.

vbsteven 7y ago

After the Parse.com fiasco I am not touching a high-vendor lock-in BaaS ever again.

inlined 7y ago
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.
- vbsteven 7y ago
  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.

etxm 7y ago

I’ve only seen self pleasure articles about this company. Has anyone seen what the language or editor looks like?

tnolet 7y ago

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.

mirekrusin 7y ago
Also Wolfram is similar.
arethuza 7y ago
Isn't the platform part of Salesforce also pitched as a general purpose application development platform? (force.com or something). Microsoft used to pitch their CRM in the same way as an "XRM".

StyloW 7y ago

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.

empath75 7y ago
it runs on kubernetes, so...
pbiggar 7y ago
Founder of Dark here. Here's a thing I wrote about docker before, that led me to create Dark. https://circleci.com/blog/its-the-future/ https://circleci.com/blog/its-the-future/
- StyloW 7y ago
  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.
  - pbiggar 7y ago
    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-financing-d64af8a58c1d https://medium.com/darklang/dark-announces-3-5m-in-seed-fina...
    - StyloW 7y ago
      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!

mroche 7y ago

> 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.

notjesse 7y ago
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?
- d2mw 7y ago
  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
  - mattbillenstein 7y ago
    haha, I've been burned by app engine too - well put.
  - 7y ago

tnolet 7y ago

The marketing reminds me of the famo.us launch. “Everything completely different and proprietary and we don’t have any actual real life examples”

tiborsaas 7y ago
For some reason I get the same vibe. Let's hope they learned from the famo.us case (badumtsss).

nudpiedo 7y ago

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.

ilaksh 7y ago

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.

bendbro 7y ago
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.
ozim 7y ago
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.

maximilianroos 7y ago

This is hardly "emerging from stealth". This was a blog post from February! https://medium.com/darklang/the-design-of-dark-59f5d38e52d2 https://medium.com/darklang/the-design-of-dark-59f5d38e52d2

ummonk 7y ago
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.
mikkom 7y ago
Lots of marketing hype on that article without any specifics.

unfunco 7y ago

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.

pkulak 7y ago

Is there a code sample I can read? Seems like this will all hinge on this new language.

andr 7y ago

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.

deleted 7y ago
[deleted]
majkinetor 7y ago
OMG, visual programming! Instant turn-down, it simply doesn't and can't work ever.
jmngomes 7y ago
> 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.
- tmikaeld 7y ago
  "Starting at US$6,250/month (Billed Annually)" 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.
pbiggar 7y ago
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.

ralphstodomingo 7y ago

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?

choiway 7y ago

So it's a lame version of dot net / Azure?

inlined 7y ago
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?

chvid 7y ago

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.

mirekrusin 7y ago

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.

verinus 7y ago
detachment from git? really? 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?
- perlgeek 7y ago
  > why is a SCM all that important? 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.
pbiggar 7y ago
> 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).

maximilianroos 7y ago

The tone here is _extremely_ cynical. 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 https://twitter.com/sama/status/571733273996488704

viraptor 7y ago
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.
- pbiggar 7y ago
  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.

twic 7y ago

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?

inlined 7y ago
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?

twic 7y ago

Looks like one thing the infrastructure doesn't automate is using the right SSL certificate: https://hellobirb.com/ https://hellobirb.com/ (that company is an early adopter mentioned in https://medium.com/darklang/dark-announces-3-5m-in-seed-financing-d64af8a58c1d https://medium.com/darklang/dark-announces-3-5m-in-seed-fina... )

omnimus 7y ago
SSL certificate automation is the hardest part of any stack.
- jmngomes 7y ago
  Depending on how you approach it, it can be completely automated: https://github.com/Neilpang/acme.sh https://github.com/Neilpang/acme.sh
pbiggar 7y ago
We're manually doing SSL at the moment, and our customer controlled the DNS. Should be fixed now.

jasim 7y ago

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.

mikkom 7y ago
> 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. Is there some information about the language somewhere? I don't seem to find any information from the site.
- jasim 7y ago
  https://medium.com/darklang/real-problems-with-functional-languages-efe668c5264a https://medium.com/darklang/real-problems-with-functional-la...

tigershark 7y ago

Previous discussions with answers from the founder: https://news.ycombinator.com/item?id=19274083 https://news.ycombinator.com/item?id=19274083 https://news.ycombinator.com/item?id=20394166 https://news.ycombinator.com/item?id=20394166 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.

deleted 7y ago

[deleted]

danpalmer 7y ago

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.

pbiggar 7y ago
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?
- 7y ago

anm89 7y ago

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.

bump64 7y ago

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...

jillesvangurp 7y ago
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?

bgnm2000 7y ago

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.

theon144 7y ago

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. 0: https://news.ycombinator.com/item?id=8863 https://news.ycombinator.com/item?id=8863

abalaji 7y ago
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.

siffland 7y ago

So is it a 'deployless' software model, in a 'serverless' environment¿ sorry i could not resist.

rowanG077 7y ago

similar things have been possible for years with C# in visual studio where you can deploy to azure with the click of a single button if you want to.

al2o3cr 7y ago

"Emerges" my foot, this is a marketing rollout. Code or GTFO

datpuz 7y ago

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.

pbiggar 7y ago

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.

dkersten 7y ago

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. [1] https://medium.com/darklang/the-design-of-dark-59f5d38e52d2 https://medium.com/darklang/the-design-of-dark-59f5d38e52d2

inlined 7y ago

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.

pbiggar 7y ago
I think that what you're calling an experiment framework is what we call feature flags.
- inlined 7y ago
  It’s good your feature flags have the necessary...features. The same word is often used for global bools; I wish there was a better word (eg “experiment” or “experiment flags”) or documentation to brag that you’re doing more than simple flags. I’m also curious what kind of infrastructure you use to affinitize the rollout to particular customers. I’m used to that being coupled to user or device IDs, which I don’t see as a coupled feature of your stack.

theshadowknows 7y ago

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.