4 ms·

Did that happen more than once?

littlestymaar 3y ago
That particular example of course no, but people writing overengineered beasts to overcome go's limitation happens all the time. Another famous example is how k8s, dealt with the lack of generics: https://medium.com/@arschles/go-experience-report-generics-in-kubernetes-25da87430301 https://medium.com/@arschles/go-experience-report-generics-i...
- lelanthran 3y ago
  > That particular example of course no, but people writing overengineered beasts to overcome go's limitation happens all the time. "happens"??? Yeah, it happened all the time, but for the last 14 months or so Go has had a serviceable implementation[1] of generics. So, sure, you could argue that projects used to implement hacky workarounds for generics, but that argument gets less relevant as time goes on. That argument is irrelevant to anyone starting a project today in Go. Probably also irrelevant to the type of microservices projects that I mostly see in Go, because any hack workaround can be replaced gradually by the language generics. [1] Unless you are referring to some deficiency of the generics implementation in Go that I am ignorant of.
  - littlestymaar 3y ago
    Generics is just one famous example, but go is so opinionated about everything, that there are countless others, from error handling to package management or concurrency primitives. It turns out that if you refuse to give the users things you think are heretical, the users will walk around your arbitrary limitations, and the result will just be worse for everyone.
    - lelanthran 3y ago
      > It turns out that if you refuse to give the users things you think are heretical, the users will walk around your arbitrary limitations, and the result will just be worse for everyone You are correct, no "but..." qualifier. It's a trade-off, and the language curators have to balance the frequncy of user's hacks against cognitive load for all users. You have to draw the line somewhere when adding language features and it is totally reasonable for a language that advertises itself as a low cognitive-load language to limit itself to a subset of features that useful for it's target users and ignore the rest of PL features. Just compare how awful it is in other languages to start an async routine and read it's results when it is complete, to go where you just read a channel you passed to the routine. That single thing alone shows that Go's creators want to deliver stuff to users who value producing solutions over language lawyering. Whatever you can do for almost all programs written in C++ or Rust will be more readable in Go with little noticeable performance degradation.
      - littlestymaar 3y ago
        > Just compare how awful it is in other languages to start an async routine and read it's results when it is complete Excuse me, what? “Starting an async routine and getting the result” in langages with async/await is just: // in JavaScript let result = await doSomething(); // or in Rust: let result = do_something().await; Please tell me how spawning a goroutine + a channel[1] is more convenient than this. Now start adding a timeout and a cancellation to you goroutine code and see how messy it gets, where it comes for free in Rust. [1] a necessarily bounded one, because Commander Pike said “f*ck you”.

That particular example of course no, but people writing overengineered beasts to overcome go's limitation happens all the time. Another famous example is how k8s, dealt with the lack of generics: https://medium.com/@arschles/go-experience-report-generics-in-kubernetes-25da87430301 https://medium.com/@arschles/go-experience-report-generics-i...

lelanthran 3y ago
> That particular example of course no, but people writing overengineered beasts to overcome go's limitation happens all the time. "happens"??? Yeah, it happened all the time, but for the last 14 months or so Go has had a serviceable implementation[1] of generics. So, sure, you could argue that projects used to implement hacky workarounds for generics, but that argument gets less relevant as time goes on. That argument is irrelevant to anyone starting a project today in Go. Probably also irrelevant to the type of microservices projects that I mostly see in Go, because any hack workaround can be replaced gradually by the language generics. [1] Unless you are referring to some deficiency of the generics implementation in Go that I am ignorant of.
- littlestymaar 3y ago
  Generics is just one famous example, but go is so opinionated about everything, that there are countless others, from error handling to package management or concurrency primitives. It turns out that if you refuse to give the users things you think are heretical, the users will walk around your arbitrary limitations, and the result will just be worse for everyone.
  - lelanthran 3y ago
    > It turns out that if you refuse to give the users things you think are heretical, the users will walk around your arbitrary limitations, and the result will just be worse for everyone You are correct, no "but..." qualifier. It's a trade-off, and the language curators have to balance the frequncy of user's hacks against cognitive load for all users. You have to draw the line somewhere when adding language features and it is totally reasonable for a language that advertises itself as a low cognitive-load language to limit itself to a subset of features that useful for it's target users and ignore the rest of PL features. Just compare how awful it is in other languages to start an async routine and read it's results when it is complete, to go where you just read a channel you passed to the routine. That single thing alone shows that Go's creators want to deliver stuff to users who value producing solutions over language lawyering. Whatever you can do for almost all programs written in C++ or Rust will be more readable in Go with little noticeable performance degradation.
    - littlestymaar 3y ago
      > Just compare how awful it is in other languages to start an async routine and read it's results when it is complete Excuse me, what? “Starting an async routine and getting the result” in langages with async/await is just: // in JavaScript let result = await doSomething(); // or in Rust: let result = do_something().await; Please tell me how spawning a goroutine + a channel[1] is more convenient than this. Now start adding a timeout and a cancellation to you goroutine code and see how messy it gets, where it comes for free in Rust. [1] a necessarily bounded one, because Commander Pike said “f*ck you”.