Live data from Hacker News

Show HN: Darklang

medium.com

51–60 of 261 posts

Re: Show HN: Darklang

#51
post #45

So what kind of prototype do you have to have to get money to work on this for 2 years?

Honestly, our "prototype" was screenshots from an 800 line demo, and about half the people we spoke to believed that this wasn't actually possible to build.

Can you speak more to the scope of this? I'll be watching the video later - but, I'm curious how this "isn't possible to build"?

Also curious about the reasoning behind a new language (Dark), instead of supporting other languages out of the box. Could've started simple with supporting node / python and worked towards go, rust, etc.

Re: Show HN: Darklang

#52
post #14

Earlier quoted context omitted.

We combine version control, deployment and feature flags, with the intention of simplifying the three concepts into one. The idea is that you use feature flags to manage versions (my video on the blog post goes through that workflow). We haven't yet got features to support moving back to old versions (apart from undo), but we will.

Thanks for the quick reply :) A few more questions # Maintenance costs & agility You're not just building a programming language, you're also building an IDE, and now a version management system (through feature flags). Each of these tasks are hard problems individually, what gives you the confidence that a small startup can build all of them? All of this while trying to make your company profitable. # Ecosystem If y…

> Each of these tasks are hard problems individually, what gives you the confidence that a small startup can build all of them? All of this while trying to make your company profitable.

For sure it's hard. FYI we're hiring: https://darklang.com/careers. The intuition is that this stuff is way easier when you don't have to support everything under the sun. The editor just needs to support the Dark language, the infra is tied to it. It reduces scope massively.

> If your language is not hosted, how do you plan on building an eco-system around it.

We plan to have a package manager that is easy to contribute to. I think we should be able to grow the ecosystem quite quickly.

Re: Show HN: Darklang

#53
post #50

The way workers and events are exposed looks pretty slick, and I think abstracting away infrastructure and dev environments is the future for teams who care about speed to market. One nagging question is, how do you plan to make money? Will you have a free/freemium self-service offering? Any plans to target enterprise? I think some assurance of financial viability would ease the minds of otherwise reluctant adopters.…

We charge for infrastructure (that is, we host your infra, so you pay based on usage) - this is also what we did at CircleCI. Small users will pay us very little or fit within the free tier. Huge users will pay a lot.

We plan to support enterprise users too, but that's a little bit down the line.

Re: Show HN: Darklang

#54
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?

Re: Show HN: Darklang

#55

> Dark is a holistic programming language No thank you. There's zero chance I'm going to learn and build anything in a language owned by a startup.

Honestly, that's totally cool. There's a certain risk profile that's right for where Dark is now (new startups, low risk projects, under-resourced projects/teams). Folks with a different risk profile should not be using Dark at the moment.

Re: Show HN: Darklang

#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 language. We want to add joins back - right now you're doing stuff the NoSQL way (which is not my preferred way, but it's where we are today). We haven't figured out or transactional model, but we want to have a good story around that.

Re: Show HN: Darklang

#57
post #48

Earlier quoted context omitted.

"speed of developer iteration" is a phrase I've heard outside of Dark. Specifically, "developer iteration" is how fast you're able to iterate on ideas with your code. If you can ship stuff faster, you can iterate on your ideas faster.

It's development and not developers the thing being iterated, right? It's as if I wrote "developer deployment".

Sure, both ways make sense. Do you measure the thing being iterated upon, or the folks doing the iteration? Since they're linked, both make sense.

Re: Show HN: Darklang

#58
post #15
post #13

Ugh, why embed tiny videos that can't go full screen.

Apologies, we don't know why this is happening - something with medium and vimeo. The videos on our home page go fullscreen: https://darklang.com .

Looks like fullscreen from iframe embeds has been disabled by Medium.

Re: Show HN: Darklang

#59
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…

Sent you a Twitter DM. Too much to type out, but I have some ideas for you.

Re: Show HN: Darklang

#60
post #51
post #45

Earlier quoted context omitted.

Honestly, our "prototype" was screenshots from an 800 line demo, and about half the people we spoke to believed that this wasn't actually possible to build.

Can you speak more to the scope of this? I'll be watching the video later - but, I'm curious how this "isn't possible to build"? Also curious about the reasoning behind a new language (Dark), instead of supporting other languages out of the box. Could've started simple with supporting node / python and worked towards go, rust, etc.

Specifically in the context of fundraising, we said "backends are way too hard to build, we can remove all the accidental complexity of infrastructure, deployment, and APIs". Many people felt that that was not possible.

The "Dark's philosophy" video addresses the language a little - everything that's cool in Dark is enabled by the super tight integration between the language, editor, and infra.

Post reply on HN