Too often people look at one benchmark -- speed in execution to determine what the best language is. Is Rust better than Go because it can run a benchmark faster? The problem the original developers were trying to solve wasn't that C/C++ or other languages couldn't run fast enough, Ken Thompson wrote the original Unix kernel in Assembly after all, then went on to write B to make it easier to write for the new kernel. Dennis Ritchie modified B which became C and so on. Google had large codebases meant long development times when that code needed to be changed to meet business requirements, which resulted in long compile times. So, from epic to user stories, to executable code was taking too long.
Go is far more agile. Epic to user stories, to executable code is much shorter giving more time for lab testing. Of course, no program is ever 'finished' upon release they'll be new business requirements, Epics, user stories and so on. When looking for a language, raw speed shouldn't be the only consideration. Go gives decent speeds, but ask yourself does the headache of C/C++ / Rust to get a program that may process each call 500ms faster worth it? I've tried C/ C++ / Rust -- Great languages, but I'll even use Go in place of Bash because I can get it done faster. On Thursday, December 15, 2022 at 1:03:23 AM UTC-5 Jason E. Aten wrote: > two comments > > a) use many cores. Suddenly your Go code runs circles around everything > else-- i.e. those > languages you mention where doing multicore in a pain. The view > that other languages are faster comes from an age long ago of single core > machines. > > b) rather than pre-mature optimization, the general wisdom, and my > specific heartfelt advice, > is to measure where the time and memory is actually being spent, and then > optimize from there. > Generally this will 100x speed your development time, and > you may find it is plenty fast already, this is on top of the 10x - 20x > development speed over C++ that you > already get with Go. Should tuning be desired subsequently, when it comes > to profiling, > the Go tools are so vastly superior to anything else out there, that you > can easily find the > hot spots and focus your optimization with laser precision. This > is much more productive than trying to guess in general and over > generalized terms about how a given > application could perform under different languages. > > On Wednesday, December 14, 2022 at 11:57:40 AM UTC-6 Kursk wrote: > >> Hi, >> Go is a high performant garbage collected language, (considered) memory >> safe programming language, and as such its performance may not be >> comparable with other languages such as C/C++/Rust under certain >> application scenarios. >> >> I was wondering, how much of the Go language could be stretched (or >> ignored) to produce as close as possible performance results if for >> example, we write a program whose garbage collector have no work to do, >> assuming that we can pre-allocate all required heap space, or that we could >> somehow work around memory safety control points such as, index boundary >> checking, etc. >> >> - Which one those performance penalty points would exactly be? >> - Which ones would be impossible to workaround? >> - What instructions/operations would be generally speaking comparable? >> >> I know this is a very abstract and theoretical question, I am of course >> not expecting a conclusive/concrete answer to my questions but just some >> general answer, to increase my understanding about language performance >> while providing some pointers to continue my research on the topic. >> >> This will hopefully lead me to a better general understanding on where to >> seek for potential optimisation opportunities within the Go language itself >> vs scenarios where a port to C/C++/Rust would most likely be a better >> option. >> >> Thanks in advance. >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9cee8bb2-3c63-4eb8-90df-917c592656a4n%40googlegroups.com.
