9 ms·

Care to elaborate?

bruhlollol 6y ago
It ignores some historical bad design decisions, the worst of them being having null in the language, the famous one billion dollar mistake. And well, no support for functional/immutable data structures is something I dislike. My squad did a micro-service in Go at work and was not pleasant as we expected.
- colesantiago 6y ago
  what language do you suggest instead of go?
  - bruhlollol 6y ago
    Rust is a better choice
    - colesantiago 6y ago
      Please expand more on why Rust "is a better choice"? I'm still not convinced by this statement.
    - panta 6y ago
      For what? Usually absolutes are not very useful...
    - isatty 6y ago
      It depends on _for what_. The most important part of these discussions often leaves out this important part. I use go as a python replacement for the most part and it’s brilliant at it. Types, compiled, good collection of external libraries and easy to read. For most of my scripting or mini projects I’m not willing to use C++ and by the same thought, I’m not willing to use rust either.
    - vips7L 6y ago
      While I am no fan of Go, Rust is not a better alternative for most use cases of the average Go program. A better alternative would more likely be Java/Kotlin/Scala/C#. All with proper generics, good standard libraries/ecosystems, and fast run times.
      - LandR 6y ago
        What if you need to compile to native? Some places don't accept having to have a VM like .NET or Java installed to run.
        jbreckmckye 6y ago
        Also GC is a real no-no for real-time.
        nobleach 6y ago
        Go has a GC. Specifying the need for manual memory-management might be moving the goal-posts a bit. Edit Phone auto-correct from memory management to measurement.
        erik_seaberg 6y ago
        To be fair, it's possible to write code that does no heap allocation in each of these languages. None of them guard against mistakes that create GC work, and Java would not be my choice for this.
        jbreckmckye 6y ago
        True. I've even had the "interesting" experience of writing low-allocation JavaScript (for 3D mostly).
        tfigment 6y ago
        .Net Core compiles to native and can be packaged to not need common runtime installed. And targets linux. You can even have it create a single file executable though admittedly it unpacks to temp folder at runtime if you do this. Down side is everything is like 80 MB minimum if you do this.
  - zxcvbn4038 6y ago
    If you feed the trolls they just make more. ;) https://www.indiatoday.in/trending-news/story/coronavirus-monkeys-from-rival-gangs-fight-over-food-in-thailand-viral-video-1655094-2020-03-13 https://www.indiatoday.in/trending-news/story/coronavirus-mo... https://www.japantimes.co.jp/news/2020/06/24/asia-pacific/thailand-town-monkeys/#.X0OtzPdq2aM https://www.japantimes.co.jp/news/2020/06/24/asia-pacific/th... https://nypost.com/2019/11/20/why-this-monkey-with-a-human-face-cant-get-laid/ https://nypost.com/2019/11/20/why-this-monkey-with-a-human-f... https://www.chinadaily.com.cn/china/2016-06/17/content_25742392.htm https://www.chinadaily.com.cn/china/2016-06/17/content_25742...
- Cthulhu_ 6y ago
  Null is only a thing for pointers, in a lot of cases you can use value types where they use a sane "zero" value for everything by default. But did you really create a new troll account to go and represent the Rust Evangelism Squad? I mean if you really want to discuss the merits of Rust vs Go, at least have the decency to do a writeup that doesn't repeat the same - known - issues with Go.
  - bruhlollol 6y ago
    I am not evangelist. Go error handling and pointers could be type safe, that's my real disappointment with it. I like its simplicity, but having a sane zero value for "almost everything" doesn't solve the problem.
- Insanity 6y ago
  Mh, so you wrote one micro-service and came to that conclusion? What did you do to learn the language beforehand? For what it's worth, I've been programming with Go professionally for a few years, and I do agree with the "null" issue. Although in practice - with a good development culture - it's less of a problem than you might think initially. We tend to avoid using pointers (because, they're not even faster than structs in _many_ instances. They don't work like pointers in C/C++). By avoiding pointers you also avoid `nil` being a thing. but if not having nil is a strict requirement I'll pick another language like Haskell instead. Pick the right tool for the job yada yada
  - jbreckmckye 6y ago
    > so you wrote one micro-service and came to that conclusion? To be fair, that's a lot more empiricism than some teams use.
  - throwaway894345 6y ago
    I'm a big fan of ML-like type systems, but I never understand why Go gets so much more grief than Python, JS, etc for having nil. At least in Go, only reference types can be nil as opposed to literally any variable. Same with conversation about generics: "How can anyone write software in a language without [type-safe] generics?" of course lots of profitable software is written in languages with no type safety whatsoever and that doesn't seem to bother people.
    - AnimalMuppet 6y ago
      I think that it doesn't bother people when a non-type-safe language isn't type safe. If you reach for Python, you know what you're getting. But when a type-safe language is type-safe-except-for-X, that bothers people who wanted a type-safe language. And it's one thing if the except-for-X is "except for conversions", like casts in C, C++, and Java. Non-type-safe generics aren't usually a place where you are deliberately bypassing the type safety; they're a place where you'd like to have the type safety you have everywhere else in the language.
      - 6y ago
hombre_fatal 6y ago
Do we really need to entertain throwaway accounts created just for the boring "lang {good,bad}!" interjection? If you want to see it, there are so many places we have that discussion. And that discussion can be found so many times online. Look at any Go version release on HN if you want to find more. Even making a top-level comment like "Can anyone explain some quick pros/cons of $lang?" would go farther than these interjections where we need to prod them with twenty questions just to help them flesh out their own point of view. That's what's annoying about it.
- xcbl 6y ago
  99.99% of the boring $lang_is_superior "discussions" is by people without throwaway accounts. These people are also often more aggressive and indoctrinated.
  - hombre_fatal 6y ago
    There is no shortage of Go users, like myself, that can admit to the downsides of it. That's why there's always the same debates about things like sum types and generics and interface{} and null pointer errors in every Go thread. And even in the recent submission where Go implements provisional generics, we go on to point out the downsides of it, like how you're still stuck with null pointers to represent sum types (like an imagined Result<T> impl). And it's pretty good discussion. I mean, the throwaway accounts so far aren't exactly raising the bar of discussion here. So far it's extremely elementary. Is this the discussion you think we're missing out on without throwaway accounts? Maybe if we keep prodding you/them for more info, they'll flesh out a novel point? Time to shit or get off the pot.
    - akeiHH 6y ago
      > Time to shit or get off the pot. Thank you for demonstrating how regular users improve the level of discussion.
- dang 6y ago
  Obviously the root comment was lame and should not have been fed, but please don't take the thread further off topic.
dang 6y ago
The HN guidelines include a version of please don't feed the trolls. It goes like this: "Don't feed egregious comments by replying; flag them instead." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

Care to elaborate?

It ignores some historical bad design decisions, the worst of them being having null in the language, the famous one billion dollar mistake. And well, no support for functional/immutable data structures is something I dislike. My squad did a micro-service in Go at work and was not pleasant as we expected.

colesantiago 6y ago
what language do you suggest instead of go?
- bruhlollol 6y ago
  Rust is a better choice
  - colesantiago 6y ago
    Please expand more on why Rust "is a better choice"? I'm still not convinced by this statement.
  - panta 6y ago
    For what? Usually absolutes are not very useful...
  - isatty 6y ago
    It depends on _for what_. The most important part of these discussions often leaves out this important part. I use go as a python replacement for the most part and it’s brilliant at it. Types, compiled, good collection of external libraries and easy to read. For most of my scripting or mini projects I’m not willing to use C++ and by the same thought, I’m not willing to use rust either.
  - vips7L 6y ago
    While I am no fan of Go, Rust is not a better alternative for most use cases of the average Go program. A better alternative would more likely be Java/Kotlin/Scala/C#. All with proper generics, good standard libraries/ecosystems, and fast run times.
    - LandR 6y ago
      What if you need to compile to native? Some places don't accept having to have a VM like .NET or Java installed to run.
      - jbreckmckye 6y ago
        Also GC is a real no-no for real-time.
        nobleach 6y ago
        Go has a GC. Specifying the need for manual memory-management might be moving the goal-posts a bit. Edit Phone auto-correct from memory management to measurement.
        erik_seaberg 6y ago
        To be fair, it's possible to write code that does no heap allocation in each of these languages. None of them guard against mistakes that create GC work, and Java would not be my choice for this.
        jbreckmckye 6y ago
        True. I've even had the "interesting" experience of writing low-allocation JavaScript (for 3D mostly).
      - tfigment 6y ago
        .Net Core compiles to native and can be packaged to not need common runtime installed. And targets linux. You can even have it create a single file executable though admittedly it unpacks to temp folder at runtime if you do this. Down side is everything is like 80 MB minimum if you do this.
- zxcvbn4038 6y ago
  If you feed the trolls they just make more. ;) https://www.indiatoday.in/trending-news/story/coronavirus-monkeys-from-rival-gangs-fight-over-food-in-thailand-viral-video-1655094-2020-03-13 https://www.indiatoday.in/trending-news/story/coronavirus-mo... https://www.japantimes.co.jp/news/2020/06/24/asia-pacific/thailand-town-monkeys/#.X0OtzPdq2aM https://www.japantimes.co.jp/news/2020/06/24/asia-pacific/th... https://nypost.com/2019/11/20/why-this-monkey-with-a-human-face-cant-get-laid/ https://nypost.com/2019/11/20/why-this-monkey-with-a-human-f... https://www.chinadaily.com.cn/china/2016-06/17/content_25742392.htm https://www.chinadaily.com.cn/china/2016-06/17/content_25742...
Cthulhu_ 6y ago
Null is only a thing for pointers, in a lot of cases you can use value types where they use a sane "zero" value for everything by default. But did you really create a new troll account to go and represent the Rust Evangelism Squad? I mean if you really want to discuss the merits of Rust vs Go, at least have the decency to do a writeup that doesn't repeat the same - known - issues with Go.
- bruhlollol 6y ago
  I am not evangelist. Go error handling and pointers could be type safe, that's my real disappointment with it. I like its simplicity, but having a sane zero value for "almost everything" doesn't solve the problem.
Insanity 6y ago
Mh, so you wrote one micro-service and came to that conclusion? What did you do to learn the language beforehand? For what it's worth, I've been programming with Go professionally for a few years, and I do agree with the "null" issue. Although in practice - with a good development culture - it's less of a problem than you might think initially. We tend to avoid using pointers (because, they're not even faster than structs in _many_ instances. They don't work like pointers in C/C++). By avoiding pointers you also avoid `nil` being a thing. but if not having nil is a strict requirement I'll pick another language like Haskell instead. Pick the right tool for the job yada yada
- jbreckmckye 6y ago
  > so you wrote one micro-service and came to that conclusion? To be fair, that's a lot more empiricism than some teams use.
- throwaway894345 6y ago
  I'm a big fan of ML-like type systems, but I never understand why Go gets so much more grief than Python, JS, etc for having nil. At least in Go, only reference types can be nil as opposed to literally any variable. Same with conversation about generics: "How can anyone write software in a language without [type-safe] generics?" of course lots of profitable software is written in languages with no type safety whatsoever and that doesn't seem to bother people.
  - AnimalMuppet 6y ago
    I think that it doesn't bother people when a non-type-safe language isn't type safe. If you reach for Python, you know what you're getting. But when a type-safe language is type-safe-except-for-X, that bothers people who wanted a type-safe language. And it's one thing if the except-for-X is "except for conversions", like casts in C, C++, and Java. Non-type-safe generics aren't usually a place where you are deliberately bypassing the type safety; they're a place where you'd like to have the type safety you have everywhere else in the language.
    - 6y ago

hombre_fatal 6y ago

Do we really need to entertain throwaway accounts created just for the boring "lang {good,bad}!" interjection? If you want to see it, there are so many places we have that discussion. And that discussion can be found so many times online. Look at any Go version release on HN if you want to find more. Even making a top-level comment like "Can anyone explain some quick pros/cons of $lang?" would go farther than these interjections where we need to prod them with twenty questions just to help them flesh out their own point of view. That's what's annoying about it.

xcbl 6y ago
99.99% of the boring $lang_is_superior "discussions" is by people without throwaway accounts. These people are also often more aggressive and indoctrinated.
- hombre_fatal 6y ago
  There is no shortage of Go users, like myself, that can admit to the downsides of it. That's why there's always the same debates about things like sum types and generics and interface{} and null pointer errors in every Go thread. And even in the recent submission where Go implements provisional generics, we go on to point out the downsides of it, like how you're still stuck with null pointers to represent sum types (like an imagined Result<T> impl). And it's pretty good discussion. I mean, the throwaway accounts so far aren't exactly raising the bar of discussion here. So far it's extremely elementary. Is this the discussion you think we're missing out on without throwaway accounts? Maybe if we keep prodding you/them for more info, they'll flesh out a novel point? Time to shit or get off the pot.
  - akeiHH 6y ago
    > Time to shit or get off the pot. Thank you for demonstrating how regular users improve the level of discussion.
dang 6y ago
Obviously the root comment was lame and should not have been fed, but please don't take the thread further off topic.

dang 6y ago

The HN guidelines include a version of please don't feed the trolls. It goes like this: "Don't feed egregious comments by replying; flag them instead." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html