| I've been meaning to ask someone that. If you switch from java to go, is it really such an improvement in non-trivial cases ? In Go, you'll be doing the C thing : you'll be reimplementing every datastructure from scratch (or use void, also known as interface{}), and have the same memory allocation problems as java. The problem with that is obvious : only experienced C library authors stand any chance of getting complicated trees right the first time (and I still only seen one person get red-black trees insert right first time once*, 3 other university professors and several assistants failed). And the fact that you need to write those things from scratch everytime means you've got to debug that extremely finicky and difficult code every single time ... and then a junior programmer comes in and says "hey I can get to the internal fields easy, why don't I just" and you're in for an 8 hour debugging session because that causes a crash in the normal insert code, not the actually wrong code. One thing I did in go that really, really bugged me was sorting a list (sorting a list of strings). I was making it as short as I possibly could without violating style rules ... 70 lines of code. That's ... well that's just not reasonable. ArrayList<String> x = Lists.newArrayList("b", "c", "d", "a");
Collections.sort(x);
System.out.println(x); Give me the Go equivalent, in less than 50 lines of code. Please. That just has got to have a short solution, right ? As it stands, I believe Go is good at being a fast conduit for nearly-ready data. A way to write asynchronous servers. If you need complicated algorithms or quick ways to change data operations ... maybe I'm wrong but it just looks like Go is really not going to be your friend. |