Go: Google's Plan9 refugees are staging a breakout

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Go: Google's Plan9 refugees are staging a breakout

bonds0097: Oct 23, 2010; I would cry but I don't think I can spare the moisture.; Pillbug

Just got an offer for a Go dev job. It's been my language of choice for the past two years on all my personal projects so I'm really excited at the prospect of using it in a more advanced production context.

# ¿ Mar 11, 2016 08:22

Adbot: ADBOT LOVES YOU

# ¿ May 4, 2024 16:44

bonds0097: Oct 23, 2010; I would cry but I don't think I can spare the moisture.; Pillbug

spongeh posted:

https://github.com/veandco/go-sdl2 These bindings work very well, but the biggest thing for me was just the lack of debugging tools. printf debugging doesn't cut it for game dev, and there wasn't anything promising that worked and didn't murder performance either. This was 6 months ago, I think I've seen a project or two that I didn't find originally that might be good once it matures, but I eventually went with a Lua based platform for my tinkering (love2d.org)

I did have some basic level loading, tile scrolling working in a plain ol redistributable .exe, so it's possible, and may someday even be a good way to go, but just keep in mind you're essentially writing everything yourself since there's not much of a community for game dev in Go.

Have you tried Delve for Go debugging? Just started using it with VS Code. Don't have much to say other than it's a thing but dunno if it's any good.

# ¿ Apr 8, 2016 03:31

bonds0097: Oct 23, 2010; I would cry but I don't think I can spare the moisture.; Pillbug

Hadlock posted:

I just wanted to say, I spent about 80% of my time today at work writing Go on Microsoft VS Code on a Mac. I am pretty sure 12 year old me in the early 90s would have never guessed that in a million years.

Same, for so many reasons.

# ¿ Apr 21, 2016 12:03

bonds0097: Oct 23, 2010; I would cry but I don't think I can spare the moisture.; Pillbug

I love how naturally Go handles both low-level and high-level stuff. I can be implementing an SSLv2 handshake one day and dealing in raw bytes easily (something I always hated doing in Python) and then just as easily (and readably) be working at a much higher level of abstraction and it all feels the same.

# ¿ Apr 26, 2016 12:39

bonds0097: Oct 23, 2010; I would cry but I don't think I can spare the moisture.; Pillbug

VOTE YES ON 69 posted:

Go rules so hard there's not much to say about it. Way more like a reimagined C than Java though. That it's GC'd is a red herring, outside of specific niches GC shouldn't be a thing devs should worry about.

So vendoring is first class now, which rules hard. I got 99 problems but dependencies are never one. What do y'all think of glide vs godep vs? I've mostly used godep, but think it will probably be glide soon.

We used godep before 1.5 but have been using glide since and I prefer it. Not having to vendor dependencies and just relying on reproducible deploys via 'glide install' is nice. The tool lacks maturity in some areas but it's constantly being improved so I'm hopeful.

# ¿ Oct 8, 2016 20:04

bonds0097: Oct 23, 2010; I would cry but I don't think I can spare the moisture.; Pillbug

Bozart posted:

That is what I put in the go user survey as something go could use. (Also I put multi-dimensional arrays but hey, that poo poo ain't coming anytime soon)

What do you mean by multi-dimensional arrays? You can do slices of slices to arbitrary depth, right?

# ¿ Dec 15, 2016 02:31

bonds0097: Oct 23, 2010; I would cry but I don't think I can spare the moisture.; Pillbug

Hadlock posted:

Will have to double check when I get home, I have a list of about 11 plugins I run that gets my workflow done.

And yeah, go linter in vscode go plugin is the poo poo, everything I do now goes through a linter. There's a ton of brittle legacy code that someone wrote, basically in notepad, and years later people are still running in to null issues that would have never happened had they been using a linter to catch all those gross mistakes.

Yeah, I made go vet and go lint Jenkins build status checks on all PRs. Also, there's one guy at the company who doesn't use goimports consistently and I will probably have to kill him.

I love the tooling in go.

# ¿ Apr 19, 2017 02:42

bonds0097: Oct 23, 2010; I would cry but I don't think I can spare the moisture.; Pillbug

You want to write your own MarshalJSON and UnmarshalJSON functions to implement the Marshaler and Unmarshaler interfaces. This blog post is ok: http://choly.ca/post/go-json-marshalling/

Otherwise, just read the json package and how they implemented marshal/unmarshal, you're basically gonna modify that.

# ¿ Dec 21, 2017 22:37

bonds0097: Oct 23, 2010; I would cry but I don't think I can spare the moisture.; Pillbug

nern posted:

Just started working on a project at work. We�re rebuilding the backend of a web application. It was all node.js and AWS lambdas. Were rebuilding it as a monolithic Go application.
I loving it.

Why the move away from serverless? Performance?

# ¿ Feb 26, 2018 13:20

bonds0097: Oct 23, 2010; I would cry but I don't think I can spare the moisture.; Pillbug

The whole point of using schemas is that you can enforce schema migration rules to ensure either backwards or forwards compatibility (or both) and have a mixed ecosystem where producers of data are updated at different rates and use different schema versions and still work correctly.

Enums can often break this very quickly since while you usually can't change the data type of a field as part of a migration, enums end up being an exception despite the fact that adding a new value to an enum is really altering the data structure. Enums suck and shouldn't be hard in a schema-first architecture, in my opinion, except for the rare case of actual static enum structures that do not need to grow or shrink over time.

# ¿ Sep 14, 2018 12:26

Adbot: ADBOT LOVES YOU

# ¿ May 4, 2024 16:44

bonds0097: Oct 23, 2010; I would cry but I don't think I can spare the moisture.; Pillbug

canis minor posted:

Is there a way to easily parse a JSON structure in Go? Let's say I've got:
code:
{
    foo: [{
        bar: [{
            qux: ''
        }, {
            quz: ''
        }]
    }, {
        baz: [{
            bax: ''
        }, {
            qur: ''
        }]
    }]
}
Let's assume I want to access foo[0].bar[0].qux - the choices I have is to define:
- a nested struct that will mirror what the json is, so I have to define a custom struct for any json I want to traverse, which I guess becomes tedious quite quickly
- define given object as interface{} and cast it at the point of retrieval - but then traversing json will look like
code:
var jsonResponse interface{}
err = json.Unmarshal(buffer, &jsonResponse)

if err != nil {
	// handle err
}

fmt.Println(jsonResponse.(map[string]interface{})["foo"].([]interface{})[0].(map[string]interface{})["bar"])...
Which is horrendous.

I'm beginning with Go, and I can't find a simple, generic way to achieve what I'm after, with people advocating approach no 1

As a strong advocate of schema-first design, I would argue for approach 1. Assuming you use an actual schema like Avro or Protobuf, you can easily leverage code generation to turn all that into Go struct types for you.

# ¿ Nov 5, 2018 18:02

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Go: Google's Plan9 refugees are staging a breakout