Hacker News Reader

Comment by void_mint | Hacker News Reader

It would be kind of a fun experiment to require a rough estimate of LoC written in a given language be included in feedback about that language. These comments are kind of a cesspool of poorly written feedback that wraps ambiguous complaints about "readability", "maintenance" and even the silly take of "Go is a language for engineering managers", whatever that means. I suspect most of the negative comments on any language come from people that have spent practically no time writing it, and thus are inherently uninformed.

Of course, if you hate a language, you're not going to write lots of code in it (unless you have to, and then I would expect your feedback to be pretty negative but at least informed). Feedback from beginners/programmers external to a language is super important for the success of that language of course, but lots of debates about things like programming language are cluttered with feedback that isn't really made in good faith. Someone that doesn't like static typing is going to leave feedback about Go that may not directly say "I just don't like static typing", but ultimately is as simple to reconcile (and thus, should mostly be discarded).

View on HN

I have written hundreds of thousands of lines of plain old C, as well hundreds of thousands of lines of Go over a career spanning three decades. I've used Go in earnest since 2013.

I would pick Go for any large project in a heartbeat.

I have to concur that the haters who post to HN probably have never used this language in earnest.

Here's what you get out of the box:

* Extensive standard library * Cheap concurrency * Fast compilation * Built-in test/benchmark framework, including coverage and race detection * Built-in heap and CPU profiling

Of all the complaints the one I understand the least is the reservations about performance. It is within 10-20% of C, and callouts to C and assembly are possible. (My 8-way multiplexed MD5 routine was written in AVX assembler and lives on in minio.) Extracting that last 10-20% is two or three sigmas away from the norm of how programming languages are used these days.

The objection to generics is similar. The lack of generics shows up -- once in a long while. It doesn't prevent me from being immensely productive with this language.

Looking back at the last few years I've wondered if I could have accomplished what I did in Go by using a different language (C in particular) and the answer, for me, is "not a chance".

Sincere question out of curiosity, since I have not been exposed to Go at all.

How do container types, like arrays or hashmaps work without generics? Do you basically have to declare and implement types/methods for each different contained type?

Arrays/slices and maps are in fact provided as built-ins that function like generics, e.g. []foo and map[foo]bar work as expected, as do associated helper methods.

But those are the only container types with built-in support like that. (Channels can similarly be of any type)

Go supports a handful of built-in generic types, like hashmaps. What Go currently lacks is user-defined generics, though that is actively being worked on.

Roughly the same way containers work in Python.

> Roughly the same way containers work in Python.

That’s not really true, since built-in containers are special sui generis generics in Go, whereas in an untyped python they get by being untyped, and in python’s statically-checked type system (as implemented in pyright, mypy, etc.) they use general-purpose generics.

That complaint is as old as the language --- the first piece about Go I ever read, after my friend Yan convinced me to pick up Go, called it out for having "generics for me and no generics for thee". I've never understood why I'm meant to care. I get, if you want to write your own generic containers, being irritated that there aren't universally available generics (yet). I don't get being upset that the language has some special-cased generics. It's not personal. They're not rubbing salt in your wounds. They just need a map type that works.

At any rate: the person asking the question is wondering how you manage to have performant containers with reasonable interfaces in a language without generics. That's a good question! If you've worked a lot in C, you might be imagining a horrible mess of void-stars or something. But no, the ergonomics are basically those of Python, with extra typing.

Given that they stated "Do you basically have to declare and implement types/methods for each different contained type?" in the comment, I don't think they were wondering if you end up using void*/interface{}.

I really don't understand how the python comparison makes sense. Since those particular containers are special cased, the ergonomics are also the same as java (and I'd argue more like java than python). Other than ownership, I don't think go's maps are any more python like than C++s or Rusts either.

> reasonable interfaces in a language without generics

and with static typing. Python doesn't fall into that category. It either doesn't have static types, or does have generics. The answer (as others have mentioned) is that go does support generics for a few particular container types.

> That complaint is as old as the language

I’m not making a complaint, I’m pointing out a fact without a value judgement.

> At any rate: the person asking the question is wondering how you manage to have performant containers with reasonable interfaces in a language without generics.

Uh, I don’t see either “performant” or “with reasonable interfaces” there, the question is: “How do container types, like arrays or hashmaps work without generics? Do you basically have to declare and implement types/methods for each different contained type?”

The answer is, for built-in containers, “no, because they use special-purpose generics”. For custom containers, its basically “yes”, but you probably only want a single contained type with an appropriate interface anyway. In neither case is “basically the same as Python” particularly accurate, though I suppose the former case is similar to typed python using generics in the same way as any language with generics would be, while the latter is loosely similar to bare Python or typed Python using protocols instead of generics. But only loosely.

Yeah, I'm choosing not to die on this hill. I'm just saying that Go has first-class table and resizable array ADTs.

They’re not first class though: you can not take in, return, or work with the ADTs, only with concrete instances of them.

Hey, there, I'm over on this other hill now, not dying on that one. :)

> The answer is, for built-in containers, “no, because they use special-purpose generics”.

Unless you want to implement utility helpers working on them then it’s yes again, because Go doesn’t have generic functions either, so while it does have a few builtin generic containers, you can’t operate genetically over them.

Others have answered, but I just wanted to add, your question is usually where beginners/non Go users start to pearl-clutch. I would advise, if you're curious, to give it a shot for a while. As with all new things, try to not just write the language you're used to, but in the syntax of the language you're using, and instead embrace patterns that exist in a given language.

Lots of people find the things you're concerned about missing to not really be the end of the world.

Or you might hate it, and that's also okay.

I hardly ever need generics directly. If I have to write an algorithm for 2 types, I can copy and tweak as easily as I can deal with the added complexity of programming with abstract types.

BUT, I need generics all the time indirectly. I've worked in lots of languages over the decades, and I highly value languages with mature/debugged/optimized standard libraries of algorithms and data types (esp. "containers").

Go has an impoverished subset "built-in", and that's all it offers.

One of the best things about Go is the high quality of its standard libraries--where it has standard libraries--so there is a gaping hole where the container and algo libraries ought to be. Experts in these algorithms could take advantage of Go's concurrency for example to write library algorithms that provide a combination of performance and safety that I couldn't create quickly if at all. They could, that is, if they had generics in the language, but they don't, so I'm on my own (for now).

When people (repeatedly) claim that Go doesn't really need generics because they (the claimants) hardly ever need generics, I have to wonder whether their knowledge of DS and algos is especially high or especially low: that they could whip up a debugged and optimized algo as easily as calling it from a library or whether they aren't even aware of the DS/algo that they really ought to be using.

Personally, it’s very rare that I need to reach for a specialized algorithm. I’m not sure if that’s primarily the problem space I work in (services providing user identity and access management), but I never find the need to go beyond a brute force search or need a data structure other than an array or built in hash map (sometimes a concurrent hash map). Most of the optimization I do involves eliminating network calls and implementing caching.

They use hack of "interface{}" which does type checking at runtime (slow). And you then cast it to a proper type.

If I remember correctly (haven't used it in a year) Go cheats a bit, and it has few functions in standard library that do have generics (like make), it just doesn't provide this functionality to the developer.

If you can avoid interface{} you should, ie. by declaring interfaces to types and using them explicitly. You can then mix your own types, and still be protected by the type system.

Yes, but that requires generics and without them code generators (and if you don't use them, a lot of copy & paste).

Agreed.

I used to use Java because it was fast enough, have good libraries and was productive enough. Go is almost as fast, the standard library has most of what you need and its ability to compile to a single binary makes deployments simple.

I also look back and think, could I have done all that in Java? Probably... but I also feel it would have required more effort.

Go and Java are close cousins.

The difference is of course the JIT -- with Go the single binary means you can disassemble it to find out what it's trying to do. JIT adds a layer of mystery.

Also, with Go it's largely possible to avoid heap allocations in performance hotspots. With Java I'm not so sure.

It is much easier to reverse engineer compiled Java than Go.

Later

But see below, I think I misconstrued this comment.

The argument above is being able to reverse engineer the machine code that will be executed by the processor. Java bytecode isn't that. That's why he said "the JIT adds a layer of mystery".

Ah, that makes sense.

I suspect parent may be better able to divine what the Go compiler intended by looking at the produced assembly, vs. knowing or predicting how the JVM will behave by looking at bytecode/decompiled Java code. Not that it is impossible, it's an additional skill that's bourne of familiarity with Hotspot/Graal/$JVM

It's awesome to see all this Java expertise on this thread but at its essence -- a jar file doesn't define the program that's going to run. It's the union of a jar and the JVM it runs on. With Go, the binary is the whole story.

So even if I can predict how a particular JVM will treat a given jar, I'm still stuck if my code might be deployed across a range of JVMs.

I say all this having written orders of magnitude more Go, with apologies to the Java programmers.

>... a jar file doesn't define the program that's going to run. It's the union of a jar and the JVM it runs on. With Go, the binary is the whole story.

I was saying the same thing - albeit poorly perhaps. I'm no Java expert either, but once had to download 'jad' off sourceforge to decompile a buggy 3rd party lib :-).

>So even if I can predict how a particular JVM will treat a given jar, I'm still stuck if my code might be deployed across a range of JVMs.

This seems like an odd objection to me. I'm not the biggest Java expert, and I don't currently use it professionally, but I've never written Java that was meant to run on a runtime I not only didn't control but did not know the version of. In theory this was supposed to be a big feature of Java, in practice the community is moving towards bundling the JVM when distributing apps, precisely because versioning is such a fiasco.

Why not just ask the current jvm what version it is and act accordingly? I mean surely you can advise the user / customer what JVM's your code is compatible with, which really translates to what JVM's you have tested your programming on, right?

I'm obviously surrounded by folks far smarter than me, so I'm posting something probably grossly uninformed to see what the experts think!

>Why not just ask the current jvm what version it is and act accordingly?

I would! That's more or less what I was saying. But earlier on in the life of Java, there were technologies like Web Start and applets that could be embedded in webpages and the idea was that they would run on the client much like JavaScript does today, and you would have little idea of what the client environment was like, other than "it's a JVM." That turned out to be a bad idea for a number of reasons, most famously security, and the situations in which you can't just bundle your JVM are dwindling.

Fair enough! Still, I'm thinking many javascript pages query to find out the browser environment and also act accordingly. I do agree with the security complaint, however I also like web apps.

I do think that you are sort of implying that web applets can't determine which jvm they're running under, is this really the case? Was there any reason that the java webapp folks prevented the applet from inquiring of the java version?

This page chats about the version stuff for applets, it seems even with applets there was some options for picking the java version:

https://docs.oracle.com/javase/8/docs/technotes/guides/deplo...

You've made a nice argument for bundling the jvm so maybe I should change my inclination there, especially since I do like avoiding depencencies.

> I do agree with the security complaint, however I also like web apps.

Java applets are basically dead at this point, it’s all JS.

> I do think that you are sort of implying that web applets can't determine which jvm they're running under, is this really the case? Was there any reason that the java webapp folks prevented the applet from inquiring of the java version?

I never wrote applets but the point I was trying to make is that your environment is fundamentally unknown in that context. You could query for different versions and so on, but you would probably never know for sure because you don’t control the runtime environment (everything from the JVM down to the OS). This was supposed to be a big selling point of Java and it has for the most part turned out to be more trouble than it’s worth. That’s all.

> I'm still stuck if my code might be deployed across a range of JVMs.

Modern Java is meant to be packaged with the JVM via jpackage. You will know exactly what you're running on.

I agree in general, but in this particular case (escape analysis [1]), you won't see what's happening in the ByteCode output. That being said, it's still very easy to see how the code will be JITed by running it through JMH (or just making sure it runs enough time to be optimized). The JVM and IDEs like IntelliJ contain tons of tools to review that.

To get back to the issue at hand, from my personal experience, if you have many small varibales, your app will perform better in Java than Go. The escape analysis in Java is probably more advanced than the one in Go, and in Java you could also use a generational GC if you prefer throughput to latency.

[1] To be more accurate, the actual optimization the JVM does is called Scalar Replacement, and it's not even about allocating variables on the stack, but rather about inlining primitives: https://shipilev.net/jvm/anatomy-quarks/18-scalar-replacemen...

But the tools that are available to profile performance, memory etc on the JDK are wonderful.

Java has come a long way. It's pretty easy to program in a functional style in Java these days. Go seems to go out of its way to make that hard. Maybe generics will help.

Go is more about explicit imperative style, defaulting to good/known performance characteristics. Would advice against trying FP with it, unless just for testing it out.

> Go is almost as fast

The performance measurements I've seen point to Go being faster. To me it seems also to make more sense since Go is compiled to native code, whereas Java still needs JVM to run the non-native binary.

Can you elaborate in what kind of cases Java had better results?

Tight loops usually where it’s really dealing with math and not business logic. The JVM GC was tuned for throughout over latency which may be a factor.

I've also been mostly using Go over the last 6-8 years. Before that it's mostly been C++, pretty "modern" towards the end.

Go would definitely be my preferred pick for distributed/server applications even though the previous large (mixed C and C++) project I was on was a large distributed application and we did just fine. In fact I'd say our productivity and quality in C++ in that other team was just as good as any I've seen (which is not a random/double blind sort of thing, who knows if that project started in Go from day 1).

I would say that in a large project the language choice has some impact but there are many other variables. A well managed C++ project with competent developers can work well. A less than well managed with so-so developers in Go can be disaster zone. There are lots of other moving pieces, testing, build automation, CI/CD etc.

There are certain areas where I would prefer not to use Go. Basically areas where you spend a lot of time up or down the abstractions. I would prefer not to implement a video codec or a signal processing system in Go. Firmware, motion control etc. would also probably not be a good fit. Going the other direction there are things I can do really quickly in Python (lessay grab some data from some services, do some manipulation, draw some graphs), generally smaller utility like pieces where I want to use data with various random types, use third party libraries. I wouldn't want to write a large project in Python because it's slow and is dynamically typed.

I would also beg to differ wrt/ 10%-20% performance difference. You tend to rely a lot more on GC and produce more "garbage" in Go and the optimizer isn't as good vs. the best C/C++ compilers, I'd say it's more like 50%-150%. But for a lot of stuff it doesn't matter. If you're just making database queries then most of your CPU is sitting there anyways and the delta on the caller side isn't a factor.

Go is pretty nice in it's zone. It's got rough edges but all in all it's fun to use. There are occasional annoyances (like those times where you implement another cache for the 10th time because you can't build a good generic cache or those times where you need a priority queue and interact with those clunky library implementations, so yeah, I'm in the generics fan club). But that hasn't stopped me from using and loving Go. I don't miss those C++ core dumps ;) or dealing with memory management (even with smart pointers and containers it can be a pain). Go's more dynamic aspects (reflection etc.) also make some things easier vs. C++. People can learn Go really quickly which is another bonus, learning C or C++ can take years.

100% on the team making the most difference. (An aside: a software project I've been admiring recently is the Apollo Guidance Computer's. To the moon and back on a 15-bit 1s complement machine and a few kb of memory. It's a case where the team was certainly better than the available tools.)

On the perf side: I'm curious to know where Go sits now relative to C assuming you elide away all heap allocations in your inner loops. In the early days Go's codegen was based on plan9's simple and simplistic C compiler's back end. Things have gotten much better since then and to my knowledge it's within striking distance of C. But I could be wrong.

there's a number of benchmarks you can checkout online.

number crunching wise, Go is on par with Java and C#: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

for webdev work, the standard library might not be that fast, but it's fast enough, and if you need even more speed the fasthttp third party Implementation offers good speed: https://www.techempower.com/benchmarks/

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Sort of supports my pulled out of thin air numbers (50-150%). In C/C++ you got those lovely SSE intrinsics ;) But look at the binary tree entry as well, that sort of x13 win for C++ really shows you how C++ lets you get sheer power with decent abstractions.

If you can find a team of competent C++ programmers, most definitely you should go with C++ for all tasks.

But if you've got a pool of people who have never touched either C++ or Go, I'd pick Go for the project. It's orders of magnitude easier to teach generic programmers the basics of writing decent Go than C++.

I recently spearheaded the creation of a new Go service at my company. If it was Node or Python I could easily imagine a team getting sucked into weeks of bikeshedding the API framework, the test framework, linting tools, formatting tools, the TLS stack, research spikes on packaging and distribution, etc.

With Go, all of these problems were basically solved by the strength of the standard library. We could not be happier.

> the TLS stack

Networking prowess of Go is often underrated in these discussions. Building an web application with server, router, mux, auth etc. all from standard library and just deploying the binary blob on the cloud (irrespective of the architecture) to get your application running with less effort than competing programming languages/frameworks is itself enough for most use cases.

Did the programming on macOS, build machines were Linux and the customer ran the code on Windows.

Zero Go-related issues during the whole project. Just drop in one executable and one config file and it just works.

I think having options is just sign of more mature language.

In python you could also implement the API framework, do unit testing, TLS, packaging using standard library. And similarly there are 3rd party frameworks for Go as well.

There's always tradeoffs, to be sure. What many are trying to convey is that Go's defaults tend to be the stronger and simpler options.

However, for a lone wolf project, I'd lean more on something like gorm, than just hand-craft and maintain lots of sql.

Another misconception is that it's all for inexperienced programmers. But you need decades of experience to appreciate all the opinionated tradeoffs already made in Go.

It's just one more tool though, and nowhere near FP, which is a different beast altogether. Lots of features around Go and ecosystem is clearly inspired from Haskell. That might be another good tool from the other end of the spectrum.

Go is just new, so it had opportunity to build what we already know. Python is older than Java. When it was first released there was no World Wide Web even, not mentioning REST.

The problem with not having generics is the systems you build instead. They either throw away type safety and use reflection, which causes hard to debug issues, or they lean on code generation, which is slow and hard to debug.

I agree that the lack of generics only shows up once in a while and doesn't hamper productivity as much as might be expected, but I'm still very excited to see them added to the language.

> throw away type safety

In theory yes, in practice if your Sort array function takes a list of interface{} instead of a well defined type is not going to cause any type bugs. Might be slow, might be ugly, but lack of types on functional/generic stdlib functions doesn't make your code buggier if the original implementation is sound.

I'm cautiously optimistic about the addition of generics to Go.

If all goes well, we'll get some nice stdlib stuff and 3rd party functions for handling different kind of data with a common api.

But if the - you know what kind of people - discover it in earnest, we'll get a hellscape of C++ templating proportions when people go way overboard with it.

Time will tell.

It’s not that Go is not a great language; The problem is that it’s a very conservative language that is not picking up low-hanging fruit. Their maintainers also have a nasty habit of being condescending to other people’s use cases; E.g., f-strings, unix shebang as comment, ... .

should we add the amazing declarative marshalling and unmarshalling to/from json and xml and possibly others? or is that part of the interaction with the outside world, ffi and marshalling in one bag?

Isn’t it stringly typed, full of runtime introspection and rather slow?

sure it is. however isn't most xml or json marshalled communication I/O bound? so even though it could be faster it also is "fast enough"?

It depends a lot how you're getting it and what you're doing with it. The existence of projects like rapidjson, simdjson, … indicates that even without GTAV-style mistakes, JSON enc/dec can absolutely be your limiting factor. Even more so if you're on a local network (e.g. between machines in the same DC) where bandwidth is… essentally infinite, for all intents and purposes? When you've got 10Gb/s or even 100Gb/s between your racks, odds are IO is only the limiting factor for very short messages (lots of framing overhead).

As for XML, it's an absolute bear to encode and decode, documents are often large (dozens, hundreds, even thousands of GB), and the format is complicated enough that writing truly fast parsers is difficult. Being CPU-bound when XML is involved is routine, especially if you need a DOM.

I find your characterization of critica of Go, highly uncharitable, but unfortunately all too common with Go apologetics.

If we look outside of Go, I see a lot of criticism of C++, Java, PHP and Node.js, but I rarely see the critics being attacked with "You just didn't write enough C++ code" to qualify for a critic license. I find this approach hypocritical.

For what it's worth, I wrote several software systems in Go, and deployed them in production. At least one of them is serving millions of daily active users.

Some things I'm happy about (and these were my reasons to use Go in the first place), like:

  1. No JIT = no warmup
  2. Portable static binaries
  3. Solid tooling
  4. (Mostly) high quality static library

What I really find frustrating in Go is not the verbosity (Rust is probably equally verbose, and I get over that), but the utter lack of type safety.

You see, most critics of Go (definitely the people complaining about lack of genrics), DO NOT complain about static typing. In fact, I don't remember ever seeing anyone complain about that. What people often complain about is _not enough static typing_.

Due to lack of genrics and other limitations of the language, Go essentially forces you to use empty intrrfaces, stringly-typed data, weak enums and runtime type checks all over the place. This leads to fragile code, and makes it very hard to have the same safety guarantees you could have in Java - let alone in a more FP-oriented language like Rust or Haskell.

> I find your characterization of critica of Go, highly uncharitable, but unfortunately all too common with Go apologetics.

I might suggest that if you're the type to use the phrase "Go apologetics", you misinterpreted my post and also emit uncharitable feedback quite often :)

> If we look outside of Go, I see a lot of criticism of C++, Java, PHP and Node.js, but I rarely see the critics being attacked with "You just didn't write enough C++ code" to qualify for a critic license. I find this approach hypocritical.

If you scroll up, you'll find my request was simply to include the level of involvement a programmer has with a given language as part of their critique. Critique away! But as with all things, when novices critique things they don't understand, they're mostly just being negative for negativity's sake.

Go into a C++ space and include "I've never written C++", followed by any criticism and let me know how serious your criticisms are taken. I can wait :)

> Due to lack of genrics and other limitations of the language, Go essentially forces you to use empty intrrfaces, stringly-typed data, weak enums and runtime type checks all over the place. This leads to fragile code, and makes it very hard to have the same safety guarantees you could have in Java - let alone in a more FP-oriented language like Rust or Haskell.

We can disagree - the purpose of my post was not to prove Go was a "good" language or not. These bits of feedback sound like you're following antipatterns, but you're welcome to program in Go however you'd like.

My experience in Go in production is limited to ~150 lines of code I wrote to contribute a small feature for one Terraform provider.

The provider in question is a very thin wrapper over an API library. The feature I added contained almost no business logic of its own and would probably take 15-20 lines in a more expressive language.

Based on that experience, I would not choose Go for a project of my own (unless it could directly benefit from Go's strengths, i.e. unless it required fast startup, portability and concurrency).

Thanks a lot for responding.

This is a pretty good example of feedback provided by language novices. You have almost no experience with the language, complained about an aspect of it (line count), and then said you wouldn't use it again, unless you would (as you defined in your closing parens).

I'm not trying to diminish your feedback at all. You like what you like, don't what you don't like, etc. Nobody is forcing otherwise. It's just an interesting pattern that you can see with parallels in almost any language. Much like when novice Clojurists say "I wouldn't use Clojure because of all the parens" - there are things that, for most novice+ users, just kind of end up not mattering a ton. The things inexperienced users think are a big deal (in your example, line count) usually end up not being a big deal.

Infix notation with all the parens is the primary reason I never got comfortable with the lisps. My mind never worked like that. So I really believe there are valid personal preferences that keep people from liking languages right from the start. (I loved forth though. My mind took to it immediately.)

Sorry, in my post I never said or implied that having personal reasons for not liking something was invalid. Distinctly the opposite. The point I was making is mostly that not liking something doesn't mean it is less functional or successful. The parens in clojure are something to acclimate to, not a forever debt. But time and time again you'll see posts discounting the entire language because of them. Much the same with Go and lack of generics/verbosity.

> The things inexperienced users think are a big deal (in your example, line count) usually end up not being a big deal.

Indeed... like Python novices complaining about significant white-space.

Haha, that's fair!

Still a no-go though (jk).

But there is an order of magnitude quantitative difference here that is hard to argue will go away with familiarity (assuming the 10x line count difference estimate is right). Fitting 10x more functionality in the screenful of code you are looking at is a big cognitive advantage.

I’ve not used Go, so I have no opinion. I know some folks that really like it, though, and I respect their opinion.

Same with Rust.

I programmed PHP for twenty years (not full-time). I never learned to like the language, but got fairly good at it.

I now program pretty much exclusively in Swift. It is full-time. I’ve been writing it since it was announced.

I like Swift quite a bit.

One of the things that I’ve learned, is that there aren’t actually that many shops that have done industrial-scale Swift projects. Lots of people have done fairly small ones, but very few really big ones (like you will find with ObjC).

Writing a half million lines in any language gives you some authority.

> Writing a half million lines in any language gives you some authority.

Totally.

In this blog post, Khan Academy says "It is performant enough for us and our team likes it". In this comment section, there are people insisting it's a bad language while having never used it. Not just "Haven't used it at that scale". Legitimately have never written a line of Go. This is part of why I made my post, to try to highlight the silliness of a lot of the "feedback" being slung around.

At the same time, I would expect the people who like it the least to have written on average fewer lines of code in Go than people who like it. It's probably like that for most languages; people tend to not heavily use tools they don't like. I've written some Go, but I have enough experience with enough languages to know I wouldn't like it any more if I were to use it more.

"I don't like it" != "It is bad"

"I don't like it" == "It is a bad tool for me". That's about all anyone ever means when they call something bad. Or it's at least all they can mean. I just think you can have a valid and informed opinion of some tool without having written 500k lines in it.

I wrote 5000 lines of java for a simple multi-user chat room server. I had a separate Java client. I replaced the server with half a page (~200 lines of Erlang) as my first attempt at using Erlang with the exact same functionality.

I still write copious amounts of Java for work and Java is still horrid.

Curious, got a link to source?

Using an existing websocket library, that chat client, with multithreading, should be a handful of lines in Java. Even writing the raw socket handling yourself, with multithreading, should only be a few classes and maybe 500 lines...

It was a fluff piece, but I’m curious if the author could give a LoC with Go’s ubiquitous, hard-coded control structure line count removed?

    if err != nil {
        return err
    }

That structure is about 7% of our lines of code.

Dang.

I have spent 3 years being employed to write Go, and i think the language is abhorrent. Once I moved to a job where I didn't need to write Go, I quit smoking.

I appreciate you adding context to your negative comment. I wouldn't really call it feedback, though, as you kinda just said "I hate it" a couple different ways.

What didn't you like about it?

Can you elaborate on why?

Writing code that does a lot of IO gets very repetetive quick - `if err != nil` is just stupid. Different libraries have different conventions on matching on errors. Then there's the inability to know if an interface pointer is valid. Comments that change the way the code is built. The type system felt like it was forcing me to expose either interfaces that are either too restrictive or too open.

So the whole "quitting smoking" thing was...a happy coincidence? Did you go cold turkey? What were the nicotine withdrawal nightmares like? I had fierce ones when I quit

Switching jobs helped a lot. Not writing Go, I think definitely helped.

At least it's not JS, the modern stack is awful and I miss the times when we used jquery and everything worked in IE6 with 2MB of RAM

Stepping from one pile into another is not a valid argument as to why standing in the original one is bad.

Go's domain is CRUD microservices, for which abstraction is generally distraction. If that's all you use it for, of course you are going to like it.

Any chance you could humor me (per my original post) and describe your professional/working relationship with Go?

Been primarily using it for two years at Google as IC.

Thanks.

That’s true, but you appear to be a test engineer at Google. Absolutely nothing wrong with that, but it’s also not the same as writing large scale services in Go so I don’t think the experiences are suuuuuper overlapping. I’m a designer and have worked at Google and seen lots of this first hand.

I didn't claim to be writing large scale services? I'm on the team with people who are though.

The code I write is adjacent: refactoring the tests so they run faster with less flakiness (guess what Go makes extremely annoying: mocking concrete types from dependencies! You must either wrap it in your own code (and continuously, manually, maintain that abstraction), give up, or alter the upstream) and writing internal services and tools. Tools are primarily in Go so we can share libraries.

No offense, but a manual tester generally doesnt have much credibility in a conversation about coding matters.

Diminishing a person's job in an attempt to discredit their feedback has even less credibility.

I don't do manual testing. (This is why the majority of people in my role hate the name).

What about writing distributed systems? Cockroach, Kubernetes, the Hashicorp stack, etcd, Prometheus

I'm most familiar with Kubernetes. This[0] would not exist if the language had sufficient expressive power. But Prometheus, Kubernetes, etcd... they're distributed CRUD. There's so. much. yaml (runtime flex types) and I believe that's in part due to the inflexibility of the language itself.

0: https://github.com/kubernetes/code-generator

The whole thing of Kubernetes is to take a goal state as data and abstract away the procedures that make it happen. You were always going to communicate with it in a data serialization format, not a programming language. It happened to choose YAML.

> You were always going to communicate with it in a data serialization format

Perhaps, it's hard to argue that a data serialization format is worse than previous alternative approaches (OLE?), but specifically a schema-less one should be up for debate? (Clearly I've become a protobuf, um, fan? Might be a bit far)

What you're trying to say is that Go's domain is mostly serverside. That's true. But it sounds too useful and ambitious, so you've modified it to "CRUD microservices". Which is silly and false, but works better as a slur on the language.

What's dispiriting here is that there are cogent arguments against Go --- decisions Go could have made differently that probably wouldn't have cost the project much in terms of its other goals of compilation speed and simplicity, but make it more annoying to work in. I switch between Rust and Go every day and miss pattern matching almost every time, for instance.

Instead, though, we get the same dumb innuendo. "It's a language for managers". "It's a language for CRUD apps". "It's a language for junior programmers". Never mind that the kernel of truth in those statements is shared by languages like Python; you can't really get away with trashing Python like that, or you'll be haunted by the ghost of one of Peter Norvig's terrifying shirts. Which is a way you know not much is really being said here, except that there's some weird turf war between Go and whatever language its haters are advocating for.

You wouldn't write a monolith in Go? I think it's fair to narrow it down to microservices (maybe just "services" though?). A lot of programming these days is translating one thing into another thing (there are several packages out there for making protobufs more efficient, f.ex.; which I think is the most I can say on the topic?). It's not a slur if it's actually good at doing something we do a lot of.

I've recently tried using it as a "better shell script for gophers" but it's still too early to say.

We've all heard the nulls, pattern matching, etc arguments already. I just think it's not that big of a pain if you are only doing CRUD and that's why it makes sense in its domain.

EDIT: I've fallen out of love with Python because it's bad at large programs (distributed or not). Didn't think that's controversial.

"Maybe just services" concedes the whole point. Yes, Go is not a good language to build a web browser in (and that's an important application domain, and we all suffer from not having a popular portable language to do that in; it's why we all run goofy Electron apps on our desktops now). But the space of all possible serverside apps is huge, and encompasses a pretty big chunk of what people actually build professionally.

There's so much more than untrusted-client<->server apps even if we find ourselves in that local maxima. Or maybe it really is the One True Way, but I think more of appliances with firmware, the Linux kernel, the apps on my phone, mainframes, 3d games, FPGAs, PL research, supercomputing... there's so many exciting applications for software! And I don't feel Go is a good match for most of it and will just cause people frustration to try.

Take a look at gvisor and come back and tell me how limiting Go is, I guess.

You're not wrong, you shouldn't be downvoted.

This is too close to my work life that I don't wish to comment on this project. EDIT: but it is a fantastic accomplishment

Of all the subdomains of serverside apps, I think "CRUD microservices" are one of the worst fits you get for Go. Fine, CRUD monoliths are even worse.

Go can get you good performance on a CRUD app, but that's probably the only advantage you'll get. On the other hand, Go doesn't have the facilities to build the frameworks that make CRUD apps so easy on languages like Java, Ruby or Python.

Go is a much better domain fit for microservices that don't do CRUD, for server and network control plane (k8s, istio, docker), configuration systems,CI/CD tools. So many things that are definitely not CRUD.

As a side note: People love to vilify CRUD apps, but they also require skill to do right. I've seen way too many botched attempts that ended up expensive to maintain and an absolute performance disaster.

What is Kubernetes control plane but CRUD against etcd?

What is an Ethernet driver but CRUD against a DMA ring?

A heap of sand minus one grain is still a heap, but eventually it's a DMA ring.

To use wikipedia's definition of CRUD, "[CRUD] are the four basic operations of persistent storage." etcd is persistent but a DMA ring is not?

But fundamentally the main way k8s resources are implemented is by observing the current state and desired state and updating the current state to be closer to the desired state, sometimes performing other actions (which are often updates on a different resource's setting)... so whether "other actions" are enough to make it not-CRUD is to the eye of the beholder.

Reply on news.ycombinator.com