Atom haskell ide backend code#
So mostly these four, and of course simply writing code (along with the standard library documentation ). I also read Alan Donovan and Brian Kerninghan's book "The Go Programming Language".
Atom haskell ide backend how to#
My first resources were the Go website, specifically the following pages/articles: How to Write go Code, Effective Go and Frequently Asked Questions. This is just the top my head, I can bring more. Memory management in Go is very hard for us to reason, despite the language claiming that developers needn't worry about this subject as it is handled for them. But the most obscure part is that it was never released, even after the cast data had no more references to it. We would intuitively think that the memory allocated for that byte slice would be released, but apparently the casting performed constitutes an active reference of the data (rather than a copy of it), so the data is not marked for garbage collection. For example, we had functions that read a stream of bytes into a byte slice, then cast that byte slice into a string and return it. And in some of these cases we're still not even sure we understand despite fixing the issues, mostly because our code is not different than examples in the Go documentation itself. These were sometimes very difficult to track down with the available Go profiling tools (pprof for example), and even more difficult to understand. We've had several instances of severe memory leaks, with the Go garbage collector not releasing or reusing memory ever. A "bad" net/http client can easily bring down a net/http server.Ģ. And in many of the cases we thought that we were reading the body in its entirety, for example in locations where the JSON decoder was reading and decoding the response, but sometimes it simply did not really read it in full, despite definitely parsing the entire JSON structure returned from the server. Turns out the client was creating a new HTTP connection for every request rather than reusing connections, and it did that because Go expects you to read the response body in its entirety even if you don't need it, otherwise connections aren't reused. We've had production downtime issues in the server caused by filehandle exhaustion. We have a client component that makes HTTP requests to a server component of ours. I wouldn't call it my day-to-day, but sure, here are some examples:ġ. In my opinion, the key to successful Go development is building many small, well tested library packages while using interfaces a lot. Programmers coming from other languages mostly ignore them in the beginning and it takes a while until they understand that exporting types from a package is a failure and that interfaces would have been a much better choice. In the end that brings a lot of benefits (testing is easier), but if you try to create a project with very few packages you will go through lot of pain due to the lack of structure. So while Go allows you to quickly learn to write code, it is a much harder challenge to learn how to structure you code in simple small packages. Yes, you probably heard that before, but when you say things like 'proper project structuring' I think that you probably try to do something in a way that it is not meant to be used.īut at the same time you probably have good reason to try that, as that was the way you did it in the past (with other languages).
Well, somehow this sounds to me like you are doing it wrong. But the choices made in designing this language, and its popularity, absolutely baffle me. You can make the case that we're simply not good enough developers or Go is just not a good fit for the type of developers we are. Finding developers is also an issue, as most developers do not really want to learn a new language, and Go is still not that common in enterprises (I used to be like that myself, but I've learned long ago that this shouldn't be such a big factor when thinking about a new job). We've spent so much time fixing obscure bugs and behaviors that betray everything we've learned in the languages we used previously in our careers that it was really not worth it. As far as I'm concerned the good things about Go (large community, fairly efficient generated executables) do not outweigh the bad. It's like they decided to take all the things that make other languages good - such as safety, brevity, intuitiveness, versioning and proper project structuring - and threw them out the window. We've been using Go at work for 2.5 years now and it has become my primary language of use at this point in time.
0 kommentar(er)
