Hacker News Reader

Comment by pcr910303 | Hacker News Reader

(Not directly related, but) The article reminds of a recent article named 'Why Go Getting Generics Will Not Change Idiomatic Go'[0].

Using functional programming in Go... just doesn't look right. Generics are useful, but won't change the whole Go ecosystem into FP. Maybe some uses of Map might make sense, but... idiomatic code will look the same.

[0]: http://www.jerf.org/iri/post/2955

View on HN

of course it will change ideomatic go. there is no reason to think otherwise. just look at javascript or c++. both languages transformed heavily and nowadays people look at you strange if you write 'var' in js or use a raw pointer in c++. :-)

so Go will change and i think that sucks hardcore. there are already enough languages where folks can go crazy with types, fp, monads etc. My selling point for Go was that it was mega restricted :-)

(I'm the author of that piece.) It will change what some people insist is idiomatic Go, but my contention is that when this all settles out, call it a year after production release of the generics, the community as a whole will generally come down against "functional style" programming in Go, and people who want to program functionally in Go will discover that they continue to be quite frustrated because you need half-a-dozen more features.

It's going to be so verbose and unfun in Go that only very stubborn people are going to stick to it anyhow. I'm not saying that because I hate the style, I'm saying that because it's still going to be a lot of boilerplate wrapped around not much payload. It really won't be fun. I like "map (f1 . f2 . f3)"; the equivalent in Go even post-generics will be crazy full of boilerplate and garbage.

It will change some aspects of idiomatic Go. I don't care much at all about the "functional" aspects but I am greatly looking forward to a proliferation of more specialized data structures that are type-safe. I think one of the major weaknesses of Go in what is arguably its wheelhouse, network servers, is that network servers are often precisely where I want some obscure data structure with the performance characteristics I need to scale up some service properly. It's true that the dynamic scripting languages showed us that you can get a long way with arrays & dictionaries, but I'd like some more stuff. I've got a few places a "map" would be slightly convenient, but I've got several places where I've got architectural problems because I had to hack in an immutable data type or tree or something else that I'd much rather be using a bullet-proof, community-tested implementation of a type-safe data structure than some subset I smashed together and lightly covered with unit tests just to do this one particular job. This is the change I'm actually looking forward to. I've also got some channel pipelines that, while they are set up and working, would be easier to understand with some helper functions that could deal with them.

I am also looking forward to either using or writing a very simple concurrent pipeline that specifies a set of transform functions and the number of workers to start up for each and takes care of actually bringing up the network correctly. Or implement structured concurrency: https://vorpus.org/blog/notes-on-structured-concurrency-or-g... Go may never enforce this but I'm tempted to try to enforce it in my programs.

Java is still an excellent option in many respects.

Notably it has: - mature generics - streams - exceptions - rock solid for server apps - some FP style libraries - good timing - probably the widest universe of libraries

Only downsides are, 1) JVM startup times and 2) it's not the newest shiny thing.

I looked at the whole language comparison recently for a greenfields project. While initially optimistic, I was surprised how many capabilities some new alternatives are missing, and by the enthusiasm to write thousands of lines of low value C-style error checking.

An architectural assessment: Above a trivial level of software, the majority of code composes something that can fail. Exceptions are an ideal mechanism for this general truth.

I have thought before that if Java's interfaces worked like Go's did, with implicit satisfaction instead of having to declare explicitly, that there would probably be no Go. If I could go back and change one thing about Java, that's what it would be. I know there's other more obvious pain points that most people would pick, but I think this is a subtle one that undergirds several of the more obvious ones.

(To be clear, I am aware that Go and Java still have differences beyond that; my claim is that with this change Java would have been "good enough" that Go either never would have been spec'd or it never would have gotten any traction if it was. Java, however, has left a significant window open for Go because it has gained traction.)

The problem with the way Java does it is that it forces a temporal dependency between interface and implementation, all to avoid a programmer error which on average will happen less than once per programmer career: http://www.jerf.org/iri/post/2954 This causes a lot of gyrations to be necessary to use them properly, which starts introducing the desire for heavyweight ways of autogenerating this, etc. and roll around that cycle a few times and that's how you end up with as much XML as code in your codebase.

I think Java and Go are a really interesting case study for people interested in programming languages, because on paper they are virtually identical languages (especially if you ignore channels and select in Go), and it gives a clean demonstration of how even those not-very-large differences end up having a profound effect on how solving problems in those languages are best done.

I mean the GC pause times and static binaries are huge to me as well vs java. go is just a better languages to develop with in my mind. I have to spend less time optimizing and more time getting shit done.

thanks foe the reply and i understand your sentiment. i think what will happen is that people will start advocating for more and more syntax changes. think of => in js instead of function. a minor tweak but with HUGE impact. probably much more than const/let etc. and eventually more and more of this will change the language.

but i hope i am wrong. :-)

in general i get your point amd agree with it. i have written large go codebases and ran into exactly the same issues. but i wouldn't agree to the trade off :-) then i would have used Rust in the first place I guess

"i think what will happen is that people will start advocating for more and more syntax changes. think of => in js instead of function."

They won't need to start; hit the Go issue tracker to see a whole bunch of them have already been made and rejected. People have been advocating for them for a while. I virtually guarantee that of all languages, the Go team will not change their mind in response to existence of generics for them. Their bar for accepting changes is very, very high. It is not insurmountable, but it is very high.

Remember, Go didn't come out yesterday. Go is now over ten years old. We have a good idea of the velocity of changes it makes. It is low.

At the end of the day, if you want to program immutably or in such a way that is declarative and introspectable, you best look to FP for prior art in those sorts of spaces. Certain problems are age-old child's play in FP-land.

Reply on news.ycombinator.com