I’ve felt that Go would fit really well in the serverless (Google Cloud, AWS, Azure) space and it wouldn’t surprise me if it would eventually beat out Java, JavaScript, C# and Python - provided it generated the most performant assets (which may not be the case right now).
While the Go core audience doesn’t seem to be interested somebody could develop a project similar to Fulmar - the incentive should be greater, given that C++ already supports meta-programming while Go doesn’t.
Serverless is mostly about cloud functions though, which is yet another fancy name for a stateless microservice.
Go definitely has the best performance characteristics for this environment due to its fast startup time and very good throughput. Java can achieve higher throughput but takes a long time to boot, and won’t reach peak throughput until the hot path has been JIT’d. I think the only thing holding Go back are lack of specialized libraries for things like ML for example, but for a lot of use cases it might be the best choice today.
For me microservices doesn’t actually express whether an instance of a “service” is short or long-lived. A stateless microservice certainly has the opportunity to be short lived but outside of serverless one is still responsible for managing the supporting infrastructure if the service needs to be available 24/7.
From a customer perspective one value proposition of serverless is that most if not all executions are ephemeral/short lived, it’s only the data that is long lived.
The cynical point of view would be to observe that in a sense we are back to a modern infrastructure that supports running a bunch of transaction scripts (powerful ones grant you) on top of your data. What has improved is the manner in which these scripts can be composed.
This is kind of a strange thing to say. Coding with numpy or pandas is definitely a Python programming experience. Yes, the libraries use C which is the only thing that makes them usable, but this doesn’t have any consequences for the user.
Maybe you object to the statement that Python is good for numerics when numerics libraries cannot be written (only) in Python? Mostly people care about writing applications though.
It does feel like transaction scripts. Every time I hear somebody talk about serverless I can’t help but hear “PHP” where I only pay for execution time. It’s exactly the same model, except without portability across hosting options.
Personally, I think of Go as “Java for the 21st Century”
That’s exactly it, yes. I rarely if ever engage in any language wars during the last 5+ years but one of the statements that makes me cringe real hard is “Python is very fast because of <insert_Python_wrapper_around_C_library_here>”.
Consider some recent benchmark that showed Python beating Elixir for web serving, but the performance-sensitive bits of the Python solution were all native C code. (And it was a very shallow test that wouldn’t surface problems with concurrency.)
If you want a language that acts as high-level glue to orchestrate calls to native libraries which do all the work, well somehow I think Elixir/Erlang could do just fine at that 
Absolutely. That’s what me and many others in this forum keep saying. Elixir can coordinate wonderfully well the parts that are aiming to squeeze every last cent per watt out of a CPU. But do claim that Python is the really fast part and I will come out barking. 
Eh, people do that all the time. And then the maintainers of the GitHub repo refuse to accept PRs because they don’t know the language they claim to have surpassed.
I find comfort in the thought that the smart and independently thinking people will see through such biased “benchmarks”.
So when I talk about language performance, I focus on developer performance. Hardware is cheap, developers are expensive (and good ones hard to get), and frankly all the system’s I have worked on for the last decade were more I/O bound than CPU bound (I stress the word “I” because this is where I work and my experience, YMMV).
I get it that Google wants to squeeze every last drop out of their CPUs, but even the largest site I’ve worked on (1.5b pages per month) consisted of code mostly waiting for the database or the search engine and we only ever had one subsystem that was performance-critical (15k transactions per second with little room for parallelism).
To me, run-time performance is table stakes - granted, an interpreter is often too slow, but every decent VM I’ve looked at is sufficient, including BEAM. Make developers faster, not your code. That’s why I want metaprogramming facilities and bells’n’whistles like that- they let you focus on developer productivity, not on coding for the machine. Code is for humans. Running it in production is mostly a side-effect 
More or less that’s the first thing I did with Elixir. And then another team extended it. And it’s still in production (both versions actually)…
I don’t actually know what “cloud infrastructure software” is. That’s even less well defined than CLI.
Why is that? Go seems pretty far from Java in its purpose.
A language designed for writing fast utility programs and very small services isn’t even playing the same game as Java.
It doesn’t seem to really draw a comparison to Elixir either. But I guess that’s why this thread exists. I don’t know Go very well. Why do you say it’s competing with Java? Or. as you say, a Java for the 21st Century?
Example all Kubernetes ecosystem like
I would say many https://www.cncf.io/ projects are written in GO. In my opinion cloud be also written in Rust 
Given that these programs mostly do distributed coordination and orchestration and require pretty much 100% availability, OTP seems to be the sweet spot here. That train has left the station, but it’s telling that Mesos sort of created an OTP-in-C++ library to get their stuff done
All true, with a minor nitpick – there are languages and runtimes in which you get less productive as a developer as well, so it’s not all “more and stronger hardware vs. hiring better programmers”. I agree that throwing hardware at computing limits is much more justified than trying to hire 3x John Carmack guys in the same team, that is unequivocally true!
Additionally, there are some VMs, like Ruby’s MRI, that scale very poorly and need cluster and orchestration much earlier than a comparable Elixir or Java setup. That can reduce developer time by having to optimize earlier in the cycle – or if ignored, it will waste a lot of your Ops team’s time.
Same with me. There were like 3 problems in total in my career that required hardcore cent per watt performance… for 16.5 years of career so far (granted I almost did not work in low-level optimization jobs). And I solved the last one with Elixir. Mostly because the previous implementation was in Ruby and the Elixir code proved 20x-25x quicker which was enough for the customers (even though I told them I can improve it even more with Go or stored procedures… they were just happy that a single report is now generating for 7 minutes and not almost 3 hours). The other 2 were solved with C++ and Go.
I don’t really think MRI would qualify as a VM. But the differences are fuzzy, at best. In any case, I never understood why Ruby – with so many things taken from Smalltalk – just didn’t go all in right away and ran on a Smalltalk VM. Even the slow-ish Squeak VM was fast enough for most things before just-in-type native code generation got added. Launching a language in the 21st century as an interpreter should just be banned (certainly now that llvm is there and super easy to use; see e.g. Julia), and it was the reason for me when Ruby got all popular to conclude I already knew a crappy interpreted scripting language or two and that was enough
I wouldn’t call LLVM easy to use They have breaking changes all the time and AFAIK it’s a major pain-point for Rust, Crystal, etc.
You are preoccupied with your own, personal developer velocity in a Peter Norvig - Lisp as an Alternative to Java kind of way. “The industry” is more interested in increasing developer velocity of almost every “working developer” out there.
I wouldn’t be too surprised if the way Java generics were adopted had something to do with the exclusion of generics from Go. While everybody may have been using generics based classes, especially those from the standard libraries, not everyone (possibly the majority) was comfortable (or competent) crafting generics based classes.
Whatever you may think of Rise of Functions as a Service: How PHP Set the “Serverless” Stage 20 Years Ago - it may very well portrait the industry perception of “developer velocity” (possibly related to “time to initial success”) that is embodied by the PHP philosophy.
Today PHP dominates the server-side programming language landscape (83.6%) even after eliminating CMSs.
To some degree Go as a langauge and FaaS as a platform embody the PHP notion of “developer velocity” so it’s not too much of a stretch to imagine that they could be commercially successful in the long run (irrespective of whether or not developers on a personal level like it).
The biggest hurdle for FaaS is the fragmentation across Google Cloud/Microsoft Azure/AWS - meanwhile Go seems to work anywhere it needs to.
I’d call it Google’s Java because
© Copyright Elixir Forum | Terms | Privacy & Cookies
