Hacker News Reader

Comment by bdamm | Hacker News Reader

It's totally on point. I've been writing a fair bit of Go lately and consequently am firmly in the Generics! Now! camp. The pace of writing in this language is almost snail like, and a lot of that is due to re-implementing common idioms like popping and pushing from/to a stack and then debugging the little typos that creep in around the edges. It's freaking annoying, and it's a shame because the language is otherwise nice to work with. If it weren't for the testing workflow I'd have given up on Go entirely, just because of how annoying it is to re-implement the basics, over, and over, and over...

View on HN

I don't know. I've worked in three different languages for years on end, and they all have different pain points. C++ is too complicated, and generics are part of that complexity. Java has an ok basic language, but the ecosystem is weird and fad-prone, jumping from beans to patterns to annotations to injection, searching for the One True Way. Go is a little too simple, which sometimes leads to rewriting fairly straightforward stuff that a few clever general mechanisms would let us write once.

This experience makes me suspect that there will always be some pain point with the language. We'll never be happy; that's impossible. The only thing we can do is choose what type of unhappiness we are willing to live with.

The thing I love about Go is its fundamental clarity. It's very upfront and literal. I find it easy to understand what is happening in any particular bit of code. And I suspect that whatever complexities we add would compromise this clarity in the name of brevity. I'd spend less time being bored, and more time being puzzled or incredulous. And fundamentally, I'd rather be bored.

> the ecosystem is weird and fad-prone

Won't dispute that but did that materially affect your chosen paradigms and patterns?

When I had the opportunity to choose, I felt I could find useful ways of doing things. The problem was that I often had to accommodate myself to someone else's choices that had been made years before, and I had to understand what the heck they had done before I could make useful upgrades. And with many ways of doing things, some of which are hugely reliant on really non-obvious behavior controlled by cryptic settings in control files or annotations, that can be hard.

Have you tried C#?

No. Based on what I've read, it seems to be Slightly Different Java. Is there some important difference?

There's a number of differences, including generics done well. The team behind C# seem really engaged and transparent. The latest C#8 brings non nullable reference types, similar to how Kotlin does it.

I wouldn't call its ecosystem weird and fad prone.

C# has the feature-bloat of C++, except with a garbage collector. (I wrote C# for 9 years and even when writing it 40 hours a week, I still had trouble keeping up with all the features that continually came out)

It has nowhere near the feature bloat of C++. A C++ language lawyer can eat C# ones for breakfast.

If you compared modern C# to C++03, then maybe (although even then I would argue that templates alone are more complicated still).

> I still had trouble keeping up with all the features that continually came out)

Not that I ever had this sentiment but even if so: why would you try to do that? Most new features are tiny enhancements you can live without and the big changes (generics, Linq) you cannot do without so you they are forced anyway. ‘Trouble’ sounds like you were actually bothered by it which seems a bit over the top?

C# has become quite a big language although it manages to hide the complexity quite well compared to C++. There is very little in the language that will trip you up, unlike C++.

The only problem I have with it is it is still really Windows only, hopefully that will improve with .Net Core 3.

I have been writing stable and robust C# software on Linux and Mac OS X for many years now, so not sure what you mean. Starting with Mono and now solely .NET Core 2 & 3. I know many people who do that as well. And our deployments (all our prod/test/staging servers) went from Windows-only 15 years ago to Linux-only since 4 years.

Maybe you are talking WPF / Desktop only; there are other options for Mono but yes, there you would be right. However the trend is, unfortunately, toward browser interfaces (Electron etc) and those you can do on Linux/Mac already with .NET Core.

My experience with .Net Core 1 and 2 was that it felt unfinished. I am planning to take another look when 3.0 is released because I do really like C#.

I wasn't thinking of Desktop although I would love to see something strong emerge there (other than Avalon).

> My experience with .Net Core 1 and 2 was that it felt unfinished

Ah, curious what made you feel that. We ported massive code bases of ASP.NET and commandline tooling over to .NET Core since the 1 and had not many issues. It's a much better experience now but it never felt unfinished to me.

I have to admit that I have been writing software for a long time and one of the things I automatically do is abstract (not too far, just far enough) the underlying implementation of whatever I make/made. So our old ASP.NET code was very easy to port for that reason; I never use internals directly and still do not. For instance MVC looks more or less the same anywhere so I just use plain old C# classes as controllers so they can be reused by apps, other (non ASP.NET) frameworks, commandline, tests etc. It adds a thin layer below them so they work but it saves a lot of time and with the coming of .NET Core it proved smart once again.

In the early days, my impression was that the build tools were totally overhauled every few months, and not always in compatible ways. JSON projects, xml projects, dotnet-cli.

> The only problem I have with it is it is still really Windows only, hopefully that will improve with .Net Core 3.

I'm developing a C# application on Windows (netcore 2.1) and it deploys and runs on OSX without a glitch.

>The only problem I have with it is it is still really Windows only, hopefully that will improve with .Net Core 3.

I've been writing games in C# that run on Windows, Linux, OSX, iOS, Android, Windows Phone, UWP, AppleTV, Nintendo Switch and more for years now.

Ironically, the most compatibility issues we had was with Windows Phone and UWP.

But maybe you weren't also a C++ developer, because if you were you'd not made such a ridiculous comparison.

I'm a fan of doing the first pass for most things in a scripted language. I mean, it may not be the least bytes or fastest code, but the time to done seems to be a lot better, and usually performs well enough a second pass isn't needed.

I really appreciate what I've seen of both Rust and Go myself. They both feel more approachable than the C/C++ legacies imho. Though I haven't gone much farther than general tutorials with either.

> The thing I love about Go is its fundamental clarity. It's very upfront and literal. I find it easy to understand what is happening in any particular bit of code.

When reading Go codebase I'm not familiar with, I'm very often having a hard time figuring which interfaces go with which structs. As in "Oh, this function accepts interface Foo, which is implemented by which structures?" and then I have go on a adventure throughout the codebase to figure out what structures go in there. Really annoying.

In a language whose intention is to be explicit and easy to read (as opposed to write) I can't understand for the life of me why the authors chose to make interface implementations implicit. It seems like a decision that pretty much only has downsides and which is contrary to the overall aim. I just don't get it.

The one reason that comes to mind is that doing it implicitly lets you use structures in terms of interfaces even when those structures come from codebases you don't control .

Suppose Bob's codebase has a structure implA that implements interface A, and you want to use in terms of its interface. If the language requires Bob to declare implA as an implementation of A, you have to persuade him to do so in his codebase. But if implicit implementation is enough, then you can just use implA directly as an A with no changes by Bob.

But yes, this is a sore point. It would be convenient to be able to declare structures as implementations of particular interfaces, even if the current implicit behavior were preserved.

> Suppose Bob's codebase has a structure implA that implements interface A, and you want to use in terms of its interface. If the language requires Bob to declare implA as an implementation of A, you have to persuade him to do so in his codebase.

Not necessarily, in some lanugages you can add an interface to type even if the type is foreign and you only control the interface. I believe this can be done in Swift, Rust, F# and quite likely some others...

I don't agree with this, and I find the pace of writing in Go to be quite quick. I've recently been working on a server that performs arbitrary work pre-defined in DAGs, with an API, full tests and several fancy features. The initial bulk of the work took me about 3 weeks and the only dependency is a test mocking library.

I've been working with Go full time for 2+ years. After forcing myself to understand its philosophy and idioms, I surprised myself with not missing generics at all. The language seem to have found a nice spot, hence its success.

Strangely, I feel the day Go has generics is the day its attractiveness will start to fade away.

Do you really need to debug errors from implementing a stack? If you mean compile-time errors, I would look into getting your editor to report them while you type.

People constantly screw up the simplest and easiest things, especially when there are hundreds of simple and easy things in a program. And Go makes sure that you have to write a hundred simple and easy things every time you work with it to solve problems.

I just finished porting 50k loc from Java to Go: https://github.com/ravendb/ravendb-go-client

You won't find hundreds of purported simple/easy things that are exclusive to Go code.

There's probably less than 10 cases where I implemented some simple thing (like a set of strings) that Java gave for free because of library function that used generics.

Among 50k loc that's background noise.

don't forget the defer keyword:

from README:

// ... use session session.Close()

can be changed to this right after you get a session:

defer session.Close()

> Go makes sure that you have to write a hundred simple and easy things every time you work with it to solve problems.

This is precisely how I feel, could never capture it in words myself.

Point is you shouldn't have to implement a stack. I have never had to do that in any language I used except C. Sounds like a nightmare.

Luckily you can implement a stack in 10 very simple lines. And if you don't want to do that, there are many existing implementations.

>there are many existing implementations

Sounds like JavaScript/Node all over again, which shouldn't surprise anybody as many of the prominent Node developers hopped over to Go.

Well, not ones as efficient as the one showed here, since those can't be expressed in the language as it currently stands.

push:

  a = append(a, el)

pop:

  n := len(a)
  el := a[n-1]
  a = a[:n-1]

It took me, literally, 10 seconds to write.

Is that an O(n) implementation of pop? I hope you realize my point..

I looked it up and it's not but the point is that you shouldn't have to worry about these things, including implementation details of trees and hundreds of other data structures.

It isn't. It re-slices the backing array and retains its capacity. (Maybe that's what you looked up at the end?)

More importantly, this will take me a minute to read and two minutes to make sure it’s doing the right thing every time I encounter it somewhere new.

I don’t think I will ever understand why so many go advocates seem so openly hostile to encapsulation. If go had used C-style for loops, I swear there would be people here defending the decision saying:

    sum := 0
    for (i := 0; i <= len(a); i++) {
        sum = sum + a[1]
    }

“See? Only four lines. What’s the big deal? It took me literally thirty seconds to write.”

Did you immediately notice the bug in my above code? If not, hopefully you get my point.

Compared to

    array.sum()

was the above code more or less clear? Is it more or less prone to bugs? When reading, which code will you have a quicker understanding of the intent?

And if you did notice the the first bug, did you notice the second bug?

Well played. I noticed neither until you pointed them out. Certainly would have missed it in a code review.

This code is inefficient.

Tune in next week to find out why!

I think parent should've made their point with a queue instead of a stack.

My work has handled this with autogeneration of things like DB models. I don't know if that would be applicable to what you're doing.

So, basically, textual, non-syntax-aware macros? It's not uncommon to use such in C to define generic data structures and operations, but it's very painful to write and maintain... and besides, it has been widely considered a pain point in C for decades. It shouldn't be necessary in a modern well-designed PL.

Reply on news.ycombinator.com