I don’t see what bitemyapp and you are talking about as mutually exclusive. In fact, it does really sound like you care about the same things.

As I understand (please correct me!) Go programmers are interested in a language which is simple in the same way C was. You could look at some code and understand what was going on and how fast it would run easily. Perhaps without the gun aimed by default at your foot. Because the complexity and bugs have no where to hide, it’s easier to write code that you can trust. Something like Haskell doesn’t fit into this niche because simple alternations to the code can have some serious impacts on its performance.

Now on the other side of things, you also have people that care about correctness and choose to push some of that work onto the compiler. They primarily set out to do that with types. By arming themselves with more expressive types, they contend that if the compiler accepts it, there’s a very high probability that it’s correct.

To me, both of these sound appealing. Honestly, they don’t seem exclusive either. I want to be able to look at 10 lines of code and understand what assembly it generates, and other times I look at code and check the types and go Oh, I get what’s happening here.

The reason they haven’t been unified is because the languages in the types design space tend to be much higher level, but that’s not always true. There’s an implementation of typed assembly that has identical performance and runtime semantics as normal assembly, but with safety guarantees. Rust’s borrowing-checker also is a derivative of linear logic applied to types, there’s a lot of other junk in there too. We really can have interesting types that don’t make the code harder to read! It’s just that the compilers community doesn’t intersect very heavily with the low-level types community so implementations are scarce.

If you’re curious I’m happy to link to some research.

do you typically do systems programming, especially network programming?

I wrote a k-ordered distributed unique id service in Haskell recently than I am considering changing to do some direct syscalls recently. Does that count? Also it was twice as fast as the Erlang version out of the box. Good chunk of the code is bit manipulation.

“Systems programming” is a pretty dodgy term. I’d consider anything with a GC to not be “systems programming” because that implies kernel dev / embedded work. There are methods for doing that kind of work in Haskell but this isn’t the time or place for talking about how the runtime is side-stepped.

how much Go have you actually written?

A couple of years ago I was starting to chafe with untyped languages. I wanted easily deployable binaries as well. Go was one the languages I hacked around in before settling on Haskell. It’s not a particularly unique or interesting language, deeper experience doesn’t change anything paradigmatically the way learning Haskell/Agda/Idris/Coq would.

There are little aesthetic touches in Go that were neat, but it was very clearly not doing what it could be. A better choice would be Rust and even that lacks higher kinded types and other things I use regularly in order to work more efficiently.

Good comparison to demonstrate what I’m alluding to would be writing an HTTP parser in Golang, then in Haskell.

If the answers to those are not favorable, I assume you are talking out your ass.

Not getting things off on the right foot mate.

Unless making the human do it isn’t that big a deal, and dramatically simplifies the language.

There is stuff Haskell doesn’t do because it would complicate the language and we don’t know how to make it nice (yet), such as dependent typing. Haskell is headed in that direction, but there’s an insistence on having a solid implementation for practical use.

This is probably a case of blub-itis where you regard the nicer stuff as silly and unnecessary, but everything beneath you is clearly primitive. Haskell has the benefit of Agda and Coq to keep it honest about its place in the order of things. Languages like Go do not, so they can convince themselves they’re king of PL hill.

Go is for writing code quickly, code that other people can read and understand quickly, and then modify quickly themselves.

https://gist.github.com/paf31/9c4d402d400d61a49656

Particularly note:

Despite these challenges, I can report that I feel much more confident in my ability to learn new Haskell libraries than in any other language. Over the course of these two projects, I have used more than 20 libraries for the first time. I put this improvement down to the expressiveness of the type language, and the ability to “follow the types” in order to learn a new set of functions. Certainly, there is a steep learning curve, but I find the benefits quickly outweigh the effort required.

I’m going to stop here. Things have already taken an acrimonious turn.

Credentials: taught Haskell for the last year quite actively. Writing a book on Haskell. Do Haskell OSS work. Giving a local class on Haskell this Friday.

If you’re getting to the point that you need to list open positions, you’re not going to fill them with the best candidates.

This is mostly true, with at least two important caveats. The first is that people sometimes may lack a local network through no fault or deficiency of their own. I recently moved interstate (in the US), which separated me from my professional contacts and any jobs they could have referred me to. So I picked up a job on a regular ol' career site (not craigslist, but close enough). And yes, I very humbly consider myself one of the best candidates. =) If the world were as cynical as you suggest, I suppose I could leverage my current position to build a network and move up from there, but there’s no indication that I’m at a deficient company.

The second caveat is that many junior engineers obviously won’t have professional networks yet. Some will build one in school through internships, but some will not (e.g. I did research instead of interning). And if you’re promoting juniors appropriately, you should be doing a lot of hiring of junior engineers.

Don’t know how I feel about these statements. All the interviews I got (and the current job I have) were via ads on stack overflow and linkedin. Our company recruits folks by advertising on these locii and hackernews (I think). I think the folks I work with are very, very good. I would not quite so strongly advise someone that they simply can’t get people who will be competent and get the job done by advertising for positions. I think it can be done. I’ve seen it being done repeatedly as we expand and I meet our new colleagues.

Applying directly to ,companies, and responding to the various job boards is a great way to get initial experience. The above comments were directed primarily to experienced engineers. I had success posting on job boards like dice.com and linkedin earlier in my career as well.

I understand your question but let me be careful about terminology first: Type safety is a property of a language not a piece of code, given a type system a piece of code could be determined to be well typed or not.

Progress says that you will always be able to continue evaluation/execution, it doesn’t require that it should terminate so a language with infinite loops can still have progress. An example of blocking progress would be if a broken type system somehow thought 3 + “foo” was well typed, then it had no rule to execute plus on different types of value.

You’ll probably like StoneKnifeForth and Ur-Scheme too, then. (I guess I should get Ur-Scheme back online.)