5 ms·

Productivity in Go is an illusion but I see the appeal of it for big enterprise teams composed of disposable programmers.

lossolo 11y ago
I am more productive in Go and C++ than in Rust. But for sure i am more productive in Rust than in C.
- deleted 11y ago
  [deleted]
- petra 11y ago
  What about memory safety? are c++ smart pointers equivalent to rust in safety ?
  - hobofan 11y ago
    Yes, but they are only checkable at runtime in C++.
    - kibwen 11y ago
      Only assuming that you never use references (or raw pointers), which depending on your needs may be unavoidable.
- kaoD 11y ago
  What's your mileage in Rust compared to C++? I found as soon as I got in the borrow-checker mindset I spent less and less time thinking about ownership and lifetimes to the point where I don't care anymore. I spend more time thinking about my program and its architecture (which I'd spend in any language) than thinking about Rust itself. What would you say are exactly the pain points of productivity for you when using Rust? My biggest gripes with Rust are macros (they're so useful but sooo hard at the same time compared to Lispy languages, where you don't have to fight the macro system as much due to their simpler syntax), compile times (which I hope will get better) and the fact that even at 1.x the the language and std still don't feel mature enough.
vardump 11y ago
So please tell us what is a productive language? At least any argument why Go is not productive, why its productivity is an illusion.
- pjmlp 11y ago
  > At least any argument why Go is not productive, why its productivity is an illusion. - generic code only via go generate and interface {} - verbose error handling - the way dependencies are handled - no language support for functional paradigms - nil pointer semantics in interfaces - very thin type system Go would be a great language in the mid-90's, nowadays given the features adopted in the mainstream it feels too little. For me, the positive thing is that it may lure developers that would use C to use Go instead, and in the process discover that their use case is perfectly doable with a memory safe language.
  - vardump 11y ago
    I've done one successful small/medium size TCP server project in Golang. Primarily programming in C++. - Generics were absolutely no issue. - Golang error handling may be verbose, but it also ensures errors locally visible and are handled where they occur. Just need to ensure all return values are handled. I much prefer it to C++, where you can never tell from local context what might throw and what won't. Generally I found it to be very productive compared to at least C++ and Java. Two aspects of Golang were a huge productivity boost for the project in question: struct automatic (de)serialization to JSON, XML, etc. was very nice. Goroutines and channels simplified the code.
kajecounterhack 11y ago
I see the appeal of it for big enterprise teams composed of disposable programmers Can you explain? Why are go programmers "disposable?" Is it because the code is understandable (especially following our style guide / enforcing gofmt, godoc, etc)? I do find our go code to be that way, but I don't think that's a bad thing. Productivity in Go is an illusion I feel productive in Go. Can you explain this statement? I like dealing with a simpler toolchain as the op mentioned.
- glennsl 11y ago
  I'm not the parent, but my impression is that Go is productive more in the sense of quantity than quality. It is easy to pick up, understand and use. But it is also very error prone, because its type system is poorly suited for proper error handling, nulls and generic code. It's certainly better than C and most dynamic languages, but that's not setting the bar very high. I really see no reason to pick up Go these days unless you're a fan of 80s retro hits. If you want most of the goodness of Rust combined with the easiness of Go, look to Kotlin and Swift.
  - catnaroek 11y ago
    > It is easy to pick up, understand and use. But it is also very error prone These two sentences are badly in conflict. How can you say you “understand” something if you find yourself repeatedly making mistakes when you use it?
    - glennsl 11y ago
      Compare a hammer and nails to a nailgun with various safety mechanisms. Which one do you think is easier to understand, and which is more prone to sore fingers?
      - catnaroek 11y ago
        > Which one do you think is easier to understand? For a toolmaker, the hammer. For a user, the nailgun. Also, there's a qualitative difference between physical tools and programming languages. The design of a physical tool can only lessen the likelihood of an accident and/or the seriousness of its consequences, but never entirely rule them out - that's why they're called “accidents”. On the other hand, programming languages can be designed to treat logical errors as invalid code. A program that doesn't compile is completely guaranteed not to corrupt your data, reveal your passwords to hackers, etc.

lossolo 11y ago

I am more productive in Go and C++ than in Rust. But for sure i am more productive in Rust than in C.

deleted 11y ago
[deleted]
petra 11y ago
What about memory safety? are c++ smart pointers equivalent to rust in safety ?
- hobofan 11y ago
  Yes, but they are only checkable at runtime in C++.
  - kibwen 11y ago
    Only assuming that you never use references (or raw pointers), which depending on your needs may be unavoidable.
kaoD 11y ago
What's your mileage in Rust compared to C++? I found as soon as I got in the borrow-checker mindset I spent less and less time thinking about ownership and lifetimes to the point where I don't care anymore. I spend more time thinking about my program and its architecture (which I'd spend in any language) than thinking about Rust itself. What would you say are exactly the pain points of productivity for you when using Rust? My biggest gripes with Rust are macros (they're so useful but sooo hard at the same time compared to Lispy languages, where you don't have to fight the macro system as much due to their simpler syntax), compile times (which I hope will get better) and the fact that even at 1.x the the language and std still don't feel mature enough.

vardump 11y ago

So please tell us what is a productive language? At least any argument why Go is not productive, why its productivity is an illusion.

pjmlp 11y ago
> At least any argument why Go is not productive, why its productivity is an illusion. - generic code only via go generate and interface {} - verbose error handling - the way dependencies are handled - no language support for functional paradigms - nil pointer semantics in interfaces - very thin type system Go would be a great language in the mid-90's, nowadays given the features adopted in the mainstream it feels too little. For me, the positive thing is that it may lure developers that would use C to use Go instead, and in the process discover that their use case is perfectly doable with a memory safe language.
- vardump 11y ago
  I've done one successful small/medium size TCP server project in Golang. Primarily programming in C++. - Generics were absolutely no issue. - Golang error handling may be verbose, but it also ensures errors locally visible and are handled where they occur. Just need to ensure all return values are handled. I much prefer it to C++, where you can never tell from local context what might throw and what won't. Generally I found it to be very productive compared to at least C++ and Java. Two aspects of Golang were a huge productivity boost for the project in question: struct automatic (de)serialization to JSON, XML, etc. was very nice. Goroutines and channels simplified the code.

kajecounterhack 11y ago

I see the appeal of it for big enterprise teams composed of disposable programmers Can you explain? Why are go programmers "disposable?" Is it because the code is understandable (especially following our style guide / enforcing gofmt, godoc, etc)? I do find our go code to be that way, but I don't think that's a bad thing. Productivity in Go is an illusion I feel productive in Go. Can you explain this statement? I like dealing with a simpler toolchain as the op mentioned.

glennsl 11y ago
I'm not the parent, but my impression is that Go is productive more in the sense of quantity than quality. It is easy to pick up, understand and use. But it is also very error prone, because its type system is poorly suited for proper error handling, nulls and generic code. It's certainly better than C and most dynamic languages, but that's not setting the bar very high. I really see no reason to pick up Go these days unless you're a fan of 80s retro hits. If you want most of the goodness of Rust combined with the easiness of Go, look to Kotlin and Swift.
- catnaroek 11y ago
  > It is easy to pick up, understand and use. But it is also very error prone These two sentences are badly in conflict. How can you say you “understand” something if you find yourself repeatedly making mistakes when you use it?
  - glennsl 11y ago
    Compare a hammer and nails to a nailgun with various safety mechanisms. Which one do you think is easier to understand, and which is more prone to sore fingers?
    - catnaroek 11y ago
      > Which one do you think is easier to understand? For a toolmaker, the hammer. For a user, the nailgun. Also, there's a qualitative difference between physical tools and programming languages. The design of a physical tool can only lessen the likelihood of an accident and/or the seriousness of its consequences, but never entirely rule them out - that's why they're called “accidents”. On the other hand, programming languages can be designed to treat logical errors as invalid code. A program that doesn't compile is completely guaranteed not to corrupt your data, reveal your passwords to hackers, etc.