wingo

ositor, but when I do, I use `picom`. Mostly just to avoid tearing.) [1]: https://github.com/BurntSushi/wingo [2]: https://github.com/BurntSushi/dotfiles/blob/ea3a88e6160f4244...

worked well for a while, but it was subject to a lot of state transition bugs and my hack became hard to maintain. So I wrote my own. In Go. (Including a full X client stack.) https://github.com/BurntSushi/wingo I love working with three monitors now, because I can freely mix and match the windows on my screen. My workspaces are dynamic (add/remove/rename as I please), so everything is composable. On one monitor, I might have a bunch of terminals in tiling mode. On another, I might have GIMP in stacking mode. Interestingly, in order to achieve this, I had to break compatibility with existing standards (but support as many as possible). As a result, some existing WM tools (particularly pagers and possibly task bars) just can't work well with my WM without explicit support. Perhaps this is why so few of these WMs exist outside the tiling world!

work flow, since I can maintain my work area for any particular project without cluttering up the rest of my desktop. For example, when I'm working on the window manager that implements this functionality, I might have a workspace called "wingo" for code. And when I want to switch back to working on the X client library for Go, I go to my workspace "xgb" and it has me right where I left off. And of course, I have workspaces like "browser", "mail", "irc", etc. I have some temporary workspaces too, which are used for scratch work. Any workspace can be removed. And I can add a new workspace with any name at any time. If you're interested, this is all implemented in my hybrid stacking/tiling window manager: https://github.com/BurntSushi/wingo (Similar features exist in i3 and xmonad, but both are emphatically tiling window managers.)

oach we took in the design of the language, somewhat to our surprise it turned out to be a really nice general purpose language." http://www.infoq.com/interviews/pike-google-go

it. > If there is a new imperative language that does interest them, it is probably Rust. Yes. I can't wait for Rust to get a bit more love in the documentation department. Pattern matching? Algebraic data types? Thread local storage? Type classes? Yes please! Where do I sign up? > The question is, who does switch to Go? One would guess that these are mostly Python and Ruby programmers who have never written much C, C++, or Haskell, and are looking for something faster and compiled. Yes, this is a generalization, and there are plenty of exceptions. Not exactly the 'Python paradox', 'better than the rest', programmers. In my experience, most Go programmers are in fact coming from Python and Ruby. The premise of the "Go" or "Python" paradox is that skilled programmers tend to be the first ones to adopt new languages. Then the less-skilled programmers follow when there is sufficient buzz. I think that if one accepts that premise, it is applicable for Go. > one of my personal pet peeves are people claiming that 'Go interfaces are like Haskell typeclasses' That is annoying, but completely understandable. They are deceptively similar on the surface. But I don't think this kind of confusion is unique to Go. You'll see it everywhere. You know what else people confuse? That Go interfaces are just like abstract base classes! :P > But if you look at the language spec, there is not much interesting. That's kind of the point. If you don't accept the overall simplicity of the design Go as a feature, then I can't blame you if you dismiss Go. If all you want to judge a language by is whether it includes cool and exciting new features, then Go will never be a good choice for you a priori. > Go is just a very boring language (which isn't necessarily bad), pretty much like Java, without the good package management (no versioning) I am utterly baffled. Go's approach to packaging is literally the best tool of its class that I've ever used. The Go tool militates toward convention rather than providing a dizzying array of features. This makes it strictly less powerful than other packaging tools, but god dammit, it makes it dead simple to install packages. You want to try my window manager, which is roughly 30,000 LOC (including my X libraries)? If you have Go installed: `go get github.com/BurntSushi/wingo`. That's it. You're done. I just ran it on my system, and it downloaded, compiled and installed my window manager---along with all of its dependencies---in less than 30 seconds. You might say---other build tools can do this! But do you know how many lines of configuration I had to write for any of this to work? None. I didn't specify dependencies. No strange command line flags. Nothing. The common case Just Works. > Goroutines are nice, but they are just green threads. Channels have been done elsewhere. This is a vast understatement. Just green threads? And please, tell me, what other mainstream language supports green threads? I know Haskell and Erlang do. Rust will (yay). Anything else? No? (I know Java doesn't, but I can't remember if this is a limitation of the JVM or if Scala or Clojure have green threads). Go does. That's a pretty big deal. Go makes a solid concurrent style of programming in a C-like language virtually free. Sure, everything is still mutable, but there are powerful idioms that---in my experience---militate against race conditions. It's not as good as Haskell/Erlang/Rust in the compile time safety department, but I'll be damned if it isn't loads easier than my other choices: C, C++, Java, Python, Ruby, Lua, blah blah. > Boring languages attract more mediocre programmers than great programmers. And close minded folk think they have all the answers. It's possible for people to enjoy using more than one tool. I'm a hacker, and I love good tools. Go is a great tool. So is Haskell. I hope that Rust will be.

e other languages seem to punish it a bit more, while at times it feels as if javascript embraces it.