77 ms·
> "I would hope that someone who decides to create a language would spend some time studying a lot of languages, especially those that came out in the past ten
by cpurdy 7y ago
> "I would hope that someone who decides to create a language would spend some time studying a lot of languages, especially those that came out in the past ten years."
Yes, I would hope the same thing.
Before designing Ecstasy, we spent a period of time evaluating existing languages (and language runtimes) for the specific use case that we had in mind (related to serverless cloud infrastructure and applications, but with some very specific goals).
That included Javascript and the V8 engine (a horrid language, but an _amazing_ runtime that came as close as any to fitting our goals), Google's Go (Gene is now a big fan, but it was a poor fit for our goals), Rust (briefly -- it wasn't a good match), and a small dive into Swift. Previously, I had read a fair bit about Smalltalk, but never got to use it for any work; Erlang is similar in that I've read about it, but never had an opportunity to use it in the wild. I'm impressed by ideas in both of these, but I find the languages themselves to be quite unappealing (to put it nicely).
So why didn't we look at Kotlin? Well, probably because I had the wrong idea of what it was, and once you get a wrong idea in your head, the wrong idea is hard to displace. Patrick Linskey was the developer who, after looking at the Ecstasy design at the time, suggested that we look at Kotlin. (He and his team use Kotlin a fair bit in their work.)
I had read some stuff years back that Gavin wrote about Kotlin, but had not thought to look at the language itself. I was under the impression that it was dormant. (I've since gotten in touch with Gavin ... I think it's pretty cool that we had similar concepts as he did.)
In retrospect, the language that I wish that I would have spent time looking at is Elixir (not necessarily to use it, but because some of the same things that it is attempting to address are relevant).
The challenge is that there are many creative people building many creative things, and we only have so many hours in the day to read and learn and use these things! I read a few hundred pages of technical topics every day, and I still can't keep up with even 1% of what is happening in our industry.
Also, over the years that I was designing the concepts that eventually formed Ecstasy, I spent a great deal of time talking with friends in the PL and language-runtime arena like Guy Steele, Rich Hickey, Doug Lea, James Strachan, various members of the Sun/Oracle Java team, Gil Tene (Azul pauseless GC), and so on. Many of the topics that I was investigating were ones suggested by these folks.
But in general, like many people who enjoy this kind of thing, I know what I like when I see it, and I collect ideas and thoughts over time. If you're a fan of poetry, I'd suggest Rilke's "For the Sake of a Single Poem", to understand how the first word of Ecstasy came to exist.
- core-questions 7y agoFascinating language. You mention serverless and the cloud a lot, but there are many of us who still have a need to write hybrid applications that run close to physical things down here on the ground. Will XTC be extensible to this use-case, with some backend deployed on top of conventional on-prem architecture?
- cpurdy 7y ago> "You mention serverless and the cloud a lot" Yes. The fairly rigorous requirements from "serverless cloud" are what originally drove us to design a new runtime model, and that new runtime model then drove us to design a new language. The language itself, though, is general purpose, and -- as an interesting result of the original use case -- extremely embeddable, i.e. relying entirely on resource injection for its connection to the "real" world. That embeddability has an interesting devolved use case: When an Ecstasy app is executed as a normal OS process, with the full set of unrestricted OS services available to the app via injection. This use case is equivalent to how a language like Java or C# works today. In other words, there are new use cases supported that weren't possible before, but additionally, the traditional use cases will continue to be well supported. > "... a need to write hybrid applications that run close to physical things down here on the ground. Will XTC be extensible to this use-case, with some backend deployed on top of conventional on-prem architecture?" Like other general purpose languages, there is no requirement for a "back end" whatsoever. On the other hand, to manage complex environments, a managed back end service is extremely useful, and we are (as the article alluded to) building one of those -- using Ecstasy, and specifically to manage Ecstasy deployments -- as part of our business (xqiz.it), and it will be available in different forms (e.g. as a hosted PaaS, and with both OSS and commercial options for non-hosted/self-hosting options). As with other languages, there are likely to be plenty of options in this area. That's all still a couple of _years_ out, though. Peace, Cameron.
- hota_mazi 7y ago> Yes. The fairly rigorous requirements from "serverless cloud" are what originally drove us to design a new runtime model, and that new runtime model then drove us to design a new language. I'm really curious to hear what you saw was missing in Kotlin for serverless cloud that made you go "We need a new language". I'm trying to be objective here but after having read all the blog entries and the documentation of the language, not only do I see hardly anything that XTC brings that doesn't already exist in Kotlin and Ceylon, and even less so what makes XTC more appropriate for serverless cloud computing than these languages. Besides, I also think a language priding itself on being designed for serverless computing is going to miss out on a huge chunk of cloud computing: the "serverful" part, which is essential and complementary.