4 ms·

Well for that purpose we already have Rust/ Swift and so many other languages. What is Go's USP apart from fast compiler.

by geodel 7y ago

monocasa 7y ago
A GCed, statically typed language that's so stupid simple that when you have an army of PHDs writing glorified billing software and implementing UX experiments that have a coinflip's chance of increasing clickthrough rate by 0.1% (or doing nothing), they don't stave off the boredom by jerking off into the template engine or something like you see in other languages? So a language for Google, by Google.
- codr7 7y ago
  Go has its issues, name a language that doesn't. For a long time I couldn't stand using it because it's so damn opinionated, but it still hits a sweet spot for me. I like C a lot because of its simplicity, but hate spending days solving trivial problems. If you really need C, nothing else will do. But if you're willing to trade some flexibility for convenience, Go lets you make that compromise without dragging along a ton of features that you didn't ask for. It's a tool, if it works it works.
- tptacek 7y ago
  The overwhelming majority of Go code isn't written at Google, and just a glance at Github will show you that it isn't being used to "jerk off into template engines" or "increase clickthrough rate by 0.1%". This comment contributes nothing to the discussion.
  - monocasa 7y ago
    > The overwhelming majority of Go code isn't written at Google I write go for my day job; I'm quite aware of their process. They control the language's future and new features pretty much single handedly. Also, I'd be very very surprised to find out that the overwhelming majority of code isn't written by google, do you have a stat on that you can quote? > it isn't being used to"jerk off into template engines". I'm saying go doesn't do that. You can't build these crazy compile time abstractions in it like you can other languages, and Google doesn't really need it to because they have enough man power to just brute force it. It doesn't want their workforce build abstractions for abstractions sake, and go doesn't really help you do that. > or "increase clickthrough rate by 0.1%". It is very much used to do that, I've been told by product and engineering friends at google.
    - tptacek 7y ago
      I'm sure developers at Google use it to do that, because that is a problem that Google works on. It is not a problem that Cockroachdb works on, or that Docker works on, or that Hashicorp works on, or that Caddy works on, or that Tailscale works on.
- dang 7y ago
  Please don't degrade the community and yourself by posting like this, regardless of how strongly you feel about programming languages. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - monocasa 7y ago
    I'm not saying it's a bad thing.
    - dang 7y ago
      Ok, but it's a bad thing to post like that to HN.
Thaxll 7y ago
Swift is nowhere outside of mobile space, on server side it's pretty much dead.
eikenberry 7y ago
Native CSP? That's what got my initial interest. The tooling really helped it stick though.
jitl 7y ago
Swift and Rust both are known for long build times.
- pjmlp 7y ago
  Mostly caused by LLVM. Other equally expressive languages have multiple implementations, including REPLs, with Go like compilation speeds. So Swift and Rust just need equally LLVM fat free implementations for the developer loop, leaving the LLVM backend for the blazing execution release builds.
  - camgunz 7y ago
    LLVM isn't fast, but there are other slow parts of the process unique to Rust [1]. [1]: http://gistpreview.github.io/?74d799739504232991c49607d5ce748a http://gistpreview.github.io/?74d799739504232991c49607d5ce74...
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
sacado2 7y ago
Readability. I never ran into go code I couldn't read.

Well for that purpose we already have Rust/ Swift and so many other languages. What is Go's USP apart from fast compiler.

by geodel 7y ago

Well for that purpose we already have Rust/ Swift and so many other languages. What is Go's USP apart from fast compiler.

monocasa 7y ago

A GCed, statically typed language that's so stupid simple that when you have an army of PHDs writing glorified billing software and implementing UX experiments that have a coinflip's chance of increasing clickthrough rate by 0.1% (or doing nothing), they don't stave off the boredom by jerking off into the template engine or something like you see in other languages? So a language for Google, by Google.

codr7 7y ago
Go has its issues, name a language that doesn't. For a long time I couldn't stand using it because it's so damn opinionated, but it still hits a sweet spot for me. I like C a lot because of its simplicity, but hate spending days solving trivial problems. If you really need C, nothing else will do. But if you're willing to trade some flexibility for convenience, Go lets you make that compromise without dragging along a ton of features that you didn't ask for. It's a tool, if it works it works.
tptacek 7y ago
The overwhelming majority of Go code isn't written at Google, and just a glance at Github will show you that it isn't being used to "jerk off into template engines" or "increase clickthrough rate by 0.1%". This comment contributes nothing to the discussion.
- monocasa 7y ago
  > The overwhelming majority of Go code isn't written at Google I write go for my day job; I'm quite aware of their process. They control the language's future and new features pretty much single handedly. Also, I'd be very very surprised to find out that the overwhelming majority of code isn't written by google, do you have a stat on that you can quote? > it isn't being used to"jerk off into template engines". I'm saying go doesn't do that. You can't build these crazy compile time abstractions in it like you can other languages, and Google doesn't really need it to because they have enough man power to just brute force it. It doesn't want their workforce build abstractions for abstractions sake, and go doesn't really help you do that. > or "increase clickthrough rate by 0.1%". It is very much used to do that, I've been told by product and engineering friends at google.
  - tptacek 7y ago
    I'm sure developers at Google use it to do that, because that is a problem that Google works on. It is not a problem that Cockroachdb works on, or that Docker works on, or that Hashicorp works on, or that Caddy works on, or that Tailscale works on.
dang 7y ago
Please don't degrade the community and yourself by posting like this, regardless of how strongly you feel about programming languages. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- monocasa 7y ago
  I'm not saying it's a bad thing.
  - dang 7y ago
    Ok, but it's a bad thing to post like that to HN.

Thaxll 7y ago

Swift is nowhere outside of mobile space, on server side it's pretty much dead.

eikenberry 7y ago

Native CSP? That's what got my initial interest. The tooling really helped it stick though.

jitl 7y ago

Swift and Rust both are known for long build times.

pjmlp 7y ago
Mostly caused by LLVM. Other equally expressive languages have multiple implementations, including REPLs, with Go like compilation speeds. So Swift and Rust just need equally LLVM fat free implementations for the developer loop, leaving the LLVM backend for the blazing execution release builds.
- camgunz 7y ago
  LLVM isn't fast, but there are other slow parts of the process unique to Rust [1]. [1]: http://gistpreview.github.io/?74d799739504232991c49607d5ce748a http://gistpreview.github.io/?74d799739504232991c49607d5ce74...

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]

sacado2 7y ago

Readability. I never ran into go code I couldn't read.