14 ms·

The thing people don't seem to appreciate/understand with go is the effects of using it in serverless and cloud native environments. Every high throughput serv

The thing people don't seem to appreciate/understand with go is the effects of using it in serverless and cloud native environments. Every high throughput service I've had moved to GO has used a tiny amount of Memory and CPU compared to the implementation it replaced, typically nodejs, python, Scala and .net. In a cloud world where it's usually boiled down to pay-per MB of in-process memory and per cycle... That can be 4-5 figures a month in reduced cloud cost for the same traffic. Tiny output binaries are also very quick to transfer and spin up in serverless as well - often reducing costs further. The benefits over time of essentially knowing things will get faster with each new version is really encouraging as well. Imagine your cloud bill went down over time as a result of simply rebuilding your service on newer golang core and redeploying.

ctopher7 5y ago
how about using rust in cloud native env? I write in go for a living (my company uses it company wide) but I use rust for my personal project never had the chance to compare both performance
dimgl 5y ago
+1 for this. There is some upfront cost though around learning Golang. Writing idiomatic Golang code takes a bit of getting used to.
- baby 5y ago
  Honestly Golang is not hard to learn, compared to other typed languages like Rust.
  - seanw444 5y ago
    Took me maybe two days to feel comfortable rewriting one of my bigger projects from Python to Go. Absolutely wonderful language.
  - dagmx 5y ago
    I think it depends on personal mental models. I found rust easier to get to grips with because it was more straightforward for the way I thought, whereas with Go I struggled with a lot of things that felt funky to me. I fully agree that Go is a simpler language up front though at the syntax level.
    - lenkite 5y ago
      I found C++ template meta-programming easier to learn than Rust. The only thing new to learn in Go was Go-routines. Followed by a scan of Effective Go, a single page of "gotchas" and one can immediately churn out software. Never found a language/stdlib so easy to start coding in.
    - Cthulhu_ 5y ago
      Could you share which things those were? I mean error handling is a common issue people first raise an eyebrow at, but other than that I've found it a really straightforward language to use (coming from Java and JS myself, a bit of obj-c/swift, some scala in between).
      - dagmx 5y ago
        Error handling is a big one for me. It just seems illogical that it's so easily skipped. There's a lot of magic in the APIs. This blog post covered it but I hit quite a few of them. I get why they're appealing but I mentally feel the API is wrong which causes friction when I use them. https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... I find I don't agree with the package and versioning story either. Publicness based on casing, the way dependencies are declared in the source code. It's lots of little things that, while I can see the appeal, they create friction with how I like to work. My background is somewhat similar, Python, C++, ObjC, Swift, Java/Kotlin, JS, C#,GLSL etc... In particular, I've used some APIs in the past that were very similar to Go and been bitten by it. E.g defining dependencies in the source quickly became an exercise in frustration when dealing with multiple packages needing updates for a shared runtime. It's not an issue people would hit when writing microservices or CLI tools, but it hit hard for working on graphics tools where everything runs in the same runtime. I know go has ways around it though but still not a fan.
  - kaba0 5y ago
    Why compare a low level language to a high level one? Of course one will be more complex, because the GC takes many of the details out of the picture, reducing the essential complexity of the problem domain.
manigandham 5y ago
All language stacks get faster over time and redeploying with a new version can improve performance and save costs. Nothing exclusive to Golang about that. Edit - I'm curious as to what is so controversial about this comment? What stack has gotten slower over time?
- kumarvvr 5y ago
  Yeah no. There is a limit to optimization, and that ends with optimized machine code. Go being a compiled language, that is cross paltform but separate binaries, should be very close to C in terms of performance. Languages like Python, Java, C#, are run on virtual machines, meaning you can optimize them only so far. As far as cloud costs are concerned, a well developed program should cost least with go. Go is best suited for running intensive compute loads in serverless environments.
  - manigandham 5y ago
    > "There is a limit to optimization, and that ends with optimized machine code." There's a vast amount of concepts when it comes to "optimization" and we are very far from the limit. There's still tons of research just to improve compiler intelligence for high-level code intention, let alone in runtime performance. > "Go being a compiled language" All code is eventually machine code. That's the only way a CPU can execute it. Virtual machines are an implementation detail and the latest versions with dynamic tiered JITers, POGO, vectorization, and other techniques can match or exceed static compilation because they optimize based on actual runtime behavior instead of assumptions; balancing memory safety, fast startup, amortized optimization, and steady state throughput. > "As far as cloud costs are concerned, a well developed program should cost least with go." This is meaningless without context. I've built 3 ad exchanges running billions of requests per day with C#/.NET which rivaled other stacks, including C++. I also know several fintech companies that have Java in their performance critical sections. It seems you're working with outdated and limited context of languages and scenarios.
    - terminalcommand 5y ago
kumarvvr 5y ago
True. Bit savings are significant only when volumes are large enough. Also, developing from ground up to target a serverless runtime, means you can reach market faster with python and other langs, but reduce cost by moving to Go or C over time.
Abishek_Muthian 5y ago
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.
peakaboo 5y ago
Rust gives many times more performance than go but is harder to learn: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- usrbinbash 5y ago
  Yeah, about such benchmarks: https://studygolang.com/resources/12288 https://studygolang.com/resources/12288 https://hacker-news.news/post/28293057 https://hacker-news.news/post/28293057
  - marcus_cemes 5y ago
    I kind of have to agree with the guy there, it would be kind of trash if everyone just inlined assembly instructions. Manual SIMD already feels a bit like cheating. Ideally, there should be two solution categories, idiomatic solutions and optimised solutions. I would prefer if the idiomatic solutions matched what the average programmer would write. I think we worry about performance far too much when choosing a language. However, when performance is important, it's important to recognise the different classes of languages, say {Go, Rust, C} vs {Python, JS, Ruby} in terms of speed and memory footprint vs productivity.
    - usrbinbash 5y ago
      No inlining of assembly is required to vastly improve the performance of Go in many such benchmarks. Pool or Arena Allocation are commonly used techniques and whether or not they are "idiomatic" isn't even up for discussion any more since the stdlib includes the former.
      - igouy 5y ago
        > … stdlib includes the former. sync.Pool — binary-trees Go #6 program https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-go-6.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... ---- Go does provide GC https://news.ycombinator.com/item?id=29323468 https://news.ycombinator.com/item?id=29323468
pjmlp 5y ago
In what concerns .NET is wasn't really better, https://devblogs.microsoft.com/dotnet/grpc-performance-improvements-in-net-5/ https://devblogs.microsoft.com/dotnet/grpc-performance-impro...
- jmnicolas 5y ago
  The difference is meaningless, it's just gRPC and it's a MS blog... so nothing to call home about. And I'm saying this as a C# dev that never wrote anything in Go.
  - pjmlp 5y ago
    Ok, here is another one, then. https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ You should learn to write some Go code then.
    - throwaway894345 5y ago
      Maybe I'm not following the thread (I'm not sure what "In what concerns .NET is wasn't really better" means), but what's the issue here? C#'s fastest framework beats Go's fastest by a marginal amount (60.1% vs 59.1%). That's probably within the error margin. Anyway, drawing sweeping performance conclusions from microbenchmarks is perilous--a high ceiling for an HTTP framework doesn't indicate anything about real-world performance for web applications (which are almost never bottlenecked on the HTTP framework).
      - pjmlp 5y ago
        The issue here is how many in the Go community like to boost themselves about how fast Go is, only because it is the very first AOT compiled language that they ever used, usually come form scripting language backgrounds and are influenced by the traditional Java/.NET hate, without ever using them in anger, including their AOT tooling. So then we come these kind of assertions like Go compiles faster than any other AOT language, it doesn't have a runtime, its performance beats Java/.NET and so on.
deleted 5y ago
[deleted]
DyslexicAtheist 5y ago
> Tiny output binaries are also very quick to transfer and spin up in serverless as well - often reducing costs further. Your point is specifically about cloud so maybe I shouldn't use go on Edge? In fact I'm struggling with the binary size right now (and have only just started with go after decades of C - because reasons beyond my control). with go 1.17 the resulting executable (running on ARM) is 11MB (stripped ldflags -w -s). I can run upx --brute and reduce it to 3MB. But that is still heavy when another lua based application (a complete NodeRed clone - with massive complexity) and 100x as many lines of code (before importing external packages) is still just short of half a MB. (apples & oranges yes ...) Maybe I shouldn't use go on an edge devices with such poor hardware? I heard about tiny-go but looking at their website could only find instructions on how to x-compile for specific boards but not for specific HW (like ARM-5 softfloat). Though I totally love the free stuff I get out of the box with go while also it feeling very familiar coming from C. The only thing I dislike is that it's not C :P
- dagmx 5y ago
  Is your Lua code standalone? i.e is the interpreter part of the application size?
  - edflsafoiewq 5y ago
    Even if it isn't, LuaJIT is half a meg, and regular Lua is about half that.
    - tgtweak 5y ago
      If you're thinking about an edge where you have less than 3MB of storage space, and likely very limited in-memory space, you'd probably still be better to go with C. These kinds of environments are becoming very small % of use case over time. Usually such resource-constrained devices & systems have their own build system or crutch libraries built in to help reduce binary sizes to this scale. It is against golang's design principle to make a language that requires external frameworks/libraries to run. As it is, you can build your golang app, send it over an ssh tunnel and have it running on the remote system without much thought at all.
keewee7 5y ago
Modern .Net is more CPU and memory performant than Go. https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/
Chyzwar 5y ago
Serverless model as implemented in aws lambda is not faster or cheaper. A single node.js process with fastify.js or hapi.js can handle hundreds if not thousands of requests per second. In lambda to handle 1000 requests per second, assuming a single request take 100ms you need to have 100 instances of lambdas running. Serverless is only cheaper if your application see very little traffic and somehow fit in very limited feature set of lambda. Otherwise, you still need to pay extra for provisioned concurrency and spend engineering resources to workaround lambda limitations. What often happen is people build own framework on top of serverless instead of just using Rails, Django, Phoenix etc.
- Blackstone4 5y ago
  The poster was comparing Go implementations versus Node.js....not serverless vs dedicated server...
pfortuny 5y ago
Not trying to nitpick but knowing that SIM cards run a version of Java, you cannot make much less than that, as far as virtual machines go. Also forth and lisp have really tiny tiny version with large capabilities. So, if size matters, I guess lots of languages have you covered on that, not just Go.
nickjj 5y ago
> Tiny output binaries are also very quick to transfer and spin up in serverless as well This is a big deal when using servers too. If you have a single server deploy that could be the difference of 1 second of downtime with Go vs 5-15 seconds for an app in a different language to start up. For multi-server deploys this could also drastically impact how long it takes to do a rolling update. Having a 10 second delay across N servers adds up. For me it hasn't been enough to seriously consider switching away from Python and Ruby to build web apps because I like the web frameworks that these languages have available for productivity but it has for sure made me wish I could live in a world where it takes any app 1 second to start up. I know Docker helps with being able to ship around essentially a single binary but it can't change how long it takes a process to start.
- tgtweak 5y ago
  For environments where build is included in deployment (Not best practice at all, but sadly common) it can be very pronounced. Don't forget that CI systems are increasingly memory/cycle/time based for billing, and having a nice lightweight build/artifact is very appreciated here.
  - nickjj 5y ago
    Yes, and speaking of CI there's also linting and formatting code. In large code bases with certain languages it can take a substantial amount of time to do this step (tens of seconds). Being able to zip through linting, formatting, building, running, testing and pushing a binary / Docker image in 1 minute vs 10 minutes is a massive win -- especially when amplified over a number of developers.
Meritiooo 5y ago
I have no clue in which scenario you talk. The normal webstuff is idling around at plenty of companies while sometimes having performance issues due to mostly bad code and bad sqls. If you talk about batch processingmost cases I'm aware are io issues. And memory is very cheap. I really don't careand it doesn't make any difference in my cases, if the tool is 5 or 500mb. Not that I prefer very small efficient languages and binaries! But I will take a language I'm confident in over a faster language most of the time.
- tgtweak 5y ago
  I'll give you a candid scenario that we went through: nodejs app built with express receiving json events from 10M clients around the world on very regular basis, pushing to a queue and checking that it was received by the queue. Extremely simple app: receive and parse json, do some very simple sanity checks on schema, convert to bson with some predefined mapping, and push to a queue (happened to be azure eventhub). To handle ~5BN events per month, peaking around 4000 events/sec, it was using up to 20 instances of node at ~200-300MB per instance in-memory and with scale-out trigger set to 75% cpu... 95th percentile was 20 cores and 12GB of ram in a serverless environment just for that one service. Add to that base container overhead and it was peaking at 16GB memory. That's not nothing in a serverless world. If it was a VM, sure, not too bad, but we're talking elastic containers and that service was built for 500% tolerance for high watermark. Not about to provision two 48GB VMs in two AZs and worry about all the plumbing "just incase". That is the point of going serverless. Moved it to golang and it was handling 2000 req/s on 1 core with 60MB in memory. It has never went over 3 cores in the 2 years since it was moved.
throwaway894345 5y ago
> Tiny output binaries are also very quick to transfer and spin up in serverless as well - often reducing costs further. I think people underestimate the benefits of services that can start super quickly (IMHO, "cost" is nowhere near the most significant benefit!). Fast restarts means your service can respond very quickly to a scale up event (which can make the difference between "things get a little slow for a moment" and "everything comes crashing down"). It also means developers iterating in a cloud environment can get faster feedback, which itself seems underrated. Further, when you push a change that takes down production, the rollback is much faster. Of course, all of these things have various workarounds (e.g., canary deploys so you're less likely to take down prod in the first place) but if you can have 5MB images instead of 5+GB images you can go a lot farther without needing to implement them. Of course, small images are necessary but not sufficient for fast startups; however, in practice the overwhelming majority of Go programs also start up quickly (although in a cloud context, this can be wasted if they're deployed on bulky distro base images).

ctopher7 5y ago

how about using rust in cloud native env? I write in go for a living (my company uses it company wide) but I use rust for my personal project never had the chance to compare both performance

dimgl 5y ago

+1 for this. There is some upfront cost though around learning Golang. Writing idiomatic Golang code takes a bit of getting used to.

baby 5y ago
Honestly Golang is not hard to learn, compared to other typed languages like Rust.
- seanw444 5y ago
  Took me maybe two days to feel comfortable rewriting one of my bigger projects from Python to Go. Absolutely wonderful language.
- dagmx 5y ago
  I think it depends on personal mental models. I found rust easier to get to grips with because it was more straightforward for the way I thought, whereas with Go I struggled with a lot of things that felt funky to me. I fully agree that Go is a simpler language up front though at the syntax level.
  - lenkite 5y ago
    I found C++ template meta-programming easier to learn than Rust. The only thing new to learn in Go was Go-routines. Followed by a scan of Effective Go, a single page of "gotchas" and one can immediately churn out software. Never found a language/stdlib so easy to start coding in.
  - Cthulhu_ 5y ago
    Could you share which things those were? I mean error handling is a common issue people first raise an eyebrow at, but other than that I've found it a really straightforward language to use (coming from Java and JS myself, a bit of obj-c/swift, some scala in between).
    - dagmx 5y ago
      Error handling is a big one for me. It just seems illogical that it's so easily skipped. There's a lot of magic in the APIs. This blog post covered it but I hit quite a few of them. I get why they're appealing but I mentally feel the API is wrong which causes friction when I use them. https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... I find I don't agree with the package and versioning story either. Publicness based on casing, the way dependencies are declared in the source code. It's lots of little things that, while I can see the appeal, they create friction with how I like to work. My background is somewhat similar, Python, C++, ObjC, Swift, Java/Kotlin, JS, C#,GLSL etc... In particular, I've used some APIs in the past that were very similar to Go and been bitten by it. E.g defining dependencies in the source quickly became an exercise in frustration when dealing with multiple packages needing updates for a shared runtime. It's not an issue people would hit when writing microservices or CLI tools, but it hit hard for working on graphics tools where everything runs in the same runtime. I know go has ways around it though but still not a fan.
- kaba0 5y ago
  Why compare a low level language to a high level one? Of course one will be more complex, because the GC takes many of the details out of the picture, reducing the essential complexity of the problem domain.

manigandham 5y ago

All language stacks get faster over time and redeploying with a new version can improve performance and save costs. Nothing exclusive to Golang about that. Edit - I'm curious as to what is so controversial about this comment? What stack has gotten slower over time?

kumarvvr 5y ago
Yeah no. There is a limit to optimization, and that ends with optimized machine code. Go being a compiled language, that is cross paltform but separate binaries, should be very close to C in terms of performance. Languages like Python, Java, C#, are run on virtual machines, meaning you can optimize them only so far. As far as cloud costs are concerned, a well developed program should cost least with go. Go is best suited for running intensive compute loads in serverless environments.
- manigandham 5y ago
  > "There is a limit to optimization, and that ends with optimized machine code." There's a vast amount of concepts when it comes to "optimization" and we are very far from the limit. There's still tons of research just to improve compiler intelligence for high-level code intention, let alone in runtime performance. > "Go being a compiled language" All code is eventually machine code. That's the only way a CPU can execute it. Virtual machines are an implementation detail and the latest versions with dynamic tiered JITers, POGO, vectorization, and other techniques can match or exceed static compilation because they optimize based on actual runtime behavior instead of assumptions; balancing memory safety, fast startup, amortized optimization, and steady state throughput. > "As far as cloud costs are concerned, a well developed program should cost least with go." This is meaningless without context. I've built 3 ad exchanges running billions of requests per day with C#/.NET which rivaled other stacks, including C++. I also know several fintech companies that have Java in their performance critical sections. It seems you're working with outdated and limited context of languages and scenarios.
  - terminalcommand 5y ago

kumarvvr 5y ago

True. Bit savings are significant only when volumes are large enough. Also, developing from ground up to target a serverless runtime, means you can reach market faster with python and other langs, but reduce cost by moving to Go or C over time.

Abishek_Muthian 5y ago

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.

peakaboo 5y ago

Rust gives many times more performance than go but is harder to learn: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

usrbinbash 5y ago
Yeah, about such benchmarks: https://studygolang.com/resources/12288 https://studygolang.com/resources/12288 https://hacker-news.news/post/28293057 https://hacker-news.news/post/28293057
- marcus_cemes 5y ago
  I kind of have to agree with the guy there, it would be kind of trash if everyone just inlined assembly instructions. Manual SIMD already feels a bit like cheating. Ideally, there should be two solution categories, idiomatic solutions and optimised solutions. I would prefer if the idiomatic solutions matched what the average programmer would write. I think we worry about performance far too much when choosing a language. However, when performance is important, it's important to recognise the different classes of languages, say {Go, Rust, C} vs {Python, JS, Ruby} in terms of speed and memory footprint vs productivity.
  - usrbinbash 5y ago
    No inlining of assembly is required to vastly improve the performance of Go in many such benchmarks. Pool or Arena Allocation are commonly used techniques and whether or not they are "idiomatic" isn't even up for discussion any more since the stdlib includes the former.
    - igouy 5y ago
      > … stdlib includes the former. sync.Pool — binary-trees Go #6 program https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-go-6.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... ---- Go does provide GC https://news.ycombinator.com/item?id=29323468 https://news.ycombinator.com/item?id=29323468

pjmlp 5y ago

In what concerns .NET is wasn't really better, https://devblogs.microsoft.com/dotnet/grpc-performance-improvements-in-net-5/ https://devblogs.microsoft.com/dotnet/grpc-performance-impro...

jmnicolas 5y ago
The difference is meaningless, it's just gRPC and it's a MS blog... so nothing to call home about. And I'm saying this as a C# dev that never wrote anything in Go.
- pjmlp 5y ago
  Ok, here is another one, then. https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ You should learn to write some Go code then.
  - throwaway894345 5y ago
    Maybe I'm not following the thread (I'm not sure what "In what concerns .NET is wasn't really better" means), but what's the issue here? C#'s fastest framework beats Go's fastest by a marginal amount (60.1% vs 59.1%). That's probably within the error margin. Anyway, drawing sweeping performance conclusions from microbenchmarks is perilous--a high ceiling for an HTTP framework doesn't indicate anything about real-world performance for web applications (which are almost never bottlenecked on the HTTP framework).
    - pjmlp 5y ago
      The issue here is how many in the Go community like to boost themselves about how fast Go is, only because it is the very first AOT compiled language that they ever used, usually come form scripting language backgrounds and are influenced by the traditional Java/.NET hate, without ever using them in anger, including their AOT tooling. So then we come these kind of assertions like Go compiles faster than any other AOT language, it doesn't have a runtime, its performance beats Java/.NET and so on.

deleted 5y ago

[deleted]

DyslexicAtheist 5y ago

> Tiny output binaries are also very quick to transfer and spin up in serverless as well - often reducing costs further. Your point is specifically about cloud so maybe I shouldn't use go on Edge? In fact I'm struggling with the binary size right now (and have only just started with go after decades of C - because reasons beyond my control). with go 1.17 the resulting executable (running on ARM) is 11MB (stripped ldflags -w -s). I can run upx --brute and reduce it to 3MB. But that is still heavy when another lua based application (a complete NodeRed clone - with massive complexity) and 100x as many lines of code (before importing external packages) is still just short of half a MB. (apples & oranges yes ...) Maybe I shouldn't use go on an edge devices with such poor hardware? I heard about tiny-go but looking at their website could only find instructions on how to x-compile for specific boards but not for specific HW (like ARM-5 softfloat). Though I totally love the free stuff I get out of the box with go while also it feeling very familiar coming from C. The only thing I dislike is that it's not C :P

dagmx 5y ago
Is your Lua code standalone? i.e is the interpreter part of the application size?
- edflsafoiewq 5y ago
  Even if it isn't, LuaJIT is half a meg, and regular Lua is about half that.
  - tgtweak 5y ago
    If you're thinking about an edge where you have less than 3MB of storage space, and likely very limited in-memory space, you'd probably still be better to go with C. These kinds of environments are becoming very small % of use case over time. Usually such resource-constrained devices & systems have their own build system or crutch libraries built in to help reduce binary sizes to this scale. It is against golang's design principle to make a language that requires external frameworks/libraries to run. As it is, you can build your golang app, send it over an ssh tunnel and have it running on the remote system without much thought at all.

keewee7 5y ago

Modern .Net is more CPU and memory performant than Go. https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/

Chyzwar 5y ago

Serverless model as implemented in aws lambda is not faster or cheaper. A single node.js process with fastify.js or hapi.js can handle hundreds if not thousands of requests per second. In lambda to handle 1000 requests per second, assuming a single request take 100ms you need to have 100 instances of lambdas running. Serverless is only cheaper if your application see very little traffic and somehow fit in very limited feature set of lambda. Otherwise, you still need to pay extra for provisioned concurrency and spend engineering resources to workaround lambda limitations. What often happen is people build own framework on top of serverless instead of just using Rails, Django, Phoenix etc.

Blackstone4 5y ago
The poster was comparing Go implementations versus Node.js....not serverless vs dedicated server...

pfortuny 5y ago

Not trying to nitpick but knowing that SIM cards run a version of Java, you cannot make much less than that, as far as virtual machines go. Also forth and lisp have really tiny tiny version with large capabilities. So, if size matters, I guess lots of languages have you covered on that, not just Go.

nickjj 5y ago

> Tiny output binaries are also very quick to transfer and spin up in serverless as well This is a big deal when using servers too. If you have a single server deploy that could be the difference of 1 second of downtime with Go vs 5-15 seconds for an app in a different language to start up. For multi-server deploys this could also drastically impact how long it takes to do a rolling update. Having a 10 second delay across N servers adds up. For me it hasn't been enough to seriously consider switching away from Python and Ruby to build web apps because I like the web frameworks that these languages have available for productivity but it has for sure made me wish I could live in a world where it takes any app 1 second to start up. I know Docker helps with being able to ship around essentially a single binary but it can't change how long it takes a process to start.

tgtweak 5y ago
For environments where build is included in deployment (Not best practice at all, but sadly common) it can be very pronounced. Don't forget that CI systems are increasingly memory/cycle/time based for billing, and having a nice lightweight build/artifact is very appreciated here.
- nickjj 5y ago
  Yes, and speaking of CI there's also linting and formatting code. In large code bases with certain languages it can take a substantial amount of time to do this step (tens of seconds). Being able to zip through linting, formatting, building, running, testing and pushing a binary / Docker image in 1 minute vs 10 minutes is a massive win -- especially when amplified over a number of developers.

Meritiooo 5y ago

I have no clue in which scenario you talk. The normal webstuff is idling around at plenty of companies while sometimes having performance issues due to mostly bad code and bad sqls. If you talk about batch processingmost cases I'm aware are io issues. And memory is very cheap. I really don't careand it doesn't make any difference in my cases, if the tool is 5 or 500mb. Not that I prefer very small efficient languages and binaries! But I will take a language I'm confident in over a faster language most of the time.

tgtweak 5y ago
I'll give you a candid scenario that we went through: nodejs app built with express receiving json events from 10M clients around the world on very regular basis, pushing to a queue and checking that it was received by the queue. Extremely simple app: receive and parse json, do some very simple sanity checks on schema, convert to bson with some predefined mapping, and push to a queue (happened to be azure eventhub). To handle ~5BN events per month, peaking around 4000 events/sec, it was using up to 20 instances of node at ~200-300MB per instance in-memory and with scale-out trigger set to 75% cpu... 95th percentile was 20 cores and 12GB of ram in a serverless environment just for that one service. Add to that base container overhead and it was peaking at 16GB memory. That's not nothing in a serverless world. If it was a VM, sure, not too bad, but we're talking elastic containers and that service was built for 500% tolerance for high watermark. Not about to provision two 48GB VMs in two AZs and worry about all the plumbing "just incase". That is the point of going serverless. Moved it to golang and it was handling 2000 req/s on 1 core with 60MB in memory. It has never went over 3 cores in the 2 years since it was moved.

throwaway894345 5y ago

> Tiny output binaries are also very quick to transfer and spin up in serverless as well - often reducing costs further. I think people underestimate the benefits of services that can start super quickly (IMHO, "cost" is nowhere near the most significant benefit!). Fast restarts means your service can respond very quickly to a scale up event (which can make the difference between "things get a little slow for a moment" and "everything comes crashing down"). It also means developers iterating in a cloud environment can get faster feedback, which itself seems underrated. Further, when you push a change that takes down production, the rollback is much faster. Of course, all of these things have various workarounds (e.g., canary deploys so you're less likely to take down prod in the first place) but if you can have 5MB images instead of 5+GB images you can go a lot farther without needing to implement them. Of course, small images are necessary but not sufficient for fast startups; however, in practice the overwhelming majority of Go programs also start up quickly (although in a cloud context, this can be wasted if they're deployed on bulky distro base images).