Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Darklang

medium.com

Post reply on HN
Print view View original

61–70 of 261 posts

Re: Show HN: Darklang

#61

Post by pbiggar »

ryanworl wrote: post #59
pbiggar wrote: post #56

Earlier quoted context omitted.

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.

Thanks!

Re: Show HN: Darklang

#62

Post by vosper »

pbiggar wrote: post #56
ryanworl wrote: post #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?

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 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 :)

Re: Show HN: Darklang

#63

Post by pbiggar »

vosper wrote: post #62
pbiggar wrote: post #56

Earlier quoted context omitted.

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

Re: Show HN: Darklang

#64

Post by braythwayt »

mattnewport wrote: post #32
braythwayt wrote: post #24

Earlier quoted context omitted.

It feels like HN regular are unlikely to be the ideal audience for this. Reaching for a metaphor, it's like a bunch of expert Unix users gathering around an IBM PC or Macintosh in the 1980s. It's so easy to bemoan the control we lose (a major problem given our existing workflows) and have no use for the functionality it confers (simplicity, batteries included, lack of yaks that need shaving). A really great new idea…

A better metaphor would be PC and Mac users gathering round a 90s 'thin client' and expressing the same concern. If you've never heard of the 90s thin clients there's a reason...

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.

Re: Show HN: Darklang

#65

Post by roynasser »

mnm1 wrote: post #16

Why should I go for a vendor locked, proprietary solution that could disappear at any moment for any critical infrastructure? Especially when it requires a proprietary language no one has ever worked in before while there are at least a half dozen tried and true tech stacks that do this exact same thing, are not proprietary, and engineers already know them?

Look very cool, and I'd love to try it out... HOWEVER....Being closed-source, backed by a single company (startup or not) is not an acceptable level of lock-in imho.. (maybe for small pocs)...

What "guarantees" that you dont decide to charge far too much (or increase price mid-way)? What "guarantees" you wont kill a feature I need/my development requires?

Its a very nifty thing but without having self-hosting ability and this being some sort of open project (at least partially so users have a 'way out' if the company's direction changes) I cant see using this for any non-personal project...

Re: Show HN: Darklang

#66

Post by Agebor »

Great to see you unveiled. Best of luck, i really look forward to having a real cloud-native way of developing software.

Do you guys plan to support smart diffs for code reviews? As you work on AST level, it should be possible to detect some more patterns, e.g. an re-arrangement of some pieces of code, refactorings of many identifiers, etc., categorise them and have a diff summary for the review.

Re: Show HN: Darklang

#67

Post by muglug »

braythwayt wrote: post #24
muglug wrote: post #18

This project represents a stark tradeoff: lose some complexity, and lose almost all control. It feels like forcing users to learn a new language is a step too far here - I can't imagine a ton of people are so eager to build slackbots that they're willing to give up all their existing tools.

It feels like HN regular are unlikely to be the ideal audience for this. Reaching for a metaphor, it's like a bunch of expert Unix users gathering around an IBM PC or Macintosh in the 1980s. It's so easy to bemoan the control we lose (a major problem given our existing workflows) and have no use for the functionality it confers (simplicity, batteries included, lack of yaks that need shaving). A really great new idea…

My first code was written in Flash 4 (I think?), so I understand the value of a easy-to-use walled garden, and I understand how companies can make money from those walled gardens.

> A really great new idea should empower millions of people completely unlike us to build software.

I agree, but I don't think this is it — it doesn't feel like the SquareSpace of backends. It requires a bunch of pre-existing knowledge (requests, databases etc.), and its language doesn't have the simplicity of most starter languages.

Re: Show HN: Darklang

#68

Post by mattnewport »

braythwayt wrote: post #64
mattnewport wrote: post #32

Earlier quoted context omitted.

A better metaphor would be PC and Mac users gathering round a 90s 'thin client' and expressing the same concern. If you've never heard of the 90s thin clients there's a reason...

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.

Re: Show HN: Darklang

#69

Post by pbiggar »

Agebor wrote: post #66

Great to see you unveiled. Best of luck, i really look forward to having a real cloud-native way of developing software. Do you guys plan to support smart diffs for code reviews? As you work on AST level, it should be possible to detect some more patterns, e.g. an re-arrangement of some pieces of code, refactorings of many identifiers, etc., categorise them and have a diff summary for the review.

We haven't started work on the built-in code review, but that seems like a cool idea, thanks!

Re: Show HN: Darklang

#70

Post by cryptonector »

ryanworl wrote: post #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?

Right, the demo video lost me at the datastore point. This is a fancy ORM. Now, I do get that making app dev so much easier is a very good thing, but ORMs are a double-edged sword. You need an option for the dev to have much more control over the schema and queries!
Post reply on HN