Through my last article and the indirect promotion of the Go programming language during the last few months, I communicated with many people who began to be interested in the language, so now I am going to write down my dissatisfaction with the language and provide a more holistic view based on my current experience. This allows some people to realize that the go language is not the best choice for their project. * * Note 1** It is important to note that some of the ideas in the article, if not all, are based on my own subjective thinking and are related to my programming habits, which are not necessary and should not be described as the "best solution". What's more, I'm still a Go language rookie, and some of the things I'm going to say may be inaccurate or wrong, so be sure to correct me in the wrong place so that I can learn something new. :D * * Remarks 2** I need to make a statement before I start: I love the language and I've explained why I think it's a better choice for many applications, but I'm not interested in the better of Go and Rust or the better of go and any other language ... Choose what you think is the best way to do what you want to do: If you think Rust is better at trying to use it, if you think that the byte code you send to the processor is causing a data bus error, try to correct it, in both cases, despite programming, rather than wasting your life blindly chasing the so-called popular language. So now let's move from the smallest to the most serious problems ... # # Please give me a ternary operator when writing a large portion of an application running on a terminal emulator, I find myself always printing some system state to confirm that the function I am debugging is on or off (such as turning on or off Bettercap one of the modules and report that information), which means that many times I need to convert a Boolean variable into a more understandable string that looks like this in C + + or other places that support this operator: ' CBool Someenabledflaghere = false;printf ("Cool module is:%s\n", Someenabledflaghere?) "Enabled": "Not Enabled"); Unfortunately, Go does not support this notation, which means that you will end up writing a bunch of things like: "' gosomeenabledflaghere: = falseisenabledstring: =" Not enabled "if Someenabledflaghere = = true {isenabledstring =" Enabled "}log. Printf ("Cool module is:%s\n ", isenabledstring)" And this is probably the most elegant solution you can think of (rather than creating a map to implement this function). Is this even more convenient? It's ugly for me, and when your system is highly modular, writing it over and over again will make your code more and more bloated, just because you're missing an operator. ˉ\\_ (Mitsujo) _/ˉ** remarks * * Well, I know you can do it by creating a function or using a string-type alias, but there's absolutely no need to write all these ugly alternatives in the comments, thank you:) # # Auto-generated stuff doesn't equal the experts in the Docs go language, I sincerely thank you for the code you shared and the things I learned every day when I read it, but I don't think they are useful: "' go//this function adds two integers//-put Captain Obvious meme Here-fu NC addtwonumbers (A, b int) int {return a + b} ' I don't think [such things] (Https://godoc.org/github.com/google/gopacket) can replace the document, But it does seem to be a standard way for users of the Go language to add comments (documents) to the code (with some exceptions), even in some of the frameworks we know have thousands of contributors ... I'm not very keen on adding detailed documentation, which is not a big problem if you like to delve into the code yourself, but if you're a heavy-weight dependent on the document, you're probably going to be disappointed. # # Git Repository as a package management system it's crazy. I had a very interesting conversation on Twitter a few days ago, where I explained to someone why the Go guide pack looked like a Github link: "Goimport" github.com/bettercap/ Bettercap "" or something like this: ' # go get github.com/bettercap/bettercap ' Simply put, in the easiest way to install go, you'll probably use it (without the vendor directory and don't overwrite the $ Gopath variables in the case) all (in fact not, but in order to simplify the problem we can assume that) in this installation directory or you set the $GOPATH variable directory of things, in my case this directory is/home/evilsocket/gocode (yes, [ That's true] (HTTPS://GITHUB.COM/EVILSOCKET/DOTFILES/BLOB/MASTER/DATA/GO.ZSHRC#L2)). Whenever I use the go get command to get or use the go get command [download required package automatically] (https://github.com/bettercap/bettercap/blob/master/Makefile#L28) After the guide package, It basically looks like this on my Computer: "' # mkdir-p $GOHOME/src# git clone https://github.com/bettercap/bettercap.git $GOHOME/src/ Github.com/bettercap/bettercap "As you can see, go actually uses Git repositories directly to manage these packages, apps or anything related to go ... It's really handy in a way, but this can be a big problem: as long as you don't use other tools or do some ugly circumvention based on the problem, every time you compile your software on a new system, the main branch of the repository where the dependency is located will be cloned whenever a dependency package is missing. This means that although the code you apply is completely unmodified, you will likely generate code differences every time you compile on a new computer * * (as long as any of your dependent packages are changed on the main branch). [] (Https://raw.githubusercontent.com/studygolang/gctt-images/master/amazing/mgc.gif) [via Giphy] (https:// GIPHY.COM/GIFS/SHIA-LABEOUF-12NUBKX6P4XOO4) when users compile their own version of the software using the source code to start reporting problems to third-party libraries, and you have no idea which submission is causing the time, please enjoy it ^\_^ Yes, right You can use tools like [Glide] (https://github.com/Masterminds/glide) or something similar to "pin" your dependencies to specific commits or tags, and create a specific directory for them ... It really is a bad design that has to be taken, and we all know that it does work, but it looks disgusting. Using URL redirection directly (http://labix.org/gopkg.in) to import a specific version of the package looks similar to the above ... This is feasible, but it is also very difficult to see, and some people may worry that this will lead toA number of security issues ... Who will control these redirects? When you use the root user or sudo to guide or compile these things on your computer, is this a mechanism that will make you feel comfortable working? I don't think so. # # Reflection? I don't think it is ... When I first heard that there was reflection in Go, I thought of many of its uses (or, I think, the use of the Go Reflection), based on the previous concept of reflection in other languages (such as python,ruby,java,c# and other languages), such as the automatic enumeration of the types of layers of the 802.11 protocol, and automatically generate the corresponding data packet according to the WiFi automatic fuzzy test or other approximate way ... It turns out that reflection is a big concept for the Go language:D for example, in an opaque interface object, you can get to its original type and you can list the domain of a particular object, but you can't simply enumerate the objects defined in a particular package (including struct and base type), This doesn't seem to matter, but without this feature you can't complete these features: 1. Constructs a plug-in system that automatically loads content from a given package without having to explicitly declare (what needs to be loaded). 2. Basically all the things you can do with the dir command in Python 3. Building the Vulnerability Checker (Fuzzer) of the 802.11 protocol that I think of, I see that the reflection is a little bit more than other languages ... I don't know what you're going to think, but it really bothers me ... # # generics? Not much of the language from object-oriented programming (to go development) complains about the lack of generics in go, which is not a big problem for me personally, because I'm not very keen on object programming at any cost. Instead, I think the object model of Go (which is not exactly the object model) is very concise, and I think this design conflicts with the complexity of generics. * * NOTE * * I don't mean to say "generic = = Face Object Programming (OOP)", but most developers want (go language support) generics because they use go instead of C + + and want to have similar templates, or Java generics ... We can really talk about a small part of the transformation from other functional languages that have generics or something like that (developer), but in my personal experience it doesn't affect statistics. On the other hand, this simplification of the object model, which appears to be similar to the function and structure directly using C, makes other things less straightforward and straightforward than other languages. Suppose you are developing a software that contains many modules (I like to modularize the software to ensure that the code is concise enough:D), all of which derive from the same base class (so youWill want to have a specific interface and be able to handle them transparently, and need to have some of the default functionality already implemented to share between the various derived modules (these are the methods that all derived modules need to use, so they are implemented directly in the base class for convenience). Well, in other languages you will have some abstract classes, or classes that have implemented some of the functionality (methods of subclass sharing) Other parts declared as interfaces (pure virtual functions): "' Cclass baseobject {protected:void Commonmethod () { cout << "I m available to all derived objects!" << Endl; }//While this needs to is implemented by every derived object virtual Interfacemethod () = 0;}; It happens that the Go language does not support this type of writing, a class can be an interface class or an infrastructure (object), but it cannot be both, so we need to "detach" This example in this way: "' Gotype baseobjectformethods struct {}func (o baseobjectformethods) commonmethod () {log. Printf ("I ' m available to all derived objects!\n")}type BaseInterface Interface {interfacemethod ()}type derived struct {// I just swallowed my base object and got its methodsbaseobjectformethods}//And here we implement the interface method in Steadfunc (d Derived) Interfacemethod () {//whatever, I ' m a depressed object model anyway ...:/} "' eventually your derived object will implement the interface inside and inherit Infrastructure body ... Although this may seem like or is an elegant decoupling, you will find that it quickly becomes a mess when you try to expand the go language polymorphism a little bit (this is a more practical(https://github.com/bettercap/bettercap/blob/master/session/module.go) # # Go is easy to compile, but CGO just like hell compile (and cross-compile) go The application is very simple, whether you are compiling or running on that platform. Using the same Go installer you can compile the same application for Windows,macos, or Android or other gnu/linux-based MIPS devices, no toolchain, no external compilers, no need to set up a specific tag for the operating system, There are no wacky configuration scripts that never run as we imagined ... This is not so great, okay? (If you're coming from a C + + world, and you often need to cross-compile the project, you'll know what that means ...) Or assume that you are a security advisor, and you now need to cross-compile the software as quickly as possible to resolve the Windows domain controller and MIPS IP camera that you were infected with yesterday (virus). Well, if you're using a local library where the go language doesn't have native support, you'll find it's not that simple, unless you're just trying to write a "Hello World" with go. Let's assume that your go project is using Libsqlite3, or libmysql, or other third-party libraries, because those who implement the whole set of object-relational mappings (which you're using in the go API) don't rewrite the database protocols defined in the Go language, Instead of just rewriting some of the systems that have been packaged through the CGO module, the system library has undergone a perfect test--so far, all languages have their own encapsulation mechanism to handle the local library--and if you just compile the project for your mainframe, it's perfectly fine. Because all the libraries you need (libsqlite3.so,libmysql.so or other libraries) can be installed via the Apt-get Install command. But what if you need to cross-compile? For example, need to compile for Android? What if there is no default library file in the target system? Of course, you can compile the library files by the system through the C + + toolchain of the system, or find a way to install the compiler directly into the system and compile everything (using your Android tablet directly as the compiling host). Well, please enjoy it. Needless to say, if you want (or need) to support multi-architecture cross-platform (why shouldn't you think that one of the biggest benefits of Go-as we say-is precisely this?) ), which will increase your compilation complexity and allow your Go project to cross-compileAt least as complex as a C + + project (ironically, sometimes even more complex). At some point in my Projects (HTTPS://GITHUB.COM/EVILSOCKET/ARC), I replaced all the SQLite databases in my project with JSON files, which freed me from local dependencies and built a 100% (based on) Go (written) application. It's easy to rely on cross-compilation again (if you can't avoid using local dependencies, that's the problem you have to solve ...). I am very sorry about this:/). If now your "smart heart" is screaming, "Use static compilation All!" "(Statically compile the library file so that they are at least packaged in a binary file), do not do so. If you use a specific version of GLIBC (C run-time library) to compile all your code statically, the compiled binaries will not work on systems that use other versions of glibc. If your "smarter Heart" is screaming, "Use Docker to differentiate a compiled version!" ", please find a way to properly configure all the platforms and all the (CPU) architecture after sending an email to tell me this method:) If your" a little bit about the go language inside "is going to suggest some external glibc alternatives, please refer to the previous requirement (how to differentiate all configurations):D # # ASLR? No! (taunt face) The next one is a little bit controversial, [Go app binaries do not have ASLR (security protection technology for buffer overflow)] (https://rain-1.github.io/golang-aslr.html). However, depending on the way the memory management of Go (and most importantly, [it does not have a pointer algorithm] (https://golang.org/doc/faq#no_pointer_arithmetic)), this does not become a security issue-- Unless you are using a vulnerable local library file-in which case Go lacks the ASLR mechanism [which makes development easier] (http://blog.securitymouse.com/2014/07/ bla-bla-lz4-bla-bla-golang-or-whatever.html). Now, I'm a little bit familiar with the idea of a Go language developer, but I don't quite agree with it: Why add complexity at run time, just to make sure that (the program) runs without having problems with something that won't be easily attacked at all? ...... Once you take into account the frequency of third-party local libraries that you will end up (in the project) (discussed above:P), I think it is not a sensible choice to directly ignore this issue. # # Summary There are many other little things about GoThe problem is that I don't like it, but it's also common in other languages that I know, so I've just been focusing on the main questions and skipping some of these questions: I don't like the grammar X subjectively (incidentally, I do like the grammar of Go). I see a lot of people, blindly to join a new language, just because on GitHub is very popular ... In one way, if a lot of developers decide to use it, there's definitely a good reason (or they're just "compiling everything into JavaScript" to catch up with a fashionable person), but there's no perfect language to say is the best choice for all applications (but I'm nipples and default injection are still hopeful u.u), it's better to compare the pros and cons before choosing. May the World Peace----------------! [] (Https://blockchain.info/Resources/buttons/donate_64.png) Keep in touch! [Follow @evilsocket] (Https://twitter.com/evilsocket)
via:https://www.evilsocket.net/2018/03/14/go-is-amazing-so-here-s-what-i-don-t-like-about-it/
Author: Simone Translator: Keon-lam proofreading: polaris1119
This article by GCTT original compilation, go language Chinese network honor launches
This article was originally translated by GCTT and the Go Language Chinese network. Also want to join the ranks of translators, for open source to do some of their own contribution? Welcome to join Gctt!
Translation work and translations are published only for the purpose of learning and communication, translation work in accordance with the provisions of the CC-BY-NC-SA agreement, if our work has violated your interests, please contact us promptly.
Welcome to the CC-BY-NC-SA agreement, please mark and keep the original/translation link and author/translator information in the text.
The article only represents the author's knowledge and views, if there are different points of view, please line up downstairs to spit groove
614 Reads
