Once the Go programmer returned (the Gopher there and back Again)

Source: Internet
Author: User
Tags php language gopher arch linux
This is a creation in Article, where the information may have evolved or changed. According to convention, the first blog post always has to say something about history, right? I am a software developer, mostly using the PHP language. First contact with it or when I was in high school, I was developing a project with a friend. We wanted to build a website for the project and found a solution that was written in PHP with a very neat and prepackaged code. At that time, I had no idea what the code was all about and didn't take the time to figure it out. Years later, I met PHP again. In my first 6 months of college (I think about 7 years ago), PHP became one of my main concerns. Two years ago, I was introduced to the go language for the first time. Most of my professional experience comes from an agency located in the center of Leeds. It was a fantastic company, and I learned a lot from it because I was given a very high degree of freedom early on. I work for a wide range of projects: Standard CMS builds, custom API interfaces, mobile applications, automation for improved efficiency, deployment and infrastructure design, and many more features. During this time in the agency, I became a friend with an intern we hired. He was really a genius, and he suddenly introduced me to the Go language. I said I would try and say what I think about it. Soon, I thought I liked it. Compared to PHP, better performance, type security, support concurrency, locally compiled binary files, quite small, boot speed is quite fast, this is very tempting! If you go from PHP to go, there will be a whole bunch of things that make you feel excited. Oddly enough, I didn't really like it that much. I think its syntax is very strange, its tools are good, but the processing error is so cumbersome, (even,) God, on Earth there is no language like the Go language support generics? I remember doing a lot of similar conversations with the intern, and he probably told me all the things I was aware of later, but I went on looking for something new to learn outside of PHP, and now it's the same with go. # # One year of using Scala (the annual of Scala) My search quickly brought me to the Scala world. If you've never heard of Scala, it's a functional programming language running on the JVM. What was attractive at the time was that the JVM was very fast (once it was up and running), and functional programming was wildly sweeping the programming world. I got hooked on Scala and spent a year circling it and learning its grammar. When I fall in love with it, although the compilation time is longer than Go, the tools that use SBT are actually not that bad (thanks to incremental compilation). I learned the grammar and spent some time writing Scala like Java, and using less syntaxA few. Next, I focused on learning the principles of functional programming, such as more purely, referencing transparency, and not modifying the state (the principles of functional programming). I had followed many of the principles described here when I was writing PHP, but I didn't think about how to write a purely functional application. During my use of Scala, I read a lot about blogs, read some of the more popular books in the Scala community, and take part in the course of Martin Odersky using Scala's functional programming. I think I can't just stay where I can make something useful. I should be in a place where I can increase my chances of working in the Scala project, I should have enough confidence in my Scala skills and I should be able to work on such projects. But the situation is ... I don't think so. I still think other people's code is confusing and difficult to read. Think that every other person writes a library that has a different (programming) style, and also needs to learn a lot of vocabulary. I understand some of the widely used libraries, like [cats] (https://typelevel.org/cats/) and [shapeless] (https://github.com/milessabin/shapeless), But still don't understand what they do or why you need them. Look back, don't misunderstand my meaning. Scala is an impressive language and I respect those who work in this language. It doesn't have any limitations, it's a good thing and a bad thing (for me, it's bad). I like the idea of staying the same, and it's unbelievable that the compiler picked up the type error. This is very rare, and it loses important things and allows errors to occur at run time. I did do something with Scala, but it also made me more and more frustrated. I tried to solve the problem I wanted to solve, but I was always so overwhelmed by all kinds of reasons. Either I lacked the experience of functional programming, or I was frustrated by things like JVM startup time. I don't know why, and I still find the new Scala grammar (which I need to learn) after a year. I feel like I've been on this road for a year, but I've had very little to gain. # # Return to go language (back to go Again) one year after using Scala, I decided to give go a chance. I find that no other language can make so many tick boxes in the box as Go, and the year of using Scala just lets me add more boxes to tick. What do these boxes have? -Fast compilation: While SBT incremental compilation can speed up compilation at development time, it takes a long time to compile from scratch, and even with SBT incremental compilation, it takes longer than ' go build '. -Quick start-up shouldUse: I am very interested in developing CLI tools. Libraries that were developed early using the Go and Scala languages have a library for creating CLI apps. This is useful for testing the startup speed of apps developed in different languages. -Low memory footprint: I'm not a fan of how much memory the JVM uses directly. But I also know that if I want to do what I do, it's still a problem for today's JVM. -feature-rich, consistent style, but simple standard library: Scala has a lot of libraries, but you can see (in fact) a lot of dependencies on Java libraries. Some are not so delightful. Most importantly, when you start to introduce these dependencies, you'll start to think (why) you have to download the entire Internet to do something very basic. -Compile-time type checking: Scala excels in this, but in most cases you need to sacrifice readability at the expense of it. In some cases, Go misses some compile-time type checking, but this is rare because there are usually other solutions that can do type checking at compile time. -Garbage collection and type safety: I don't want to touch something too low, but I still want to have more control over what the application does when I use PHP. -Embedded concurrency Primitives: from PHP, this is where I want to explain more. When I use Scala to develop programs, I have the opportunity to use concurrency, but I've never been able to control as much as I do with Go. -Widely used programming style conventions: from the Php,php standard recommendation (PSR) is quite popular, I know I like to have a language that can be used everywhere in the code style conventions. I believe many languages can benefit from this, including Scala. For me, Go meets all these requirements, even more. I think Go gives you a lot of things that you can use out of the box. You can also find these things in other places, but not as well as Go, and neat. Some of the go features that started to irritate me also became acceptable. I think I finally understood something, like the Go language, to make some compromises, to make sure that the boxes like those above could be ticked. In order for you to get more benefits, some other places will be uncomfortable, but one thing is very clear, the language is generally designed to maximize development productivity. Error control is a good example. It's cumbersome, and sometimes it's not so useful. However, it makes it very clear where errors occur in the function, which means that when you read someone's code, you can clearly know when or why the error occurred. Another can make this judgment, the beginning of the season I am puzzled by the ' context ' package. I didn't really like it, and thought it was a very lengthy way of dealing with problems. Why can't we just kill Gor?Where's outines? ' Context ' is very much like an error, and its verbosity is explicit, telling you that some content of a given code is likely to be canceled at some point. You can't kill goroutine because you can't handle the goroutine it produces? After all, they are no longer children. Conventions, tools make the Go language development project incredibly consistent. So far, it's better than any language I've ever used. When you have tools like ' goimports ' and ' gometalinter ', it's not surprising that every project has the same code style, even the same document style. Tools can also help you avoid the same bugs and reduce misunderstandings in your code. I started using Go to write software, I think the best thing is, I can really solve the problem. I want to solve the practical problem, not just some random math teaching problems. I've been working on some tools to help automate some of my Arch Linux desktops in recent times (which I hope can be written very quickly). I wrote some tools to manage my workspace, to show notifications for something, to do something like auto-configuring my display (all of which are some of the things that solve the desktop environment, but it's the beginning of everything). When I was learning Scala, I suggested that the solution that I proposed to create was very interesting, but it was not possible to write software that solved the actual problem until the Go language was used. This is not a Scala error, it does solve the problem. I know this is a huge paradigm shift, and given my history, I will need a very large radius of bending learning curve. For me, go has no learning threshold, actually go has no learning threshold. Without very complicated compiling tools, grammar can be loaded into your brain at once, and you can get started quickly. Maybe you can read someone's code from day one, including reading the code in the standard library. The Go language is not perfect, but it is constantly being perfected. I am very excited about the future of the language, and I see what I want from it.

via:https://www.elliotdwright.com/2018/02/26/there-and-back-again/

Author: Elliot Wright Translator: gogeof 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

714 Reads
Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.