5 ms·

Disclaimer: I am totally newbie in Go. But quite experienced in Java and Js/Ts. I never jumped the Go bandwagon because of the lack of generics. Can I now try

• selljamhere 5y ago
  > Also I wonder whether the language has a IDE support as good as IntelliJ with Java (safe function extraction, type-safe autocomplete) Jet Brains makes GoLand, which is about as good as they come. It should feel familiar if you're used to IntelliJ. https://www.jetbrains.com/go/ https://www.jetbrains.com/go/
• bearcherian 5y ago
  If you're main problem with a new language is that it's not written like the language you are used to, you're not going to be happy with the new language.
  • lolive 5y ago
    Newer is not always better. So I prefer to stay behind a little, if I can. [I stayed away from JavaScript until ES6 and Typescript. And I think I avoided myself a lot of headaches being that cautious]
    • lolive 5y ago
      Oh. And and at one moment in my career, I had to jump into serious web dev ;( But it was just after the death of IE ;) [Call me lucky] My 2 cents: widespread adoption is not synonym with long term perenity.
  • Aeolun 5y ago
    Hence I’m not happy with anything that doesn’t look like Java. Go seems amazing otherwise, but I cannot get over the fact that it forces me to capitalize or not capitalize my variables, and has types in the wrong order.
    • rob74 5y ago
      Well then I guess it's Java for you until retirement. Go can feel a bit alien if you only know "C-style" languages, because its creators took inspiration from a wide array of languages, including Pascal. Actually Pascal-style declarations are easier to read, but you have to keep an open mind and not just go "doesn't look like what I'm used to, so it must be bad"...
      • runarberg 5y ago
        C/Java style of annotating the return type of a function first, and then annotating the argument types before the name feels really old school at this point. Python, TypeScript, Go, Rust, etc. all opted for annotating after the name. Since this is so prevalent in newer languages, despite a pretty strong tradition in the other direction, I wonder if there is a pretty good reason for this which language design experts are keenly aware of when they design new languages.
        • saghm 5y ago
          I think it's much easier to parse unambiguously, especially when you have operators on values that also appear in types (e.g. `*` and &`).
        • lelanthran 5y ago
          > C/Java style of annotating the return type of a function first, and then annotating the argument types before the name feels really old school at this point. Python, TypeScript, Go, Rust, etc. all opted for annotating after the name. > > Since this is so prevalent in newer languages, despite a pretty strong tradition in the other direction, I wonder if there is a pretty good reason for this which language design experts are keenly aware of when they design new languages. My $0.02: Maybe consistency between named functions and anonymous functions? If you put the return type of a function before the name then it reads ambiguously when the name is left out (as in anonymous functions): // Named function int funcName (params) { ... } // No-name function int (params) { ... } Which leads to the language needing alternative syntax or extra keywords when declaring anonymous functions: // Something like this maybe? int lambda (params) { ... } If you put the return type after the function information but before the body then it's always consistent: // Named function funcName (params) : int { ... } // No-name function (params) : int { ... } And, of course, to retain consistency you then make sure that all variables are declared the same way (type following variable name): // Var declaration myvar : int; The disambiguation comes into its own when creating functions inline: // Prefixed return-type looks odd callFooWithFunc (int (argslist) { ... }); // Prefixed return-type requires extra keywords to not look odd callFooWithFunc (int lambda (argslist) { ... }); // Suffixed return-type looks normal callFooWithFunc ((argslist) : int { ... });
  • eru 5y ago
    You can like generics without requiring everything to look like Java. (In fact, generics have been a relatively late and reluctant addition to Java. They had been at home in ML-family languages and others for ages before.)
• Lhiw 5y ago
  > the lack of lambdas and the lack of the functional handling of collections seems problematic to me Why? 95% of lambdas I see should have been written without them. It's very rare I run into situations where it is more elegant or not really possible to write it another way. Devs just love doing tricky shit for no reason it seems.
• ImprobableTruth 5y ago
  Go has lambdas https://go.dev/ref/spec#Function_literals https://go.dev/ref/spec#Function_literals
  • eru 5y ago
    Yes, but without generics it's hard to do much useful with lambdas in your statically typed language. You can't even write a filter or map function. And eg Go's old workaround for polymorphic sorting functions was just atrocious: it was rather convoluted, and only really worked at all for in-place sorting.
    • Intermernet 5y ago
      "without generics it's hard to do much useful with lambdas in your statically typed language" I challenge you to read the source for the Go standard library and maintain that position. Lambdas are orthogonal to generics in pretty much every aspect. You need to stop thinking in terms of "filter or map". Programming languages that didn't include these idioms existed long before Go, and will exist long after Go. I welcome the introduction of generics, but I still don't have many places in many code-bases where they'll be used.
      • eru 5y ago
        Map is a pretty fundamental thing you might want to do to your data structures (and more). Look up all the places that Haskell's "Functor" pops up for example. Filter is much more limited in where it's applicable, that's true. In any case, I already gave another example in my comment: sorting. And sorting's API is done terribly in the Go standard libraries. The Go standard library does a lot with callbacks; and yes, it manages to get something useful out of them via something even uglier: mutation.
• skybrian 5y ago
  Go has function literals, which are basically lambdas but a bit more verbose. Typical Go style doesn’t use them as often as other languages. You might assign one to a variable, giving you an inner function. But loops are usually written as for loops, not map calls. One API call that comes to mind where you might use one is ast.Inspect. [1] Go often works well for replacing shell scripts, even without generics. [1] https://pkg.go.dev/go/ast#Inspect https://pkg.go.dev/go/ast#Inspect
  • tgv 5y ago
    > Go often works well for replacing shell scripts, even without generics. That’s selling the language short. Way too short.
    • skybrian 5y ago
      Understatement is easier than making a stronger case for it, and my Go experience is somewhat out of date.
• drvd 5y ago
  > I am [...] quite experienced in Java and Js/Ts. > I never jumped the Go bandwagon because of the lack of generics. > Can I now try Go? Probably no. You still would be very disappointed. Go's take at writing and maintaining software often is pretty repugnant to people with a strong Java or JavaScript mindset. If missing user defined parametric polymorphism ("generics") was a reason to not even _try_ it you will be offended by by other things Go does in its particular way. Be it error handling, pattern matching, concurrency, mutability, etc. Basically if you try to write Java (or JavaScript) programs in Go you will suffer and hate Go. Same for C++/Rust aficionados. Go's newly added "generics" still come without "library support".
  • klabb3 5y ago
    This feels like an unusual opinion. Lots of people from different backgrounds are happy with Go. And it's praised particularly for its concurrency model. That said, generics are still new and won't have the strongest library support for a while, and it takes a bit for idioms to settle. It wouldn't be unreasonable to wait for ~a year.
  • BatteryMountain 5y ago
    I actually agree with you. I'm mostly a C# developer that uses a ton of generics and when I tried Go previously I was disappointed that it didn't have generics. But I continued on. And so I found a handful of other things that would irritate me or would be an inconvenience versus doing the same thing in C#. So generics alone is not the main problem here, it is going from a C#/Java mindset to a Go mindset. In some way we would probably get bored with Go because it is so simple/easy and not much to mess up, versus the super complex object empires in C#/Java land. So the problem is not really a problem, go is just a different tool for a different kind of problem or if your brain works in a specific way - but I wouldn't call it a problem at all. In a way, go is what Buddhism is to other (more fully featured) religions. I think if you get proficient with you can probably have a very peaceful programming experience and not fight against the system (like in Java, half the battle is just battling the tooling). Thanks for bringing this up, will give Go another look again, its been a while!
    • 5y ago
• zxcq544 5y ago
  For IDE you can try goland(which is Intellij Idea for go). For replacing shell scripts go should be fine. It's closer to C than Java, so you will often write "if err!=nil" which is not a problem actually. Go feels like C with Hashmaps and simplified threading.
• flippinburgers 5y ago
  The lack of generics was never really a problem to begin with.