21–30 of 142 posts
As for the GUI problem mentioned in the article, we now have https://github.com/andlabs/ui I haven't yet tried this lib, It may not as good as something as Qt, but I think it is a good beginning.
Earlier quoted context omitted.
That creates some mostly unnecessary boilerplate. I.e., if an error happens down the stack in function to read config, which calls a function to parse a file, which calls a function to read a file, you'll have to either propagate (or otherwise handle) that `err` manually or lose the precious information. On the contrary, Java-like pattern of functions like `Config readConfig() throws IOError, ParseError` simplifies c…
The readConfig example is not really an issue in go. Just return the io error and type switch after the readConfig. if config, err := readConfig(ioReader); err != nil { switch err.(type) { case io.ErrClosedPipe: // do one thing case ParseError: // do something else case ... } }
Manually, on every function call that may fail - that was my only point why exceptions may result in a clearer code.
section, err := parseSection(ioReader)
if err != nil { return nil, err }
section = parseSection(reader) // throws IOErrorIn the beginning i missed repl, but i've realised using repl in the first place was a mistake.. Now i rely on docs(godoc is awesome) and when i need to test something i use go playground.
As for the GUI problem mentioned in the article, we now have https://github.com/andlabs/ui I haven't yet tried this lib, It may not as good as something as Qt, but I think it is a good beginning.
However I feel that Go is not really intended to be used for desktop applications, I would much rather see a Rust GUI library.
Towards the end of the article there seems to be a confusion between servers and web servers. Yes, Go is nice for writing servers, no, web servers aren't the only things out there doing 'serving' in systems-land. Three examples from CloudFlare all written in Go: 1. Our Internet compression/optimization technology called Railgun 2. Our DNS server 3. Our CA infrastructure All are networked, all are highly concurrent. A…
The error handling one is an area I've never understood - in a well-designed Go app errors will be returned from functions/methods and you'll either deal with them or not _/err. I love try/catch/finally but I fail to see how doing either a _ or writing a simple log function to do something with returned errors necessarily represents "more code" than handling exceptions.
That creates some mostly unnecessary boilerplate. I.e., if an error happens down the stack in function to read config, which calls a function to parse a file, which calls a function to read a file, you'll have to either propagate (or otherwise handle) that `err` manually or lose the precious information. On the contrary, Java-like pattern of functions like `Config readConfig() throws IOError, ParseError` simplifies c…
If I didn't need the things that Go provides before, that does not mean I do not need them today or tomorrow.
Error handling is a way of thinking: TDD is one, Go's approach is another.
REPL is not a must, environment without REPL means you have to think more about what you want. It's a process. You should be able to read source code and figure out how things work.
Like many mentioned here, Go is great at doing system stuff, like background queues and processing. Stay with Python until you need to get thing faster, then move them to Go. That's how you should think of it.
Towards the end of the article there seems to be a confusion between servers and web servers. Yes, Go is nice for writing servers, no, web servers aren't the only things out there doing 'serving' in systems-land. Three examples from CloudFlare all written in Go: 1. Our Internet compression/optimization technology called Railgun 2. Our DNS server 3. Our CA infrastructure All are networked, all are highly concurrent. A…
He then makes some crazy statements about operator overloading as if that is the essence of a good language. I disagree. I don't want operator overloading. I almost never used operator overloading in C# or Java. Maybe that's just me, but it's certainly not a reason to avoid a language.
The crux of his argument is that C++ users who switched to Java years ago are the types of programmers that Go wished to convert.
He neglects to mention deployment. He neglects to mention stability in runtime. He neglects to mention any low level meddling that you have to do in compression. The examples you posted are exactly the kind of things that Go soars in. It's very convenient to leave them out while beating your chest about how your language is a superior language because it is superior in a very specific niche.