Thank you for all the insights! On Fri, 16 Dec 2022 at 14:59, Rich <rma...@gmail.com> wrote:
> 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 a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/WBnqwLjzTmE/unsubscribe. > To unsubscribe from this group and all its topics, 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 > <https://groups.google.com/d/msgid/golang-nuts/9cee8bb2-3c63-4eb8-90df-917c592656a4n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAE9Yvdgi9ieca%2Bb7LqBLTbBK2OjFbkNJOPgWLK96E%3DZyzCicSQ%40mail.gmail.com.
