I'm a Sr. Software Engineer at Flashpoint. I specialize in Python and Go, building functional, practical, and maintainable web systems leveraging Kubernetes and the cloud. Blog opinions are my own.
Python is significantly faster than running go run myfile.go. However, that's not Go's intended use case, really. That's more for debugging along the way, since go run does include the compilation each time.
I think it's interesting to compare the difference between go run and executing the compiled go executable, so the third set of each (ex: ./1_1) is go running the resulting compiled executable 100 times.
I'm a Sr. Software Engineer at Flashpoint. I specialize in Python and Go, building functional, practical, and maintainable web systems leveraging Kubernetes and the cloud. Blog opinions are my own.
Also, I am not a regular Go programmer. I've started doing challenges in Go just for my own amusement, but I would definitely not assume that whatever solution I come up with is optimal 😅
Oh, if this were production code I totally would, but I'm really only building these solutions to solve the problem, and not looking to make them infinitely extensible.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Woah, nice! Am I reading this right, that the Python is significantly faster than Go? Or is this including compilation each time?
Python is significantly faster than running
go run myfile.go. However, that's not Go's intended use case, really. That's more for debugging along the way, sincego rundoes include the compilation each time.I think it's interesting to compare the difference between
go runand executing the compiled go executable, so the third set of each (ex:./1_1) is go running the resulting compiled executable 100 times.Ooooh ok that makes sense. Cool!
Also, I am not a regular Go programmer. I've started doing challenges in Go just for my own amusement, but I would definitely not assume that whatever solution I come up with is optimal 😅
Hi jess!
Just a small advert: you should defer f.Close() after check if there's an error.
Also: Check out my GitHub Repo.
Oh, if this were production code I totally would, but I'm really only building these solutions to solve the problem, and not looking to make them infinitely extensible.