Live data from Hacker News

Show HN: Darklang

medium.com

191–200 of 261 posts

Re: Show HN: Darklang

#191

I had a chance to sit down with Ellen, one of the co-founders, and see an earlier beta. Congratulations to the entire team on this milestone; excited to see what you have in store. For context, I used to run a consulting company where I shipped a lot of greenfield software, especially CRUD MVP apps (which I think is a segment you're targeting). So I love folks trying to make this kind of work easier. I'm curious who…

This is an excellent analysis. I'm in that "far right" crowd so I am just not seeing this at all.

> I think that leaves you with the beginner crowd.

The problem with that, is ... well ... $$$.

Re: Show HN: Darklang

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

> We deliberately cut relational features for now because they didn't mesh with our language. We want to add joins back

You're going to get caught in that age-old trap.

Try to make something to "make programming easy", then realize it meets the needs of very few due to lack of features, and then start adding features until it's not "easy" any more it's just programming.

And then you realize you're decades behind what people are already using to do programming.

Re: Show HN: Darklang

#193
post #63
post #62

Earlier quoted context omitted.

> We want to add joins back - right now you're doing stuff the NoSQL way Can you expand on the database capabilities? By NoSQL do you mean no relational data, no constraints, etc? You can do joins in Mongo, but it's still not an RDBMS. And you can have relational data and constraints in databases that support non-SQL query languages. NoSQL is a bit of an overloaded term these days :)

Yes, that was a bit vague, sorry. What I meant was that our datastores are simple key-value stores at the moment.

> What I meant was that our datastores are simple key-value stores at the moment.

And if you go down the route of trying to expand that, then you are no longer a tool for easily building APIs, you are now a database tool also ... and before you know it you are trying to replicate features that RDBMs have had for 40 years. I wouldn't envy trying to have to implement ACID transactions.

I realize it seems like this is hyperbole but have you drawn a fine line in the sand at where the features for Dark end? Because if not you will quickly paint yourself into a corner with this.

Re: Show HN: Darklang

#194

We have no insight as to what the actual costs of running the infrastructure is. Dark can basically ask for any numbers they want and you'd have to pay it if you build something sizable on this platform, because moving away would be even more costly.

We absolutely want everyone using Dark, so jacking the price like this would be extremely counter productive. If we did that, no-one would start using Dark after that.

> so jacking the price like this would be extremely counter productive

Maybe right now, if the funds are there. But what about in the future, where revenue is required to keep it alive?

These comparisons to Amazon are unfounded, because Amazon is not going to create a blog post one day alerting their customers that AWS is shutting down. AWS was built because Amazon needs it, and people knew that when they signed up. It's not going anywhere.

Re: Show HN: Darklang

#195

I had a chance to sit down with Ellen, one of the co-founders, and see an earlier beta. Congratulations to the entire team on this milestone; excited to see what you have in store. For context, I used to run a consulting company where I shipped a lot of greenfield software, especially CRUD MVP apps (which I think is a segment you're targeting). So I love folks trying to make this kind of work easier. I'm curious who…

This is an excellent analysis. I'm in that "far right" crowd so I am just not seeing this at all. > I think that leaves you with the beginner crowd. The problem with that, is ... well ... $$$.

I segmented the beginner crowd into two cohorts: side project folk and operations people ducktaping zapier+airtable, etc. The former does not have budget, the latter does (small businesses, early stage startups).

Re: Show HN: Darklang

#196
post #95

Earlier quoted context omitted.

Go - OK, it has one implementation (open-source), but it's backed by one big player (Google) and used by many others... also the simplicity at core design decisions sound like the kind of choices that would make an alternative compiler easier to implement than for other languages Rust - pretty fast growing open-source community despite only one implementation... but yeah I'm sort of worried that Rust is a "hard to im…

> with maybe a not high enough bus factor I'm assuming you don't mean the traditional bus factor, but one of alternative implementations? Rust (and from what I can tell after short research Julia at least partially too) has quite a big development team that is supported by many different companies with no benevolent dictator, so I don't see a big bus factor risk.

I generally read bus factor as having few who fully understand a codebase written in said language so if they were to be hit by a bus you'd lose ability not easy to hire.

Re: Show HN: Darklang

#197
post #161

Earlier quoted context omitted.

Will you guys be transparent on the pricing then?

Absolutely! We don't have any pricing right now because we have not done any work to figure out what the pricing will be.

Huh, but you have investors, eh? :-)

What about this: pass through infrastructure cost with a wee markup for maintenance/support and negotiate a modest percentage of gross revenue from your successful client companies.

That way you have a low-risk "farm" of potential big hits, and your users have stable costs.

Re: Show HN: Darklang

#198

Earlier quoted context omitted.

I have heard of thin clients, they competed with desktop apps, which were the incumbent technology. But thin clients did win, we just call them web apps now, which we run in thin client emulators we call “browsers.” And I recall incumbents scoffing at web technology back then, too.

From my perspective all the negatives of the web app approach have largely come to pass and I'm moving away from hosted cloud apps. Once bitten twice shy I guess. I'm not sure it's time to declare a winner.

Yes, your personal perspective invalidates thousands and thousands of webapps out there that are reaching massive numbers of people that they otherwise never would have ;-)

Re: Show HN: Darklang

#199
post #77
post #28

Earlier quoted context omitted.

We do intend the HN audience to love this too. Our target audience is developers building backends. We don't expect we'll wrestle people from their Emacs, so we're definitely not targeting all possible developers today, but definitely developers.

You're never going to wrestle anyone who experienced more than one tech hype cycle into such a stark vendor lock-in situation.

Yes, of course HNers are too wise to be taken by simple vendor lock-in!

    Facebook is closing Parse (parse.com)
    1202 points by theunquietone on Jan 28, 2016 | hide | past | web | favorite | 500 comments
https://news.ycombinator.com/item?id=10991729

...oh.

;-)

Re: Show HN: Darklang

#200
post #176

Earlier quoted context omitted.

So, no Rust or Go for you? EDIT: I got it, I got it. Go has multiple implementations. Bad example.

rustc had at least one other major implementation, mrustc [0], but it appears that it fell out of maintenance earlier this year :/. Last I checked, it was capable of compiling releases of rustc well past 1.0. [0]: https://github.com/thepowersgang/mrustc

Last time I looked at mrustc, it didn't have a borrow checker it just assumed the lifetimes were valid.
Post reply on HN