How confident are you that your database abstraction is going to fulfill the needs of someone with anything more than a few trivial query workloads? I didn't hear much about the database at all other than "it just works." This sounds like a recipe for full table scans falling over once more than ~10K records are in a given table. What about transactions? Can I do joins?
The model here is that we own the responsibility of making it scale. We haven't solved the problem of significant workload, but there doesn't seem to be any reason why this wouldn't work - certainly our current (low-scale) users have not had any scaling issues with Dark. If there's a fatal flaw we haven't thought of, please let me know. We deliberately cut relational features for now because they didn't mesh with our…
Show HN: Darklang
201–210 of 261 posts
Re: Show HN: Darklang
#202Who is this for exactly? I don't see how the target can be entirely non-technical people, since this still assumes some knowledge around databases/functions/REST/HTTP/Schemas/etc. Technical people have very little reason to use this, since this platform is a walled garden of proprietary tooling, and there's only so much you can achieve with abstractions and fancy ORM. You won't be able to break out of the mould when…
There is a large - and growing - population of technically-minded people who understand the core concepts you're referring to (REST APIs, databases, HTTP, etc) and have ideas or needs for applications, but don't have the experience required to build non-naive implementations of their ideas. Moving the bar on "high-level programming" up a few notches to remove even more of the plumbing required to build and launch an…
That is, after they learn a new programming language, error handling concept, a new IDE, and a proprietary data store.
But yes, after that it's almost drag-and-drop!
Re: Show HN: Darklang
#203Earlier quoted context omitted.
> Our target audience is developers building backends. Why wouldn't developers building back-ends just continue building back-ends in their preferred language and environments? I type this as I'm tabbed out of Visual Studio creating API back-end in C# .Net Core right now. It's easy. With this I'd have to 1) Learn a new language 2) Learn a new GUI interface for that language 3) Lock myself in
... buuuuut you don't have to learn how to: 1) deploy your code 2) deploy your datastore 3) manage your datastore 4) shard your datastore 5) deploy your infrastructur3 Among many other things. The value of Dark Lang lies not just in the programming language and the IDE, but in the holistic experience for backend development it provides, since _all_ of the overhead required to actually move to production and make new…
Or you can just get a cheap host and throw a table into a SQLite database (a file) and use JavaScript.
I'm probably not the target audience.
Re: Show HN: Darklang
#204Earlier quoted context omitted.
It seems that darklang goes one step further than your average faas: every new code you write is deployed as you write it without any explicit deploy action, but the design of the Lang/IDE ensures new code is always behind a feature flag that makes that new behavior visible only to you until you decide to expand the audience until eventually reaching 100% of the users. You can do that with any language and any server…
That progressive deployment is neat and all, but I'm not convinced that's a problem that actually existed. More importantly, I'm definitely not convinced it's a big enough feature to drive a significant amount of developers to sacrifice the ecosystem benefit from using a popular/open-source language to use a proprietary language that only works on one proprietary cloud host. Like how is that a 10x improvement on modi…
Right now I'm looking at it for what it is: food for thought.
For me this gradual deploy matters because:
1. it generalizes local development and production and possibly also staging/testing environments in between. I don't have to setup some docker-compose environment that sets up the whole shebang locally. I don't have to setup complex CI systems that spin up an env for integration tests. And I don't have to bend over backwards to ensure that both local and automated test envs are reasonably similar so I can troubleshoot when stuff fails only on CI.
2. even if I don't have that many users, and even if my uptime is not that important; I still don't want to unduly break the application. Somebody will be watching and complaining, if only your boss. What usually happens is that people tend to batch changes and have periodic pushes to production. I've seen products with relatively small user bases have very time consuming release processes. Starting weekly, then biweekly, then monthly. The more the pain, the less frequently you ended up doing them . The less frequently you ended up doing them the more painful they become. Then you end up with somebody dedicated on that because this "release engineering" is becoming clearly a bottleneck. And you do more of it, because now it's somebody's job.
Re: Show HN: Darklang
#205Earlier quoted context omitted.
Three counting google go, gcc-go and llvm-go. Last I checked the latter two were quite incomplete.
Gcc-go lags behind, but is official and kept complete. Llvm-go is unofficial.
Re: Show HN: Darklang
#206[1] "We're in this for the long haul" isn't the only reason to be worried about vendor lock-in. The other reasons might be worry that the pricing changes (for the service or for support) or that their priorities change or simply don't line up with yours (eg you require a feature that they don't plan to add).
Re: Show HN: Darklang
#207Earlier quoted context omitted.
Hijacking the joke comment to plug Dark a little bit. Data migrations and schema changes are hard (especially when you want to test on a subset of users), and Parse only avoided a lot of this pain because it was typically used for relatively simple-schema'd projects. Dark seems to have done the hard work of making an entire language and environment to avoid footguns and provide more-or-less seamless data migrations,…
> I haven't been able to try it yet but desperately want to! Yes, always good to plug something you haven't used. Are you an investor by any chance?
Re: Show HN: Darklang
#208Earlier quoted context omitted.
There is a large - and growing - population of technically-minded people who understand the core concepts you're referring to (REST APIs, databases, HTTP, etc) and have ideas or needs for applications, but don't have the experience required to build non-naive implementations of their ideas. Moving the bar on "high-level programming" up a few notches to remove even more of the plumbing required to build and launch an…
> Dark definitely won't be for everyone, but it seems to me like it will empower a lot of people to bring their ideas to reality more easily than before. That is, after they learn a new programming language, error handling concept, a new IDE, and a proprietary data store. But yes, after that it's almost drag-and-drop!
But those concepts you listed are certainly more straightforward (and aligned with "building an app") than dev ops, hosting, deployment, scaling, database config, etc..
Re: Show HN: Darklang
#209They are 'allowing' people into a private beta of a programming language? Coupled with the fact it is not open source and has a bunch of fad ad-tech videos on the front page this is so many red flags.
- Trendy font that reminds me of Comic sans - 1 MB of images and JS - Mission statement and values read as generic lifestyle brand copy. - A 1.4 mb PNG header image on their beta sign up page - Tiny unreadable video (with huge black borders) or full screen only.
Re: Show HN: Darklang
#210Earlier quoted context omitted.
There is a large - and growing - population of technically-minded people who understand the core concepts you're referring to (REST APIs, databases, HTTP, etc) and have ideas or needs for applications, but don't have the experience required to build non-naive implementations of their ideas. Moving the bar on "high-level programming" up a few notches to remove even more of the plumbing required to build and launch an…
> "Dark definitely won't be for everyone, but it seems to me like it will empower a lot of people to bring their ideas to reality more easily than before." I agree. > "There is a large - and growing - population of technically-minded people who understand the core concepts you're referring to (REST APIs, databases, HTTP, etc) and have ideas or needs for applications, but don't have the experience required to build no…
Funny that you bring up Wix, I was thinking of that comparison too earlier..
In the early days, we had Geocities, Angelfire and other hosted web publishing sites where people could tinker with the CSS and images and post their content.
Then came Wix and Squarespace and the like, where you could also edit the HTML and start to add some functionality..
Now we have Darklang where you can write code as well..
Each one targetted the level of sophistication of the current generation of digital natives who wanted to build something for themselves on the web.
And each one is likely a stepping stone along the way for those who want to keep learning and have more power and control as they build more sophisticated things.