Show HN: Darklang
21–30 of 261 posts
Re: Show HN: Darklang
#22Earlier 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.
So no GitHub integration?
Re: Show HN: Darklang
#23I have a few random questions.
1. What is the support for interop with other languages (e.g., python for machine learning, rust for low level). Or is that even a reasonable question to ask?
2. What is the pricing structure going to look like?
Very exciting! This is great.
Re: Show HN: Darklang
#24This 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'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 should empower millions of people completely unlike us to build software.
Re: Show HN: Darklang
#25Does (or will) Dark have a light mode? Given the name and seeing the dark mode screenshots in the article, I wonder. This is an honest worry for an older developer like me. When you're young, your eyes can focus on just about anything. This changes as you get older. A dark mode causes your pupils to open wider, where a light mode gets them to stop down. And if your lenses are imperfect, stopping down helps make thing…
Re: Show HN: Darklang
#26> Speed of developer iteration is the single most important factor in how quickly a technology company can move.
What? "Speed of developer iteration" barely makes any sense, it's poor wording.
In any case that proposition seems dubious. Companies exist to please customers, not its own developers. Too often we (developers) conflate our happiness/productivity with that of the actual stakeholders.
With that said, at scale one tends not to need a faster feedback loop, but greater guarantees around correctness (in logic, deployments, etc). Encouraging us to work in a mindless, iterative manner goes in the opposite direction.
Re: Show HN: Darklang
#27How does version management work with dark? Do I get access to the "raw text files"?
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.
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 your language is not hosted, how do you plan on building an eco-system around it. (I know you come from a Clojure background so you've probably seen the wonders of being able to re-use Java's ecosystem).
Re: Show HN: Darklang
#28This 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…
Re: Show HN: Darklang
#29How do I work with a team of people on something like this? How does it deal with conflicts?
That said, we haven't tested this with teams of more than two people, so we might need to change how this works.
Re: Show HN: Darklang
#30Why 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?
I don't think there are any languages that allow the same thing that Dark allows - the integration with the infrastructure is the whole point. I certainly haven't seen deployless or live values in any other stacks. Which ones are you thinking of?