7 ms·

Not to sound arrogant. However I think Go (golang) is still in the hype wagon / cargo cult phase. It's popular as in the "popular latest javascript UI/UX" sens

Not to sound arrogant. However I think Go (golang) is still in the hype wagon / cargo cult phase. It's popular as in the "popular latest javascript UI/UX" sense. Not to diminish Go _extraordinary_ achievements, however it's still to early to say. E.g. Ruby - used to be _mega_ popular, everything was Ruby at some point. Hype is over and it doesn't look too promising. Niche is taken and it stays there.

duaneb 10y ago
> Not to sound arrogant. However I think Go (golang) is still in the hype wagon / cargo cult phase. Well, you came off sounding kind of arrogant. I'm not sure what this has to do with the discussion. There are many valid uses of java that can be done in go, regardless of its popularity. There are many valid uses of java that can not be replicated in go, regardless of its popularity. You can swap out that criticism with pretty much any language built in or after the 90s and it's still just as valid. I mean, feel free to critique—it could very well be at its peak popularity and cannot take ANY MORE java marketshare—but this still requires argument.
- deleted 10y ago
  [deleted]
cyphar 10y ago
> Not to sound arrogant. However I think Go (golang) is still in the hype wagon / cargo cult phase. I'm not going to comment on the "hype" point, since your probably right. I just wanted to mention that I found out the other day that the Go garbage collector doesn't free memory. So your process will never shrink in memory usage (on Linux it uses MADV_DONTNEED and on BSD&Solaris it used MADV_FREE -- which means that essentially the page of memory becomes an overcommitted page that doesn't exist anymore). But that still won't stop your kernel from killing it. > It's popular as in the "popular latest javascript UI/UX" sense. Not to diminish Go _extraordinary_ achievements, however it's still to early to say. > E.g. Ruby - used to be _mega_ popular, everything was Ruby at some point. Hype is over and it doesn't look too promising. Niche is taken and it stays there.
- jakub_h 10y ago
  > So your process will never shrink in memory usage But it should at least stop growing (unless my understanding about non-moving GCs is off, which it could be).
  - cyphar 10y ago
    > > So your process will never shrink in memory usage > But it should at least stop growing (unless my understanding about non-moving GCs is off, which it could be). As long as there isn't a bug in the GC :P. I'm currently debugging a Docker problem that looks like a bug in the GC, I'm not sure.
- Atom4966 10y ago
  > I just wanted to mention that I found out the other day that the Go garbage collector doesn't free memory. If you mean `free` as it's used in `C`, then I guess technically, it doesn't `free` memory, but I fail to see the practical difference between that and how it it releases memory back to the OS - which is does. > So your process will never shrink in memory usage I think you've been mislead. This statement is observably false.
  - cyphar 10y ago
    > > I just wanted to mention that I found out the other day that the Go garbage collector doesn't free memory. > If you mean `free` as it's used in `C`, then I guess technically, it doesn't `free` memory, but I fail to see the practical difference between that and how it it releases memory back to the OS - which is does. Misusing memory overcommitment doesn't count as "freeing" memory. Sure, it happens to mean that the kernel frees the page and provides a new one in its place (which is a Linux-ism and isn't explicitly stated in the man page). MADV_DONTNEED has several quite big issues (it's worse than munmap in almost every category since it has to do an munmap immediately and then create a new page as well). The point is that the process still will get killed if overcommit_ratio is a sane value. > > So your process will never shrink in memory usage > I think you've been mislead. This statement is observably false. Depends how you want to define "memory usage". I defined it implicitly as "sum of size of all mappings given to the process". In other words, how much is committed to the process. That number doesn't go down. RSS does go down, but I'm currently investigating what looks like Go not reusing "unused" pages properly.

duaneb 10y ago

> Not to sound arrogant. However I think Go (golang) is still in the hype wagon / cargo cult phase. Well, you came off sounding kind of arrogant. I'm not sure what this has to do with the discussion. There are many valid uses of java that can be done in go, regardless of its popularity. There are many valid uses of java that can not be replicated in go, regardless of its popularity. You can swap out that criticism with pretty much any language built in or after the 90s and it's still just as valid. I mean, feel free to critique—it could very well be at its peak popularity and cannot take ANY MORE java marketshare—but this still requires argument.

deleted 10y ago
[deleted]

cyphar 10y ago

> Not to sound arrogant. However I think Go (golang) is still in the hype wagon / cargo cult phase. I'm not going to comment on the "hype" point, since your probably right. I just wanted to mention that I found out the other day that the Go garbage collector doesn't free memory. So your process will never shrink in memory usage (on Linux it uses MADV_DONTNEED and on BSD&Solaris it used MADV_FREE -- which means that essentially the page of memory becomes an overcommitted page that doesn't exist anymore). But that still won't stop your kernel from killing it. > It's popular as in the "popular latest javascript UI/UX" sense. Not to diminish Go _extraordinary_ achievements, however it's still to early to say. > E.g. Ruby - used to be _mega_ popular, everything was Ruby at some point. Hype is over and it doesn't look too promising. Niche is taken and it stays there.

jakub_h 10y ago
> So your process will never shrink in memory usage But it should at least stop growing (unless my understanding about non-moving GCs is off, which it could be).
- cyphar 10y ago
  > > So your process will never shrink in memory usage > But it should at least stop growing (unless my understanding about non-moving GCs is off, which it could be). As long as there isn't a bug in the GC :P. I'm currently debugging a Docker problem that looks like a bug in the GC, I'm not sure.
Atom4966 10y ago
> I just wanted to mention that I found out the other day that the Go garbage collector doesn't free memory. If you mean `free` as it's used in `C`, then I guess technically, it doesn't `free` memory, but I fail to see the practical difference between that and how it it releases memory back to the OS - which is does. > So your process will never shrink in memory usage I think you've been mislead. This statement is observably false.
- cyphar 10y ago
  > > I just wanted to mention that I found out the other day that the Go garbage collector doesn't free memory. > If you mean `free` as it's used in `C`, then I guess technically, it doesn't `free` memory, but I fail to see the practical difference between that and how it it releases memory back to the OS - which is does. Misusing memory overcommitment doesn't count as "freeing" memory. Sure, it happens to mean that the kernel frees the page and provides a new one in its place (which is a Linux-ism and isn't explicitly stated in the man page). MADV_DONTNEED has several quite big issues (it's worse than munmap in almost every category since it has to do an munmap immediately and then create a new page as well). The point is that the process still will get killed if overcommit_ratio is a sane value. > > So your process will never shrink in memory usage > I think you've been mislead. This statement is observably false. Depends how you want to define "memory usage". I defined it implicitly as "sum of size of all mappings given to the process". In other words, how much is committed to the process. That number doesn't go down. RSS does go down, but I'm currently investigating what looks like Go not reusing "unused" pages properly.