4 ms·

well, this is probably not a good link in order to find why people like Go. But in general: - it's a simple language. pretty much as easy to use as languages l

by slx26 7y ago

well, this is probably not a good link in order to find why people like Go. But in general: - it's a simple language. pretty much as easy to use as languages like python or ruby. - decent performance (not the best, but pretty good for most use-cases (low-latency GC included)) - concurrency made simple (and the supported concurrency model is suitable for most use-cases) - typed (not the best, most expressive type system, but pretty good for most use-cases) - backed by a big company, mature enough for most use-cases so, it strikes a good balance between being painless and being useful.

michaelcampbell 7y ago
Not criticising, but I find it amusing that 2 things that people seem to point out about go; backed by a big company, and simple, are the same 2 things so many shit on Java for, for years. You didn't, but reading your post made me think of it.
- slx26 7y ago
  well, reflecting about it now I'm not so sure that the "big company" argument is that positive. when a language is just starting, having resources is extremely helpful, but in the long run it's indeed possible that the company becomes a liability to the community. about simplicity, while I wouldn't say Java is a complex language, and I might even agree that the language itself is easy, it's also quite verbose, and it doesn't feel as light to use as golang. I would personally mention two things (besides the verbosity of Java): 1) the OOP in Java kinda leads me to start designing around classes, and I feel I need a solid design/plan right from the start, while in golang I feel a bit more like I'm working with a scripting language, but the interfaces and the way the language works makes it quite easy to refactor code and move things as I need it, and in practice I end up with good organization and modular code precisely because it's very easy to move things around. just that frame of mind is a big change (though this is extremely subjective). 2) when I write Java I feel like I need an IDE. yeah, again partly because of the verbosity and boilerplate, but I also feel the environment is more complex. with golang I just write a "package main; func main() { some code }" and then run "go run myprogram.go". that makes the language feel really light and easy to use. I'm not afraid to try to write a demo program and run it even with my eyes closed. with Java I don't feel so much in direct control, and I regularly end up confused about random configurations and things. I don't try to argue that Java is significantly more complex as a language (the typical programming environment is quite different), but it still feels much heavier and complicated than golang. well, I'll stop here or I'll end up sounding like a fanboy (I wasn't a big fan of many of the golang design choices at the start)
tschellenbach 7y ago
Pretty close to the best performance though. So close that the difference doesn't matter for almost all apps. C and C++ are faster. Rust is maybe sometimes faster. Java is mostly slower. Python/Ruby you get a 20-40x faster performance on 1 goroutine. Much bigger gain if you do many things concurrently.
- kerkeslager 7y ago
  Is that from a performance benchmark, or is it from any of the ways where Python and Ruby are actually used? In processing large data sets, Fortran and Python are often used, and if you write similar code in Fortran and Python, you'll get much better performance in Fortran. But if you write Python using PANDAS, you can achieve comparable speeds, with much less developer effort because you're using a much higher-level language with more modern tools for all the glue, while calling out to highly-optimized loops for the heavy lifting. Similarly, for web scaling: the speed of Python isn't nearly as relevant, because you're running your Python in a WSGI web server that is written in highly-optimized C. And if your application is so specialized that a C-wrapper doesn't exist that handles the parts that need optimization, you can profile your Python code, and use the very good C integration to optimize the bottlenecks. Language choice based on performance is a premature optimization. I'm not espousing Python, either, necessarily: it's just a good example for this case because it's a slow language where its slowness doesn't really matter.
  - fjp 7y ago
    I love working in Python and I've seen this argument over and over. In real life if you find your performance bottleneck is some part of a Python library, chances are you're going to look around your company and not find someone that has the competence and time to fix your performance bottleneck by creating a usable and bug-free C implementation.
    - kerkeslager 7y ago
      > In real life if you find your performance bottleneck is some part of a Python library, chances are you're going to look around your company and not find someone that has the competence and time to fix your performance bottleneck by creating a usable and bug-free C implementation. Okay but: 1. How often do you find your performance bottleneck is some part of a Python library? My entire point is that modern Python development almost always delegates hotspots to pre-optimized libraries. 2. If your bottleneck is a use case that's unsolved so that there isn't a pre-existing library for it, it's probably unsolved because it's a difficult enough problem that using the C foreign-function interface is the least of your problems. It's also likely that you need a level of optimization which Go can't give you, so you're going to have to drop down to C/Fortran/assembly/whatever regardless of whether you're using Python or Go.

by slx26 7y ago

michaelcampbell 7y ago

Not criticising, but I find it amusing that 2 things that people seem to point out about go; backed by a big company, and simple, are the same 2 things so many shit on Java for, for years. You didn't, but reading your post made me think of it.

slx26 7y ago
well, reflecting about it now I'm not so sure that the "big company" argument is that positive. when a language is just starting, having resources is extremely helpful, but in the long run it's indeed possible that the company becomes a liability to the community. about simplicity, while I wouldn't say Java is a complex language, and I might even agree that the language itself is easy, it's also quite verbose, and it doesn't feel as light to use as golang. I would personally mention two things (besides the verbosity of Java): 1) the OOP in Java kinda leads me to start designing around classes, and I feel I need a solid design/plan right from the start, while in golang I feel a bit more like I'm working with a scripting language, but the interfaces and the way the language works makes it quite easy to refactor code and move things as I need it, and in practice I end up with good organization and modular code precisely because it's very easy to move things around. just that frame of mind is a big change (though this is extremely subjective). 2) when I write Java I feel like I need an IDE. yeah, again partly because of the verbosity and boilerplate, but I also feel the environment is more complex. with golang I just write a "package main; func main() { some code }" and then run "go run myprogram.go". that makes the language feel really light and easy to use. I'm not afraid to try to write a demo program and run it even with my eyes closed. with Java I don't feel so much in direct control, and I regularly end up confused about random configurations and things. I don't try to argue that Java is significantly more complex as a language (the typical programming environment is quite different), but it still feels much heavier and complicated than golang. well, I'll stop here or I'll end up sounding like a fanboy (I wasn't a big fan of many of the golang design choices at the start)

tschellenbach 7y ago

Pretty close to the best performance though. So close that the difference doesn't matter for almost all apps. C and C++ are faster. Rust is maybe sometimes faster. Java is mostly slower. Python/Ruby you get a 20-40x faster performance on 1 goroutine. Much bigger gain if you do many things concurrently.

kerkeslager 7y ago
Is that from a performance benchmark, or is it from any of the ways where Python and Ruby are actually used? In processing large data sets, Fortran and Python are often used, and if you write similar code in Fortran and Python, you'll get much better performance in Fortran. But if you write Python using PANDAS, you can achieve comparable speeds, with much less developer effort because you're using a much higher-level language with more modern tools for all the glue, while calling out to highly-optimized loops for the heavy lifting. Similarly, for web scaling: the speed of Python isn't nearly as relevant, because you're running your Python in a WSGI web server that is written in highly-optimized C. And if your application is so specialized that a C-wrapper doesn't exist that handles the parts that need optimization, you can profile your Python code, and use the very good C integration to optimize the bottlenecks. Language choice based on performance is a premature optimization. I'm not espousing Python, either, necessarily: it's just a good example for this case because it's a slow language where its slowness doesn't really matter.
- fjp 7y ago
  I love working in Python and I've seen this argument over and over. In real life if you find your performance bottleneck is some part of a Python library, chances are you're going to look around your company and not find someone that has the competence and time to fix your performance bottleneck by creating a usable and bug-free C implementation.
  - kerkeslager 7y ago
    > In real life if you find your performance bottleneck is some part of a Python library, chances are you're going to look around your company and not find someone that has the competence and time to fix your performance bottleneck by creating a usable and bug-free C implementation. Okay but: 1. How often do you find your performance bottleneck is some part of a Python library? My entire point is that modern Python development almost always delegates hotspots to pre-optimized libraries. 2. If your bottleneck is a use case that's unsolved so that there isn't a pre-existing library for it, it's probably unsolved because it's a difficult enough problem that using the C foreign-function interface is the least of your problems. It's also likely that you need a level of optimization which Go can't give you, so you're going to have to drop down to C/Fortran/assembly/whatever regardless of whether you're using Python or Go.