Ryan is an engineer in the Sacramento Area with a focus in Python, Ruby, and Rust. Bash/Python Exercism mentor. Coding, physics, calculus, music, woodworking. Looking for work!
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.
Ryan is an engineer in the Sacramento Area with a focus in Python, Ruby, and Rust. Bash/Python Exercism mentor. Coding, physics, calculus, music, woodworking. Looking for work!
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.