5 ms·

> I would say that if the compiler got 100% slower, that would be a failure. Still a weird thing to care about. If the compiler were 100x slower, that would st

> I would say that if the compiler got 100% slower, that would be a failure. Still a weird thing to care about. If the compiler were 100x slower, that would still be faster than continually handling boilerplate with human brains.

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.
dvirsky 7y ago
Is it though? I work on a system that builds in singe to double digit minutes. The productivity loss from x2 slowing down of the compiler is going to be so painful compared to the gains I'll get by not copying some sorting functions etc.
com2kid 7y ago
Have you ever worked at a place where builds can take multiple days? If not, don't speak so hastily about compiler speed not being important. Slow compilations means work arounds like batching changes together for tests on commits, which means doing binary searches across commits to find out who broke the tests, or just reverting everyone's commit and telling people to resubmit and hope it goes through next time. Ever waited a week trying to get a single change committed because you kept getting batched with other people's broken code? Slow compilation times matter, a lot. C++ is the nightmare case scenario for this, I've seen templates that take 10 minutes to compile, and once a team gets sizable, build queues became a thing, and they slow development to a crawl. A 100x slower compiler has a huge impact on productivity. Copy and pasting code for those instances where you need to use template/generic programming is a huge win over waiting days for any and all changes to compile. FWIW typically in these situations local rebuilds are faster, from 10 - 30 minutes in my experience, but I've only had the pleasure of working on code bases of such size twice, so who knows how bad it can get.
- hinkley 7y ago
  The way I like to describe it from a systems or operations perspective is this: Slow (or flaky) build processes create gamblers. You don't want people gambling with prod. When it's expensive (time or attention) to verify your work, people start lying to themselves. They tell themselves they've done enough, or that red test or wrong data on the screen is "just a glitch", and you know they do this because when they get caught breaking stuff they will tell you the same thing they told themselves. The progression that works is this: You make the tool. You make the tool reliable. You make the tool straightforward. You make the tool cheap. You make the tool mandatory. People keep skipping step 4 and thinking rhetoric (even verbal abuse) will save them. If you meet idiots all day...
- davnicwil 7y ago
  What types of software and systems have you worked with that take on the order of days to compile?
  - com2kid 7y ago
safety-third 7y ago
Go's compile speed is its raison d'être. It straddles the line between convenient scripting languages and heavy compiled languages. You deal with boilerplate using either interfaces or code generation. It's not as pleasant as first-class generics, but it's not completely awful either.

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.

dvirsky 7y ago

Is it though? I work on a system that builds in singe to double digit minutes. The productivity loss from x2 slowing down of the compiler is going to be so painful compared to the gains I'll get by not copying some sorting functions etc.

com2kid 7y ago

Have you ever worked at a place where builds can take multiple days? If not, don't speak so hastily about compiler speed not being important. Slow compilations means work arounds like batching changes together for tests on commits, which means doing binary searches across commits to find out who broke the tests, or just reverting everyone's commit and telling people to resubmit and hope it goes through next time. Ever waited a week trying to get a single change committed because you kept getting batched with other people's broken code? Slow compilation times matter, a lot. C++ is the nightmare case scenario for this, I've seen templates that take 10 minutes to compile, and once a team gets sizable, build queues became a thing, and they slow development to a crawl. A 100x slower compiler has a huge impact on productivity. Copy and pasting code for those instances where you need to use template/generic programming is a huge win over waiting days for any and all changes to compile. FWIW typically in these situations local rebuilds are faster, from 10 - 30 minutes in my experience, but I've only had the pleasure of working on code bases of such size twice, so who knows how bad it can get.

hinkley 7y ago
The way I like to describe it from a systems or operations perspective is this: Slow (or flaky) build processes create gamblers. You don't want people gambling with prod. When it's expensive (time or attention) to verify your work, people start lying to themselves. They tell themselves they've done enough, or that red test or wrong data on the screen is "just a glitch", and you know they do this because when they get caught breaking stuff they will tell you the same thing they told themselves. The progression that works is this: You make the tool. You make the tool reliable. You make the tool straightforward. You make the tool cheap. You make the tool mandatory. People keep skipping step 4 and thinking rhetoric (even verbal abuse) will save them. If you meet idiots all day...
davnicwil 7y ago
What types of software and systems have you worked with that take on the order of days to compile?
- com2kid 7y ago

safety-third 7y ago

Go's compile speed is its raison d'être. It straddles the line between convenient scripting languages and heavy compiled languages. You deal with boilerplate using either interfaces or code generation. It's not as pleasant as first-class generics, but it's not completely awful either.