Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eleven Years of Go

blog.golang.org

Post reply on HN
Print view View original

141–150 of 170 posts

Re: Eleven Years of Go

#141

Post by pjmlp »

xedrac wrote: post #125
AtlasBarfed wrote: post #116

Earlier quoted context omitted.

Rust fundamentally improves C++ with memory safety and allegedly provably correct concurrency. It is a vastly different set of assumptions, design, and opinions than C++. What does Go do to fundamentally deviate from Java? IMO it is basically the same space with a few different opinions. It has GC, is C-style, a more modern stdlib than C/C++.

Go improves on Java in several ways, perhaps most importantly, it is much nicer to deploy - no JVM. It's also a lot less verbose, compiles way faster and uses composition instead of inheritance. Having said that, I really hate Java, and only mildly dislike Go.

Java has had support for AOT compilation to native code since 2000, just not as free beer.

Re: Eleven Years of Go

#142

Post by pjmlp »

avinassh wrote: post #119
blandflakes wrote: post #101

Earlier quoted context omitted.

The vast majority of my work has been on the JVM - and most of that in Java. I tried Go for a while, and came away pretty unhappy. First, similarities: Go seems like a really good language for building software for teams. It's straightforward and simple, and generally what you see is what you get. That's great. Where it wins: - having a standard formatter is amazing - having a compiler that is fast, and an executable…

How was experience using Go routines? And how would you compare it with Java? I am sure Java would have something similar

It had green threads in the early day, than concurrency packages, finally project Loom with virtual threads.

Re: Eleven Years of Go

#143

Post by valenterry »

wirrbel wrote: post #139
valenterry wrote: post #133

Earlier quoted context omitted.

I think it is easier to understand from a relative perspective. If you come from Haskell, you will probably not like Go at all. But if you come from doing shell scripting or C, then Go will be much nicer. And then it also has some actual nice things and removes some obstacles that exist in other languages. I think with more experience, people will start dislike Go more and more and switch to other languages. But for…

A bit of an update to my point above, it does feel a bit like Pascal to me, but kind of missing some of Pascal's nice stuff... My pet theory to the popularity is that it feels satisfying to just churn out many lines of code and in Go it seems you do that instead of using abstractions or "magic" as in many other languages. So Yeah, I expect popularity to drop as more "legacy" code bases need to be picked up by devs ..…

That's what I expect, too. In the end, the biggest problem is always to understand and change complex foreign code.

Re: Eleven Years of Go

#144

Post by lenkite »

premek wrote: post #99

I'd like to hear some Java devs opinions on Go. On one hand I'd like to try and learn something new, on the other hand, everything I could do in go I would probably do better in java (as in I know how to do it already)

Go's standard library is spectacular. Java could be as easy as Go to write quick micro-services, utilities etc if all the HTTP client and server stuff were part of the standard library. If Java had offered a Java -> native option right out of the box (instead of installing and setting up GraalVM), Go would have had difficulty in achieving the adoption it had today.

Go lang also made some fundamental re-useable interfaces that are leveraged across all its packages making the stdlib consistent to learn.

I still prefer Java though - because Intellij rocks and I am personally faster with development. But for newbies, golang is easier.

Re: Eleven Years of Go

#145

Post by jhoechtl »

thefounder wrote: post #67
jhoechtl wrote: post #44

Earlier quoted context omitted.

WASM is their weaker part. On the flip-side the WASM takeup is also rather modest so the net loss is not that big. Eventually they might come up with a solution to get their huge WASM files down to bearable size. Sure its because they have to ship the bigger part of their VM with it.

I'm developing an entire desktop app in WASM(with electron). Once you build the right abstraction it's just Go...simple and fun! To me the main issue I have with Go is the incomplete reflect package(i.e StructOf )

Soemthing to show the world, github / -lab repo, the like?

Re: Eleven Years of Go

#146

Post by novok »

tensor wrote: post #113
preommr wrote: post #87

I use Go quite a bit, and I have the exact opposite experience from a lot of these testimonials. Someone else mentioned go just works, they don't have to fight the tooling, or that they worked on a go program that works five years later (which language does this not apply to). ??? I've had quite a few problems with things like plugins for go deleting unused imports because I am in the habit of saving frequently. I re…

The simpler the language the better it is for complex code. Heavy abstractions won't help another reader of your code understand what's going on. In most cases it means it will take them much longer to understand. Concise code with heavy abstraction can help eliminate errors, but it definitely doesn't make reading it easier. It also doesn't make solving problems any easier. Solving problems is all about algorithms an…

Code that requires codegen or some verbose structure to express some constraint or idea that could be expressed in a sentence or two or a simple oneliner with the right abstraction can actually be harder to read because of the miles of boilerplate you have dive through.

Ex doing string processing in python vs golang. In golang or java even it's far more lines of code and far harder to understand.

Re: Eleven Years of Go

#148

Post by blandflakes »

avinassh wrote: post #119
blandflakes wrote: post #101

Earlier quoted context omitted.

The vast majority of my work has been on the JVM - and most of that in Java. I tried Go for a while, and came away pretty unhappy. First, similarities: Go seems like a really good language for building software for teams. It's straightforward and simple, and generally what you see is what you get. That's great. Where it wins: - having a standard formatter is amazing - having a compiler that is fast, and an executable…

How was experience using Go routines? And how would you compare it with Java? I am sure Java would have something similar

They (Go routines) mostly get out of the way and provide some abstraction over what I've typically used things like Future for in Scala.

As pjmlp mentioned, The concurrency package is pretty nice to know, and offers functionality to chain work or fire off an async task or enqueue stuff to be done as messages, but it's not as trivial as marking a function async. Clojure and Scala have more direct paths to this sort of convenience. Loom will be interesting!

Re: Eleven Years of Go

#149

Post by andreygrehov »

geodel wrote: post #114
premek wrote: post #99

I'd like to hear some Java devs opinions on Go. On one hand I'd like to try and learn something new, on the other hand, everything I could do in go I would probably do better in java (as in I know how to do it already)

I am mainly Java developer but used Go for some tools. I can't use Go for official applications because Go's XML library is little funky and my work is quite a bit XML dependent. It also lacks pure Go drivers for major commercial databases. If these 2 things were there I would have written lot more Go.

Just curious, what kind of drivers are missing?

Re: Eleven Years of Go

#150

Post by valyala »

skrtskrt wrote: post #14

I have really been enjoying Go, except for the built-in templating library. It's a wart on the standard library IMO. The template declaration and invocation hierarchy seems unnecessarily complex and is almost 100% undocumented. It just hurts my brain and doesn't make any sense to me in comparison to jinja, whatever jekyll uses, etc. It has very very poor documentation. Some docstrings are not a replacement for actual…

I also had hard times with built-in templating library for Go. That's why I created quicktemplate [1]. Usually it is much easier and natural to write templates in quicktemplate comparing to built-in templating library. As an additional benefit, quicktemplate templates work much faster (10x and more) than standard Go templates. The only downside that quicktemplate templates must be pre-compiled to Go code before building the app.

[1] https://github.com/valyala/quicktemplate

Post reply on HN