I remember a chat I had with Jim Waldo a long, long time ago (to my best knowledge, Jim is the father of checked exceptions in Java). I’ll skip over the whole chat, but basically what it came down to was that Java was a language for, let’s call it “the unwashed masses” and that a lot of safety features were required to keep them from shooting themselves in the foot. I retorted that if that’s your staff, you’ve lost already regardless of the language ;-).
In any case, when I say “developer productivity”, I mean overall developer productivity. No matter how smart I think I am, I cannot “win” from 100 colleagues in typing faster or better code. I can help 100 colleagues by removing obstacles, help increase code readability, use libraries that comes with DSLs like Phoenix, etcetera. An extensible language provides that leverage, and I’ve seen that all the way back to when I was in my 2nd or 3rd job and we maintained a suite of ODBC drivers where all OSes supported (which were pretty much “all”) could run as client or server - the possibile leverage here was marginal but present in the C preprocessor, and a lot of the heavy lifting got done by the then smartest cookie on the block; we just used it and it made all the difference in having a single codebase compile across all Unixes, VMS, MacOS, Win32, etcetera. Not everybody needs to be able to use the bells’n’whistles, but if a couple do and can, in a smart way, that makes a huge difference. Coding is a social activity, and therefore there is potential for leverage. That’s why I want a “smart” language that helps humans instead of machines.
Google is the worst example on the planet for most of us. They share traits with maybe three or four other companies, and it seems like the usual equations around software development are reverted - they’re run-time scale is so massive that it’s worth throwing lots of bodies at problems and make sure that they cannot shoot themselves in the foot while keeping CPU usage maxed out; whether they’re productive or not is secondary and therefore, a “dumb but fast” language like Go makes sense for them. Not for my employer, past or present – we have a limited number of minds and they need to work as smartly as possible. My hunch is that it’s mostly been the Google fandom that saw such a rapid adoption - fashion over technology, as is the norm in our industry.
To me, stuff coming out of Google is only interesting anecdotically and maybe for the wow factor; it’s like me grabbing a rod to catch some brook trout in a local stream and watching “Deadliest Catch” in the evening. Both activities are called “fishing”, but whatever I pick up while watching that show on Discovery is not gonna make me better at catching trout for dinner. Same label, entirely different activities.
“Need a very small and focused microservice? Need a CLI tool? Need a network daemon? Go is good.”
^^ that’s the bottom line.
I’ve built the backbone of my service on Elixir/BEAM, but I also defer some processing to Go where it makes sense (currently HTTP tracing). If I were to build a CLI tool for my service, then I’d reach immediately for Go.
I’ve been coding in Elixir for about 6 months and Go for about 3 weeks…
Go is just painful most of the time, and if you don’t adhere to the wonky standards then you further obstruct development. An example is how you need to have your source in $GOPATH to take advantage of the tooling. Most libraries assume this, too. So I have:
myservice/
apps/
web/
worker/
but to get my Go app to play nice with my structure I need to symlink the directories. I don’t know, I just consider it very bad practice to make such assumptions about project structure for every single developer who uses the language.
Add to that the dire workarounds to structure complex apps using packages (effectively need to dump all files for a package in the same directory) and the crappy package management in general… I’d rather do what I need to do and get the hell out. I wouldn’t dream of developing a complex application using it, though I am using Echo (potentially Beego eventually) to build a simple API server for internal use.
It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical.
when I say “developer productivity”
I’m not disagreeing with your reasoning - I’m just pointing out that often technologies that are judged as inferior will still be successful, possibly even dominant.
Not everybody needs to be able to use the bells’n’whistles, but if a couple do and can, in a smart way, that makes a huge difference.
Not for my employer, past or present – we have a limited number of minds and they need to work as smartly as possible.
I imagine that PagerDuty is very much aware that “software is their business”. However while “software is eating the world” many businesses and organizations are still treating software/IT as a necessary evil, a cost centre (rather than a profit centre), so if anybody from the “the unwashed masses” could just “handle it” - so much the better.
My hunch is that it’s mostly been the Google fandom that saw such a rapid adoption
All I’m saying is that none of us should be blindsided if Go becomes successful on a larger scale. PHP has been derided endlessly and yet … and with FaaS where time is money it seems strange to use dynamic languages like JavaScript or Python, while OO languages like Java and C# seem like an ill fit. Something compiled and procedural (possibly functional) seems like a better fit - and Go fits the “compiled and procedural” description.
That’s all true. At larger companies with lots of developers of varying skill levels, lowest common denominator solutions tend to win the day. Go fIts there well and I’ve even seen it in person where a large company wanted to transition to Go specifically because it forced devs to work in a very specific box. There were a lot of concerns about the overall skill level at that company that I got to hear about.
Elixir, much like Ruby, is an exceptional solution for letting a small team be very effective. I think there is a tendency among developers to assume that if you can do that, you aren’t as effective for larger teams.
I find it very sad how true this has been throughout all my career (which is gonna hit 17 years in Q4 2018). For some reason, the more efficient you become as a singular programmer, or a very good team player but only in a very small (3-5) high-end programmers, somehow the poorer fit you are for companies like SAP and countless other “enterprise services” derivatives.
There is something about their bureaucracy and adamant approach to unified processes that absolutely positively alienates creative and capable people.
Most complaints I hear about FaaS providers is around cold start times of their stateful functions. There are cold start times related to their runtime container too, but those seem to be much less rage inducing.
Seems that in today’s FaaS world the functions are rarely pure. They typically need to load some lookup data, or make connections to other systems. And it’s this multi-second cold-start overhead that kills their service latency metrics, even if the runtime start time was zero.
You’d have this same problem regardless of the startup time of these micro-apps written in Go (or any other language). Except if FaaS were instead executing micro-apps with zero cost startup, it would be difficult to pass them DB connections, http connections, or large amounts of bootstrap data. Which you can do if you’re executing functions within a language container. Your micro-app would be forced to spend this time on every invocation.
Well you could have a parent process holding connections open to pass into worker containers like that. systemd works similar to that as an init system for linux actually (hence why it is SO much faster than the old sysV style).
You could, but you don’t. FaaS providers will execute your F with whatever data blob triggered them. In the case of F’s being go executables, you’re still having the FaaS runtime calling your executable given some static template.
mygoapp --data {some json} typically
Even if mygoapp was then grabbing connections and forking off workers transparent to the FaaS provider, that provider would still bill you based on however long mygoapp took to return and would execute mygoapp on every invocation of the trigger event.
Or at least that’s how I’m visualizing the OP. My takeaway was that if you could ship executables with zero startup times to FaaS providers, then you wouldn’t need FaaS containers, just a trigger processor and an OS container.
Now I suppose that your mygoapp could spin up a whole ecosystem of small go apps and do some sort of message dispatching to the process that is maintaining longer lived asking it to access the long lived resources while delegating the stateless part of sub-programs.
Although, you’d need a way to ship those sub-programs, or develop your all-in-one mygoapp with a lot of disparate functionality. Essentially shipping your own FaaS runtime as a function. Which seems pretty complicated and still doesn’t get around the problem that it takes your long-running resource holder time to acquire those resources and that the FaaS system will likely tear down the container your FaaS implementation is running in more often than you’d like. That’s the real problem ppl seem to have with FaaS providers, the lack of lifecycle controls around the management of the underlying container.
It wasn’t designed for writing very small services. It’s designer thinks that it should be the alpha & omega of languages and that it is perfect for large-scale development
Go is like Java in that it was designed with the idea that its users would never be as intelligent as the designer and so they needed to be constrained in the ways that suited the designer’s taste. Then promoted by a huge corporation as the one language to rule them all. The creation of Go very much parallels the creation of Java (only more extreme in some ways), the differences come simply from the fact that it was designed in 21st century rather than the 1980s and so started with a somewhat evolved set of assumptions about what a type system should look like.
I feel like I’m getting close to the line of some of our community standards here, but I believe that it is true that Go is a language designed to force all other programmers at Google to program the way Rob Pike wants them to: the verbose at-the-source error handling, the disdain for generics, the bizarre package management decision that sacrifices reproducible builds in favor of always using the latest… Those are decisions that stem from experience with and focus on what we would call “programming in the small”, yet in no way do the creator, maintainers, or community believe that Go is limited in terms of “programming in the large”.
As for those of you arguing further down that Go will become “successful on a larger scale”, well, you are 100% correct. It will, less because of the particular set of features it offers, and more because of massive promotion.
Nice to see that articulated. I’m only 8 years in and couldn’t quite put my finger on it. I went from freelancing to full-time 3 years and decided to quit and return to contracting due to rampant pigeon-holing. Most companies simply don’t know how to take advantage full-stack developers.
But…if people still want to use this FaaS language proxy solution. You can apparently run any application in a FaaS environment. This thread gives some good details on how you can get Elixir running with AWS Lambda. I assume the same strategy would work well for Go, Rust, etc.
Not really seeing the value proposition of the running the BEAM on a FaaS platform unless possibly the FaaS infrastructure is a BEAM -like (e.g. processes hibernate at a much lower cost). So beyond that it would be simply about Elixir “the language” - but frankly I would prefer to see static typing.
So when it comes to a large scale function-based codebase I think something in the class of OCaml would likely be a better fit for managing it. I suspect it could be much more intelligently managed than Go code.
I think you could have 1st class OTP like support for Elixir within Lambda. That said, it isn’t there today. This was just an example of how people can use languages that aren’t necessarily AWS native, within Lambda.
If Elixir is what you know and you simply don’t want to manage servers, some of the methods described in the thread make sense. You can run anything. And as long as you have enough traffic to keep your container running, you’ll have all the benefits of Elixir. It would be as if you had a regular Elixir service running normally, but if you stopped getting requests for a while, the whole machine goes away.
You just need a request bridge from a supported Lambda lang into your service. You then get containerized deployments for free. Kind of cool now that I think about it.
