1. 24
  1.  

  2. 17

    blue collar (mediocre) developers

    Ugh.

    I’m glad that I make things for a living instead of telling other people what to do. I pity the sorts of programmers who think that because they went to college and have a few stock options and are “professionals,” they have more interests in common with their employers than with other workers. If that makes me a blue-collar developer, I’m proud to call myself one. It doesn’t make me mediocre.

    (I’ve got no dog in the Go vs X fight. There is a whiff of historical reenactment about it, but as a dyed-in-the-wool Lisp guy, I’m in no position to throw stones there. The emphasis on consistency and predictability and the eschewal of special cases remind me of Common Lisp in its better moments. But I’m glad I get to work every day in a language with more of the mod cons.)

    1. 10

      Do people really hate Go? I mean people, not HN commenters? For me, and the problems I solve, it doesn’t seem like a good fit, and I wouldn’t choose it for a project in any of my particular problem spaces. I do think that there’s some Sapir-Whorf thinking going on (speaking purely metaphorically – the actual theory seems wrong), and arguments tend to devolve into pointless appeals to authority.

      But if it makes your problems easier, hey, no skin off my nose.

      1. 3

        I really hate it. Because I’m scared that one day I might have to write it. Being good with types really is part of my identity, at least professionally if not personally. I am paid enough to live comfortably, on the basis of what I can do in Scala. The idea that my skills could be worthless, that I might have to go back to writing in Java or something even worse, is upsetting and threatening; how could it not be?

        1. 7

          So don’t do it. You don’t have to take every or any given job. You will almost always have some sort of options. Others probably feel the same way about Scala or other things as you do about Go.

          I’ve been fun-employed for the last 5 years after a lockup period ended from an acquisition. I do contracts or work that I find enjoyable, that teach me something new or that meet some other goal of mine.

          There’s no need for hate (your own words) and there’s no chance that your skills in Scala or something else will suddenly be worthless or useless.

          Relax.

          1. 1

            I’m going to need to continue working for some years yet. One of my friends is an absolute Perl wizard but is having real trouble finding a job in the place where he wants to work. So I think the danger is real.

      2. 9

        I do not think that hate is the right word though, it is a hasty generalization to say it is so; the criticism comes out of the way it is designed compared to languages living in 2014, including those who are still successful from decades ago despite their shortcomings. Some people do have valid reason to be indifferent to it and express why they are so. That is not hate.

        1. 10

          Some people do have valid reason to be indifferent to it and express why they are so.

          Being indifferent to things rarely warrants extensive blogging. And certainly not to the level that we’ve seen from monthly Go-is-horrible-because-it-doesn’t-have-generics posts.

          1. 6

            I fully agree with your observation. This has driven the golang community to consider everybody touching the subject with an honest but critical eye a priori as a potential offender, not sticking to a technical argument and thus making anything meaningful hard to pass by. I wish the programmer community at large was less on taking sides based on hateful speech over actual technical merit.

            1. 2

              In a relatively off-topic manner, I dislike the -1 system in lobsters when I press the wrong button by chance, upvoted @journeysquid ’s post :)

        2. 9

          Amusingly, discussions about Go and PHP both follow similar trajectories, albeit with wildly different features being discussed. People lambast PHP for a whole variety of technical reasons (all valid), while the supporters trot out arguments of pragmatism and ease of use (also valid).

          Swap around the features being discussed and it’s basically a verbatim Go argument.

          queue burning at the stake for suggesting parallels between Go and PHP

          1. 13

            This isn’t too far off actually…

            But, where Go has deliberate design decisions, PHP has rampant train wrecks of poor choices that compound on each other in horrible, horrible ways.

            The ease of use is also from a dramatically different angle: ease of use for novice programmers vs ease of use for engineers.

          2. 3

            Well, some people enjoy debates with antivaxers, but most people are just annoyed that non-sense like this comes up in 2014.

            Same with Go.

            1. 3

              the hate wasn’t so much about the product/brand but that other people were falling for it.

              Well, of course. Why would you waste energy complaining about something that no-one is in favour of?

              Nobody thinks that Brainfuck is a good language, but nobody hates it either; there’s no risk that you’ll get stuck working in it for the next 15 years.

              Edit for downvoters: I’m not saying anything about Go here, I’m explaining the phenomenon of people caring about things.

              1. 3

                This is well written but I think over-all this is essentially an ad-hominem. I don’t mean any disrespect to the author in saying this but let me explain why I think that:

                Saying that people are unhappy with and criticize Go because it challenges their identity is saying that the criticism they have isn’t really valid or important, they only don’t like it because of their personality or something.

                The criticisms really are valid though:

                • The lack of polymorphism/generics means you can’t make a hetrogeneous collection in a type safe way. They recently introduced some kind of text substitution system to account for this.
                • The language lacks tail call elimination: This restrict blocks programmers from using certains kinds of procedural abstractions.
                • The language has goto: This breaks the ability to look at code in terms of block structured units.

                Go is overall pretty nice: safer than C, much higher level but still able to write the same sort of programs and has excellent concurrency features. So aren’t people right to be frustrated about these things? They make programming in the language worse and it’s disappointing to see something miss out on its potential.

                1. 3

                  Yes, it’s incredibly condescending of the author to dismiss the opposition as merely insecure.

                  He seems to think that “Go is heavily criticized because the language designers made decisions that lots of people disagree with” is too simple to be the truth.

                2. 3

                  Leaning on “pragmatism” probably isn’t the angle you want to take given it’s (anti) intellectual pedigree: http://en.wikipedia.org/wiki/Pragmatism

                  That aside, if we mean a focus on what is practical, it seems unlikely to be practical to make a human do the work a compiler could do. You can do a lot better than Go these days. You could do a lot better than Go 10 years ago.

                  There are things I like about Go. Binaries and cheap threading come to mind. But to ignore the work PL has done to make entire classes of problems history is a perpetuating the “Null value billion dollar mistake”. Golang’s type system is near useless and emblematic of the sort of type system that dyn-langers wanted to escape to begin with.

                  1. 9

                    So, every time I see a comment like this about Go, two questions come to mind:

                    • do you typically do systems programming, especially network programming?
                    • how much Go have you actually written?

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

                    That aside, if we mean a focus on what is practical, it seems unlikely to be practical to make a human do the work a compiler could do.

                    Unless making the human do it isn’t that big a deal, and dramatically simplifies the language. Writing Go incurs low cognitive overhead—its greatest advantage. Go is for writing code quickly, code that other people can read and understand quickly, and then modify quickly themselves.

                    Edited: removed comments on pragmatism because I don’t want to enter a philosophical debate I’m not qualified to have.

                    1. 13

                      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.

                      1. 5

                        Absolutely. Your comment reminds me of this video where SPJ talks about the intersection of these two approaches to the same goal. Also the title of the video is snarky and misleading. =/

                        Rust is a big step forward there, but they are still working out how to do a lot of this stuff. In the interim, there isn’t anything higher level on the C-like side that performs well besides Java. That’s why Go is seeing so much popularity. That and an extremely useful standard library.

                      2. 9

                        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.

                        1. 3

                          I wrote a k-ordered distributed unique id service in Haskell recently

                          That sounds like a pretty cool project! Is it open source? =)

                          Not getting things off on the right foot mate.

                          Maybe not, but I’m tired of people denigrating Go.

                          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.

                          As lousy as it may be, most programmers don’t really understand higher kinded types or have a lot of trouble reasoning about them.

                          As far as Rust, the Go standard library is huge and extremely useful for the type of work its designed for. Rust has a lot less there.

                          Languages like Go do not, so they can convince themselves they’re king of PL hill.

                          I don’t hold that opinion, nor do many Go users I’ve worked with. Go isn’t being about the king of any PL hill, it’s about being an effective tool for a certain job. Rob Pike is up front about this, he wanted a programming language that did the kinds of things he does on a day to day basis.

                          Certainly, there is a steep learning curve, but I find the benefits quickly outweigh the effort required.

                          Maybe. But Go has a shallow learning curve and doesn’t require a lot of cognitive breaks from other languages that are widely used. Large portions of the Go user base are immigrants from Python and Ruby, it’s no surprise they find Go easier to learn than Haskell.

                          1. 5

                            That sounds like a pretty cool project! Is it open source? =)

                            Yes, and it’s being used in production, albeit not by me: https://github.com/bitemyapp/blacktip

                            Maybe not, but I’m tired of people denigrating Go.

                            I’m not sure why people thought a language that roughly equates to ALGOL + C FFI + green threads created by people with a luddite streak would be warmly welcomed by the wider software community.

                            As lousy as it may be, most programmers don’t really understand higher kinded types or have a lot of trouble reasoning about them.

                            You saw the part where I teach Haskell right? Don’t bs me about what can/can’t be learnt that you haven’t even tried to learn. Higher-kinded types are one of the easier things to learn in programming. Not hard at all.

                            Rob Pike is up front about this, he wanted a programming language that did the kinds of things he does on a day to day basis.

                            So do I. That’s why I use Haskell. I don’t want to keep solving the same stupid problems over and over.

                            Large portions of the Go user base are immigrants from Python and Ruby, it’s no surprise they find Go easier to learn than Haskell.

                            I’m not going to disagree, except to note that this is only due to familiarity, not because Haskell is intrinsically more difficult.

                            It’s also worth considering that the “ramp-up” is a one-off cost whereas friction lasts for-ever-and-ever. Consider the immense cost one simple mistake with the language design nulls have cost us? Haskell eliminates that and countless more. It’s faster to write things in Haskell than Go because of the higher level constructs. It has a concurrent and parallel runtime. It gives you your choice of green threads, OS threads, CPU pinning, software transactional memory, promises, channels, transactional channels…

                            http://chimera.labs.oreilly.com/books/1230000000929

                            1. 3

                              Blacktip is neat. But I do have to note that it isn’t exactly a tremendous amount of work, nor a particularly complex system. Now show me a Haskell implementation of chubby / zookeeper / etcd. I don’t know of one, but I would be interested if there was one.

                              would be warmly welcomed by the wider software community

                              It is though, people who complain about Go are a loud minority.

                              You saw the part where I teach Haskell right? Don’t bs me about what can/can’t be learnt that you haven’t even tried to learn. Higher-kinded types are one of the easier things to learn in programming. Not hard at all.

                              I know Haskell, and understand higher kinded types. Don’t assume what I do or don’t know. :P

                              I’m not going to disagree, except to note that this is only due to familiarity, not because Haskell is intrinsically more difficult.

                              Familiarity is extremely important. Personally, I would be thrilled if programming education increased emphasis on functional languages.

                              It’s faster to write things in than Go because of the higher level constructs.

                              But you have to know more of those higher level constructs. Green threads multiplexed onto OS threads and channels are easy to reason about and quite expressive on their own. There is a paradox of choice problem with having too many bells and whistles.

                              1. 6

                                FWIW, there is my implementation (work in progress, there is at least 1 known bug I’m fixing) of Raft in Ocaml https://github.com/orbitz/scow

                                A few thoughts on the experience:

                                • I read most of the Go implementations as I did this. I found them hard to understand and often broken. The latter is not the fault of the language but I believe the first is. Being able to send pointers between goroutines, I believe, will be viewed as a mistake in the long term. It makes understanding a program significantly harder.

                                • I saw Mutexes. I found this strange. This has to do with my first point.

                                • I found much of the code difficult to test and poorly abstracted. This is a mix of the language and particular developers, I believe.

                                • My code is much uglier than I like, I’m working on fixing it.

                                • By providing functors, a compile time abstraction tool, my Ocaml code is much easier to test and it breaks into clear components. It’s also heavily modular without, IMO, making it significantly expensive to understand. It’s also type safe, in that even though the Log and the Transport are orthogonal components the user can implement it guarantees that the Log stores things the Transport knows how to send. This is convenient, but admittedly it’s something anyone would identify quickly and fix in a language like Go (Bohr Bug).

                                • I leverage the type system heavily in propagating errors. This means when I discover a new error case I can add the code that creates it and then the compiler tells me every place to fix it. This is much harder to identify in a language like Go (Python, Ruby, and Java to some degree) and leads to abolishing a whole class of difficult to find bugs (Heisenbugs). I think this is the more significant contribution in building complicated systems.

                                1. 1

                                  Nice, I’ll definitely take a look. I’ve been meaning to get better at Ocaml. You are just implementing for kicks?

                                  My code is much uglier than I like, I’m working on fixing it.

                                  You’ll get there! :D

                                  I read most of the Go implementations as I did this. I found them hard to understand and often broken.

                                  Yeah, I don’t know why but most of the Raft implementations I’ve seen in Go are just written poorly. That and, Raft isn’t that easy to understand to begin with.

                                  I leverage the type system heavily in propagating errors. This means when I discover a new error case I can add the code that creates it and then the compiler tells me every place to fix it.

                                  Indeed, this is really useful. But also sometimes not. When you have a lot of errors that have meaningful solutions, it’s definitely great. But when the errors pretty much always mean die, it doesn’t matter so much.

                                  1. 1

                                    You are just implementing for kicks?

                                    Yep.

                                    But when the errors pretty much always mean die, it doesn’t matter so much

                                    But I don’t have to propagate all errors with this style. With Ocaml I can enforce handling errors (with some discipline) or I can say an error isn’t really handleable and not force it (generally using exceptions). In the case of Go, I unfortunately do not have the ability to make this choice. For myself, this is an important enough to trade-off a rather crappy concurrency model (OCaml’s sucks) for better error handling (Go’s sucks), because errors are what really distinguish complex systems from simpler systems.

                                2. 3

                                  Blacktip is neat. But I do have to note that it isn’t exactly a tremendous amount of work, nor a particularly complex system. Now show me a Haskell implementation of chubby / zookeeper / etcd. I don’t know of one, but I would be interested if there was one.

                                  That’s pretty rude. That said, https://github.com/NicolasT/kontiki exists. As does https://code.facebook.com/posts/302060973291128/open-sourcing-haxl-a-library-for-haskell/ and tons of other things.

                                  If you’re going to assign homework, you’re doing it with me. Why don’t we both write HTTP parsers in our languages of choice and compare brevity, performance, and time to develop?

                                  I know Haskell, and understand higher kinded types. Don’t assume what I do or don’t know. :P

                                  I’m going to have a hard time believing that If you think they’re complicated. I taught them to my student who never programmed before. Not a problem.

                                  Familiarity is extremely important.

                                  No it isn’t. It misleads people into local maxima that aren’t far from a global minima.

                                  But you have to know more of those higher level constructs.

                                  You have to take a driver’s test before driving a car too. You realize this stuff isn’t that hard to learn with the right pedagogy right?

                                  Green threads multiplexed onto OS threads and channels are easy to reason about and quite expressive on their own.

                                  If you want to program that way in Haskell, nobody’s stopping you. That’s the default for us anyway (green threads, MVars/channels, STM)

                                  paradox of choice problem

                                  Lol. No.

                                  Civil engineers don’t struggle with having choices in building materials. Don’t be ridiculous.

                                  This isn’t productive. You should ping me about learning Haskell. You’re probably going through what I did, where I knew a “bit” of Haskell and thought I knew enough to write it off. (I ignored Haskell for ~5 years) - I had no idea what I was talking about though.

                                  https://github.com/bitemyapp/learnhaskell

                                  Offer still stands to do the side-by-side with parsers in Go and Haskell.

                                  1. 4

                                    That’s pretty rude.

                                    I don’t mean to be rude, I mean to be accurate. Being a smaller project doesn’t mean it’s bad, it just means it’s small.

                                    I’m going to have a hard time believing that If you think they’re complicated. I taught them to my student who never programmed before. Not a problem.

                                    I wonder what you told them then. It’s easy to demonstrate the value of first order type constructors, List<T>, done. I’ve never seen any demonstration of second order type constructors that wasn’t of dubious utility, or extremely niche.

                                    First order generics are even of questionable utility in the problem domain Go purports to solve, as evidenced by the multitude of problems people have used Go to solve. Of course, Go maps, slices, and channels are all generic, and that seems to be enough for most.

                                    This isn’t productive.

                                    I agree. But I’d like to point out that you don’t like my claims against Haskell any more than I like you complaining about Go. You assume I dislike Haskell, I don’t. The only reason I’m here is to address your claim that “you can do a lot better than Go these days,” which I clearly disagree with.

                                    If Go is so bad, why has it gained tremendous traction in a few short years while Haskell remains niche? Because people try Go and find they can solve real problems quickly, especially the dynamic language folks. Meanwhile, people check out Learn You A Haskell, or other resources, and hit a brick wall.

                                    Haskell aside, Go succeeds because it’s made for a specific type of programming, not despite of that. The language itself, the standard libraries, the tooling, the ecosystem, the community, are all built around that purpose and the core principle of simplicity.

                                    You want to do homework, lets up the ante from an http parser to an http server, that serves files in the current directory.

                                    package main
                                    
                                    import (
                                        "net/http"
                                    )
                                    
                                    func main() {
                                        http.ListenAndServe(":8080", http.FileServer(http.Dir(".")))
                                    }
                                    

                                    My server is extremely concise, and has speed comparable to Nginx. I can configure the number of cores it uses by setting the GOMAXPROCS environment variable.

                                    This is, of course, cheating. But at the same time, it’s perfectly legitimate within the Go philosophical system. Go is about tools that solve real problems. The net/http code is quite nice, not anywhere near as complicated as Nginx or Apache. Because Go was designed to solve that kind of problem.

                                    Keep trying to convince people that Haskell is a great tool, I hope you succeed. There are a lot of useful ideas there that should be widespread. Just consider that Haskell being a good thing doesn’t invalidate the advantages of different approaches.

                                    1. 2

                                      Haskell’s IO subsystem makes it faster than Nginx, not comparable to.

                                      http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf

                                      http://adit.io/posts/2013-04-15-making-a-website-with-haskell.html#serving-static-content

                                      My server is extremely concise, and has speed comparable to Nginx.

                                      Yeah so is that one.

                                      I can configure the number of cores it uses by setting the GOMAXPROCS environment variable.

                                      Haskell has RTS arguments. Either you’re presenting arguments in bad faith, knowing Haskell has equivalents, or you’ve overstated your knowledge. (I’m guessing the latter)

                                      First order generics are even of questionable utility in the problem domain Go purports to solve, as evidenced by the multitude of problems people have used Go to solve. Of course, Go maps, slices, and channels are all generic, and that seems to be enough for most.

                                      …no.

                                      https://hackage.haskell.org/package/mono-traversable

                                      1. 5

                                        Haskell’s IO subsystem makes it faster than Nginx, not comparable to.

                                        Same for Go, which I consider comparable to because it’s not off by a factor of 2. So unless Haskell is 2x as fast as Nginx, I would consider it comparable as well.

                                        Yeah so is that one.

                                        But it’s not literally part of the standard library. The emphasis was on the nature of the ecosystem.

                                        Haskell has RTS arguments. Either you’re presenting arguments in bad faith, knowing Haskell has equivalents, or you’ve overstated your knowledge.

                                        Neither. Merely explaining the Go example further, since you only toyed with Go fleetingly years ago. You keep assuming that I’m making arguments out of malice. I’m still not trying to be rude. :P

                                        …no.

                                        Well you can take that one up with Rob Pike, I’m done arguing about generics with people who haven’t bothered to use a language without generics for any appreciable amount of time. It’s as sad to me as people who say IO in Haskell is unreasonably difficult because of the IO monad. You’re the one who believes “everything beneath you is clearly primitive,” in your words.

                                        1. 1

                                          I’m done arguing about generics with people who haven’t bothered to use a language without generics for any appreciable amount of time

                                          Mostly out of curiosity: does Pascal,C, C++, and Java (pre-1.5) count? I already did those and I’m not in a hurry to go back…

                                          1. [Comment removed by author]

                                            1. 4

                                              Post your HTTP parser in Go, I’ll post mine in Haskell, we’ll benchmark.

                                              I’m traveling to two cities on business over the next five days. I’ll be back on Tuesday though, and I may have time then.

                                              Even so, this benchmark is questionable at best. How much of HTTP? Do large file uploads need to be accounted for? Test suite? Does time reading the RFC count? How is that time measured? How do I know you don’t just have an HTTP parser you’ve written? Meaningful benchmarks are a hard problem in of themselves.

                                              1. 1

                                                Just parsing the bytes of the HTTP payload. Test suite can be static request payloads that get parsed. You’ll want to use a benchmark suite that measures statistical significance of benchmark results like Criterion

                                                I know of an HTTP parser in Haskell but I planned to write one myself, albeit possibly with some help from friends that have done more parsing work than I.

                                                1. 3

                                                  No parsing of the body makes it fairly easy. From there it’s just parse the first line, and then parse the K/V pairs. Alright, you’re on—once I get back on Tuesday. ;)

                                                  1. 1

                                                    Cool. Criteria I’ll be considering are LOC, performance, time to develop, and correctness. Format the code using gofmt please. We track development time using contiguous screen-recording (video). Ping me next week when you’re ready. :)

                                  2. 1

                                    Have you considered using ReaderT or any other approach to remove the use of unsafePerformIO https://github.com/bitemyapp/blacktip/blob/master/src/Database/Blacktip.hs#L52 ?

                                    1. 2

                                      Have you considered using ReaderT or any other approach to remove the use of unsafePerformIO … ?

                                      Yes, I’m intentionally not doing so. It’s a singleton service, you shouldn’t ever have multiple instances of it running. I’m considering adding code to lock it down further.

                                      https://github.com/bitemyapp/blacktip#this-is-a-singleton-service-one-instance-per-servermac-address

                                      I’m not going to make it ReaderT because that implies running multiple instances in a single process would somehow make sense. unsafePerformIO’d global is unmistakable.

                                      1. 1

                                        I think that unsafePerformIO should be avoided since it is an impure construct in a pure language. Requiring would indicate a deficiency in the ideals of the language: it isn’t needed though the obvious solution is to create the reference and pass it as a parameter to the functions that need it.

                                        Of course this “pattern” of using unsafePerformIO can be shown to not violate referential transparency or anything but it would improve code quality to avoid dangerous functions. It doesn’t set a good example to beginners either.

                                        As I’m sure you know (but other people reading might not) ReaderT just lets us pass a variable around without having to add an extra parameter to all your functions. It doesn’t imply that you should run multiple instances.

                                        To make it a singleton service you could attempt to bind on a specific port, failing when someone (another instance) already binds there.

                                        1. 1

                                          vanila asked in IRC if this pattern was okay.

                                          16:22 < vanila> What are peoples thoughts on the NOINLINE unsafePerformIO create IORef/MVar trick?
                                          16:23 < carter> its kosher
                                          
                            2. 1

                              tl;dr: some people criticize Go because some other people use it. The former are bad, the latter are good. The author provides a description of assumed psychological motivations instead of proving his point.

                              On the up side, he calls it “Go” and not “Golang”.

                              1. 1

                                I’ll bite.

                                But the Go philosophy of simplicity and pragmatism above all else is the polar opposite of what those languages espouse (in which complexity in the language is ok because it enforces correctness in the code).

                                One reason I love haskell is because of its elegance. What is elegance? It is simplicity done right. A few simple properties can describe a whole lot of ideas. No factories, patterns, copy+paste bullcrap.

                                1. -8

                                  Go is a language designed for PhDs with bad coding skills who work at Google on systems software.