While that’s what they’d teach you in CS it’s missing enough nuance to be incorrect.
> There is a limit to optimization, and that ends with optimized machine code.
While that’s true, you overlook the cost of language abstractions. I’m don’t mean runtime decisions like any use of byte code but rather the language design decisions like support for garbage collection, macros, use of generics and/or reflection, green threads vs POSIX threads and even basic features like bounds checking, how strings are modelled and arrays vs slices.
These will all directly impact just how far you can optimise the machine code because they are abstractions that have a direct impact to the machine code that is generated.
> Go being a compiled language, that is cross paltform but separate binaries, should be very close to C in terms of performance.
No it shouldn’t. C doesn’t have GC, bounds checking, green threads, strings, slices, nor any of the other nice things that makes life a little easier as a modern developer (I say this not as a criticism of C, I do like that language a lot but it suits a different domain to Go).
> Languages like Python, Java, C#, are run on virtual machines, meaning you can optimize them only so far.
Aside from CPythons runtime, their instructions still compiles to machine code.
These days no popular language, not even scripting ones, interprets byte code upon execution. [edit: I posted that before drinking coffee and now realise it was a gross exaggeration and ultimately untrue.]
You’ll find a lot of these languages compile their instructions to machine code. Some might use an intermediate virtual machine with byte code but in a lot of cases that’s just part of the compiler pass. Some might be just in time (JIT) compiled, but in many cases they’re still compiled to machine code.
> 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.
That’s a hugely generalised statement and the reality is that it just depends on your workloads.
Want machine learning? Well then Go isn’t the best language. Have lots of small queries and need to rely on a lower start up time because execution time is always going to be short, we’ll node will often prove superior.
Don’t get me wrong, Go has its place too. But hugely generalised statements seldom work generally in IT.
Yeah, now I think about it, plenty of runtimes do. I have no idea why I posted that when I know it’s not true. Must have been related to the time of the morning and the lack of coffee.
> There is a limit to optimization, and that ends with optimized machine code.
While that’s true, you overlook the cost of language abstractions. I’m don’t mean runtime decisions like any use of byte code but rather the language design decisions like support for garbage collection, macros, use of generics and/or reflection, green threads vs POSIX threads and even basic features like bounds checking, how strings are modelled and arrays vs slices.
These will all directly impact just how far you can optimise the machine code because they are abstractions that have a direct impact to the machine code that is generated.
> Go being a compiled language, that is cross paltform but separate binaries, should be very close to C in terms of performance.
No it shouldn’t. C doesn’t have GC, bounds checking, green threads, strings, slices, nor any of the other nice things that makes life a little easier as a modern developer (I say this not as a criticism of C, I do like that language a lot but it suits a different domain to Go).
> Languages like Python, Java, C#, are run on virtual machines, meaning you can optimize them only so far.
Aside from CPythons runtime, their instructions still compiles to machine code.
These days no popular language, not even scripting ones, interprets byte code upon execution. [edit: I posted that before drinking coffee and now realise it was a gross exaggeration and ultimately untrue.]
You’ll find a lot of these languages compile their instructions to machine code. Some might use an intermediate virtual machine with byte code but in a lot of cases that’s just part of the compiler pass. Some might be just in time (JIT) compiled, but in many cases they’re still compiled to machine code.
> 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.
That’s a hugely generalised statement and the reality is that it just depends on your workloads.
Want machine learning? Well then Go isn’t the best language. Have lots of small queries and need to rely on a lower start up time because execution time is always going to be short, we’ll node will often prove superior.
Don’t get me wrong, Go has its place too. But hugely generalised statements seldom work generally in IT.