Hacker News new | past | comments | ask | show | jobs | submit login

I agree that structs should enforce using all fields or have provided some defaults at declaration, a result type would be nice, FFI is much harder than most other PLs I’ve worked with, and if your use case is a bad case for the GC, you’re in trouble.

At the same time, I really like go. No other AOT-compiled language I know of makes concurrency so easy: `go foo()`. It’s wonderfully simple and I love that using the language doesn’t cram my working memory. It feels like all the space is there for my problem. It isn’t the right tool for some jobs, and of course, you’re perfectly entitled to your opinion. But I think it’s a welcome tool in the toolbox.

I recently had to implement Raft in Go, and I don’t know of a better language for that. Feel free to inform me otherwise. The race condition checker, RPC libs, and simple concurrency let me focus on the algorithm implementation. The iteration speeds for me were super fast too since Go keeps compile times snappy.

These are all useful tradeoffs for me to keep in mind when deciding the right tool for the job. I wouldn’t consider these “lies” personally, but maybe I do have the wool pulled over my eyes :)




> I agree that structs should enforce using all fields

Nah, enforcement would be a problem if you're just say making a protocol decoder, you might "just" write struct as defined by API but not need to use all of its fields, or not use it inside the package (say package that decodes some JSON then just returns a struct with it)

I'd like go vet option for that tho as in some cases that would be useful.

> or have provided some defaults at declaration

Outright initializers would be nice vs New*() for any type that needs it and having developer to remember to call that




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: