Thank you for your work! Is this an indicator that Google is interested in or using Elixir internally or is it just a response to growing requests from the community?

The latter. But you should realize Google is pretty conservative internally in the main repository because of the amount of code/tooling/etc. While we let people experiment in the main repository, they are controlled experiments. Even if we decided, tomorrow, to move the main repositories away from our current set of programming languages, that would be a fairly long term path, not a short one.

Outside of the main repository, or on google open source projects, or etc, people can generally do what they want, they just don't get the benefits of the above if they aren't using a language we already support very well.

So which languages are use internally in the main repository then?

What category are you looking for?

Supported or used or being experimented with or what?

Java, C++, Python, Golang, and Swift/ObfC for iOS apps

No JavaScript? Or is that because it's not used internally but in the public internet?

Google's "big" client apps (Inbox / Gmail / Calendar) are a mix of Java converted to JS (GWT) and native JS with the Closure library/compiler. I think, anyway.

Not sure if GWT is still that relevant nowadays. AngularJS was developed by Google many years ago. It was already pure JS.

Inbox by Gmail launched in 2014, long after Angular JS was first released, and uses GWT.

Close. Apps is using mostly using j2cl.

As addition to JavaScript, they have used their own language called Dart for some their services like AdWords or AdSense [1].

[1]: https://www.dartlang.org/community/who-uses-dart

JavaScript and Typescript should be in the list, as should Dart.

You should let Ericsson know the language that powers their telecom systems is an experiment.

Pretty clear that DannyBee was referring to their particular Elixir deployment environment, rather than to Elixir as a language, no?

It's FUD aimed at a particular language, though. If you know anyone inside Google you probably know how regularly people "experiment" without pushback; all of the internal Dart projects, for example.

Being the person in charge of the new language process, I'm just going to tell you your information is not correct.

Can you explain to me then how Elixir is more experimental than Go was when it was deployed in its early days?

Err, I thought I was quite clear that the experiment is people using the new-to-google language, not the language itself

I think it's pretty well known that the approved internal Google languages are Java, C++, Go, Python. Could someone correct me if I'm wrong?

I have a hard time finding information about the limits of App Engine. Eg Heroku has all kinds of stuff going on like connection limits and daily restarts and whatnot. How is that with App Engine for Elixir? Is this documented anywhere?

Also, why use App Engine over Compute Engine for Elixir? I understand "if you want more control" but can you elaborate about what kind of "more control" someone would want that App Engine doesn't offer?

A question: what are the pluses/minuses of deploying to App Engine vs Compute Engine. Specifically, what are the tradeoffs of Elixir on App Engine? Thanks in advance.

That's a good question. It comes down to how much you want to control the devops vs how much you want someone else to handle it for you.

App Engine is a platform-as-a-service (PaaS) which generally means a lot of things are done for you. You give App Engine the code, and App Engine builds it, deploys it, scales it, monitors it, applies OS patches, and generally provides a bunch of related services for you.

Compute Engine is more infrastructure-as-a-service (IaaS) which means the service gives you VMs, and you handle installation, build, deployment, and setting up load balancing, scaling, monitoring, etc. the way you want.

There are also hybrid products that fall somewhere in the middle. Kubernetes Engine is an example. Indeed, you can locate most hosting platforms somewhere on this spectrum.

Note also that there are trade-offs specific to Elixir as well. PaaSes generally have to be opinionated about application architecture. Most PaaSes assume a stateless web application well suited for container-based deployment, which runs somewhat counter to Erlang's stateful services and hot code swapping. If you're writing a typical web app (say, using Phoenix) then a PaaS like App Engine will often work very well. But if you are doing something different and managing persistent nodes and processes, you may need to control deployment yourself, which makes a lower level service like Compute Engine more useful.

Gigalixir runs on GCP and seems to fill all of the Elixir specific gaps for a PaaS offering. Just knowing that there are first class API clients for the rest of GCP’s offerings makes Google a pretty clear choice for Elixir devs at this point.

Thanks for the rich reply. So you mention PaaS may not be suited for persistent processes. Do you think it could work well with Phoenix’s channels (web sockets)? As I understand, they create a process per user web socket connection. Phoenix also allows multiple nodes to discover and share these channels’ state AFAIK — are there any tools that make this discovery easier from Google’s side for Elixir to automatically connect the nodes, say when instances are brought up or down? I think it would be good to have this as part of the documentation if there is, as it would be a key selling point if it’s relatively easy.

Phoenix uses Postgres by default and Postgres has been the go-to-database for many. When will Postgres on CloudSQL be available to all?

It already is! It's available in open beta for all customers, with a GA release coming in the near future.

Disclaimer: I work for Google Cloud

One question (but first congrats on releasing this!) - is there a way to achieve hot-reloading currently?

This would help handle an important use case for me: ability to keep thousands of (client) websocket connections alive across deployments, to avoid missing a data update.

Thanks!

Agreed, also just want to say thanks, this is awesome news. Much appreciated!

Just want to say thank you and this is great news!

On a related note, there goes my weekend.