5 ms·

I absolutely agree. Bored by Java and After getting burned due to performance limitations by Python applications at scale I switched to Go and never looked bac

I absolutely agree. Bored by Java and After getting burned due to performance limitations by Python applications at scale I switched to Go and never looked back. I still use Python for ML, DS and I don't think it'll change anytime soon due to the tools/library ecosystem. > Tiny output binaries are also very quick to transfer and spin up in serverless as well - often reducing costs further. What's your serverless stack for Go? Cloudflare claims Go is not the right language for their workers due to sandboxing constraints[1]. > Go fundamentally is not designed to support secure sandboxing of tenants without running each tenant in their own process... [1] https://community.cloudflare.com/t/native-golang-support-for-workers/65896/8 https://community.cloudflare.com/t/native-golang-support-for...

marcus_cemes 5y ago
WebAssembly is fundamently a very well isolated piece of executable code, and Cloudflare focussed on JS by creating their own stripped-down version of the V8 runtime, so you don't have to ship one. They focussed on some efficient solutions, rather than a versetile "just give us a docker image" approach. Other cloud providers just let you push code, charge you extortionate amounts of money to build the several hundred MB docker image that includes Node.js and node_modules, the data bandwidth of transfering those images between datacentres, storing the build cache in a multi-regional bucket (why???), then they charge you to store the image in their registry and then finaly give you a 10+ cold start time.
- Abishek_Muthian 5y ago
  As far as serverless Go is concerned my experience has been only with Heroku as I prefer hosting on my own instances and Heroku seems to be reasonable for my use case. I hear fly.io is better in terms of performance and they do offer distributed PostgreSQL. I guess those who are already into AWS would probably be choosing Lambda for serverless Go. If the experience is same as Node JS or Python on Lambda, Then I don't think there would be much to complain other than the cost; But of course cannot match the speed or cost of a CF worker for the reasons you've pointed.
  - marcus_cemes 5y ago
    Fly.io is amazing, I'm very excitied for it! They spin up a long-lived instance on the edge closest to the user and create a Wireguard tunnel in-between. They also have a free tier and reasonable pricing. Heroku is just far too expensive for a hobby project.
    - throwaway894345 5y ago
      Usually the database (not the compute) is where things get expensive (Heroku's 10K rows is not practical for most tasks unless you're willing to do unholy things to put more data into a row).
  - potta_coffee 5y ago
    I've written many lambdas in Python but have switched entirely to Go for all my new lambda work. Go is just better in every way - uses a fraction of the memory and executions take a tiny amount of the time Python takes.
    - tgtweak 5y ago
      I have a feeling AWS lambda's hypervisor has a lot of overhead, and simply making your workload smaller/lighter has a very noticeable reduction in execution time (cold start is <10ms on most of our GO lambdas). re: full serverless: I mean, try for yourselves but unless you're running an echo statement, you'll probably be hard pressed to get lower than this. Some early experiments with Rust showed 5x that, and that is as close to GO as I would dare to compare.
      - hrez 5y ago
        A while back I saw perf. tests on lambda cold starts per language. And somewhat surprisingly python was the fastest. It's probably not the same test but python is still at the top [1] [1] https://www.simform.com/blog/aws-lambda-performance/#StartupsTimesPerLanguage https://www.simform.com/blog/aws-lambda-performance/#Startup...
- tgtweak 5y ago
  The Cloudflare worker JS is a mess of incompatibility and design idiosyncrasies that make it really impractical for true edge application design. What I mean by cloud native & serverless is specifically containerized platforms where you ship your container and they run it - where a golang container can be 30MB with everything included vs a full-fat nodejs container in the 100-500MB range. Scala is also huge when bundled and shipped as a fat jar. Hell even windows binaries if you really wanted to push something to the end client, are trivial in golang and invoke none of the .net client library, c++ redistributable or "shipping java with your app" headaches of other solutions. Only Delphi and C linked against winapi can offer this same level of portability on Windows. AWS's lambda golang is first-class as well as GCP's golang "Cloud Functions". Again, can't speak highly enough of using golang on cloud.
  - throwaway894345 5y ago
    My only grievance with Go in the cloud is that it's tedious to have to set up a CI job or similar to build your binaries to deploy in your functions. I really wish I could just ship the source code and have it compile for me (or failing that, if CloudFormation or AWS SAM or Terraform or whatever could transparently manage the compilation).
    - tgtweak 5y ago
      For us it's as simple as docker build right from the repo -> push to registry for test deployment then tag with prod for rollout from there. Probably not ideal for 20+ dev teams or high complexity deployments but this is the simplest CI and its much quicker build than node, so dev's can do it locally in all cases.
      - throwaway894345 5y ago
        Yeah, this is fine for early stage startups, but eventually you don't want developers to deploy directly to production.
        5y ago
- huki_2231 5y ago
  I have very different experiences: At my workplace we're using Go with Lambda and Fargate for several mid-size and one large application. The costs (image storage, transfer ...) you're referring to are actually almost neglectable. Aurora is by far the largest in our stack. On the other hand: Creating WASM is a big pain. I understand that Cloudflare and others promote it for their own business reasons, but from a developer/customer point of view docker or lambda are much more robust and simple.
throwaway894345 5y ago
> After getting burned due to performance limitations by Python applications at scale I switched to Go and never looked back Same here. Not just performance, but also tooling. We used to use pipenv for reproducible dependency management, but literally any change to the lockfile would take 30+ minutes to rebuild--this isn't including the time it takes to pull the dependencies in the first place, which was only a few minutes anyway. This meant that our CI jobs would take ~45 minutes and we would spend a ton of time trying different caching tricks and adding various complexity to our CI process to bring these times down, but they were still unsavory. With Go, we don't even need caching and everything builds and tests run in just a few minutes (end to end). Not only that, but Go's static typing was a boon. Years ago we would try keeping our types up-to-date with Sphinx (and code review checks), but inevitably they would fall out of date and the only thing worse than no type documentation is incorrect type documentation. Further, this didn't stop people from writing stupid code nearly as well as a type checker does (think "code whose return type varies based on the value of some input parameter" and various other such things). We eventually tried mypy but it was immature (couldn't express recursive types), cumbersome (e.g., expressing a callback that takes kwargs was tedious), confusing (I don't think I ever figured out how to publish a pypi package with type annotations that would be picked up automatically by mypy), slow, etc. I'm sure these things will improve with time, and there are also various other Python type checkers (although with everything in Python, each tool seems to have its own hidden pitfalls). On the plus side, Python's Unions are better than Go's various patterns for emulating algebraic data types aka enums aka sum types. Similarly, with Python we would try to deploy AWS Lambdas, but it didn't take long and these would bust the (at the time) 250MB limit (compressed). I'm guessing Lambda has since raised this limit, but even still. Go binaries with as many (direct and transitive) dependencies would yield an artifact that was two orders of magnitude smaller and it would include the standard library and runtime. This also meant that our Docker images could be a lot smaller which has a whole bunch of other benefits as discussed here: https://news.ycombinator.com/item?id=30209023 https://news.ycombinator.com/item?id=30209023. With respect to performance, beyond the obvious problems, it also made tests far slower, and slow tests (and slow test suites) get run less frequently and later in the software development lifecycle which has a lot of knock-on effects (especially in a language that relies so heavily on tests rather than static analysis to catch bugs). We would also have to go through and purge tests or move them out of band of CI because we wanted to be able to do Continuous Deployment (and even if you don't want to be able to continuously deploy to production, being able to rapidly iterate in lower/ephemeral environments is really nice--getting high-fidelity local dev environments is either futile or very close thereto). It's really surprising how many advantages Go confers (at least relative to Python) beyond those which are obvious from the marketing.
huki_2231 5y ago
>> Cloudflare claims Go is not the right language for their workers due to sandboxing constraints[1]. That seems to be only relevant for functions / workers at the edge due to resource limitations. For traditional functions (I'm using AWS Lambda) Go is perfectly suited.

marcus_cemes 5y ago

WebAssembly is fundamently a very well isolated piece of executable code, and Cloudflare focussed on JS by creating their own stripped-down version of the V8 runtime, so you don't have to ship one. They focussed on some efficient solutions, rather than a versetile "just give us a docker image" approach. Other cloud providers just let you push code, charge you extortionate amounts of money to build the several hundred MB docker image that includes Node.js and node_modules, the data bandwidth of transfering those images between datacentres, storing the build cache in a multi-regional bucket (why???), then they charge you to store the image in their registry and then finaly give you a 10+ cold start time.

Abishek_Muthian 5y ago
As far as serverless Go is concerned my experience has been only with Heroku as I prefer hosting on my own instances and Heroku seems to be reasonable for my use case. I hear fly.io is better in terms of performance and they do offer distributed PostgreSQL. I guess those who are already into AWS would probably be choosing Lambda for serverless Go. If the experience is same as Node JS or Python on Lambda, Then I don't think there would be much to complain other than the cost; But of course cannot match the speed or cost of a CF worker for the reasons you've pointed.
- marcus_cemes 5y ago
  Fly.io is amazing, I'm very excitied for it! They spin up a long-lived instance on the edge closest to the user and create a Wireguard tunnel in-between. They also have a free tier and reasonable pricing. Heroku is just far too expensive for a hobby project.
  - throwaway894345 5y ago
    Usually the database (not the compute) is where things get expensive (Heroku's 10K rows is not practical for most tasks unless you're willing to do unholy things to put more data into a row).
- potta_coffee 5y ago
  I've written many lambdas in Python but have switched entirely to Go for all my new lambda work. Go is just better in every way - uses a fraction of the memory and executions take a tiny amount of the time Python takes.
  - tgtweak 5y ago
    I have a feeling AWS lambda's hypervisor has a lot of overhead, and simply making your workload smaller/lighter has a very noticeable reduction in execution time (cold start is <10ms on most of our GO lambdas). re: full serverless: I mean, try for yourselves but unless you're running an echo statement, you'll probably be hard pressed to get lower than this. Some early experiments with Rust showed 5x that, and that is as close to GO as I would dare to compare.
    - hrez 5y ago
      A while back I saw perf. tests on lambda cold starts per language. And somewhat surprisingly python was the fastest. It's probably not the same test but python is still at the top [1] [1] https://www.simform.com/blog/aws-lambda-performance/#StartupsTimesPerLanguage https://www.simform.com/blog/aws-lambda-performance/#Startup...
tgtweak 5y ago
The Cloudflare worker JS is a mess of incompatibility and design idiosyncrasies that make it really impractical for true edge application design. What I mean by cloud native & serverless is specifically containerized platforms where you ship your container and they run it - where a golang container can be 30MB with everything included vs a full-fat nodejs container in the 100-500MB range. Scala is also huge when bundled and shipped as a fat jar. Hell even windows binaries if you really wanted to push something to the end client, are trivial in golang and invoke none of the .net client library, c++ redistributable or "shipping java with your app" headaches of other solutions. Only Delphi and C linked against winapi can offer this same level of portability on Windows. AWS's lambda golang is first-class as well as GCP's golang "Cloud Functions". Again, can't speak highly enough of using golang on cloud.
- throwaway894345 5y ago
  My only grievance with Go in the cloud is that it's tedious to have to set up a CI job or similar to build your binaries to deploy in your functions. I really wish I could just ship the source code and have it compile for me (or failing that, if CloudFormation or AWS SAM or Terraform or whatever could transparently manage the compilation).
  - tgtweak 5y ago
    For us it's as simple as docker build right from the repo -> push to registry for test deployment then tag with prod for rollout from there. Probably not ideal for 20+ dev teams or high complexity deployments but this is the simplest CI and its much quicker build than node, so dev's can do it locally in all cases.
    - throwaway894345 5y ago
      Yeah, this is fine for early stage startups, but eventually you don't want developers to deploy directly to production.
      - 5y ago
huki_2231 5y ago
I have very different experiences: At my workplace we're using Go with Lambda and Fargate for several mid-size and one large application. The costs (image storage, transfer ...) you're referring to are actually almost neglectable. Aurora is by far the largest in our stack. On the other hand: Creating WASM is a big pain. I understand that Cloudflare and others promote it for their own business reasons, but from a developer/customer point of view docker or lambda are much more robust and simple.

throwaway894345 5y ago

> After getting burned due to performance limitations by Python applications at scale I switched to Go and never looked back Same here. Not just performance, but also tooling. We used to use pipenv for reproducible dependency management, but literally any change to the lockfile would take 30+ minutes to rebuild--this isn't including the time it takes to pull the dependencies in the first place, which was only a few minutes anyway. This meant that our CI jobs would take ~45 minutes and we would spend a ton of time trying different caching tricks and adding various complexity to our CI process to bring these times down, but they were still unsavory. With Go, we don't even need caching and everything builds and tests run in just a few minutes (end to end). Not only that, but Go's static typing was a boon. Years ago we would try keeping our types up-to-date with Sphinx (and code review checks), but inevitably they would fall out of date and the only thing worse than no type documentation is incorrect type documentation. Further, this didn't stop people from writing stupid code nearly as well as a type checker does (think "code whose return type varies based on the value of some input parameter" and various other such things). We eventually tried mypy but it was immature (couldn't express recursive types), cumbersome (e.g., expressing a callback that takes kwargs was tedious), confusing (I don't think I ever figured out how to publish a pypi package with type annotations that would be picked up automatically by mypy), slow, etc. I'm sure these things will improve with time, and there are also various other Python type checkers (although with everything in Python, each tool seems to have its own hidden pitfalls). On the plus side, Python's Unions are better than Go's various patterns for emulating algebraic data types aka enums aka sum types. Similarly, with Python we would try to deploy AWS Lambdas, but it didn't take long and these would bust the (at the time) 250MB limit (compressed). I'm guessing Lambda has since raised this limit, but even still. Go binaries with as many (direct and transitive) dependencies would yield an artifact that was two orders of magnitude smaller and it would include the standard library and runtime. This also meant that our Docker images could be a lot smaller which has a whole bunch of other benefits as discussed here: https://news.ycombinator.com/item?id=30209023 https://news.ycombinator.com/item?id=30209023. With respect to performance, beyond the obvious problems, it also made tests far slower, and slow tests (and slow test suites) get run less frequently and later in the software development lifecycle which has a lot of knock-on effects (especially in a language that relies so heavily on tests rather than static analysis to catch bugs). We would also have to go through and purge tests or move them out of band of CI because we wanted to be able to do Continuous Deployment (and even if you don't want to be able to continuously deploy to production, being able to rapidly iterate in lower/ephemeral environments is really nice--getting high-fidelity local dev environments is either futile or very close thereto). It's really surprising how many advantages Go confers (at least relative to Python) beyond those which are obvious from the marketing.

huki_2231 5y ago

>> Cloudflare claims Go is not the right language for their workers due to sandboxing constraints[1]. That seems to be only relevant for functions / workers at the edge due to resource limitations. For traditional functions (I'm using AWS Lambda) Go is perfectly suited.