I still remember how involved pbiggar thesis on compiling scripting languages such as php was
Show HN: Darklang
111–120 of 261 posts
Re: Show HN: Darklang
#112Who 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 the time comes, so why waste your time in the first place? Do it right the first time and maintain your flexibility and freedom later on.
I believe the only remaining target audience here is technically-inclined people that want to build a cheap prototype quickly, just to test ideas. This is a playground basically.
Re: Show HN: Darklang
#113This 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…
> A really great new idea should empower millions of people completely unlike us to build software.
Do you mean, like, some sort of "silver bullet"?
Re: Show HN: Darklang
#114Earlier 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…
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.
> Our target audience is developers building backends.
Why wouldn't developers building back-ends just continue building back-ends in their preferred language and environments?
I type this as I'm tabbed out of Visual Studio creating API back-end in C# .Net Core right now. It's easy.
With this I'd have to 1) Learn a new language 2) Learn a new GUI interface for that language 3) Lock myself in
Re: Show HN: Darklang
#115Earlier quoted context omitted.
So, no Rust or Go for you? EDIT: I got it, I got it. Go has multiple implementations. Bad example.
What? Go? gccgo: https://golang.org/doc/install/gccgo gopherjs: https://github.com/gopherjs/gopherjs tinygo: https://github.com/tinygo-org/tinygo gollvm (aka Gollum): https://go.googlesource.com/gollvm/ llvm-go: https://llvm.org/svn/llvm-project/llgo/trunk/README.TXT
I'm genuinely curious (not disparaging) who is using any of these (except for tinygo and gopherjs, for which the use case is apparent and niche)? Does anyone use gccgo or llvm-go? And why?
Re: Show HN: Darklang
#116Who 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 app is only a good thing in my mind. It provides more options for more people.
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.
Re: Show HN: Darklang
#117I got the email, and read through the post, it seems awesome. I remember the original HN post and am excited to see the progress. I 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.
1. The "foreign function interface" in Dark is HTTP. So to do machine learning, either use a service that for it, or put your ML stuff in a container with a HTTP wrapper around it. 2. We plan to charge for infrastructure, on a usage basis. If you use only a little, that should fit within the free tier.
Who backs your infrastructure? GCP, AWS, Azure?
Re: Show HN: Darklang
#118Having worked full stack for so long, sometimes things like this seem way over the top and I don't really get it. Why not have control over your language? Why not have control over deployment, VCS, servers, etc? I think I understand now that this isn't for me, but could have been once. At one point in your career, you know little or none of this stuff. Something like this would have been very empowering for me while…
I am in the same boat, I've been full stack for many years across a variety of technologies. The intro video doesn't seem like anything is being made any easier, other than hiding a few of the templated bits away from the developer. But the developer still has to understand what all this stuff MEANS. You need to understand REST, GET, PUT, REPL and any other acronyms that are involved in API development. If you know a…
One thing that crossed my mind while walking since my last comment is that this could be great when you work on a team with some junior developers. Like you say, they need to learn all the acronyms and concepts between them, but they're working in an ecosystem with guard rails and mentors who (assuming they're experienced with Dark) can easily keep them on track and help them solve common problems. Hopefully there would be less edge cases and rabbit holes to die in.
At the same time, I value all those scary holes I ventured into as a junior dev, the problem solving skills it helped develop, and the independence it instilled.
It's hard to say, I think this is a cool idea but I'm biased to prefer my own methods I guess. I can't imagine working in such a closed ecosystem these days.
Re: Show HN: Darklang
#119Dark looks really cool. When I heard about it before my initial reaction was a huge "nope", but after watching the videos I'm curious to try it out. It's amazing just how little friction there is for you to get an API endpoint backed by a datastore up and running. That being said, there are a bunch of unknowns. Having my entire application, even down the language it's implemented in, being proprietary is a little sca…
You might want to check out the serverless framework.
It's not remotely as unique as you seem to think, as even that framework is just one of many.
Re: Show HN: Darklang
#120I'm having trouble understanding what this is. Is it supposed to be a competitor to Django/Rails/etc.? or a competitor to ansible? a competitor to docker? Something else?
If I have a Django/Django REST Framework app, can I deploy it with Darklang? How is it better than "git push heroku master" for small apps?