3 ms·

There are other reasons for rewriting like getting to a more easily maintainable code or when a previous solution has simply outlived it's usefulness. Also, C

by omarkj_ 14y ago

There are other reasons for rewriting like getting to a more easily maintainable code or when a previous solution has simply outlived it's usefulness. Also, C is not the only language worth rewriting in.

voidlogic 14y ago
"Also, C is not the only language worth rewriting in" Agreed! I would really like to see someone write a node.js and Go back-end for the same front-end and do a head to head comparison. As someone who spent a fair amount of time rewriting node.js prototypes in Go, I'm probably biased. I feel like javascript is a much less maintainable language. Perhaps is was the original node.js implementations (I don't think it was), but the Go versions were always faster, used less memory and IMHO were more readable.
- iends 14y ago
  Any particular lessons learned rewriting from node to Go? I've got a small but growing node/socket.io app I figured I'd have to one day rewrite in go if I really wanted it to scale.
  - voidlogic 14y ago
    Nothing too unexpected, off the top of my head, I've noticed: * Use Go tip; You can grab a snapshot review all the open issues for that snapshot (most are enhancements). * Like any re-factor doing it sooner as opposed to later is less work :) * Do some "from scratch" Go projects before doing re-factor projects to get your legs under you (if they are not already there) * Write Go in Go, not C/Python/Java in Go. This is harder than you think when you get started, but, if you ask for help and people tell you you are fighting the system, carefully consider their advice. * A lot of the Go community likes to use single letter variable names in contexts like receivers, struct state (just look at the stdlib), buck the system, don't do that, use short camel case names. The next guy / you in six months will be glad you did. * If you have a Java/C++ background you might often write a single threaded version of a daemon and later multithread it later, this is generally an unnecessary step in Go. * The Go versions really are not much larger (LOC) * There is lots of useful Go code on github (don't be afraid to try them) * If you are doing front-endy kind of stuff supplement "net/http" with Gorilla where needed whenever you can rather than rolling your own. ttp://www.gorillatoolkit.org/ * "go tool prof" is a great tool, know how to use it and its top20 / web commands. Even if you don't feel the pain, use it and you will learn what things you do are expensive and it will keep trouble from sneaking up on you. * If you are using a SQL based store, use a driver that implements the interfaces in "database/sql" rather than providing its own interface. This will make your life very simple if you need to migrate between mySQL <-> Postgre, etc * LiteIDE is a nice lean cross platform Go IDE that includes syntax highlighing, autocomplete (with gocode) and debugging support. The only think I had to do was write my own syntax highlighting theme, based on Solarized, because I thought the included ones were gross.

by omarkj_ 14y ago

voidlogic 14y ago

"Also, C is not the only language worth rewriting in" Agreed! I would really like to see someone write a node.js and Go back-end for the same front-end and do a head to head comparison. As someone who spent a fair amount of time rewriting node.js prototypes in Go, I'm probably biased. I feel like javascript is a much less maintainable language. Perhaps is was the original node.js implementations (I don't think it was), but the Go versions were always faster, used less memory and IMHO were more readable.

iends 14y ago
Any particular lessons learned rewriting from node to Go? I've got a small but growing node/socket.io app I figured I'd have to one day rewrite in go if I really wanted it to scale.
- voidlogic 14y ago
  Nothing too unexpected, off the top of my head, I've noticed: * Use Go tip; You can grab a snapshot review all the open issues for that snapshot (most are enhancements). * Like any re-factor doing it sooner as opposed to later is less work :) * Do some "from scratch" Go projects before doing re-factor projects to get your legs under you (if they are not already there) * Write Go in Go, not C/Python/Java in Go. This is harder than you think when you get started, but, if you ask for help and people tell you you are fighting the system, carefully consider their advice. * A lot of the Go community likes to use single letter variable names in contexts like receivers, struct state (just look at the stdlib), buck the system, don't do that, use short camel case names. The next guy / you in six months will be glad you did. * If you have a Java/C++ background you might often write a single threaded version of a daemon and later multithread it later, this is generally an unnecessary step in Go. * The Go versions really are not much larger (LOC) * There is lots of useful Go code on github (don't be afraid to try them) * If you are doing front-endy kind of stuff supplement "net/http" with Gorilla where needed whenever you can rather than rolling your own. ttp://www.gorillatoolkit.org/ * "go tool prof" is a great tool, know how to use it and its top20 / web commands. Even if you don't feel the pain, use it and you will learn what things you do are expensive and it will keep trouble from sneaking up on you. * If you are using a SQL based store, use a driver that implements the interfaces in "database/sql" rather than providing its own interface. This will make your life very simple if you need to migrate between mySQL <-> Postgre, etc * LiteIDE is a nice lean cross platform Go IDE that includes syntax highlighing, autocomplete (with gocode) and debugging support. The only think I had to do was write my own syntax highlighting theme, based on Solarized, because I thought the included ones were gross.