4 ms·

i'm forced to work in Kotlin vs. Go sometimes at my job and I agree 100%, go is the best. Just a few items: 1) if thing vs if (thing) kotlin makes you add un-n

i'm forced to work in Kotlin vs. Go sometimes at my job and I agree 100%, go is the best. Just a few items: 1) if thing vs if (thing) kotlin makes you add un-needed () 2) a string is always "" vs null! 3) you can follow the logic always 100% of the time vs. getting lost in a maze of clever kotlin.

entire-name 5y ago
Isn't item (3) more of a policy thing rather than a language thing? Granted, I actually never coded in Kotlin (and very very little in Go), so if it's "encouraged" in Kotlin, then your point (3) makes sense.
- isbvhodnvemrwvn 5y ago
  I've worked with systems where some of the things were defined as a DSL within Kotlin (with implicit receivers and a shitton of extension functions), so you can definitely shoot yourself in the foot.
  - iudqnolq 5y ago
    I think it's ameliorated by being designed by an IDE developer, so all that magic has control+click to go to definition. I've debugged some hairy nested implicit receiver code with jetpack compose pointer events, and found it very easy to read exactly what was executed. I'm a beginner though, and kotlin was the first language where it occurred to me I could just read the source of a library.
- dangoor 5y ago
  This is actually one of our reasons for choosing Go! We recognized that we'd have to come up with a fairly detailed style guide for Kotlin to reflect how we wanted to generally approach things so that it's possible to jump into another part of the codebase and not get lost.
- lima 5y ago
  Yes and no - that this kind of policy is hard to enforce, and only affects your code base. The nice thing about Go is that its simplicity permeates the entire ecosystem.
newnamenewface 5y ago
I feel like go by itself is very nice but dependency management across inter-opping projects really sucks. I feel like an idiot every time I run into dependency versioning issues and have to spend half a day figuring out what mixture of versions of each dependency to set. Any advice?
- andrewfromx 5y ago
  i don't think dependency management is great in any language. Maybe cargo and rust win at that? But I happen to know go's well at this point. Ruby is terrible! And don't even get me started on node.js. But recently I got a go build error and had to just put in printlns: https://andrewarrow.substack.com/p/installing-go-from-source-to-debug https://andrewarrow.substack.com/p/installing-go-from-source...
  - house9-2 5y ago
    > i don't think dependency management is great in any language. Ruby is terrible! If you use bundler and Gemfile.lock everything 'just works' in Ruby. Node/npm/yarn is a nightmare
gher-shyu3i 5y ago
> you can follow the logic always 100% of the time You can see the bare bones if conditions and for loops sure, but what are they actually trying to do? golang code is very thin - it takes a lot to write to convey a particular piece of logic. What a few lines of map/filter/accumulate/group by in a more expressive language like Java or Kotlin becomes dozens of lines in golang. It becomes challenging to extract the underlying logic and to follow it. Java and Kotlin are strictly superior.
kubb 5y ago
You might have missed the part of the article where they describe the weaknesses of Go that they've discovered while porting their Python code, but they downplay them to make the whole thing sound more like a success.
- LanceH 5y ago
  It's getting the job done, it's faster, and the developers are happy. It sounds like a success because it is.
  - DangitBobby 5y ago
    The developers say positive things after having spent months on this effort. It's just as likely a psychological defense mechanism against melancholy as it is an actual optimism for the new Eldritch Horror that's been unleashed on them. Especially if they weren't given a choice on what language they would be using. > Our engineers come from a variety of programming backgrounds, so we certainly do have a diversity of opinion on Go vs. other languages. That said, Go is doing the job we “hired” it to do when we started Goliath, and we’re thankful for the team driving its continued evolution and the community that has built up around it! If you were calling a reference for a potential new hire, would you consider this a glowing review?
    - LanceH 5y ago
      > If you were calling a reference for a potential new hire, would you consider this a glowing review? Ships code on time, on spec, performance exceeding expectations. Sure.
      - DangitBobby 5y ago
        Only one of those was actually said. The article is not a glowing review of go. The carefully chosen snippets of text conspicuously say nothing about how the engineers, at the end of the day, like using the language.
jniedrauer 5y ago
> 2) a string is always "" vs null! This is really just semantics, because nullable strings do exist in go: *string. The difference is you pay a surprisingly severe performance penalty for them.
unscaled 5y ago
String in Kotlin can never be null. String? (with a question mark) can. Kotlin String == Go string Kotlin's String? == Go *string They're fully equivalent in this regard. If you wanted to note where Go strings are actually superior to Kotlin strings I'd give: 1. Go strings are slices. For immutable data that's pretty cool. I like it less when it comes to mutable arrays. 2. Go strings are single-byte UTF8, instead of wide-char UTF16. That's strictly superior. Both of these limitations are probably due to the JVM, not Kotlin itself.

entire-name 5y ago

Isn't item (3) more of a policy thing rather than a language thing? Granted, I actually never coded in Kotlin (and very very little in Go), so if it's "encouraged" in Kotlin, then your point (3) makes sense.

isbvhodnvemrwvn 5y ago
I've worked with systems where some of the things were defined as a DSL within Kotlin (with implicit receivers and a shitton of extension functions), so you can definitely shoot yourself in the foot.
- iudqnolq 5y ago
  I think it's ameliorated by being designed by an IDE developer, so all that magic has control+click to go to definition. I've debugged some hairy nested implicit receiver code with jetpack compose pointer events, and found it very easy to read exactly what was executed. I'm a beginner though, and kotlin was the first language where it occurred to me I could just read the source of a library.
dangoor 5y ago
This is actually one of our reasons for choosing Go! We recognized that we'd have to come up with a fairly detailed style guide for Kotlin to reflect how we wanted to generally approach things so that it's possible to jump into another part of the codebase and not get lost.
lima 5y ago
Yes and no - that this kind of policy is hard to enforce, and only affects your code base. The nice thing about Go is that its simplicity permeates the entire ecosystem.

newnamenewface 5y ago

I feel like go by itself is very nice but dependency management across inter-opping projects really sucks. I feel like an idiot every time I run into dependency versioning issues and have to spend half a day figuring out what mixture of versions of each dependency to set. Any advice?

andrewfromx 5y ago
i don't think dependency management is great in any language. Maybe cargo and rust win at that? But I happen to know go's well at this point. Ruby is terrible! And don't even get me started on node.js. But recently I got a go build error and had to just put in printlns: https://andrewarrow.substack.com/p/installing-go-from-source-to-debug https://andrewarrow.substack.com/p/installing-go-from-source...
- house9-2 5y ago
  > i don't think dependency management is great in any language. Ruby is terrible! If you use bundler and Gemfile.lock everything 'just works' in Ruby. Node/npm/yarn is a nightmare

gher-shyu3i 5y ago

> you can follow the logic always 100% of the time You can see the bare bones if conditions and for loops sure, but what are they actually trying to do? golang code is very thin - it takes a lot to write to convey a particular piece of logic. What a few lines of map/filter/accumulate/group by in a more expressive language like Java or Kotlin becomes dozens of lines in golang. It becomes challenging to extract the underlying logic and to follow it. Java and Kotlin are strictly superior.

kubb 5y ago

You might have missed the part of the article where they describe the weaknesses of Go that they've discovered while porting their Python code, but they downplay them to make the whole thing sound more like a success.

LanceH 5y ago
It's getting the job done, it's faster, and the developers are happy. It sounds like a success because it is.
- DangitBobby 5y ago
  The developers say positive things after having spent months on this effort. It's just as likely a psychological defense mechanism against melancholy as it is an actual optimism for the new Eldritch Horror that's been unleashed on them. Especially if they weren't given a choice on what language they would be using. > Our engineers come from a variety of programming backgrounds, so we certainly do have a diversity of opinion on Go vs. other languages. That said, Go is doing the job we “hired” it to do when we started Goliath, and we’re thankful for the team driving its continued evolution and the community that has built up around it! If you were calling a reference for a potential new hire, would you consider this a glowing review?
  - LanceH 5y ago
    > If you were calling a reference for a potential new hire, would you consider this a glowing review? Ships code on time, on spec, performance exceeding expectations. Sure.
    - DangitBobby 5y ago
      Only one of those was actually said. The article is not a glowing review of go. The carefully chosen snippets of text conspicuously say nothing about how the engineers, at the end of the day, like using the language.

jniedrauer 5y ago

> 2) a string is always "" vs null! This is really just semantics, because nullable strings do exist in go: *string. The difference is you pay a surprisingly severe performance penalty for them.

unscaled 5y ago

String in Kotlin can never be null. String? (with a question mark) can. Kotlin String == Go string Kotlin's String? == Go *string They're fully equivalent in this regard. If you wanted to note where Go strings are actually superior to Kotlin strings I'd give: 1. Go strings are slices. For immutable data that's pretty cool. I like it less when it comes to mutable arrays. 2. Go strings are single-byte UTF8, instead of wide-char UTF16. That's strictly superior. Both of these limitations are probably due to the JVM, not Kotlin itself.