5 ms·

We moved a huge chunk of our code from Python to Go. We have one simple Go binary that just listens on a certain port and API requests from our Django app are p

We moved a huge chunk of our code from Python to Go. We have one simple Go binary that just listens on a certain port and API requests from our Django app are proxied to the Go instance running. No issues, no panics, no memory leaks. It's pretty amazing to see a long running process never growing in memory (well, if you're coming from the Python world at least, I'm sure the JVM is pretty solid at keeping it's place nice & tidy). Folks - Go ain't a fad, it's a great language if your problem domain benefits from concurrency AND if you need to deploy to multiple locations and love being able to just drop a single binary and walk away.

kamaal 13y ago
How good is Go, as a replacement for Java?
- beatgammit 13y ago
  What do you mean "replacement for Java"? It's a completely different language: * no classes (only structs and embedding) * no VM, only a run-time (cross-compiling is trivial though) * hardly anything is an object * no exceptions * concurrent by design It's quite possibly the most distant language from Java in the procedural world, which I think is a good thing. It forces you to rethink your data and their interactions. I think Go is a great language and works in most of the spaces where Java lives, except maybe GUIs, but Java was never any good at that anyway. It's more suited for the server, but it can work well for computationally-intensive tasks as well. Go is better thought of as a replacement for whatever server stack you have than a replacement for a given language.
  - swah 13y ago
    But the runtime performance is probably closer to Java than Python...
    - beatgammit 13y ago
      Well, yeah, because Go is compiled, not interpreted. It's GC isn't as optimized as Java's, but for straight computational speed, it's pretty comparable to other compiled languages. It just isn't a drop-in replacement for Java because it doesn't live in the same space. It does, however, have a similar feel as Python, especially with slices (except Go's don't copy data) and first-order functions. It's a completely different feel though than Python.
  - jebblue 13y ago
    >> I think Go is a great language and works in most of the spaces where Java lives, except maybe GUIs, but Java was never any good at that anyway. Eclipse is the world's most popular IDE it's written in Java, Minecraft one of the most popular Indie games ever made was written in Java. What gives you the impression that Java isn't good for GUI's? It's great for GUIs and it's cross platform from the start.
    - deleted 13y ago
      [deleted]
    - msbarnett 13y ago
      If Eclipse is evidence that Java is good at GUIs, I shudder to think what the output of something bad at them must be like to use. edit: to give you a constructive response: Eclipse is an excellent illustration of how godawful Java is at GUIs. It chugs horribly on even high end hardware because of Java's interminable GC pauses getting in the way of interactive response times. It looks native nowhere, and somehow contrives to feel even more alien than it looks. It manifests platform dependent UI bugs, completely defeating every last shred of its claimed "write a GUI once, deploy it anywhere" advantages.
    - eridius 13y ago
      If you want to make the argument that Java is good for GUI's, feel free, but you just picked the two worst examples I could possibly think of. As a Mac user, the UI for Eclipse is such a huge turn-off that it soured me on Java as a whole (back before I really knew anything about Java; today, there's plenty of other stuff to dislike besides the GUI toolkit). And Minecraft? That's not a UI, that's an OpenGL game. Nothing about the custom OpenGL-based UI it presents to users says anything about Java, or has any bearing on other Java apps you might write.
      - jebblue 13y ago
        Ok, you have a good point. I'll instead list Open Office and LibreOffice and Symphony and Lotus Notes. Those are hugely complex GUI's and work as good as or better than anything proprietary out there in the same class pf products.
  - pjmlp 13y ago
    > * no VM, only a run-time (cross-compiling is trivial though) There are native code compilers available for Java. > * concurrent by design Java was there first
    - bjeanes 13y ago
      "concurrent by design" != "can be concurrent / has threads"
      - pjmlp 13y ago
        Not all Java implementations map language threads to OS threads. The implementations that use green threads are no different than go-routines, which were seen for the first time in Modula-2 just as information.
        bjeanes 13y ago
        What I was implying is that "built for concurrency" isn't just about threads (or goroutines). It's about communication between concurrent routines and shared state. Go is designed to have less coordination in concurrency by encouraging communication via channels instead of shared state.
- 0xdeadbeefbabe 13y ago
  The real downside of go is that it didn't exist when Java arrived. It would have made a much better intro to CS language than Java. Then Android wouldn't have decided to use Java because so many new programmers used it in school.
  - pkulak 13y ago
    I don't think Go could have existed in 1996. It feels like a reaction to Java, in some sense. And even if it was built, exactly as it is now, in 1996, it probably would have gone no where. "It doesn't even have object inheritance! And what do we need all these concurrency things for? Windows has only had preemptive multitasking for a year, and multi-core is still a decade away."
    - malodyets 13y ago
      Your second paragraph quotes a fictitious someone in 1996, right?
      - pkulak 13y ago
        Haha, yes, thanks. I added quotes.
    - pjmlp 13y ago
      Oberon and Oberon-2 were available in 1991, which Go takes the method syntax and package concepts from. GC enabled system programming languages, which failed most likely due to the Pascal syntax.
    - 0xdeadbeefbabe 13y ago
      Yeah not enough Object for 96, but still it feels like an old language to me.
    - wtbob 13y ago
      Well, Limbo existed in 1995, but it got nowhere…
  - 13y ago
- swah 13y ago
  IOW, How reusable do you feel the stuff you write in Go is?

kamaal 13y ago

How good is Go, as a replacement for Java?

beatgammit 13y ago
What do you mean "replacement for Java"? It's a completely different language: * no classes (only structs and embedding) * no VM, only a run-time (cross-compiling is trivial though) * hardly anything is an object * no exceptions * concurrent by design It's quite possibly the most distant language from Java in the procedural world, which I think is a good thing. It forces you to rethink your data and their interactions. I think Go is a great language and works in most of the spaces where Java lives, except maybe GUIs, but Java was never any good at that anyway. It's more suited for the server, but it can work well for computationally-intensive tasks as well. Go is better thought of as a replacement for whatever server stack you have than a replacement for a given language.
- swah 13y ago
  But the runtime performance is probably closer to Java than Python...
  - beatgammit 13y ago
    Well, yeah, because Go is compiled, not interpreted. It's GC isn't as optimized as Java's, but for straight computational speed, it's pretty comparable to other compiled languages. It just isn't a drop-in replacement for Java because it doesn't live in the same space. It does, however, have a similar feel as Python, especially with slices (except Go's don't copy data) and first-order functions. It's a completely different feel though than Python.
- jebblue 13y ago
  >> I think Go is a great language and works in most of the spaces where Java lives, except maybe GUIs, but Java was never any good at that anyway. Eclipse is the world's most popular IDE it's written in Java, Minecraft one of the most popular Indie games ever made was written in Java. What gives you the impression that Java isn't good for GUI's? It's great for GUIs and it's cross platform from the start.
  - deleted 13y ago
    [deleted]
  - msbarnett 13y ago
    If Eclipse is evidence that Java is good at GUIs, I shudder to think what the output of something bad at them must be like to use. edit: to give you a constructive response: Eclipse is an excellent illustration of how godawful Java is at GUIs. It chugs horribly on even high end hardware because of Java's interminable GC pauses getting in the way of interactive response times. It looks native nowhere, and somehow contrives to feel even more alien than it looks. It manifests platform dependent UI bugs, completely defeating every last shred of its claimed "write a GUI once, deploy it anywhere" advantages.
  - eridius 13y ago
    If you want to make the argument that Java is good for GUI's, feel free, but you just picked the two worst examples I could possibly think of. As a Mac user, the UI for Eclipse is such a huge turn-off that it soured me on Java as a whole (back before I really knew anything about Java; today, there's plenty of other stuff to dislike besides the GUI toolkit). And Minecraft? That's not a UI, that's an OpenGL game. Nothing about the custom OpenGL-based UI it presents to users says anything about Java, or has any bearing on other Java apps you might write.
    - jebblue 13y ago
      Ok, you have a good point. I'll instead list Open Office and LibreOffice and Symphony and Lotus Notes. Those are hugely complex GUI's and work as good as or better than anything proprietary out there in the same class pf products.
- pjmlp 13y ago
  > * no VM, only a run-time (cross-compiling is trivial though) There are native code compilers available for Java. > * concurrent by design Java was there first
  - bjeanes 13y ago
    "concurrent by design" != "can be concurrent / has threads"
    - pjmlp 13y ago
      Not all Java implementations map language threads to OS threads. The implementations that use green threads are no different than go-routines, which were seen for the first time in Modula-2 just as information.
      - bjeanes 13y ago
        What I was implying is that "built for concurrency" isn't just about threads (or goroutines). It's about communication between concurrent routines and shared state. Go is designed to have less coordination in concurrency by encouraging communication via channels instead of shared state.
0xdeadbeefbabe 13y ago
The real downside of go is that it didn't exist when Java arrived. It would have made a much better intro to CS language than Java. Then Android wouldn't have decided to use Java because so many new programmers used it in school.
- pkulak 13y ago
  I don't think Go could have existed in 1996. It feels like a reaction to Java, in some sense. And even if it was built, exactly as it is now, in 1996, it probably would have gone no where. "It doesn't even have object inheritance! And what do we need all these concurrency things for? Windows has only had preemptive multitasking for a year, and multi-core is still a decade away."
  - malodyets 13y ago
    Your second paragraph quotes a fictitious someone in 1996, right?
    - pkulak 13y ago
      Haha, yes, thanks. I added quotes.
  - pjmlp 13y ago
    Oberon and Oberon-2 were available in 1991, which Go takes the method syntax and package concepts from. GC enabled system programming languages, which failed most likely due to the Pascal syntax.
  - 0xdeadbeefbabe 13y ago
    Yeah not enough Object for 96, but still it feels like an old language to me.
  - wtbob 13y ago
    Well, Limbo existed in 1995, but it got nowhere…
- 13y ago
swah 13y ago
IOW, How reusable do you feel the stuff you write in Go is?