3 ms·

This is a terrible take. It's like one of those people who buys a massive over priced knife block with 48 knives in it that they never use. Most go devs have

This is a terrible take. It's like one of those people who buys a massive over priced knife block with 48 knives in it that they never use. Most go devs have lived through bloated java/php/python/ruby/js projects that become a pile of dependencies. Go is to coding what brutalism is to architecture. Simple, functional, efficient. Dont build a massive dependency chain, dont build magic, repeating yourself is OK. Be an adult and deal with your errors (it's a feature)... That minimalist no bullshit language semantics that force you not to be lazy is a feature not a bug.

2024throwaway 3y ago
I'm not sure why you included php in your list of examples of things that become bloated with dependencies. I've never seen that be the case.
- sleepybrett 3y ago
  [flagged]
  - 2024throwaway 3y ago
    I just opened the composer.json file for a complex PHP application, it has 20 imports, total. I just opened the package.json for a react frontend, it has 80 imports. I just opened the Gemfile for a complex rails application, it has 150+ imports. But sure, I'm just trolling I guess.
    - deleted 3y ago
      [deleted]
- nasretdinov 3y ago
  Look at your list of built-in modules though :)
  - 2024throwaway 3y ago
    So stdlib counts as dependencies now?
    - nasretdinov 3y ago
      Well stdlib normally doesn't have stuff like Oracle drivers and such. I think one of the reasons why PHP tends to need so few external dependencies is because it has so many extensions to cover basically anything that you don't need PHP libraries all that much. I don't personally see it as a bad thing but it's something worth considering.
pjmlp 3y ago
If Rust was already matured by the time Docker was rewriten from Python, and Kubernetes from Java, I bet that Go wouldn't have been the lucky candidate.
- zer00eyz 3y ago
  I like rust, I write go. There was a thread here the other day where a rust dev pointed out that "Rust is the language tokio ate"... https://nullderef.com/blog/rust-async-sync/ https://nullderef.com/blog/rust-async-sync/ Rust is a lot of overhead when go is "good enough" for 99% of what needs to get done. That doesn't mean go is good for everything. I would still rather write Rust than C or C++ or bunch of other languages. Look at a project like Pingora, from cloud flair. Perfect Rust project, bad Go project. Rust is in the kernel, rust is what im looking at for a USB driver. I would not shove go in either of these places.
  - pjmlp 3y ago
    Go could have been like Modula-3, D or C#, instead they decided to revamp Oberon and Limbo, the version 1.0 of those languages from the 1990's, not what was latter done from their learnings, e.g. Active Oberon. Now thanks to Docker and Kubernetes adoption success, we're stuck with it. At least now generics are supported, unless one needs gccgo, maybe in 10 years we get Pascal enumerations.
    - zer00eyz 3y ago
      It whooshed right past your head. Go is stone cold simple to pick up. ITs simple to reason about. I can decompose a project and spoon feed it to a JR engineer and they can get through it. Rust is none of those things. Its great for low level stuff, it is in the kernel right next to C and go will NEVER be there. Why, because that is what rust is good at. > At least now generics are supported, unless one needs gccgo, maybe in 10 years we get Pascal enumerations. Again I like rust. Crates being colored (as in functions), the shitty compile and tests times... these are things that are holding back rusts adoption in more places... None of this stuff is on the road map to get fixed, it's quite the glass house you have. Go is going to replace a fair bit of python/ruby in the next few years... Is it going to be rust or zig that eats into c/c++? If the rust community keeps on the way it has been, zig will eat all the core apps we depend on.
wrs 3y ago
I don’t think any of that is contradicted by what this seems to be trying to do. In fact, Go doesn’t make you deal with your errors (you’re free to ignore the returns) whereas this would (via exhaustive pattern match).
- zer00eyz 3y ago
  > In fact, Go doesn’t make you deal with your errors Your right, it does not. I will _ =: an error in a throw away script all the time. I see that in a code review, in production code... Big red flag. This is a departure from an exception, that might be thrown in one place and handled far far away from the code you're looking at.
  - strongly-typed 3y ago
    I'm not an expert in Go, and my experience is somewhat limited, however, a few years back I fixed a really subtle bug in a project that was related to the fact that errors _weren't_ being handled correctly. As a relative newbie to Go, the code in the diff[0] didn't appear to be doing anything wrong, until I added some print statements and realized that the numbers were not adding up correctly. IMO, if the returned value had been more like a Rust optional or result type, I think this issue would have either not been a bug in the first place, or it would have been easier to spot the bug. [0]: https://github.com/semilin/genkey/commit/fafed6744555c5a81fd2c6f218091cc746150c05 https://github.com/semilin/genkey/commit/fafed6744555c5a81fd... EDIT: The fact that this was a bug at all makes me fear for the rest of the code base. If this one slipped through the cracks, how can I know that the rest of the code base is correct?
    - randomdata 3y ago
      > The fact that this was a bug at all makes me fear for the rest of the code base. The fact that the commit was accepted into a release without any changes to accompanying tests is what is most concerning. You should be afraid.
    - nasretdinov 3y ago
      Is the wrong code in the new part of the diff or in the old one? Generally getting zero value from a map is a feature, but the code that the diff replaces did look overly complex and fragile to me already tbh

2024throwaway 3y ago

I'm not sure why you included php in your list of examples of things that become bloated with dependencies. I've never seen that be the case.

sleepybrett 3y ago
[flagged]
- 2024throwaway 3y ago
  I just opened the composer.json file for a complex PHP application, it has 20 imports, total. I just opened the package.json for a react frontend, it has 80 imports. I just opened the Gemfile for a complex rails application, it has 150+ imports. But sure, I'm just trolling I guess.
  - deleted 3y ago
    [deleted]
nasretdinov 3y ago
Look at your list of built-in modules though :)
- 2024throwaway 3y ago
  So stdlib counts as dependencies now?
  - nasretdinov 3y ago
    Well stdlib normally doesn't have stuff like Oracle drivers and such. I think one of the reasons why PHP tends to need so few external dependencies is because it has so many extensions to cover basically anything that you don't need PHP libraries all that much. I don't personally see it as a bad thing but it's something worth considering.

pjmlp 3y ago

If Rust was already matured by the time Docker was rewriten from Python, and Kubernetes from Java, I bet that Go wouldn't have been the lucky candidate.

zer00eyz 3y ago
I like rust, I write go. There was a thread here the other day where a rust dev pointed out that "Rust is the language tokio ate"... https://nullderef.com/blog/rust-async-sync/ https://nullderef.com/blog/rust-async-sync/ Rust is a lot of overhead when go is "good enough" for 99% of what needs to get done. That doesn't mean go is good for everything. I would still rather write Rust than C or C++ or bunch of other languages. Look at a project like Pingora, from cloud flair. Perfect Rust project, bad Go project. Rust is in the kernel, rust is what im looking at for a USB driver. I would not shove go in either of these places.
- pjmlp 3y ago
  Go could have been like Modula-3, D or C#, instead they decided to revamp Oberon and Limbo, the version 1.0 of those languages from the 1990's, not what was latter done from their learnings, e.g. Active Oberon. Now thanks to Docker and Kubernetes adoption success, we're stuck with it. At least now generics are supported, unless one needs gccgo, maybe in 10 years we get Pascal enumerations.
  - zer00eyz 3y ago
    It whooshed right past your head. Go is stone cold simple to pick up. ITs simple to reason about. I can decompose a project and spoon feed it to a JR engineer and they can get through it. Rust is none of those things. Its great for low level stuff, it is in the kernel right next to C and go will NEVER be there. Why, because that is what rust is good at. > At least now generics are supported, unless one needs gccgo, maybe in 10 years we get Pascal enumerations. Again I like rust. Crates being colored (as in functions), the shitty compile and tests times... these are things that are holding back rusts adoption in more places... None of this stuff is on the road map to get fixed, it's quite the glass house you have. Go is going to replace a fair bit of python/ruby in the next few years... Is it going to be rust or zig that eats into c/c++? If the rust community keeps on the way it has been, zig will eat all the core apps we depend on.

wrs 3y ago

I don’t think any of that is contradicted by what this seems to be trying to do. In fact, Go doesn’t make you deal with your errors (you’re free to ignore the returns) whereas this would (via exhaustive pattern match).

zer00eyz 3y ago
> In fact, Go doesn’t make you deal with your errors Your right, it does not. I will _ =: an error in a throw away script all the time. I see that in a code review, in production code... Big red flag. This is a departure from an exception, that might be thrown in one place and handled far far away from the code you're looking at.
- strongly-typed 3y ago
  I'm not an expert in Go, and my experience is somewhat limited, however, a few years back I fixed a really subtle bug in a project that was related to the fact that errors _weren't_ being handled correctly. As a relative newbie to Go, the code in the diff[0] didn't appear to be doing anything wrong, until I added some print statements and realized that the numbers were not adding up correctly. IMO, if the returned value had been more like a Rust optional or result type, I think this issue would have either not been a bug in the first place, or it would have been easier to spot the bug. [0]: https://github.com/semilin/genkey/commit/fafed6744555c5a81fd2c6f218091cc746150c05 https://github.com/semilin/genkey/commit/fafed6744555c5a81fd... EDIT: The fact that this was a bug at all makes me fear for the rest of the code base. If this one slipped through the cracks, how can I know that the rest of the code base is correct?
  - randomdata 3y ago
    > The fact that this was a bug at all makes me fear for the rest of the code base. The fact that the commit was accepted into a release without any changes to accompanying tests is what is most concerning. You should be afraid.
  - nasretdinov 3y ago
    Is the wrong code in the new part of the diff or in the old one? Generally getting zero value from a map is a feature, but the code that the diff replaces did look overly complex and fragile to me already tbh