10 ms·

As someone with no skin in the game, it seems to me that the philosophical conundrum of Go is whether one needs to use a language designed to produce the kind o

As someone with no skin in the game, it seems to me that the philosophical conundrum of Go is whether one needs to use a language designed to produce the kind of code consistency it gives to Google-scale orgs or if you're better off working with a more "dangerous" or harder-to-read language which may create more technical debt but also allow you forge your own path as your devs prefer. I keep looking at languages like Go and frameworks like Angular as being steered for huge-org problems, but I wonder if startups are better off incurring the debt of riskier, less conservative languages and paradigms and worrying about the technical debt only once they've reached the scale where it a) actually matters to your agility in delivering customer value and b) you have the capital to make it worth solving the problem. Maybe this is reading too much into the generics kerfluffle, but I would love to be enlightened if anyone can clarify this further.

kasey_junk 9y ago
I don't have a strong opinion about your premise about large vs small orgs. But what I will say is that I largely dislike go as a language, yet I still usually pick it for solving problems even if they are just for myself. The reason for that is largely the 'come back to it' factor. I'm reasonably able to identify go code I wrote and put away. I can't say the same for other languages I've used professionally.
- stcredzero 9y ago
  If you have enough irons in the fire, all of those different versions of "you" might qualify as a "large org," depending on your definitions of "large" and "org."
gameswithgo 9y ago
My experience from a host of language experiments of late: ranging from F#, to Rust, to Nim, to C#, to Go, to C++ Is that it just doesn't matter very much. F# has very powerful generics, and there are particular circumstances where that saves me a lot of typing. But you can still get it done in C# with less powerful generics, or Go with none. F# has sum types, and replaces null with an option type - great ideas, but you can approximate these ideas in any language if you need to. Similarly, Nim's metaprogramming has let me do some really clever things, but again, it just saves some typing. I've found that language features and properties are often given more weight than they deserve. The really hard problems I've had when coding are just the actual problems. And while a particular language can be life-changing in particular problem domains, its rare that they are life changing in general. Go is maybe the language I think is least interesting of all of the ones I've played with but I currently prefer it over the others because 1. stable, mature language and tools (unlike nim) 2. fast compile times (unlike rust) 3. compiles to native executables F# might be my favorite if it had fast compile times and native compilation. Rust might be my favorite if I ever grok the borrow checker. But if someone said I had to use language X to do project Y I would almost always be fine with it, unless there were insurmountable performance problems caused by the language.
- seanwilson 9y ago
  > F# has sum types, and replaces null with an option type - great ideas, but you can approximate these ideas in any language if you need to. How? You can make up for it somewhat with linters, unit tests etc. but it's tiring and nowhere near as robust as a type checker that enforces null checks for you.
  - gameswithgo 9y ago
    oh I agree, and understand. You lose compile time enforced type safety against nulls when you approximate it, and I do think it is the right approach to use option types instead of null, and that more languages should do this. But it is just one parameter of a thousand affecting how easy it is to write good code, it sometimes has runtime costs.
- peterevans 9y ago
  Go is like the Six Million Dollar Man language, compared to C. It's everything C can do, but much better. Both C and Go are very, very simple languages; there aren't many keywords, and it's pretty easy to grok both at a functional level. It takes, of course, a bit to reach the second-level understanding you need to make full use of either language, but it's easy to hit the ground running in both. We sometimes get stuck on one language being better than others because it has X feature or Y concept, and I've seen some people essentially root for one language over another. But at the end of the day, languages are tools to get your work done, and on balance the work is going to be hard whichever route you go. Use the one that suits the talents you have available and that broadly complements the needs that you have.
  - gameswithgo 9y ago
    Yes it is definitely true that coming to a nearly-complete understand of Go is very very easy compared to Rust, F#, or Nim. I haven't used it with teams of people on any way yet but I imagine it makes it somewhat easier to drop into code that isn't yours and understand it. There are less ways to create voodoo. Which can be a pro or a con, depending!
  - 9y ago
geodel 9y ago
I have no advice to offer but for myself I wrote a project of few hundred LOC and it like a manageable version of Bash/Python/Perl etc. One benefit I see is it can be used on windows. mac, linux machines without any special setup , once I generate binary for specific platform. Since it is structured code, I keep adding more features without much breakage. I know people can do it so many other languages and ways. My point was that Go can be used for variety of person or single developer projects. It is more tuned towards making new/interesting things in boring language vs learning interesting language to reimplement existing things.
kylell 9y ago
that was my opinion too, I even thought what a stupid name Go, is another Google thing shoved down our throats, but then I worked with it and from node.js where you install a few packages and you see npm install saying 1201 packages installed, from java where you do a change and wait 30 seconds to recompile, just to see you got it wrong, and you get a huge stack trace and you need a huge frameworks for basic web stuff, from net core that I can't get it to work on mac for the love of good, I can't think of a better language at this moment, it allows me to go to machine language go without any VM or interpreter.
dilap 9y ago
for me what is great about Go is it removes BS and incidental complexity, & is just really well-designed and pleasant to work with. i happily choose it for personal projects. semi random, but for another example of someone enjoying the hell out of go for personal projects, take a look at: https://github.com/fogleman https://github.com/fogleman that guy's amazing, one of my programming heroes.
- adwhit 9y ago
  > for me what is great about Go is it removes BS and incidental complexity, & is just really well-designed and pleasant to work with. i happily choose it for personal projects. Go was the first compiled language I learned coming from Python and scientific computing. And I felt the same way and was so delighted to write fast native multithreaded code without ceremony. But then I learned some other languages that have elegant and powerful type systems (namely, Rust, OCaml and Haskell) and now I'm somewhat disgusted at my former self. Go could have been great, but it ain't. It's a blub language if ever there was one. I know my opinion on these things doesn't matter. But I feel resentful of Go, I feel like I was duped.
  - platinumrad 9y ago
    For me Go is a smooth brain C with an enormous standard library, making it very pleasant for weekend side projects or quick and dirty "scripting". Not having sum types is a huge pain sometimes and generics would be nice but otherwise I wouldn't want the language specification to change too much. Tail call optimization would also be nice but that's on the implementation side. In particular, I wouldn't want Go to become more restrictive like Rust or Haskell.
    - egeozcan 9y ago
      I wanted to use go for scripting but working with gopath weirdness made me hate my life and went back to nim (which is perfectly fine, I just still envy the go ecosystem).
      - 9y ago
mbertschler 9y ago
I made the experience that no matter what language you choose, and no matter the size of the problem you are trying to solve, after about a week of writing code you will have to start refactoring parts of it. While up to that point a more dynamic or "risky" language may have given me some advantage in development speed, it might make it harder to change things without breaking parts of your application by accident. Having a compiler that catches 80% of the errors you can make during big code changes already starts becoming a real advantage. I don't think that Go is a perfect language, but for most of my use cases it is the most efficient one overall.
msie 9y ago
One refreshing thing with a language w/o classes and inheritance is that you aren't worried about having the design make use of those features. That's one problem I had with C#. I was constantly redesigning my class hierarchy instead of getting things done.
- jrs95 9y ago
  A big benefit of using Go for me is that it influenced how I write Java. Keeping the use of class inheretince to a minimum (by using composition) and having interfaces for nearly everything makes for a much more flexible code base.
jrs95 9y ago
I sort of get the comparison, but my experience between Go and Angular has been completely different. Angular reminds me much more of something like Spring. Go on the other hand, while not particularly exciting or expressive, is mostly out of my way and lets me just get shit done. It’s a bit of an overused point now, but it’s boring in the best way possible. That’s pretty unique IMO and is a much different experience than you get from working with Angular.
confusedlambda 9y ago
I wouldn't classify it as large vs small. It's a better or worse fit depending on how the team writes software. Here is one example: Go has a simple syntax that rarely changes and has been backwards compatible since 1.0. It even has a built-in code formatter to keep things consistent. This means that you can write a service with the confidence that it will compile on the latest version of Go when you need to change it. Even if that is months or years later. Additionally, the dependencies for Go programs are stored on disk, relative to the project, in a simple hierarchy. I can't think of a single other language or package manager that makes it easier to vendor all your dependencies. And I do so for most Go projects I work on (I mostly use it for standalone services, not libraries). Here are the typical steps for reviving a project that I haven't touched for over year: git clone ... cd ... go test ./... This can be very useful for the some teams and utterly useless for other teams.
- merb 9y ago
  > vendor all your dependencies this has pro's and cons.
  - confusedlambda 9y ago
    Yep. Vendoring isn't "good" or "bad" in general, it's "appropriate" or "inappropriate" for a specific project.
- earenndil 9y ago
  > backwards compatability Eh, you get that with most languages, though.
- pdimitar 9y ago
  Elixir vendors dependencies as well by the way. It's very useful as you pointed out. Additionally, I agree with your points about Go.
randomdata 9y ago
Being currently involved in a startup using Go, I go back and forth with this in my mind on a regular basis. On one hand, development is much more arduous than I have experienced on other projects with more featureful languages. During development, I really find myself missing what those languages have to offer. But on the other hand, when the day is done and I look at what has been created, I'm really impressed with the quality of the project. A good team can write good software in any language, but I do believe this language has helped this team write better software than they might have in another language. I suppose that, like everything, there are tradeoffs. I'm not not yet sure which tradeoffs are most important to me.
- inlined 9y ago
  I typically summarize it as "go takes twice as long to write and half as long to debug. Since you spend a lot more time debugging code than writing new code, this is a good trade-off"
  - flavio81 9y ago
    No.
- ngrilly 9y ago
  What are you missing when programming in Go?
  - majewsky 9y ago
    .map() .filter() Not having to write useless type casting boilerplate like this: https://github.com/majewsky/sqlproxy/blob/f5b297e7dce14c045323881f272b97a3fdfb74c3/driver.go#L260-L266 https://github.com/majewsky/sqlproxy/blob/f5b297e7dce14c0453... Not having to write `if err != nil { return nil, err }` every second line. (Or, in other words, Rust's question-mark operator.)
  - randomdata 9y ago
    For me, an implicit way to convert between similar, but not identical, types. A real-world open source example I am aware of having a similar issue is Upspin[1]. There are ways to mitigate this, but you (well, I) cannot always control all the types third-party dependencies rely on. There is a clear path to working around this case, but I find it to be a bit tedious. I miss languages where, through generics, duck-typing, or similar that I can simply pass the application's structure to the third-party library and it "just works". [1] https://github.com/upspin/upspin/blob/master/upspin/proto/proto.go https://github.com/upspin/upspin/blob/master/upspin/proto/pr...
jksmith 9y ago
I'm suspecting (but can't back it up with empirics until I get a large team using golang), that because of the advance in popularity of golang and huge increase of golang codebases, the choice of golang is just as much a business decision as it is a programmer decision. If golang does prove to be a "get shit done" language, your VP is not going to be as concerned about what devs think if it can be used to get to market faster. Doesn't make any diff if it is goog or a 3 person shop. I can give you some counter-testimonial for .net when I ran a 50 dev project. Skillsets were all over the place, the architects wrote boilerplate the devs didn't understand, and the codebase was messy, thanks in due part to .net drawing commodity developers and Anders making sure csharp has 5 different ways to do everything. Lang history driven in large part by new features is turning out to be bad for business, IMO. I want something solid for my team that's easy to code, easy to test, and easy to consistently hire for. And I want them all to be SME's on the code they write for their domain. What that gets me is a lot of devs who will effort point stories about the same, no matter what team they are on. My gut tells me I can get to that state of bliss with something like golang faster than I can .net. Lot of mitigating factors built into that I get it, but that's what my gut tells me.

kasey_junk 9y ago

I don't have a strong opinion about your premise about large vs small orgs. But what I will say is that I largely dislike go as a language, yet I still usually pick it for solving problems even if they are just for myself. The reason for that is largely the 'come back to it' factor. I'm reasonably able to identify go code I wrote and put away. I can't say the same for other languages I've used professionally.

stcredzero 9y ago
If you have enough irons in the fire, all of those different versions of "you" might qualify as a "large org," depending on your definitions of "large" and "org."

gameswithgo 9y ago

My experience from a host of language experiments of late: ranging from F#, to Rust, to Nim, to C#, to Go, to C++ Is that it just doesn't matter very much. F# has very powerful generics, and there are particular circumstances where that saves me a lot of typing. But you can still get it done in C# with less powerful generics, or Go with none. F# has sum types, and replaces null with an option type - great ideas, but you can approximate these ideas in any language if you need to. Similarly, Nim's metaprogramming has let me do some really clever things, but again, it just saves some typing. I've found that language features and properties are often given more weight than they deserve. The really hard problems I've had when coding are just the actual problems. And while a particular language can be life-changing in particular problem domains, its rare that they are life changing in general. Go is maybe the language I think is least interesting of all of the ones I've played with but I currently prefer it over the others because 1. stable, mature language and tools (unlike nim) 2. fast compile times (unlike rust) 3. compiles to native executables F# might be my favorite if it had fast compile times and native compilation. Rust might be my favorite if I ever grok the borrow checker. But if someone said I had to use language X to do project Y I would almost always be fine with it, unless there were insurmountable performance problems caused by the language.

seanwilson 9y ago
> F# has sum types, and replaces null with an option type - great ideas, but you can approximate these ideas in any language if you need to. How? You can make up for it somewhat with linters, unit tests etc. but it's tiring and nowhere near as robust as a type checker that enforces null checks for you.
- gameswithgo 9y ago
  oh I agree, and understand. You lose compile time enforced type safety against nulls when you approximate it, and I do think it is the right approach to use option types instead of null, and that more languages should do this. But it is just one parameter of a thousand affecting how easy it is to write good code, it sometimes has runtime costs.
peterevans 9y ago
Go is like the Six Million Dollar Man language, compared to C. It's everything C can do, but much better. Both C and Go are very, very simple languages; there aren't many keywords, and it's pretty easy to grok both at a functional level. It takes, of course, a bit to reach the second-level understanding you need to make full use of either language, but it's easy to hit the ground running in both. We sometimes get stuck on one language being better than others because it has X feature or Y concept, and I've seen some people essentially root for one language over another. But at the end of the day, languages are tools to get your work done, and on balance the work is going to be hard whichever route you go. Use the one that suits the talents you have available and that broadly complements the needs that you have.
- gameswithgo 9y ago
  Yes it is definitely true that coming to a nearly-complete understand of Go is very very easy compared to Rust, F#, or Nim. I haven't used it with teams of people on any way yet but I imagine it makes it somewhat easier to drop into code that isn't yours and understand it. There are less ways to create voodoo. Which can be a pro or a con, depending!
- 9y ago

geodel 9y ago

I have no advice to offer but for myself I wrote a project of few hundred LOC and it like a manageable version of Bash/Python/Perl etc. One benefit I see is it can be used on windows. mac, linux machines without any special setup , once I generate binary for specific platform. Since it is structured code, I keep adding more features without much breakage. I know people can do it so many other languages and ways. My point was that Go can be used for variety of person or single developer projects. It is more tuned towards making new/interesting things in boring language vs learning interesting language to reimplement existing things.

kylell 9y ago

that was my opinion too, I even thought what a stupid name Go, is another Google thing shoved down our throats, but then I worked with it and from node.js where you install a few packages and you see npm install saying 1201 packages installed, from java where you do a change and wait 30 seconds to recompile, just to see you got it wrong, and you get a huge stack trace and you need a huge frameworks for basic web stuff, from net core that I can't get it to work on mac for the love of good, I can't think of a better language at this moment, it allows me to go to machine language go without any VM or interpreter.

dilap 9y ago

for me what is great about Go is it removes BS and incidental complexity, & is just really well-designed and pleasant to work with. i happily choose it for personal projects. semi random, but for another example of someone enjoying the hell out of go for personal projects, take a look at: https://github.com/fogleman https://github.com/fogleman that guy's amazing, one of my programming heroes.

adwhit 9y ago
> for me what is great about Go is it removes BS and incidental complexity, & is just really well-designed and pleasant to work with. i happily choose it for personal projects. Go was the first compiled language I learned coming from Python and scientific computing. And I felt the same way and was so delighted to write fast native multithreaded code without ceremony. But then I learned some other languages that have elegant and powerful type systems (namely, Rust, OCaml and Haskell) and now I'm somewhat disgusted at my former self. Go could have been great, but it ain't. It's a blub language if ever there was one. I know my opinion on these things doesn't matter. But I feel resentful of Go, I feel like I was duped.
- platinumrad 9y ago
  For me Go is a smooth brain C with an enormous standard library, making it very pleasant for weekend side projects or quick and dirty "scripting". Not having sum types is a huge pain sometimes and generics would be nice but otherwise I wouldn't want the language specification to change too much. Tail call optimization would also be nice but that's on the implementation side. In particular, I wouldn't want Go to become more restrictive like Rust or Haskell.
  - egeozcan 9y ago
    I wanted to use go for scripting but working with gopath weirdness made me hate my life and went back to nim (which is perfectly fine, I just still envy the go ecosystem).
    - 9y ago

mbertschler 9y ago

I made the experience that no matter what language you choose, and no matter the size of the problem you are trying to solve, after about a week of writing code you will have to start refactoring parts of it. While up to that point a more dynamic or "risky" language may have given me some advantage in development speed, it might make it harder to change things without breaking parts of your application by accident. Having a compiler that catches 80% of the errors you can make during big code changes already starts becoming a real advantage. I don't think that Go is a perfect language, but for most of my use cases it is the most efficient one overall.

msie 9y ago

One refreshing thing with a language w/o classes and inheritance is that you aren't worried about having the design make use of those features. That's one problem I had with C#. I was constantly redesigning my class hierarchy instead of getting things done.

jrs95 9y ago
A big benefit of using Go for me is that it influenced how I write Java. Keeping the use of class inheretince to a minimum (by using composition) and having interfaces for nearly everything makes for a much more flexible code base.

jrs95 9y ago

I sort of get the comparison, but my experience between Go and Angular has been completely different. Angular reminds me much more of something like Spring. Go on the other hand, while not particularly exciting or expressive, is mostly out of my way and lets me just get shit done. It’s a bit of an overused point now, but it’s boring in the best way possible. That’s pretty unique IMO and is a much different experience than you get from working with Angular.

confusedlambda 9y ago

I wouldn't classify it as large vs small. It's a better or worse fit depending on how the team writes software. Here is one example: Go has a simple syntax that rarely changes and has been backwards compatible since 1.0. It even has a built-in code formatter to keep things consistent. This means that you can write a service with the confidence that it will compile on the latest version of Go when you need to change it. Even if that is months or years later. Additionally, the dependencies for Go programs are stored on disk, relative to the project, in a simple hierarchy. I can't think of a single other language or package manager that makes it easier to vendor all your dependencies. And I do so for most Go projects I work on (I mostly use it for standalone services, not libraries). Here are the typical steps for reviving a project that I haven't touched for over year: git clone ... cd ... go test ./... This can be very useful for the some teams and utterly useless for other teams.

merb 9y ago
> vendor all your dependencies this has pro's and cons.
- confusedlambda 9y ago
  Yep. Vendoring isn't "good" or "bad" in general, it's "appropriate" or "inappropriate" for a specific project.
earenndil 9y ago
> backwards compatability Eh, you get that with most languages, though.
pdimitar 9y ago
Elixir vendors dependencies as well by the way. It's very useful as you pointed out. Additionally, I agree with your points about Go.

randomdata 9y ago

Being currently involved in a startup using Go, I go back and forth with this in my mind on a regular basis. On one hand, development is much more arduous than I have experienced on other projects with more featureful languages. During development, I really find myself missing what those languages have to offer. But on the other hand, when the day is done and I look at what has been created, I'm really impressed with the quality of the project. A good team can write good software in any language, but I do believe this language has helped this team write better software than they might have in another language. I suppose that, like everything, there are tradeoffs. I'm not not yet sure which tradeoffs are most important to me.

inlined 9y ago
I typically summarize it as "go takes twice as long to write and half as long to debug. Since you spend a lot more time debugging code than writing new code, this is a good trade-off"
- flavio81 9y ago
  No.
ngrilly 9y ago
What are you missing when programming in Go?
- majewsky 9y ago
  .map() .filter() Not having to write useless type casting boilerplate like this: https://github.com/majewsky/sqlproxy/blob/f5b297e7dce14c045323881f272b97a3fdfb74c3/driver.go#L260-L266 https://github.com/majewsky/sqlproxy/blob/f5b297e7dce14c0453... Not having to write `if err != nil { return nil, err }` every second line. (Or, in other words, Rust's question-mark operator.)
- randomdata 9y ago
  For me, an implicit way to convert between similar, but not identical, types. A real-world open source example I am aware of having a similar issue is Upspin[1]. There are ways to mitigate this, but you (well, I) cannot always control all the types third-party dependencies rely on. There is a clear path to working around this case, but I find it to be a bit tedious. I miss languages where, through generics, duck-typing, or similar that I can simply pass the application's structure to the third-party library and it "just works". [1] https://github.com/upspin/upspin/blob/master/upspin/proto/proto.go https://github.com/upspin/upspin/blob/master/upspin/proto/pr...

jksmith 9y ago

I'm suspecting (but can't back it up with empirics until I get a large team using golang), that because of the advance in popularity of golang and huge increase of golang codebases, the choice of golang is just as much a business decision as it is a programmer decision. If golang does prove to be a "get shit done" language, your VP is not going to be as concerned about what devs think if it can be used to get to market faster. Doesn't make any diff if it is goog or a 3 person shop. I can give you some counter-testimonial for .net when I ran a 50 dev project. Skillsets were all over the place, the architects wrote boilerplate the devs didn't understand, and the codebase was messy, thanks in due part to .net drawing commodity developers and Anders making sure csharp has 5 different ways to do everything. Lang history driven in large part by new features is turning out to be bad for business, IMO. I want something solid for my team that's easy to code, easy to test, and easy to consistently hire for. And I want them all to be SME's on the code they write for their domain. What that gets me is a lot of devs who will effort point stories about the same, no matter what team they are on. My gut tells me I can get to that state of bliss with something like golang faster than I can .net. Lot of mitigating factors built into that I get it, but that's what my gut tells me.