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

Seven years of Go

blog.golang.org

Post reply on HN
Print view View original

121–130 of 318 posts

Re: Seven years of Go

#121

Post by weberc2 »

zigzigzag wrote: post #11
fizzbatter wrote: post #8

So, i was a Go developer for ~4 years, then for the last 4 months or so i've been learning and using Rust. The pure joy of some things with Rust was astounding. Now, i joined a new job and they're in need of a new language for some backend tasks - the choice was mine. Rust or Go? The backend tasks were heavy API servers - nothing amazing, we don't do groundbreaking work. Python was their existing language, but they w…

Out of curiousity, why were the only choices Go or Rust? The type of thing you describe sounds ideal for Scala, Java, Kotlin, C# ...

Honestly, unless you need some special library or your team is already familiar with those languages, I would pretty much always recommend Go over those languages. Everything is just simpler, and it's at least as fast as any of those languages.

Re: Seven years of Go

#122

Post by greendragon »

snovv_crash wrote: post #44
greendragon wrote: post #18

Earlier quoted context omitted.

Curious what they weren't so happy about with Python? Was it purely performance? If so, did they consider PyPy, or at least profile what the slowest bits are so they can evaluate whether to throw everything out or just rewrite the slow bits? Was it the language itself? Not everyone likes dynamic languages, though it's odd they started with it. Did you consider Node at all?

From my time doing server backend python dev, it is only catching any problems at runtime, everything from missing arguments to typos in variable names that accidentally match another variable, turning your int to a string. Having a compiler catch these saves much time and hairpulling. And having unit tests as a final defense, rather than the only defense, does wonders for my peace of mind.

As a Python user and fan I hear this complaint a lot. I understand but I can't really agree since things like typos and type fails pretty much never happen to me, at least in production. My secret? I use the REPL, heavily. (And not even in the grand Lisp fashion, because Python's REPL isn't very advanced, mostly I use it just off to the side and maybe or maybe not running an instance of the full program, or parts of it.) Using the REPL catches most of those things just as quickly as a compiler, plus it can catch things compilers don't, such as null pointer exceptions.

Two lesser secrets are using a linter, which catches all sorts of issues too, and second actually getting the full program locally to a state where I can have it execute (most of) the new code I just wrote that I didn't verify in the REPL, or using data sources I didn't just define temporarily in the REPL, so I can make sure it seems to do what I intended. A lot of devs don't seem to do the second bit... Checked in code for Java compiles and passes existing tests and went through a basic code review but inevitably bugs get filed because it doesn't actually do everything the story said, it's like they didn't even try out their own code, it just looked correct and the compiler/tests agreed.

I think when you're working with the REPL interactively instead of relying on the common "edit -> save -> compile -> ship it|start over" cycle you don't miss those details as much, because you're constantly trying out your own code. Maybe my experience is because I don't typically use dynamic languages as scripting languages, at least in the sense of quickly hacking up a script, saving, getting to skip the compile step (look how much faster it is to develop in dynamic languages!!!), and running it until it works. I have done that, but even then, I'm usually writing the bulk of the script in the REPL -- or rather in my editor that can send text to the REPL. It's quite different from what seems to be the thing that made these languages popular to begin with, which is not having to explicitly type everything and getting to skip a (potentially long) compile step (which also encourages more source sharing).

Re: Seven years of Go

#123

Post by wyager »

weberc2 wrote: post #102
wyager wrote: post #91

Earlier quoted context omitted.

How is Go safer than, say, Java? It doesn't really do anything particularly useful or interesting on the safety front; it's type system is weak, it has null pointers, its error management mechanisms are mediocre.

It's not safer than Java. The selling point over Java is developer friendliness (simpler language, tooling, dependency management, deployment, etc).

I was asking the GP why he cited safety as a feature of Go. I agree with you; that's not a good argument.

Re: Seven years of Go

#124

Post by jkn »

pcwalton wrote: post #57
brandur wrote: post #41

Earlier quoted context omitted.

I've taken a very similar path recently myself and started looking into Rust. > 2. Proper error handling. I love error checking Hugely agree here. I can get behind Go's overall mentality of returning errors instead of throwing exceptions, but in my mind there are not enough primitives in the language to keep this style of coding safe and sustainable. Rust's `Result` type, `try!` macro, and pattern matching are an inc…

> Overall though, Go is probably still the more practical choice between the two languages (due to Rust's incredibly high barrier to entry). It depends a lot on your use case. I wouldn't say that Go is unconditionally more practical: there are cases in which you just can't use it.

Indeed. But looking at the GC improvements in Go 1.8 ("typical" GC pauses of less than 100us), the set of cases where you can't use the language might be shrinking significantly. Now if only they could turn that in some sort of guarantee...

Re: Seven years of Go

#125

Post by bbatha »

drej wrote: post #47

My 2c: Go is incredibly convenient for non-programmers. I don't make a living writing software, I make a living answering quantitative questions, using computers. I use Python for most tasks, but when I need extra performance and/or portability, I grab Go every single time. The main appeal is the quality standard library that covers most things I get in contact with. I could get immersed in it right away, because I d…

Go is the VB, or the PHP of service development. Lots of obvious and immediate shortcomings, but with just the right amount of niceties for its domain in a very easy to teach and deploy package.

Re: Seven years of Go

#126

Post by weberc2 »

Manishearth wrote: post #45
fizzbatter wrote: post #8

So, i was a Go developer for ~4 years, then for the last 4 months or so i've been learning and using Rust. The pure joy of some things with Rust was astounding. Now, i joined a new job and they're in need of a new language for some backend tasks - the choice was mine. Rust or Go? The backend tasks were heavy API servers - nothing amazing, we don't do groundbreaking work. Python was their existing language, but they w…

A lot of this comment resonates with my experience and views :) > You'll note that i didn't list Generics. I know that's high on peoples list, but not mine This is me too. Been programming in Rust for 3 years, and picked up Go two years ago. I like the language; I like how it feels like "C but safety net". I haven't used it for anything important (course projects a bit), but this is because so far Rust works for almo…

You can also build enums by building a struct with a `Tag` field. This works well and generally has better performance characteristics than using interfaces.

Re: Seven years of Go

#127

Post by pcwalton »

jkn wrote: post #124
pcwalton wrote: post #57

Earlier quoted context omitted.

> Overall though, Go is probably still the more practical choice between the two languages (due to Rust's incredibly high barrier to entry). It depends a lot on your use case. I wouldn't say that Go is unconditionally more practical: there are cases in which you just can't use it.

Indeed. But looking at the GC improvements in Go 1.8 ("typical" GC pauses of less than 100us), the set of cases where you can't use the language might be shrinking significantly. Now if only they could turn that in some sort of guarantee...

The sole performance metric of GC is not pause times! Throughput matters just as much if not more!

GC pauses are not the only reason to use Rust. Rust is not "little Go" that you reach for only if you don't want GC. You might want package management, data-race-free concurrency, a mature optimization framework, runtime-free operation, concurrent data structures, fast C interfacing, etc. etc.

Re: Seven years of Go

#128

Post by richard_todd »

pcwalton wrote: post #112
weberc2 wrote: post #92

Earlier quoted context omitted.

I don't mind the repetitive glue code. It might be nice to clean it up a bit, but it's the least of my concerns with Go. When I miss generics, it's usually for some tree-like structure, but the cases where I need a high-performance tree structure and can't take the performance hit of `interface{}` are few and far between.

Performance is not the main problem with interface{}.

Indeed, but I think if they REALLY don't want to change the Go language, an officially blessed std library of "go generate"-able collections and algorithms would be an ok workaround for private use inside a package. It's extra work for the users, but you'd get widely-used, widely-tested, type-safe collections. The main problem would be interoperability when two packages independently generate an RBTree that Go thinks are different types.

Re: Seven years of Go

#129

Post by pcwalton »

weberc2 wrote: post #113
pcwalton wrote: post #57

Earlier quoted context omitted.

> Overall though, Go is probably still the more practical choice between the two languages (due to Rust's incredibly high barrier to entry). It depends a lot on your use case. I wouldn't say that Go is unconditionally more practical: there are cases in which you just can't use it.

Right, but I think those cases are few and far between. Basically where you need blistering performance and/or deterministic resource usage. I would throw "safety" in there, but many (most?) safety-critical applications are written in C, and Go is certainly safer than C.

> Right, but I think those cases are few and far between. Basically where you need blistering performance and/or deterministic resource usage.

No, there's a lot more. See my reply to your sibling comment.

> I would throw "safety" in there, but many (most?) safety-critical applications are written in C, and Go is certainly safer than C.

This argument doesn't make any sense to me. Why is being better than a language from 1978 our sole criterion? Shouldn't we try to make our software as reliable as possible?

Besides, Go is not any safer than C when it comes to data races. I care about those a lot too.

Re: Seven years of Go

#130

Post by weberc2 »

sandGorgon wrote: post #60

has anybody evaluated building an api in Go vs Kotlin ? We are considering moving our financial tool api from python to either Go or JVM/Kotlin/JavaLombok+lambda . I really like Kotlin as a language.. but im really worried about the future. Jetbrains isnt Google.... I like Kotlin also because we are an app-based startup.. and we have been considering Kotlin on the app side as well. That would be a nice crossover of e…

I've tried both for a personal project. Kotlin is a fun language, but you've got all the headaches of the JVM ecosystem to deal with (tedious build tooling, deployment headaches, egregious memory consumption, etc). OTOH, Go is simple to pick up, and it's ecosystem is great. Everything compiles into a single binary, so deployment is moving a single file--no runtime dependencies, no JVM to configure, etc.
Post reply on HN