4 ms·
> We’re creating a new programming language, tightly integrated with an editor, compiler and PaaS, to allow engineers to build distributed applications using hi
by temuze 9y ago
> We’re creating a new programming language, tightly integrated with an editor, compiler and PaaS, to allow engineers to build distributed applications using high-level primitives.
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.
- jethro_tell 9y ago> "High-level primitives"? "Use APIs as easily as if they were functions"? Honestly, sounds like using AWS services with Boto. No that's what they are doing, you just use the new language.
- pbiggar 9y ago1,2) Yes, agreed. 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).
- z0r 9y agoIs your editor written in elisp?
- pbiggar 9y agoOCaml and Elm right now.
- chasedehan 9y agoWhy don't you just build on top of Atom? Like Julia did with Juno.
- gnulinux 9y agoAlso, sorry but I'll (probably) never use anything other than emacs. I already invested ~10 years of customization. Most people did the same for other editors, IDEs etc. Its way too ambitious to make your own editor for a programming language. No project uses just one language. I'm not going to use emacs for 3 other languages and your app for one other. If your language is way too good, I'll try port an emacs mode and ignore your editor. Half your business model is already ignored by me.
- cbluth 9y agoThe whole thing reeks of a hoax
- pbiggar 9y agoEmacs is great - I used Paredit for years, and really learned to love the REPL in emacs. Actually, I still use Magit every day! 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.
- oliwarner 9y agoWebscale.
- moltar 9y agoCoffeeScript comes to mind ;)