Goodbye Python, Hello Go (thinkfaster.co)

I'm happy to report that JetBrains' VIM plugin is almost flawless (Block-based editing, window splitting, save/close, it's all where it's supposed to be).

I used to be in the same camp. But if you add a linter and parser and full blown backend to make lookups for code completion to your VIM configuration you might as well use an IDE. I've switched to IntelliJ for Java.

It dumps numpy arrays in /dev/shm which can loaded by other processes by the filepath, muuuuuch nicer than passing things around

Not even if X is better than Y for every specific task?

Prospector does a better job and it prevents you from wasting time with what essentially are stylistic choices and BS like a hard 80 chars limit per line (remember, A Foolish Consistency is the Hobgoblin of Little Minds)

And yes, yes, automated stilling tools are better

Intelisense is needed but even the standard vim autocompletion plugin does an ok job

In Golang, you're still using a thread-based abstraction.

In Python, "going async" involves switching to a slightly different style of programming and using different I/O libraries. While that has advantages, using threads lets you stick with the standard style.

flake8 is a linter that doesn't need much config, and you can config it to give you only "serious" errors and not stylistic issues.

I gave a talk on these subjects last year at the Paris Open Source Summit: https://speakerdeck.com/sfermigier/python-quality-engineerin... (NB: Black didn't exist yet at the time).

Saying "Go is overall a much better language" is like saying a wrench is a better tool than a screwdriver. You should keep both in your toolbelt and switch out when the need arises.

For your question, start with the regexp and os package, learn how to open a file, read in the contents, and then while iterating over the contents, apply a regex to the text. That should get you to the point that you can search plaintext for character strings. Good luck.

Just a few months ago I replaced an almost 100-line Go "script" with two lines in the Makefile. The fact that Go is great for big projects doesn't automatically make it good for everything. Go is for programs, not scripts.

    func main() {
      url := "https://example.com"
      mem := "memory.txt"
      oldsum, err := ioutil.ReadFile(mem)
      if err != nil {
        log.Fatal(err)
      }
      
      // Download URL
      resp, err := http.Get(url)
      if err != nil {
        log.Fatal(err)
      }
      defer resp.Body.Close()
      body, err := ioutil.ReadAll(resp.Body)
      if err != nil {
        log.Fatal(err)
      }
      
      // Hash it
      newsum := sha512.Sum512(body)
      
      if oldsum != newsum {
        err = exec.Command("xmpp_notify", url + " changed").Run()
        if err != nil {
          log.Warn(err)
        }
        err = ioutil.Write(mem, newsum)
        if err != nil {
          log.Error(err)
        }
      }
    }

The only downside really is that you have to compile the Go code, which is fast but not as fast as just interpreting a Bash script (the first time).

Another possible issue is executable size - if you have a lot of Go scripts they may take up a fair bit of space.

I wish Go had an interpreter / JIT mode for scripts.

Edit: Before someone says "but that's 3 times longer than the bash code!" please write the equivalent Bash code that has proper error checking.

I'd love to see some future bash like language that's strongly typed, has a consistent and simple syntax, but retains these advantages.

  #!/usr/bin/env stack
  -- stack script --resolver=lts-12.2
  
  import System.Process (system)
  
  import Control.Lens
  import Crypto.Hash.SHA256
  import qualified Data.Bytestring.Lazy as B
  import Network.Wreq
  
  url = "https://example.com"
  mem = "memory.txt"
  
  main = do
      oldsum <- B.readFile mem
      newsum <- (hashLazy . view responseBody) <$> get url
      when (oldsum /== newsum) $ do
          exitCode <- system $ "xmpp_notify " ++ url ++ " changed"
          B.writeFile mem newsum

They can use heuristics to get fairly okish. Pycharm is not bad and VSCode's new Python extension seems to work fairly well. But it's never going to be as rock solid as Java code completion for example.

If you need an IDE to solve common pain points of a language, isn't it fair to say that another language which lacks those pain points is a better fit for you? Using an IDE to aid you, to smooth things out and allow for more rapid development and better workflow is one thing. Being forced to use one because the language is lacking is a bad look on the language!

Python lacks a tool to painlessly produce the same, that is, a self-contained binary that includes the VM and all the dependencies. Determining Python dependencies may be slightly tricky, because `import` is an executable statement, and dependencies may be native-code libraries.

There are several tools for that, but all have their downsides, and none is in widespread use. Polishing such a tool until it's as simple and fool-proof as Go's build tool could be quite beneficial for Python community.

You can develop an application in python that utilizes distro-supplied python libraries. If you package your library in .deb or .rpm, it's trivial to utilize the dependencies from the distro.

Otherwise, you can install from pypi via pip, and especially into a virtualenv. You can declare each dependency's specific version if you so choose. Modern distros support python2.7 and python 3.x.

If you're on some other operating system, yeah, using python sucks for you.

While it's fair to say python is not statically compiled, it's no different than managing dependencies in other dynamically linked software.

Unlike python, go applications have to be cross compiled. For the most part, native python code will run anywhere the interpreter runs.

In the world of containerized applications, vendoring dependencies is a moot point anyway. We're all shipping around big tarballs with everything baked in anyway, so go doesn't offer any advantages in that space other than smaller binary size.

Not to say that go doesn't have some advantages over python, but I think the dependency management problem is vastly overstated, at least when it comes to python.

Nuitka (nuitka.net) has been able to compile python programs to a single stand alone executable reliably, robustly and easily for a while now.

It's a real gem and deserves to be more popular. We are very far from the quirks of pyinstaller or cxfreeze : it just works, even with numpy or qt.

Yes, go is still superior for deployment :

- it can cross compile

- executables are smaller

- it's built in so it's just an easier experience

- it doesn't depend on libc

But it's important to spread the word: the time were your python program was hard to ship is over.

Just use nuitka.

You should make it easy as possible for users of your software .

But they don't use the tools created to catch these kinds of errors, and complain that they aren't protected against these errors? There's a fairly large disconnect there. Hell, I have protection against this built into my VIM install. Not running these basic tools is tying a hand behind your back.

numpy - https://github.com/gonum/gonum matplotlib - https://github.com/gonum/plot pandas - https://github.com/kniren/gota (API not finalized)