4 ms·

Git Large File Storage Is Written in Go

41 points by AliCollins 12y ago

__Joker 12y ago
Shouldn't there be a "client" in the title ?
- heinrich5991 12y ago
  FWIW the test server is also written in Go: https://github.com/github/lfs-test-server https://github.com/github/lfs-test-server
- kid0m4n 12y ago
  I wouldn't be surprised if the server was as well
__Joker 12y ago
As OP is trying to highlight Go, What are the advantages of using Go for the Git LFS client ? I can only gather from the previous thread was that, one of the reason for going with Go so as to get a native executable ?[1] 1. https://news.ycombinator.com/item?id=9345137 https://news.ycombinator.com/item?id=9345137
- technoweenie 12y ago
  Yes, that's really important for the Git LFS project to us. Of the languages that we're comfortable with, it's the only one that met that requirement. I feel like there have been a lot of blog posts and HN discussions about the merits and downsides to Go, and I don't really have anything new to add to that.
  - aikah 12y ago
    Speed also. Your hub client is way faster now that you moved from Ruby to Go. Doesn't mean Ruby was a bad choice, IMHO it helped you iterate faster on the initial product/prototype. I think both compiled and scripted solutions have their place in software development. What editor do you use at Github to write Go code?
- nothrabannosir 12y ago
  Something else about this kind of job cum go: "asynchronous I/O"* is extremely straightforward. Decoupling of the semantic threads ("goroutines") and OS-level threads mean a blocking I/O op only blocks your goroutine, which is cheap. If you are doing heavy I/O, you can still program sequentially. No need to manage I/O event queues, threadpools nor callbacks. Cherry on top: you never need to worry about blocking libraries, either. Every library automatically fits the model. It may not have been their consideration, but for anything I/O heavy, this is a godsend. Sorry for the tangent. This is now biting me on a new project and I feel like I didn't properly appreciate this until I didn't have it anymore.. * from the pov of OS threads

41 points by AliCollins 12y ago

__Joker 12y ago

Shouldn't there be a "client" in the title ?

heinrich5991 12y ago
FWIW the test server is also written in Go: https://github.com/github/lfs-test-server https://github.com/github/lfs-test-server
kid0m4n 12y ago
I wouldn't be surprised if the server was as well

__Joker 12y ago

As OP is trying to highlight Go, What are the advantages of using Go for the Git LFS client ? I can only gather from the previous thread was that, one of the reason for going with Go so as to get a native executable ?[1] 1. https://news.ycombinator.com/item?id=9345137 https://news.ycombinator.com/item?id=9345137

technoweenie 12y ago
Yes, that's really important for the Git LFS project to us. Of the languages that we're comfortable with, it's the only one that met that requirement. I feel like there have been a lot of blog posts and HN discussions about the merits and downsides to Go, and I don't really have anything new to add to that.
- aikah 12y ago
  Speed also. Your hub client is way faster now that you moved from Ruby to Go. Doesn't mean Ruby was a bad choice, IMHO it helped you iterate faster on the initial product/prototype. I think both compiled and scripted solutions have their place in software development. What editor do you use at Github to write Go code?
nothrabannosir 12y ago
Something else about this kind of job cum go: "asynchronous I/O"* is extremely straightforward. Decoupling of the semantic threads ("goroutines") and OS-level threads mean a blocking I/O op only blocks your goroutine, which is cheap. If you are doing heavy I/O, you can still program sequentially. No need to manage I/O event queues, threadpools nor callbacks. Cherry on top: you never need to worry about blocking libraries, either. Every library automatically fits the model. It may not have been their consideration, but for anything I/O heavy, this is a godsend. Sorry for the tangent. This is now biting me on a new project and I feel like I didn't properly appreciate this until I didn't have it anymore.. * from the pov of OS threads