Ghost of Reagan Past posted:

I'm writing a lovely, bare-bones NES emulator for shits and giggles. What's a good library for graphics for someone who doesn't do graphics?

EDIT: Basically I'd just like the ability to draw pixels on a screen. I don't need much, but I also don't know exactly what I need, and I don't work with graphics at all professionally. I ALSO don't really know Go and I'm using this as a way to learn some.

EDIT #2: As a Python programmer I want to scream at some of this. Why is there no 'in' operator? Why does writing a for each loop require extra syntax? Why is gofmt such a dick? Give me the gun to shoot my own face off, please, I'm a competent programmer, I swear.

Startyde posted:

I've a not dissimilar question, terminal ui. I'm guessing people don't just use ncurses c bindings but have no idea. Is there a standard lib for console menus, simple tiled windowing?

rt4 posted:

In Java-like languages, I'm accustomed to catching exceptions, then throwing a new exception in a "chain" so that I get information about every level of the stack trace. Does Go have this capability? I haven't found one, so I've created this pattern in my modules instead:

code:

if err != nil {
		return errors.New("mail API request failed: " + err.Error())
	}

This provides an error specific to this particular function while preserving the error from the function it called. Is there a better way to do it?

homercles posted:

I'm building a tool that does a lot of computation through lots of goroutines, and pipelining chunks of work in N:M relations. Before I start optimising, I want to know, for each goroutine:

• How much time it is waiting on channels to return data
  
• How much time it is running
  
• How much time it is pending to run because other goroutines are currently running
  

Is it possible to get these goroutine stats in a concise manner?

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.

bonds0097 posted:

Why the move away from serverless? Performance?

MALE SHOEGAZE posted:

in my experience, lamdas / microservices are a function that maps simple problems to complex distributed systems problems

MALE SHOEGAZE posted:

in my experience, lamdas / microservices are a function that maps simple problems to complex distributed systems problems

Mao Zedong Thot posted:

Pham Nuwen posted:

Editor-chat was last year but I'll mention that I use Acme (https://research.swtch.com/acme) which deeply frustrates my vim-using colleagues.

Seat Safety Switch posted:

I don't think even the guys I know who are into 9front use Acme daily.

DARPA posted:

Some fun today realizing bufio Reader.ReadLine() doesn't guarantee it will actually read an entire line, even if one is available, so you still need to loop to assemble a complete line until isPrefix is false.

quote:

ReadLine is a low-level line-reading primitive. Most callers should use ReadBytes('\n') or ReadString('\n') instead or use a Scanner.

Helicity posted:

Confluent's Kafka client has me a little confused. When producing a message to the topic, the topic name is a pointer to the string type and I have no idea why this would be useful. Why can't it just be a string?

code:

type TopicPartition struct {
	Topic     *string
	Partition int32
	Offset    Offset
	Error     error
}

rt4 posted:

It seems absurdly slow compared to what I'd expect from other languages and how the database performs at an interactive prompt.

limaCAT posted:

I was going to ask about the usual "ok but what about 'missing feature X'" (mostly exception handling and generics) but this talk (and some slides on currency and channels) convinced me about looking a bit deeper at Go as a serious language:

Dangerllama posted:

^^ a good post.

The package management piece is in the process of being baked now. I won’t go into the craziness, but there was “dep” for a while, which is now in the process of being replaced with vgo.

Khorne posted:

Go is good tool for web services and similar applications. I've used it off and on since 2014 and as long as you don't venture too far from that realm it's truly well designed. It's also not bad for command-line/one-off programs that most people would probably reach for Python/bash/perl/whatever to make. Its portability, single day learning curve, ease of developing in, and ease of setting up its environment are all great. It has similar level performance to pretty much anything for web stuff. It's not slow and carrying five tons of baggage like lots of the common web backend languages, and it doesn't require significant developer investment like C++ or functional languages. It also doesn't require consuming a bloated corpse like the JVM languages.

Its package management left a lot to be desired last time I used it, but it was supposed to be fixed at some ambiguous time in the future which may have already happened.

Due to the positives, people often use it for things it's real bad at. It is missing language features that are very useful for certain types of applications, but it's mostly intentional to make the language better at what it's good at. It's a current-gen tool for a specific type of program and a drat good one.