121–130 of 261 posts
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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?
On a more serious note, in my personal experience, the GCC and the LLVM back-ends are generally much better at math- and computation-heavy workloads and worse at… everything else, basically. But that was a long time ago, when gccgo still used to spawn a thread for every goroutine, so my experiences are probably outdated. Also, back in the day the LLVM back-ends used to be the only way to get link-time optimisation with Go. The GCC back-end probably can do it by now.
To answer your question directly, I don't know any large projects that use them, but they exist. Which means that there is an alternative. Unless Google goes full Oracle, that is.
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 get something running, how is it addressing the problem much better than all the no-code/low-code solutions?
For that market, I don't think having them even deal with a separate "backend" and "frontend" is a good idea, they should just be dealing with logic only and have that whole concept abstracted away.
I'm recalling the disaster that was the Parse framework. What makes this any different?
Earlier quoted context omitted.
Who backs your infrastructure? GCP, AWS, Azure?
GCP.
Earlier quoted context omitted.
As a concrete example of this: https://twitter.com/stevehind/status/1173643069347917824 > I’ve been lucky enough to be an alpha user of Dark. As a non-engineer, self-taught coder, I was able to build and deploy the back end of a react app, including a Stripe integration, faster on Dark than anything else, including Heroku + Flask. Real game changer.
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?
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 manage to get some software to accomplish her task.
There has been momentum around this kind of idea (personally I've used WolframLanguage, Anvil) - pros and cons to each approach. I'm excited to see where this goes!
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 really great new idea should empower millions of people completely unlike us to build software. Do you mean, like, some sort of "silver bullet"?