Go 1.18

Post by jen20 » Wed, Mar 16, 2022, 3:50 AM UTC

hodgesrm wrote: post #352

codeflo wrote: post #340

Earlier quoted context omitted.

That’s true, a binary tree isn’t a problem, it’s a tool for solving a certain class of problems. Since you can’t build reusable tools in pre-generic Go, (and, to be honest, only a limited set of tools with Go’s new generic system), programmers are forced to reinvent half-baked ad-hoc solutions all over their code base. I once read an article about a C codebase that contained dozens (!) of specialized linked-list impl…

Specialized collections are not necessarily bad. ClickHouse has dozens of hash table implementations, each tuned to a specific use case. It's what you do when you need something to go very fast.

Post by BoorishBears » Wed, Mar 16, 2022, 3:54 AM UTC

movedx wrote: post #381

rr808 wrote: post #364

Earlier quoted context omitted.

Engineers are people who can create a solution to a problem in an efficient and effective way. Specialists who know every detail are craftsmen who can create the best possible solution but they aren't necessarily good engineers.

> Engineers are people who can create a solution to a problem in an efficient and effective way. How do you create an "efficient" and "effective" solution if you're not aware of as many options as possible, i.e. fuzzing for security vulns? How is your solution "effective" if I can throw a bunch of Unicode at an input field and crash your application because the "engineer" didn't know what fuzzing is?

Post by sriram_malhar » Wed, Mar 16, 2022, 4:07 AM UTC

_0w8t wrote: post #98

zozbot234 wrote: post #76

Earlier quoted context omitted.

Go has shared memory and mutexes, but using them means giving up on memory safety because the whole rigmarole that Rust does to preserve safety in concurrent code is totally missing in Go. So that's a meaningful reason to stick to CSP - sure, it might create easy deadlocks but at least it won't totally crash your app with a potentially exploitable fault.

Go could have provided message queues with priorities Erlang style or something closer native solutions in Linux/Max/Windows that are known to work. They are safe, allows to avoid deadlocks just as channels and much more flexible. And with mutex one can build those as necessary, even if interaction with channels is ugly.

    receive
        {high_p, Message} ->
            process_high(Message)
    after 0 ->
            receive
                {high_p, Message} ->
                    process_high(Message);
                {low_p, Message} ->
                    process_low(Message)
            end
    end 

Post by stouset » Wed, Mar 16, 2022, 4:17 AM UTC

matthewmacleod wrote: post #124

philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

I think my biggest non-specific, slightly silly irritation when using Go is just how annoying I find it to write clear code in it, because the focus on simplicity feels like it too often comes at the expense of clarity, correctness, and expressiveness. I don't like that I'm not able to express simple constraints that I find a really important for improving code quality in other environments – things like "this field…

Post by metadat » Wed, Mar 16, 2022, 4:23 AM UTC

alophawen wrote: post #371

metadat wrote: post #317

Earlier quoted context omitted.

Goroutines and channels seem comparatively simple compared to the representational symbolic changes involved with generics, which make the code look and read more like Greek. The beauty of Go is (was) largely in its simplicity and python-esque (or maybe better than python) readability. With generics, reading and reasoning about code becomes [even] more challenging. Personally for me, at this juncture I'm finding that…

I spent 4 months in '21 rewriting a golang backend to properly use channels for concurrency. The previous developers did misuse it and left a steaming pile for me to find. However contracting pays well, so I don't care. You might want to reflect on your reasons for jumping ship because your tooling gained a new feature. Sound's rather irrational to me.