Klemsy - Fotolia
Ecstasy programming language targets cloud-native computing
Startup Xqiz.it has a new Ecstasy programming language that aims to arm developers for the cloud-native computing era with features that Java and other programming languages lack.
While recent events have focused on Java and how it will fare as computing continues to evolve to support modern platforms and technologies, a new language is targeted directly at the cloud-native computing space -- something Java continues to adjust to.
This new language, known as the Ecstasy programming language, aims to address programming complexity and to enhance security and manageability in software, which are key challenges for cloud app developers.
Oracle just completed its Oracle Open World and Oracle Code One conferences, where Java was dominant. Indeed, Oracle Code One was formerly known as JavaOne until last year, when Oracle changed its name to be more inclusive of other languages.
Ironically, Cameron Purdy, a former senior vice president of development at Oracle and now CEO of Xqiz.it (pronounced "exquisite"), based in Lexington, Mass., is the co-creator of the Ecstasy language. Purdy joined Oracle in 2007, when the database giant acquired his previous startup, Tangosol, to attain its Coherence in-memory data grid technology, which remains a part of Oracle's product line today.
Designed for containerization and the cloud-native computing era
Purdy designed Ecstasy for what he calls true containerization. It will run on a server, in a VM or in an OS container, but that is not the kind of container that Ecstasy containerization refers to. Ecstasy containers are a feature of the language itself, and they are secure, recursive, dynamic and manageable runtime containers, he said.
For security, all Ecstasy code runs inside an Ecstasy container, and Ecstasy code cannot even see the container it's running inside of -- let alone anything outside that container, like the OS, or even another container. Regarding recursivity, Ecstasy code can create nested containers inside the current container, and the code running inside those containers can create their own containers, and so on. For dynamism, containers can be created and destroyed dynamically, but they also can grow and shrink within a common, shared pool of CPU and memory resources. For manageability, any resources -- including CPU, memory, storage and any I/O -- consumed by an Ecstasy container can be measured and managed in real time. And all the resources within a container -- including network and storage -- can be virtualized, with the possibility of each container being virtualized in a completely different manner.
Overall, the goal of Ecstasy is to solve a set of problems that are intrinsic to the cloud:
- the ability to modularize application code, so that some portions could be run all the way out on the client, or all the way back in the heart of a server cluster, or anywhere in-between -- including on shared edge and CDN servers;
- to make code that is portable and reusable across all those locations and devices;
- to be able to securely reuse code by supporting the secure containerization of arbitrary modules of code;
- to enable developers to manage and virtualize the resources used by this code to enhance security, manageability, real-time monitoring and cloud portability; and
- to provide an architecture that would scale with the cloud but could also scale with the many core devices and specialized processing units that lie at the heart of new innovation -- like machine learning.
General-purpose programming language
Ecstasy, like C, C++, Java, C# and Python, is a general-purpose programming language -- but its most compelling feature is not what it contains, but rather what it purposefully omits, Purdy said.
For instance, all the aforementioned general-purpose languages adopted the underlying hardware architecture and OS capabilities as a foundation upon which they built their own capabilities, but additionally, these languages all exposed the complexity of the underlying hardware and OS details to the developer. This not only added to complexity, but also provided a source of vulnerability and deployment inflexibility.
As a general-purpose programming language, Ecstasy will be useful for most application developers, Purdy said. However, Xqiz.it is still in "stealth" mode as a company and in the R&D phase with the language. Its design targets all the major client device hardware and OSes, all the major cloud vendors, and all of the server back ends.
Mark FalcoSenior principal software development engineer, Workday
Ecstasy is heavily influenced by Java, so Java programmers should be able to read lots of Ecstasy code without getting confused, said Mark Falco, a senior principal software development engineer at Workday who has had early access to the software.
"To be clear, Ecstasy is not a superset of Java, but [it] definitely [has] a large syntactic intersection," Falco said. "Ecstasy adds lots and lots onto Java to improve both developer productivity, as well as program correctness." The language's similarity to Java also should help with developer adoption, he noted.
However, Patrick Linskey, a principal engineer at Cisco and another early Ecstasy user, said, "From what I've seen, there's a lot of Erlang/OTP in there under the covers, but with a much more accessible syntax." Erlang/OTP is a development environment for concurrent programming.
Falco added, "Concurrent programming in Ecstasy doesn't require any notion of synchronization, locking or atomics; you always work on your local copy of a piece of data, and this makes it much harder to screw things up."
Compactness, security and isolation
Moreover, a few key reasons for creating a new programming language for serverless, cloud and connected devices apps are their compactness, security and isolation, he added.
"Ecstasy starts off with complete isolation at its core; an Ecstasy app literally has no conduit to the outside world, not to the network, not to the disk, not to anything at all," Falco said. "To gain access to any aspect of the outside world, an Ecstasy app must be injected with services that provide access to only a specific resource."
"The Ecstasy runtime really pushes developers toward safe patterns, without being painful," Linskey said. "If you tried to bolt an existing language onto such a runtime, you'd end up with lots of tough static analysis checks, runtime assertions" and other performance penalties.
Indeed, one of the more powerful components of Ecstasy is the hard separation of application logic and deployment, noted Rob Lee, another early Ecstasy user who is vice president and chief architect at Pure Storage in Mountain View, Calif. "This allows developers to focus on building the logic of their application -- what it should do and how it should do it, rather than managing the combinatorics of details and consequences of where it is running," he noted.
What about adoption?
However, adoption will be the "billion-dollar" issue for the Ecstasy programming language, Lee said, noting that he likes the language's chances based on what he's seen. Yet, building adoption for a new runtime and language requires a lot of careful and intentional community-building.
Cisco is an easy potential candidate for Ecstasy usage, Linskey said. "We build a lot of middlebox-style services in which we pull together data from a few databases and a few internal and external services and serve that up to our clients," he said. "An asynchronous-first runtime with the isolation and security properties of Ecstasy would be a great fit for us."
Meanwhile, Java aficionados expect that Java will continue to evolve to meet cloud-native computing needs and future challenges. At Oracle Code One, Stewart Bryson, CEO of Red Pill Analytics in Atlanta, said he believes Java has another 10 to 20 years of viability, but there is room for another language that will better enable developers for the cloud. However, that language could be one that runs on the Java Virtual Machine, such as Kotlin, Scala, Clojure and others, he said.