14 ms·

Compared to other languages, I find Go's syntactic support for partial application and currying lacking, and every http.HandlerFunc I weep for the redundancy I

• Insanity 7y ago
  Author here! I'm pretty happy that I can use Go to do these things, but you are absolutely right that without the syntactic sugar it gets quite messy to read! Lambda expressions - sure you can do them - but it'd be nice if you also had the syntax we came to know from other langs. (->, =>)
  • enriquto 7y ago
    your first Go example is missing a parenthesis
    • Insanity 7y ago
      Thanks, I checked the syntax again and noticed some other places where I missed it. :D
• stunt 7y ago
  GO syntax is very regressive comparing to where we hopped programming languages should go. I believe GO success is partly because in recent years, we have many new specialized engineers that programming isn’t their main focus (DevOps, Data Scientists, SREs) and naturally they are looking for tooling with shorter learning curve. Also when you consider how many developers have a hard time to learn GIT after so many years, you realize why companies need something as simple as GO comparing to Rust, or Java comparing to Scala for instance.
  • F-0X 7y ago
    >GO syntax is very regressive comparing to where we hopped programming languages should go. Speak for yourself maybe, but I appreciate Go's overall style. You also mention Rust and Scala in your post. If that is to be the future of language syntax, I should quit.
    • minxomat 7y ago
      The syntax being regressive is pretty objective. It's not a value judgement. It has it's pros and cons.
    • shantly 7y ago
      I like that I can dive into pretty much any Go code and it won't be doing anything basic some way I'm not used to or can't very quickly figure out without having to look anything up. Kinda like Java in that regard, but even more so, plus way less verbose. I mean it's gotten better but take Javascript where just a few years ago fundamental branching & execution order and might be provided by some library and it wasn't always the same one (thinking especially of various competing promise libraries) or friggin' imports might look different. Or Rails where you might have a codebase come across your laptop that's in some version you haven't used recently and using a bunch of libraries you're not used to and now half the symbols in a given file aren't defined there or anywhere else that Grep can find and it's unclear where they even come from, so it's off to the docs for a bunch of abandoned gems to get any sense of what's even going on. Go mostly avoids that sort of deeply unproductive junk. It does achieve that by not providing certain things, plus static typing (thank god for TypeScript, finally some sanity). I'm OK with that. I don't use it as my daily driver but I'm never even a little sad to drop into or contribute to a Go codebase, and I don't need a huge margin of uncertainty on the question "how fast can you get up to speed with this?" for Go code, which I can't say of just about any other language, sight-unseen.
      • spullara 7y ago
        Go is pretty verbose, especially error handling, vs modern Java code.
  • Elrac 7y ago
    I hear you, but there are also upsides. As a veteran of many programming languages, I find Go's minimal feature list a plus! Especially if I'm not rushed, I have an annoying tendency to try for the most elegant, succinct, idiomatic or general way to program a solution, and given a sufficiently expressive language I then fall victim to analysis paralysis. By giving me so few options, Go removes a major cognitive load. Very often there's a single obvious way to get something done and I'm not tempted to try anything fancy.
    • kitd 7y ago
      I find the opposite effect to be true. In many/most cases, the type model of a piece of Go code is not at all obvious without detailed inspection. When pretty much anything can implement any interface, and one can only tell whether an interface is fully implemented by close examination of a whole source file (rather than reading a simple implements keyword), the cognitive load is far greater.
      • kjeetgill 7y ago
        I understand where you're coming from, and I've made many a shallow criticism from a place of frustration, but please understand that thats what this is. The lack of an implements is not just a matter of "less syntax fever!" but one that facilitates other language design choices: in particular static compile time duck-typing. Among the "everybody knows or knows-about" class of languages this is pretty fresh. You can go back and forth on the point of this (or the value of the trade-offs) but it's pretty key to Go's flavor. As a Java geek, I'm pretty familiar with the way you'd prefer and I like it quite a bit too, but once I'd tried it, I've really missed Go's flavor more than a handful of times. Static duck-typing has some great downstream ecosystem effects. For one, it really facilitates smaller, tight interfaces. If my code uses a type A from another package B, and A has 20 functions that in my code only uses 3 of, I can create an interface on my end with just the 3. Then any testing or any alternative implementations apply only to the minimal interface. If that alternative implementation is by another author, it can interop with my code without importing type A package B. Obviously you don't need this all the time but it's killer when you do.
      • 7y ago
  • icholy 7y ago
    It sucks when you're writing it, but makes up for it when working with other people's code.
  • rad_gruchalski 7y ago
    This will probably confirm your point. I write software professionally for 20 years. I’ve written professionally in: perl, php, java, cfml, actionscript 2 and 3, javasctipt / node, c#, java, erlang, ruby, scala, python and golang. The last year almost exclusively golang. I work full back end / distributed systems and infrastructure automation. I find golang simplicity liberating, especially now with GO111MODULE. No need for stuff like node’s package.json, no maven’s project.xml (I have no problem with maven), no sbt, small native binaries (this is where golang, in my head, beats erlang), simple type system. Instead of focusing on designing the ins and outs of the architecture, it allows me to focus on the flow, like erlang! The structure, design, come later, with proper unit and integration tests. I love it, it is so simple to switch from r&d mode into production grade system development.
• mhd 7y ago
  I'm getting some serious Java 1.x flashbacks here, so just give it 20 years…
  • pjmlp 7y ago
    As early Java adopter, I find it ironic that Java is already considered a PhD language from Go users point of view.
  • nine_k 7y ago
    It took mere 8 years for Java to implement generics, though.
    • apta 7y ago
      golang is older than that at this time. They deliberately ignored proven concepts in programming language design for some hand-wavy goal of "simplicity", making unsubstantiated claims about "programming in the large" and "scalabilty" along the way.
      • nine_k 7y ago
        To quote some other HN comments: "systems PHP", "If I need a well designed language, I have Rust. Go's sell for me is it's so naively simplistic it's actually useful when your team members are idiots". These are a bit harsh, but sort of hints on the target audience: people who have neither a lot of programming experience, nor a developed taste, but have practical problems to solve without shooting themselves in the foot.
        • Insanity 7y ago
          That seems unnecessarily harsh towards Go programmers in my opinion. Languages have different up and downsides and different areas where they shine. There's plenty of people with a lot of programming experience writing Go, and whose taste might just have diverged a bit from the "mainstream". :)
• aasasd 7y ago
  You just name all variables with five characters max and save typing on that.
• jerf 7y ago
  "http.HandlerFunc I weep for the redundancy I create." Are you properly using the Template pattern, and creating middlewares that factor out repeated bits? There is some stuff that doesn't work for very well, but it does work for many things and it's easy to miss. (Go doesn't have many tools. You must learn to use the ones you have to the fullest. If you do, the remaining gaps are much, much smaller than commonly supposed.)
  • atombender 7y ago
    Middlewares force you to use a Go context to pass data, which has its own downsides. I personally much prefer passing data explicitly — through function composition and structs and so on — to contexts.
    • jerf 7y ago
      Specific "middleware libraries" may; the general concept does not. The general concept is just to wrap a decorator around an http.Handler with something else that implements http.Handler. You don't need any sort of specialized "middleware support"; all Go interfaces already support being decorated. I have found that there is a bit of a misconception in the Go community that there's something special about http.Handler and that you need lots of special code to deal with it. I've seen the misconception that "middleware" is something special and that you can only do it to http.Handlers a lot, but a "middleware" is just "a decorator applied to http.Handler". You can decorate any interface value the same way. There's also a misconception that "routers" are something special, like, they have their own type or something. But they aren't. They're just http.Handlers that can examine a request and figure out which other http.Handler to call. One thing I do a lot is wrap my top-level logger around the "router" that is the top level of my website; in one shot, you decorated the entire website. It's all just http.Handlers, there's no "real" distinction.
      • atombender 7y ago
        Right, I was specifically referring to routers like Chi where you attach middlewares to a "mux". These don't rely on function composition, and so the only way to pass information onwards — loggers, sessions, and so on — is to use contexts. The community has a lot of nice middlewares that do things like basic auth, session management, cache headers, etc. If you use decorators and not middlewares, you'll have to write your own middleware code.
• edem 7y ago
  The language is lacking in every other department as well, so it is not a surprise.