Silkenweb Example: Hackernews Clone

Less is exponentially more (2012)

67 points by tpaschalis 5 years ago | 100 comments

nshepperd 5 years ago
> Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark.
> ...[rant about 'inheritance' and 'subclassing' and 'hierarchies']...
> If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition.
How do you get all the way through designing a programming language without realizing how incredibly wrong-headed this is? "Inheritance hierarchies are bad", so... you exclude generics (which are compositional, and have nothing to do with inheritance), and only support subtyping polymorphism via 'interfaces' (ie. inheritance)? That is the exact opposite of his claimed principles!
(And then as a minor concession to programming usability, he adds generics anyway, but only for built in types (maps and arrays), so advanced data structures are still an exercise in void* wrangling.)
- autarch 5 years ago
  I was thinking exactly the same thing. I don't understand how you segue from generics to "too many types are bad" to "inheritance is bad". I totally agree with the last idea. Inheritance is not a great model for code and it quickly becomes unwieldy.
  But that has nothing to do with having an expressive type system and generics.
  We can look at Rust for an example. It's "OO model", such as it is, is fairly similar to Go's. You can define a thing that combines data and behavior. You can define traits/interfaces that objects can implement. You can use those trait/interface types in place of concrete types. But Rust also gives you generics, sum types, and pattern matching. IMO, that makes for much cleaner code than doing the equivalent in Go.
- cannabis_sam 5 years ago
  The explanation is actually simple:
  «Rob Pike doesn’t know what type theory is or why it is useful»
  Look at his latest statement on «generics» in Go: https://evrone.com/rob-pike-interview
  He acknowledges that parametric polymorphism is a good thing that Go is gonna get, but then repeats his ignorant view on types by conflating type theory with shitty OOP inheritance and class hierarchies.
- jatone 5 years ago
  because generics generally are unncessary. there is a very small subset of programs where they are useful if you have arrays and maps already available.
  there was no need to rush an implementation of generics.
hyperman1 5 years ago
A few years ago I started to play with go. First impression was great. But a month or so in I started to having more and more doubts. As a Java/C++ programmer I was missing especially the generic collections. Slice and map are a good start, but not enough.
Then one day I had to implement the swap operation for sorting. Again. And I thought that even C's qsort was better, and WTF am I wasting my time on this half-assed language. I dumped it, tried rust, and even with its slow compile times I couldn't be happier.
Now a few releases later, they fixed sort so I can only implement compare. Sorry, it's not nearly enough. Essential parts are simply missing. Exhibit A is source code generation, a clear indication go isn't enough on its own. I'm not working with an ecosystem where my human time is less important than the language philosophy. I want to express a repetitive pattern in the language, and then never think about dumb bureaucratics again.
It was a near miss, though. SOme things are clearly correct. I want to look again when they finally have generics, and some basic collections. I hope that day comes and I can give it a new chance. But until then, less was simply not enough .
- throwaway894345 5 years ago
  It's interesting the things that people think are essential and the things they are willing to put up with. I'm willing to put up with writing my own sort.Interface, adding in a few lines of boilerplate for error handling, loops, and the odd linked-list/btree/etc. I'm not willing to script my own build system in an imperative DSL or deal with dependency hell a la Java, Python, C/C++, etc. I'm willing but very reluctant to use a language that requires me to write a bunch of scripts to automate publishing source code and documentation packages. I'm willing but very reluctant to use a language with minutes-long build times. I'm willing but very reluctant to use a language that where most packages are poorly documented, lacking even basic type information (looking at you, Python and JS). I'm willing but very reluctant to use a language in which the ecosystem is an absolute mess due to the pervasive use of inheritance. I'm unwilling to use a language that simply can't be optimized (and "just write it in C" or "just use multiprocessing" are only applicable to a narrow range of bottlenecks--good luck processing a large Python data structure, for example).
  This isn't Go fanboyism; I've worked with lots of languages in my career, and I still get really excited and try new languages all the time, but they all tend to optimize for nice-to-have things (such as a type system that can handle those 1-5% of use cases where Go would have you drop to interface{}) in exchange for essential things like sane tooling. Rust stands alone as a possible exception, but only since it shipped non-lexical lifetimes, rust-analyzer, and a long tail of other improvements that have recently brought its usability down into a range that is acceptable for general application development.
  - ex_amazon_sde 5 years ago
    I've worked with lots of languages as well and dependency management in Go is the worst.
    Not being able to package build and runtime dependencies with proper versioning is an incredible pain.
  - pydry 5 years ago
    >I'm not willing to script my own build system in an imperative DSL or deal with dependency hell a la Java, Python, C/C++, etc.
    Ironically, the fact go tried to make me use GitHub as a stopgap package manager (& denied one was necessary) while they built their own was what made me run away screaming.
    They've since fixed that but seeing them fail at what Perl managed in 1995 and what became standard is larger languages around the turn of the millenium in a brand new language in 2010 wasn't a great omen.
    - throwaway894345 5 years ago
      People scoff about "GitHub as a package manager", but it hasn't chafed me much. Moreover, the scoffing isn't very substantial--it's often some variation of "but GitHub goes down all the time?! You will never be able to build/distribute your software!", which is trivially refuted (the GitHub UI goes down all the time, but its git service going down is much rarer; you can use a caching proxy if you're really concerned about reliability of the git service just like you would with a more typical package repo; GitHub isn't necessary to distribute Go applications unlike Pypi/NPM/etc for Python/JS apps). There are probably lots of good reasons for why the GitHub model is inadequate, but for whatever reason these aren't brought up in the aforementioned scoffing and I haven't stumbled on them (e.g., I don't have any private repo dependencies for my projects, but perhaps it would be a PITA for those who do?).
  - winrid 5 years ago
    Go has been by far the worst language for me to deal with dependencies. Java probably being the best, especially if you factor in build times.
- spyspy 5 years ago
  The sort library has been massively upgraded since you used it. There are a lot more helpers so you don’t need to reimplement the swap and less functions for each slice type.
- apta 5 years ago
  Even if it does get generics, it's not enough to fix all the issues with the language.
  Java and C# are getting native compilation soon (GraalVM, CoreRT), and when they do, it's hard pressing to see why anyone would settle for an inferior language (golang) over mature and better designed systems.
- jahaja 5 years ago
  > I'm not working with an ecosystem where my human time is less important than the language philosophy. I want to express a repetitive pattern in the language, and then never think about dumb bureaucratics again.
  Writing code is not where time is spent. Repeating oneself, duplicating code, is fast and easy. Debugging someones code that felt like "expressing" themselves through it however, takes time, and a lot of it.
  I really have no idea why some people so often need to use generics, and similar, beyond the built-in map and slice/array, when I seemingly do not, even though I write Go as my full-time job. Sure there a lot of difference between apps/domains, but the bulk of the code is usually not that different.
  - hyperman1 5 years ago
    Partially I agree,and I'm not happy to see this downvoted.
    But more code written equals more code to read. Adding a field to a struct means modifying all the boilerplate too. It is all to common to forget just one place. Boilerplate plus maintenance attracts bugs.
    Generics are easily overused and abused, but a well placed generic can save a ton of time.
    As an example, and the pnly generic I wrote in a week, today I had to generate a ton of test data programatically in java. So I wrote roughly a 3 line method
```
  T select(int index, T... values)
```
    and used it on each of the fields with different types like this:
```
  struct.anInt=select(i,0,1,INT_MAX);
```
    This allowed me to quickly iterate trough all combinations of common and edge cases. If I had to specify all cases individually, there was no chance I'd exhaustively test every combinations.
    - jahaja 5 years ago
      I agree of course that there will always be situations where generics/expressiveness will be convenient. But my argument is about proportionality. I'd like to optimize for the 98% of the time spent, not the last 2%. It's like when people insists on buying an ultraportable laptop for work even though they'll never move it from their desk. - "But imagine how nice it will be that time I'll be on the train!".
  - qppo 5 years ago
    Have you ever worked with sequences/iterators/generators or their abstractions? They make incredibly composable, portable, sound, and readable code. And most useful programs are built on patterns that can be optimally represented using them.
    They're also impossible to implement and extend without generics.
    If your mental model of writing a program is giving instructions to an abstract machine, generics may seem pointless. However if you're interested in representing a problem and its solution, and allowing the language tooling to translate that into an optimal list of instructions for an abstract machine - generics are pretty critical.
  - s17n 5 years ago
    Kinda sad that this is getting downvoted, regardless of whether you agree it is certainly a cogent argument.
    - NoodleIncident 5 years ago
      Whatever argument it's trying to make would have been better received without the blatant insults.
nobleach 5 years ago
While this philosophy has a lot of value, it just isn't for me. I did a few apps in Go, and fought my way to a decent level of proficiency. I got to a point where I could solve some problems without constantly consulting the docs. But in the end, I wasn't enjoying the experience. The speed was great, the compilation was great. All the selling points were true. But it was missing so many things that I enjoyed using from other languages. (Mostly methods for dealing with collections of data - everything in Go is a for loop). I did another project in Kotlin shortly after and wow, that language has everything AND the kitchen sink! But, I truly enjoyed myself more while working with it. So, this is not me saying Go is "bad". It's actually quite good. It's just not something I enjoy.
- LandR 5 years ago
  I feel the same, we are starting to use Go now and I really don't like it.
  Things that in other languages I can do in half a dozen lines of code, I find I'm writing 4x time more in go.
  And I find it pretty unreadable, it's not nearly as expressive as other languages I enjoy using.
  There's too many missing features I use heavily in other languages that make my life easier that I really miss them in go.
  I will say I do like that its opinoinated on the formatting. Just takes away an entire tiresome argument.
  - eriktate 5 years ago
    > And I find it pretty unreadable, it's not nearly as expressive as other languages I enjoy using.
    I tend to conflate higher expressiveness with being "clever" until you're really proficient in the language. I think Go's main value prop is that it performs well with very little ramp up time compared to languages with more powerful features.
    If you have a team of people who are really strong with something like OCaml or Scala, they'll be amazingly productive. But if you have a rotating team of engineers with varying backgrounds, it's hard to beat Go when you're talking about time-to-productivity.
    - sanderjd 5 years ago
      The basic set of more expressive operations (like map, filter, and reduce/collect) are not "clever", they exist in lots of "boring" languages, not just languages like OCaml and Scala. It is true that their semantics must be learned, but this is also true of the semantics of for, while, if, switch, function(), object.method(), etc. etc. We don't lament that learning how function calls work is lengthening the ramp-up time of people who already know how to write straight-line code and jumps.
    - ieRei6ae 5 years ago
      > if you have a rotating team of engineers
      That's the problem: burning out engineers.
      Google has been developing a language to make it easier to change cogs in the machine.
      The quotes from Pike are pretty clear:
      http://nomad.uk.net/articles/why-gos-design-is-a-disservice-...
  - sanderjd 5 years ago
    To the "everything in Go is for loops" point of the parent, I really think the value of higher-level abstractions of common loop patterns are often underrated for readability and correctness. The advantage is that it is a lot more obvious when code veers from the pattern, which alerts the reader to spend more time thinking through what it is actually doing. Put another way, it is easier to write a for loop that looks like a 1:1 map from one set of values to another but actually does something a bit different, than it is to write a map operation that does something besides mapping.
  - tpaschalis 5 years ago
    I think you're right regarding the verbosity, but I personally find this is outweighed by the fact that my code is 2x more likely to run correctly on the first try, and do what I expect it to.
    - goatlover 5 years ago
      2x more compared to ... C++, Java, Python/PHP/JS/Ruby, Haskell? Which kind of language is the comparison?
- tpaschalis 5 years ago
  Of course it's a matter of preference and being the right tool for the right job! Personally after using Go to build a simple ray-tracer and having to do numerical computations with it, I would really think twice before doing it again.
  Want to reverse an array? You can't just list.reverse() or list[::-1] like you'd do in Python. Want a simple lookup if a value exists? You can't ['a', 'b', 'c'].include? 'a' like you'd do in Ruby. Want to reach for low-level primitives? You'd have to delve into CGO territory, which is not always "elegant". Want different concurrent paradigms (eg. an actor model), well, maybe you're better off without it.
  But it's up to you whether that kind of 'simplicity' is desirable or not.
  - fwip 5 years ago
    One of the things that Go tries to do is keep you from accidentally calling expensive operations.
    Testing for membership in an array is O(n) in almost any language - and there's a lot of new coders who will happily call it inside a loop. My second internship, I reworked an O(n^4) method to O(n^2) for some code written in R by a senior statistician. This raised the feasible N from 4 to about 13 (in terms of what results you could get in two or three days of compute).
    Google doesn't want anyone making that mistake in production, where throwing more servers at the problem costs a whole lot of money. And they hire a lot of junior devs.
    I'm sure as somebody who's writing their own raytracer, you know the performance cost of this lookup intimately, and you've made the performance trade-off when picking your data structures. (E.g: maybe the include function is called rarely, or it really is just 3 items, etc). But Go is made for teams of varying skill levels, and so it takes the position that doing uncommon things should take some extra work.
    - nobleach 5 years ago
      I absolutely get, and appreciate that. I'd never tell anyone NOT to use it. I'm simply sharing my own experience as I've been asked several times if I've ever considered Go for new services. I certainly have. I've produced. I just would choose not to do it again.
- metreo 5 years ago
  Less is more... until you need more.
free_rms 5 years ago
Pike's take is pretty unfair to C++11, given how ideas like 'rvalue references' held up REALLY well.
Yes, they were introducing even more complexity to a complex language, but how else are they supposed to incorporate better ways of doing things while maintaining backwards compatibility?
I suppose one could always just build a new language that doesn't have the historical cruft, but in this case that's Rust and not Go.
ses1984 5 years ago
>Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I'm a philistine about types but I've never found that model particularly expressive.
Whoa, hold it there... inheritance and subclassing are OOP, types is a different subject, right?
- ChrisSD 5 years ago
  To be honest programmers have a habit of being very loose with language. Terms like "OOP" and "types" have very context dependent meanings. Given the context, I took him to simply be talking about people coming from "class-based" languages, not anything to do with types in general.
  - fernmyth 5 years ago
    > To be honest programmers have a habit of being very loose with language.
    I wish this weren't true. It's quite damning.
    It's less bad in a real-time conversation, with fast feedback about how well we're being understood. But it still hints that we don't have the concepts clear in our own minds.
  - ses1984 5 years ago
    Yeah but it feels almost like a strawman, it feels out of place.
- acarl005 5 years ago
  Yes, he has conflated generics with inheritance/hierarchies. You can have generics without the mess that is inheritance.
- dhsksndjsb 5 years ago
  OOP involves a type hierarchy, which is a prerequisite for giving meaning to the idea of inheritance. You can't talk about classes without actually talking about types, and inheritance creates a type hierarchy.
  From golang documentation:
  "Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy. The concept of “interface” in Go provides a different approach that we believe is easy to use and in some ways more general. There are also ways to embed types in other types to provide something analogous—but not identical—to subclassing. Moreover, methods in Go are more general than in C++ or Java: they can be defined for any sort of data, even built-in types such as plain, “unboxed” integers. They are not restricted to structs (classes).
  Also, the lack of a type hierarchy makes “objects” in Go feel much more lightweight than in languages such as C++ or Java."
  - pjmlp 5 years ago
    Nope, it depends pretty much on the OOP language, there are a couple of CS variants to chose from.
acarl005 5 years ago
Whenever the topic of generics comes up, especially in Go, things seem to devolve into a ragefest about inheritance and OOP. Why? I don't want the mess of inheritance any more than the next chap. I just want generics for algebraic types—a single definition for a List, Set, Map. I wish the error-handling looked more like Rust's Result type instead of the double-return idiom. Algebraic types alone (without inheritance) make things an order of magnitude more expressive.
- ansible 5 years ago
  > I wish the error-handling looked more like Rust's Result type instead of the double-return idiom.
  After this and a few other issues I had with Go's design, I just started learning Rust. Though I hear good things about Swift these days, hopefully they will provide full support for all popular platforms in the future.
  - tonyedgecombe 5 years ago
    Swift is nice but I don't see it making much sense outside of the Apple ecosystem.
    - winrid 5 years ago
      It's a wonderful language. I'd love to work with it server side it I found said job.
MereInterest 5 years ago
For any new language that I learn, my go-to thing to try is to implement 4th-order Runge-Kutta solving of an ODE. This implementation must be usable for both built-in types and user-defined types, and must have reasonable performance for the language.
* C++, easily doable with templates.
* Python, easily doable with duck typing.
* Rust, doable, though with some restrictions. I needed to require the derivative function to return the same type as its input, rather than returning something that can be scalar multiplied and added to the same type as the input.
* Java, not possible. Adding/multiplying of built-in types can be done with + and * , but user-defined types require .add() and .multiply()
* Go, not possible. Go doesn't support generics, and I'm certainly not going to copy/paste a numeric method once for every system that I examine. Also, same issue as Java with no operator overloading.
Complexity has to go somewhere. By aiming for a simple language, Go forces the complexity to be in the developer side instead.
FpUser 5 years ago
"People who are excited about C++11's new features are not going to care about a language that has so much less. Even if, in the end, it offers so much more."
I find Go too limiting and definitely not offering "so much more". The author is probably right mentioning "big teams". Sure if I have whole shebang of programmers each nibbling at small particular task and appropriate budget it will work. But comparing the amount of work per developer per time I can have with more sophisticated "traditional" languages does not put Go in any good standing in my opinion.
greendave 5 years ago
> What you're given is a set of powerful but easy to understand, easy to use building blocks from which you can assemble—compose—a solution to your problem. It might not end up quite as fast or as sophisticated or as ideologically motivated as the solution you'd write in some of those other languages, but it'll almost certainly be easier to write, easier to read, easier to understand, easier to maintain, and maybe safer.
I really like go, and I daresay it makes many things easy to implement and understand, but I do find the flexibility/lack of sophistication allows one to end up writing what amounts to improved C. Great for smaller projects, but surprisingly difficult to manage as it grows.
pot8n 5 years ago
Golang didn't succeed because it is simple or powerful or any of the, I apologize, nonsense your hear from the Gophers. Golang succeeded because it was the only available relevant option and alternative to the aging Python and Java when the cloud took off in the early 2010s.
- AnimalMuppet 5 years ago
  OK, but for Go to succeed in that environment, it had to be better than Python and Java at programming for the cloud. It doesn't matter that Python and Java were "aging" - programming languages don't die from old age. Go had to be better than what was there.
  And in what ways was it better? Power and simplicity (at least for writing those kinds of programs).
  - sl1ck731 5 years ago
    Why did it have to be better? It just had to be created and evangelized to a specific group (and likely because it was by a specific company). I don't think it has anything to do with "better" in one way or the other.
    Developers are constantly looking for new languages to fiddle with without any objective reasoning.
    - AnimalMuppet 5 years ago
      Sure, they're looking for new languages to play with. They're not looking for new languages to write major projects in, though. You write major projects in languages that you have already fiddled in, and the fiddling has given you confidence that they're up to the task. Nobody (sane) sees a publicity blurb and decides to bet a major project on it.
      Don't confuse "they came to a different conclusion than me" with "they're sheep".
  - dunefox 5 years ago
    It didn't have to be better (since it isn't), it juset had to be backed and pushed by Google.
- pjmlp 5 years ago
  Go is basically Limbo combined with Oberon-2 method syntax, two very successful programming languages from Bell Labs and ETHZ respectively, hence why Go was such a guaranteed success.
  - AnimalMuppet 5 years ago
    First, combining two successful languages in no way guarantees success. (Imagine combining Lisp with C++ syntax.) There are lots of ways to do it where the whole is less than either of the parts.
    Second, you seem to have a strange definition of "success". Limbo was a success? Well, some people used it, and some software got written in it, and some people used the software. Not much software and not many people, though, in the grand scheme of things. Same with Oberon-2. Even if you consider those two languages to have been successes, Go is a far greater success - it's successful in a way that neither Limbo nor Oberon-2 ever were.
    - pjmlp 5 years ago
      Exactly, that is why it was needed to add the Google branding into the mixing potion.
      Had Go been created at Bell Labs or ETHZ, and it would have shared the same fate as its influences.
      You missed the sarcasm on my comment.
- decebalus1 5 years ago
  I don't think I agree. Anecdotally based on what was happening at companies I worked at which used Go, I think the main reason for its success was Google cargo-culting.
- ggregoire 5 years ago
  Isn't Golang as simple as Python while being as powerful* as Java?
  * I guess many people will disagree for the lack of generics (among other things), but the compiler and static types are powerful tools.
oftenwrong 5 years ago
This does a poor job of justifying the claim that golang is more expressive despite having fewer features than similar languages. I agree to a certain extent that golang's simplicity is an advantage. However, its simplicity does actually make it less expressive.
For example, in Java one can trivially create a class like `Maybe<T>` with a method `Maybe<R> map(Function<T, R> mapper)`. This can be used with any classes filling in the parameters. I believe golang is unable to express this.
smoorman1024 5 years ago
I've been working in golang professionally for about a year now coming from a long career in C++. Although there is some simplicity to golang that can be appreciated things like this below make me think that the premise of less is more is fundamentally incorrect if you cannot accomplish everything that is necessary.
https://github.com/protocolbuffers/protobuf-go/blob/master/i...
Specifically the last one of embedding an empty array of mutexes into a struct prevents that struct from being copied. This is something that is easily and explicitly accomplished in C++ by making the constructors private.
api 5 years ago
I love Go for this reason. It minimizes it's own cognitive load, freeing the mind to spend more time thinking about being clever solving the problem rather than being clever with the language.
I also adore goroutines and miss them in any other language. They are really fibers and let you do light concurrency without fiddling with async constructions. Async programming is just an ad hoc way of implementing fibers, and it imposes more cognitive load because now you have two different approaches to every problem in the same language (one async, one not).
IMHO minimizing language-imposed cognitive load should be a core goal of any programming language. Human brains are finite, and programmers should spend the majority of their mental energy thinking about the problem being solved not the language.
- wahern 5 years ago
  Unfortunately a substantial number of people seem to suffer from a type of concurrency Stockholm syndrome. They prefer explicit and awkward concurrency constructs, perhaps because until Go, mainstream languages like JavaScript, C#, and Python implemented hacks largely because of implementation constraints, so it's all they know. They say thinks like, "I prefer knowing exactly when I might block". Yet you never hear them bemoan the fact that the OS hides process scheduling and VM paging; they don't complain that they can't hook into this at all, let alone be forced to do it 100% of the time for even the simplest code. They never ask that their language force them to be explicit about how and when a simple function call will setup a new stack frame. All of these things were, decades ago, the equivalent of fibers (or more generically asymmetric stackful coroutines). People were likewise skeptical about those things, but today these innovations--function calls, preemptive scheduling, virtual memory--are ubiquitous and invisible and the notion of doing away with them completely or even as default semantics, for all basic programming, would be inconceivable. What small cost they impose upfront by being the default (and often only) construct is vastly outweighed by their power; they're undeniably the correct way to model the vast majority of computing problems at the level with which they're concerned.
  I agree, goroutines (or perhaps something a little more generic that doesn't conflate stack reification with scheduling) are absolutely the correct abstraction, and this will be proven in a few decades time. But until then we're stuck with people rationalizing the limitations of async constructs in their favorite languages; constructs primarily chosen because of quirky design constraints, principally C interop and C-based VM implementations that leak the semantics of the C ABI stack.
  - apta 5 years ago
    Java is going a similar route (project Loom), but they'll be implemented in a better way. Things like timeouts in golang are awkard to enforce, and monitoring hierarchies are not built-in. Java's Loom is already getting both.
    - hactually 5 years ago
      Getting getting getting, every time I head about how Golang is spanking other languages I see the "BUT MUH JAVA IS GETTING X IN Y $MONTHS".
      If you really can predict the future please tell me lotto numbers rather than being abrasive.
vorpalhex 5 years ago
I code in Javascript/Node, and I also code in Go. They're both very useful tools and they're useful in different ways. I find Go to be a good tool when I know what I'm writing and I have clear forms in each step.
jasode 5 years ago
Previous discussion since the HN "past" link doesn't bring up the prior thread because tld was ".de" instead of ".com" : https://news.ycombinator.com/item?id=6417319
DLA 5 years ago
I'm going to jump in and take a hard Pro-Go stance. Based on experience developing for more than 5 year with Go and deploying systems around the world--in-house hosted and cloud.
I have immensely enjoyed the "less is exponentially more" philosophy with Go. In Go there is one or a small number of way to do something. Contrast that with C++ where there are any number of ways to do something and at least as many styles of coding. Too much choice results in complexity.
IMO the generics debate is overblown. The systems I've build with go tend toward heavy data processing (ETL, correlation, extraction and the like) and service (JSON APIs supporting front-ends; event some front ends with Go Templates). Never once was I like "my life sucks because I don't have generics." Fair and balanced: Processing JSON in Go takes some getting used to, especially when the JSON structure changes. However, there are some good libs to help. It's just a friction point given the typed nature of Go.
The operational simplicity of Go cannot be overstated. Go's production of a deployable binary with zero dependencies is a blessing. There's an amazing deploy tool you can use called: cp. Compare that to the library version hell that is C++ (and I'm also a C fan and very experienced dev). No. Thank. You.
The cross compilation of Go code works beautifully. Just 2 weeks ago I had to demonstrate a tool to a customer and due to COVID it was virtual. We had problems with MS Teams connecting to our dev platform so literally 15 minutes before the demo I cross-compiled to a Win binary and moved it to the machine hosting the Teams call. Victory.
Because of go fmt, all Go code looks the same. That's a massive advantage to read/understand/use OPC (other people's code). Ditto for the automatic documentation generation -- it looks the same and behaves the same across Go projects.
I abhor the Java ecosystem for so many reasons I just don't have the energy to go into. It's my opinion, so not up for debate. If Java works for you, by all means have at it. Robust solid technology for sure. Not hating here; just choosing.
So, my Go journey has been and continues to be fantastic. It is my preferred platform for pragmatic reasons--the same sort of reasons it was developed by Google in the first place. My team and I can get stuff done quickly. We can scale it. We can leverage all the CPUs on a box running big data processing flows. We can have automatic code-linked documentation and formatted code and can leverage the same from others. We have build in testing. We can make high performance services and servers with ease. We don't have to deal with ridiculous configuration nonsense. We get instant compilations. We get great tool support (vscode + Go for the win). We get a batteries very much included stdlib.
And most of all we get a platform that understands and managed complexity in a favorable way.
$0.02. Ok, maybe $0.05 (inflation).
- dunefox 5 years ago
  > I abhor the Java ecosystem for so many reasons I just don't have the energy to go into.
  If you can gather some energy, I'd be interested in that.
  - DLA 5 years ago
    Like I said there's nothing wrong with the stack. I was ONLY speaking of my personal preferences why I choose not to Java when I can Go: Just personal preferences.
    -- Compile times!
    -- Operational complexity vs. Go.
    -- Built-in tooling vs. Go.
    -- Verbose XML configuration files.
    -- Lots of libs favor XML vice JSON.
    -- Deeply-nested code directories.
    -- Class-centric model (only).
    -- Verbosity and boilerplate.
    -- Factories of factories of factories. :)
    -- JVM install and config (many dials = control but also complexity).
    -- Impractical / painful to write without an IDE.
    -- Concurrency model, as compared to Go.
    -- Std lib not matched to work I use Go for.
    -- Memory consumption.
    -- Performance (for the work I do).
    -- Multiple inheritance (allows unnecessary complexity).
    -- https://astaxie.gitbooks.io/build-web-application-with-golan... vs. https://medium.com/@ssaurel/create-a-simple-http-web-server-...
    -- Oracle.
    (edits: reformat pretty; compile times)
    - apta 5 years ago
      > -- Compile times!
      golang compile times are similar for any non-trivial project. Ironically, they're even much worse than Java's for quick changes (e.g. change a single file then recompile to run tests) since golang has to spit out a binary that is in the 10s of MBs compared to Java which just needs to change a single class file.
      > -- Operational complexity vs. Go.
      The JVM is superior for operations, observability, and monitoring to anything that golang has to offer.
      > -- Verbose XML configuration files. > -- Lots of libs favor XML vice JSON. > -- Factories of factories of factories. :)
      Nothing to do with the language.
      > -- Deeply-nested code directories.
      I've seen the same in golang code due to its packaging.
      > -- Verbosity and boilerplate.
      golang is more verbose and error prone for any non-trivial code base
      > -- JVM install and config (many dials = control but also complexity).
      The JVM is configurable and gives the user the ability to tune his program (say latency vs throughput), unlike golang which doesn't. Secondly, you can compile to native code using GraalVM.
      > -- Concurrency model, as compared to Go.
      Java is getting green threads (see project Loom), and they'll be superior to what golang offers.
      > -- Impractical / painful to write without an IDE.
      Irrelevant for any non-trivial code base, since golang needs and IDE as well.
      > -- Std lib not matched to work I use Go for.
      let's see what golang has to offer anything remotely similar to java.util.concurrent.*
      > -- Memory consumption.
      Depends on how you set up your JVM (Xmx, GC settings, etc.). Java is getting value types soon to address this even more.
      > -- Performance (for the work I do).
      They're on par, and for any non-trivial code base, Java tends to be faster.
      > -- Multiple inheritance (allows unnecessary complexity).
      Java doesn't support multiple inheritance.
  - winrid 5 years ago
    Same!! Although, an experienced C++ dev might just abhor the thought of pointer chasing everywhere, even if it's not a big deal in 90% of web backends.
westicecoast32 5 years ago
I'm writing a language. I was wondering what you all suggest it have before you would seriously try it out? I don't think most people cares about syntax; does it need to be attached to a large project?
The beta of the last language I wrote had maybe half a dozen fans. I threw away the compiler/language because I didn't really know how to write a compiler back then. I'm writing a new one now
dang 5 years ago
See also:
https://news.ycombinator.com/item?id=16548684 (2018)
https://news.ycombinator.com/item?id=6417319 (2013)
Discussed at the time: https://news.ycombinator.com/item?id=4158865
abjKT26nO8 5 years ago
Needs "(2012)" in the title.
kenforthewin 5 years ago
Please tag this with the date, 2012. Great but old blog post.