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

Twelve Years of Go

go.dev

Post reply on HN
Print view View original

141–150 of 244 posts

Re: Twelve Years of Go

#141

Post by kaba0 »

Andys wrote: post #118
leoc wrote: post #50

Earlier quoted context omitted.

If you think there's some virtue in writing verbose and inexpressive imperative code, what does Go provide in that department that you couldn't have got from Java 1.44?

It is lighter and faster and requires no runtime.

Than Java 1.14? Yes. Lighter is true of current Javas as well, but faster is dependent on the program. Go can often prevent garbage from being generated in the first place, but when creating garbage is a must, Java will happily handle heaps up to a terabyte in size, and its GCs are simply the state of the art.

Also, Go most definitely has a runtime, what runs the GC otherwise?

Re: Twelve Years of Go

#142

Post by princevegeta89 »

machiaweliczny wrote: post #48
princevegeta89 wrote: post #27

Would you say Go is suitable for web services and apps? I was trying to compare it with a rapid development framework like Rails but felt Go Web Frameworks aren't as mature and ready like Rails. Any insight would be appreciated, thanks!

I suggest going Rails/Next.js/Django and then extracting Go microservices if you ever need it.

This seems to be a really valid point

Re: Twelve Years of Go

#143

Post by ohCh6zos »

closeparen wrote: post #125
Zababa wrote: post #120

Earlier quoted context omitted.

> if err != nil { return err } I'm far from a Go expert, but I feel like this line is a bit pointless, especially if you write it a lot. At this point, why not just not handle the error, or panic?

The community strongly discourages panic.

A huge issue with Go is ‘idiomatic’ Go.

Re: Twelve Years of Go

#144

Post by princevegeta89 »

lawn wrote: post #127
princevegeta89 wrote: post #27

Would you say Go is suitable for web services and apps? I was trying to compare it with a rapid development framework like Rails but felt Go Web Frameworks aren't as mature and ready like Rails. Any insight would be appreciated, thanks!

You should also consider Elixir with Phoenix, as it's a comparable experience with Rails (although not as many libraries) while giving you much better performance. And Phoenix LiveView is just an incredible productivity boost, there's nothing quite like it.

Have been working a lot with Elixir lately. It's just that I wanted to see where Go stands

Re: Twelve Years of Go

#145

Post by agumonkey »

caente wrote: post #54
jrockway wrote: post #29

A good twelve years. Go really changed the way I think about programming. I used to be excited by programming language features instead of what problem I was actually trying to solve with programming. I'd spend hours condensing 10 lines of perfectly working code into 1 line of the most concise text possible; huffman encoded better than even gzip could imagine. And I'd feel great about it. I'd imagine people reading i…

> I used to be excited by programming language features instead of what problem I was actually trying to solve with programming. I'd spend hours condensing 10 lines of perfectly working code into 1 line of the most concise text possible (...) they should be impressed by what the program does for them, not what language features you used to implement it. Interestingly, what made me go through similar evolution was the…

I believe he has a point. Go was from day one trying to walk a different path. It was wisely dumb, pragmatic, simple (even though yeah verbose on many fronts). It changes your focus on external value rather than internal value.

Re: Twelve Years of Go

#146

Post by kaba0 »

throwaway894345 wrote: post #79
ryandvm wrote: post #76

Earlier quoted context omitted.

C#/Java are almost as fast, but not for immediate execution environments. If you have one off invocations of the code, Go executables will beat the pants off Java as you wait for the JVM to fire up and for HotSpot to kick in.

I've heard smart people argue convincingly that the JVM doesn't actually take long to fire up, and that this is something of a myth. It may take a bit of time for the JIT to optimize, but that shouldn't impact basic CLI tools (un-JIT-ed code is basically just interpreted code, and that runs quickly enough). I'd be curious to hear from people who have looked into this.

For smallish programs, a recent JVM will start up in 100ms. This is enough to make some CLI tools (like eg. git, with many separate invocations that return almost instantly) slightly bad to use, but longer running CLI tools are perfectly fine with it. There is also Graal to AOT compile classes and that way the startup time is truly negligible.

What actually increases JVM startup time is class loading, as it has to do byte code validation and the like for each new class. This is only apparent for largish frameworks though.

As for JIT, there is no much point for short-lived programs. Like, most python scripts are run without that and people write prod code in it.

Re: Twelve Years of Go

#147

Post by _0w8t »

throwaway894345 wrote: post #72
_0w8t wrote: post #68

Earlier quoted context omitted.

Most perceived verboseness of Go comes not from the language or libraries but from the formater that does not allow to compress 3 lines of the error check down to single if err != nil { return err }

If this is the case, I think the fault here lies with flawed perception and not the formatter.

The formater in many cases essentially doubles the number of lines. That requires to scroll much more frequently than with more compact formatting.

Re: Twelve Years of Go

#148

Post by grey-area »

kisstheblade wrote: post #131
grey-area wrote: post #65

Coming from other languages, the most interesting thing about Go for me (in my limited experience of a few other languages) was all those things they left out: No inheritance - no more digging through the massive world-tree of objects to find the code that actually does things. No churn - I have not seen a Go update break my code in about 8 years of use. No complexity - I like the culture of simplicity and eschewing…

"No inheritance - no more digging through the massive world-tree of objects to find the code that actually does things." You still have interface methods? I had problems navigating a new codebase and find the places "actually doing things". Some object was passed in somewhere which mysteriously implemented a one method interface defined on the spot in the other go file. I.e. the implementation had no relation to the…

There are certainly ways to write confusing code in Go too, no inheritance is just one cause of confusion subtracted.

IMO interfaces are best used sparingly and in a minimalist way like io.Reader (but I prefer them to Java interfaces and have not found them confusing nor felt compelled to find all concrete types conforming), callbacks are best avoided if possible, and yes dependency management has only recently improved.

https://pkg.go.dev/io#Reader

Re: Twelve Years of Go

#149

Post by throwaway894345 »

kaba0 wrote: post #136
throwaway894345 wrote: post #61

Earlier quoted context omitted.

Agreed. It still surprises me that so many other languages fail at the fundamentals (minimal learning curve, static binaries, fast builds, reproducible dependency management, great tooling, great stdlib + ecosystem, etc) and yet many devotees of those languages have positively hyperventilated about Go's error handling and type system for 12 years. Go is finally getting generics and I'm sort of cautiously excited abou…

I’m not arguing that there are languages where the state of tooling is bad to say the least, but how did Go raise the bar compared to something like Java or C#, the actual “blue-collar” languages?

There's a lot to like about Java and C#, but here are a few things that Go improved upon that spring to mind. Note that in some cases, Java and C# may have caught up in the interim. Note also that some things (e.g., low-latency GC) understandably weren't available from day 0 in Go, but followed quickly:

* Static binaries by default

* Single, straightforward build system (no DSLs)

* Single, ubiquitous code formatter

* Minimal learning curve

* Zero-work package publishing

* Zero-work documentation generation and publication

* Testing framework out of the box

* Production-grade HTTP server out of the box

* Low latency GC out of the box

More generally, C# and Java have always seemed to have a philosophy of "make everything as abstract and configurable as possible, and make the user understand every configuration option in order to do anything (overwhelm the user with configuration)". Granted, I haven't used C# or Java seriously since Go was open sourced, so it's possible that these are among the things that improved in C# and Java following Go's release.

Re: Twelve Years of Go

#150

Post by quadcore »

AnimalMuppet wrote: post #107
quadcore wrote: post #12

I cant believe they are moving forward with "generics". Programmers on average already tend to make things more complicated than they should be. Now every single module in the ecosystem is gonna use more abstractions, generics to fit their social environment. Its well known that abstractions are the devil. How many modules are gonna use generics when they should not? Most? Programmers are bad at programming and they…

> Its well known that abstractions are the devil. Woah there. No, it is not "well known", nor is it correct. Over abstraction is very problematic (and very common), true. But under abstraction is also problematic. There is a sweet spot, and it's hard to find. But the correct answer is emphatically not "no abstraction".

That's what I meant, in compressed form. Plus we know you better err on the side of under abstracted in practice. So what I meant is we know abstraction is where the devil lies because in practice programmers tend to over abstract to look smart. With generics as for one.
Post reply on HN