Live data from Hacker News

Show HN: Darklang

medium.com

131–140 of 261 posts

Re: Show HN: Darklang

#131
Not sure I'd want to be writing services I depend on in a language whose priority is ease of prototyping.

In his post, Real problems with functional languages [0], Paul Biggar creates a false dichotomy: static types help us to write correct programs while dynamic types let us prototype faster. Dark wants to be able to do both.

I believe Haskell allows us to reject outright incorrect programs sooner and allows us to prototype things faster due to its types and inference engine. I don't really see how Haskell is poor as a prototyping language. From experience it's better than dynamic languages as it has allowed me to focus on logic and domain problems instead of mucking up my code with brittle run-time and equality checks... and then chasing down bugs I've made for myself.

No where is it mentioned what type system Dark is using. Will Dark allow a program to be deployed that it cannot reason about? What about higher-kinded types and polymorphism? Does it enforce termination or is bottom a type in every kind? Does the type system enforce linearity in usage? Quotient types? Row types?

This looks like a cool project but I don't think I'd use it for anything without knowing more about how it works.

[0] https://medium.com/darklang/real-problems-with-functional-la...

Re: Show HN: Darklang

#132

I think the fact it maintains the "backend/frontend" separation makes it an awkward product solution imo. Dark being a proprietary language means most "experienced" or "full-time" software engineers probably won't touch it. You can get pretty close to "deployless" with FaaS services now anyways in whatever language you like. So if this is being targeted toward low-experience/no-experience developers that just want to…

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 serverless stack around, but it still requires work. I'm struggling often to make my teams accept that this little extra setup work will let you iterate faster and often it's not that obvious that it would, since the overhead of the process is non-zero (for some value of zero).

I can't wait to try darklang; I'm really curious. I just need to think of a pet-project that would be suitable for the beta.

Re: Show HN: Darklang

#133
post #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.

Respectfully: why should you be considered a fair steward of trust for them, either? Those people shouldn't be using a startup-backed, no-accountability platform either.

Re: Show HN: Darklang

#134
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."

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 non-naive implementations of their ideas."

Sure, but one could argue the Darklang approach is actually not that far from a "naive implementation" of those ideas. There's only so much you can do with prefab code and lock-in tooling. There's definitely a market for "Wix for SaaS software", but does Darklang strike the right balance?

Re: Show HN: Darklang

#135
post #2

Hey folks, excited to finally unveil Dark and show you what we’ve been working on! We haven’t publicly shown how Dark works before, what code is like, or how deployless works. We hope you like it. We’re not fully publicly available yet (we hope you’ll excuse this Show HN when you can’t use it, sorry!), but we’re working hard to open Dark up to more people. Would love to hear your feedback. I’ll be around all day to a…

I’m not sure if it is possible to give you any feedback on a closed source, invite only beta release but I do have a question:

Where is this hosted? Asking as an EU based user with GDPR requirements.

Re: Show HN: Darklang

#136

Earlier quoted context omitted.

So this "non-engineer" learned a new programming language, understands Heroku and Flask, and created a REST API integration for Slack? Can anyone let me know what an engineer is again?

Many people who are "self-taught coders" don't perceive themselves as "engineers", often because many other forms of engineering have certifications. They expect that "engineer" requires a certain level of knowledge that they do not have; it's an unknown unknown kind of thing. I know someone who, through using a lot of Goole Sheets, managed to re-invent SQL joins. She'd never identify as an engineer, but she did mana…

A lot of people can do some magic stuff when it comes to spreadsheets (and as a self-taught software engineer, I am not one of them), but does that same logic really apply to API endpoints?

Look at how many acronyms are in the intro video alone ... the narrator says "we'll just use REPL ...". Does someone playing around in Google Sheets say "yes, REPL, great choice!" or do their eyes glaze over?

What about when you tell them they have to learn "Darklang"?

Re: Show HN: Darklang

#137
This may be too ambitious- throwing away control over code, editors, infrastructure, and having a sub-par offline experience seems like a dangerous move.

After watching both videos, Dark just looks like a more managed version of AWS Lambda, with a fancy proprietary editor.

Re: Show HN: Darklang

#138
Brain dump: Looks very cool. From what I can tell...

pros:

* No tooling to set up, don't have to think about project structure or computation (VMs or cloud functions)

* Don't have to think about databases, connection strings, etc

* Fast deployments

* Perfect for rapid prototyping or hackathons

cons:

* Vendor lock-in at the language and infrastructure level

* Not open source

* Have to learn a new language

Compared to serverless (for a CRUD application), I wouldn't have to write configuration to set up the API endpoints / dynamodb tables. Also, deployments would be super fast which closes the developer feedback loop. I shouldn't have to worry about emulating my stack locally or deploying my stack every time I want to test my code.

The cons make this very hard for me to buy though. My ideal framework would be open source in a popular language (JS / Go), runs on cloud (AWS / Azure / GCP), fast deployments (no cloudformation), low configuration / convention based (like nextjs), and integrates with popular NoSQL data stores (mongo, redis, etc). Basically it would be completely conventional with an opinioned data access and the ability to override features to add more complicated functionality like optimizing data access after the initial prototyping.

Re: Show HN: Darklang

#139
not sure to which spectrum this falls into but: how different is this from firebase? or from any other backend-as-a-service? surely not something for engineers, but for business/product people that want to quickly bootstrap/hack their own backend/api

Re: Show HN: Darklang

#140
post #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.

> a certain risk profile

Sure: hobby projects and experiments.

I would not include "under-resourced teams" or "new startups" in that, without many strong qualifiers attached.

Post reply on HN