3) You're totally right: we're concerned about this and have been thinking about it a lot. Obviously, vendor lock-in is a disadvantage for us because it will hurt adoption, so we'd definitely prefer this wasn't the case.
4) Bear in mind that the editor only targets Dark, including our infrastructure component, APIs, and language. So this is substantially less work than say, building vim or Atom.
5) We're targeting way way easier than that. Literally you should be able to call an API in one line (including all the retry logic, backoffs, rate limiting, auth, etc).
No that's what they are doing, you just use the new language.
I know there are many many people who have deeply invested in their environments, whether it's an editor, language, framework, etc. And there are also millions who haven't, and are looking for the tool that speaks to them like Emacs did to you.
Not sure if this is ambitious enough. Maybe you should make a database, too :)
But seriously, you'd have to convince me of a lot of things before I consider using a service like this, much less basing a business off of it:
1) The bar for your language is going to be high. Not only does it need to be appreciably better than everything out there, it needs to compensate for a lack of community / libraries.
2) You'll need to show me that your language is production ready. For most languages, it takes years to build up that level of confidence.
3) Holy vendor lock-in, Batman! What happens if you go out of business? You mean you're trying to lock me into an ecosystem that you haven't even built yet?
4) If that's not all, a new editor as well? Editors are substantially harder than most programmers think they are. It's hard to make them fast, harder to make them intuitive and there are tons of companies who focused solely on editors who have failed.
5) "High-level primitives"? "Use APIs as easily as if they were functions"? Honestly, sounds like using AWS services with Boto.