Go 1.13 Release Notes • Hacker News Board

Re: Go 1.13 Release Notes

#261

Post by dx034 » Fri, Sep 06, 2019, 12:35 PM UTC

axaxs wrote: post #14

cameronbrown wrote: post #6

I occasionally use Python for large-scale processing of structured data (XML, JSON) and the data's really messy as you'd expect (malformed responses, missing fields, normalisation, etc..). One of the things putting me off of Go for these kinds of projects is it's much more verbose/harder to handle edge cases - it feels like I'm less productive writing the program, but end up building something much more stable than t…

> is it's much more verbose/harder to handle edge cases - it feels like I'm less productive writing the program, but end up building something much more stable than the Python equivalent This is exactly how I felt moving from a Python codebase to Go. But you realize on the 100th or so Python stacktrace that it's worth the investment up front, if not for type safety alone. > I really need the performance for my worklo…

> Careful with that assumption. A pure Go application will in many cases be more performant than a pure Python one, but Python has a better C interop story. In the particular cases of parsing XML and JSON, I'd wager Python is much faster, actually.

Using encoding/json maybe but also using 3rd party libraries? jsoniter is pretty fast, I just ran some tests and for my use cases it outperformed Python.

Re: Go 1.13 Release Notes

#262

Post by tapirl » Sun, Sep 08, 2019, 7:07 AM UTC

pjmlp wrote: post #255

tapirl wrote: post #204

Earlier quoted context omitted.

It depends on which fields of your expected jobs are. Go is the language of cloud infrastructure, and half of blockchian projects are written in Go.

What cloud infrastructure? On my bubble everything cloud is either Java or .NET, alongside VM images, and native OS containers. Azure and AWS also have hardly any major tech done in Go.

PaaS platform: docker, rkt, k8s, openshfit, gvisor, kata-container, etcd, consul (and more hashicorp tools), istio, linkerd2, flannel, calico, wavenet, traefik, vitess, nat, ...

Re: Go 1.13 Release Notes

#263

Post by dang » Sun, Sep 08, 2019, 9:22 PM UTC

meddlepal wrote: post #82

littlestymaar wrote: post #53

Earlier quoted context omitted.

> a better C, aimed at server-side data plumbing I agree with all what you said but this. Go isn't a better C, it's a better Java.

> it's a better Java. Ah ha ha ha ha ha ha. No. Just no. I say this as someone who writes Go day in and day out and wrote Java for a decade. Maybe it is if the last time you touched Java was 2001.

This sort of comment will get you banned here. Please post thoughtfully and substantively, or not at all.

https://news.ycombinator.com/newsguidelines.html

Re: Go 1.13 Release Notes

#264

Post by yencabulator » Thu, Sep 12, 2019, 6:11 PM UTC

masklinn wrote: post #216

majewsky wrote: post #201

Earlier quoted context omitted.

Not in Go. Number literals don't have a type until they're assigned to a variable or used in a place that implies a type (e.g. a function argument). For example, the following is valid: var u uint32 = 10000000000.0 / 100000 even though 10000000000 overflows uint32 and it's also written like a floating-point literal.

> Not in Go. Yes in go. `var u = 1e7` gives a float. That means 1e7 is a float literal. You can coerce it to an integer by explicitly typing the target, but it's still a float literal.

`1e7` is an untyped numeric constant with a default type of float64.

https://blog.golang.org/constants

https://golang.org/ref/spec#Constants