Live data from Hacker News

Show HN: Darklang

medium.com

201–210 of 261 posts

Re: Show HN: Darklang

#201
post #56

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…

It's very easy to paint yourself into a corner if you haven't figured out at least a plan of attack for these topics up-front, especially if you're starting to ramp up actual use of your product.

Re: Show HN: Darklang

#202
post #116

Who 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…

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

Re: Show HN: Darklang

#203

Earlier 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…

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

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

#204

Earlier 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…

I do share that feeling of unease that comes from non only from the lock-in but also from the departure from the text-only environment I'm so used and probably many other things that might be practical showstoppers for dark adoption.

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

#205

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

llvm-go is checked into the (recently unified) llvm repo now, so I think that it's official now. They do lag behind though.

Re: Show HN: Darklang

#206
I... don't want to be negative, I like new languages, but I can't help but feel underwhelmed. I guess I just don't understand how this meets the goals that were talked about in previous posts (or how it allows development "without accidental complexity"). I don't understand how this makes things easier and I guess when they claimed that deployment is super fast, I didn't realize they meant to infrastructure under their control. Besides the problems other people mentioned (vendor lock-in[1], non-open source programming language, few details on security), being limited to deploying on their platform, while not that unexpected and I certainly understand it, is not what I'm looking for in a programming language. I also don't really like the "HTTP is the FFI" aspect.. even in mainstream languages with fantastic library support, I find myself reaching for FFI (or libraries that themselves use FFI to wrap something else) surprisingly often. I guess this will be a hard pass for me.

[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

#207
post #148

Earlier 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?

Sigh. Not an investor, just a developer who's read their stuff and knows the pain points, and generally a fan of people doing things out of the box w/r/t software tooling. It is possible to be excited about a design pattern without knowing how a specific implementation pans out - and I probably should have said "plug what Dark is trying to do" rather than "plug Dark." But I'm chill with people disagreeing with that.

Re: Show HN: Darklang

#208
post #116

Earlier 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!

I don't recall saying it would be easy or trivial..

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

#209

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

Agreed, the quality of their web site tells a lot, especially when their product is for developers

- 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

#210
post #134
post #116

Earlier 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…

To your last point, I think we'll have to wait and see?

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.

Post reply on HN