Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eight years of Go

blog.golang.org

Post reply on HN
Print view View original

211–220 of 291 posts

Re: Eight years of Go

#211

Post by coldtea »

jhjwe888 wrote: post #120
rdsubhas wrote: post #41

Earlier quoted context omitted.

I'm not sure what you mean by vocal minority's complaints. Golang generics is the second most voted issue on GitHub itself: https://github.com/issues?q=is%3Aopen+is%3Aissue+sort%3Areac... (I'm not sure if GitHub sorting is broken, but the same issue has more +1s than the top +1d issue as per that sort mode as well) Generics has the most experience reports in Go 2 proposal. Maybe this can be categorized and excluded a…

It should be obvious to folks on HN why a Github issue that may go completely unseen by a large swath of the go community, or +1's which can be gamed/trolled, should not be taken as a valid measure. But it must be explained I guess.

Confirmation bias much?

Re: Eight years of Go

#212

Post by therealdrag0 »

dilap wrote: post #162
MrBuddyCasino wrote: post #19

Earlier quoted context omitted.

Java has some flaws, but slow compilation is not one of them. Incremental compilers are available and pretty much eliminate pauses.

Really? I've recently been recruited to pitch in on a Java project, they're using maven, and the compiles sure aren't incremental. What should we be using instead?

Eclipse or IntelliJ IDEs will compile while you code (like C#). Depends on the project setup and dependencies. But I've found that this works for most development until I need to produce an artifact. Then I run maven which does a lot more than just compile code and usually is longer than 40s.

Re: Eight years of Go

#213

Post by camus2 »

bsaul wrote: post #191
camus2 wrote: post #82

Earlier quoted context omitted.

> while paying much less attention to the vocal minority's complaints That's debatable. Those who can't stand the language don't bother using it,therefore don't bother complaining about it. My point is Go biggest critics have already abandoned the language long ago. Go reminds me Rails. It had a huge success 8 years ago but since all other languages have caught up when it comes to RAD webdev. The JVM and others will…

i don't think you can "catch up" with go, because it has aimed at being minimalist. catching up by removing major features to a language isn't something i've ever witnessed.

> because it has aimed at being minimalist.

You can absolutely catch up with the concurrency model, on the single binary deployment, and a other features. Go isn't "minimalist", that's false, go look at the reflect package, it's complex as hell.

Re: Eight years of Go

#214

Post by christophilus »

dilap wrote: post #162
MrBuddyCasino wrote: post #19

Earlier quoted context omitted.

Java has some flaws, but slow compilation is not one of them. Incremental compilers are available and pretty much eliminate pauses.

Really? I've recently been recruited to pitch in on a Java project, they're using maven, and the compiles sure aren't incremental. What should we be using instead?

Gradle? https://gradle.org/gradle-vs-maven-performance/

Re: Eight years of Go

#215

Post by kibwen »

tedunangst wrote: post #200
steveklabnik wrote: post #172

Earlier quoted context omitted.

We’ve actually worked a lot to ensure that Mozilla can’t dictate what happens with Rust; we run a consensus based process, and while Mozilla has the largest single group of people involved in leadership, it’s still a very stark minority. As a huge production user, Mozilla’s needs are still important to us, but we think of Rust as an open source project Mozilla contributes to, not a Mozilla project per se.

I wonder if this is good or bad. Sometimes it helps to have that singular vision. I think here of all the systems C coders I know, who have never used complex numbers, yet that finds its way into the standard.

As a Rust user outside of Mozilla, it's very good. Rust would have had a hacked-on OO system solely in order to implement the DOM in Servo if browser engine hackers were the only ones with a voice. :P

It's fair to be concerned at the potential evolution of a language that doesn't have a BDFL (I myself came to Rust from Python, after all), but in practice I've come to trust the Rust devs as having very good taste (objective, I know!) and a strong resistance to maximalism (regardless of what some may claim... the list of features removed from the language is longer than the list of features that it has!).

Re: Eight years of Go

#216

Post by dboreham »

slrz wrote: post #173
dekhn wrote: post #38

Earlier quoted context omitted.

Complaints about generics aren't coming from a minority group. It's a majority now.

Thank deity Go language design is not done by popular vote. If you want the Trump of programming languages, you probably have to look elsewhere.

Electoral College?

Re: Eight years of Go

#217

Post by z0r »

kjksf wrote: post #159
terminalcommand wrote: post #114

Earlier quoted context omitted.

I've run into concurrency problems using maps while writing an irc client. It was really frustrating for me, because it did not happen everytime I ran the program, but rather rarely. I had chosen Go for it's memory-safety and easy concurrency. But I felt like I could not vouch for my program's safety any more. I did not know about sync/map at the time, had I known, I would probably have used it. I think Golang has a…

For concurrency issues, -race flag is your friend. Don't blame the language for your buggy code. Unless otherwise stated, Go's data structures are not thread-safe. Maps are not thread safe. In that respect Go isn't different from any other mainstream language with pre-emptive threading (C++, Java, C#).

go, a language which comes with many built in concurrency primitives, has chosen to leave its core datatypes thread unsafe (the magic ones with generic powers) and gives no sensible tools to remedy this with. this is one of the many ways in which it is a language hostile to its users.

Re: Eight years of Go

#218

Post by z0r »

cube2222 wrote: post #189
ryanplant-au wrote: post #163

Earlier quoted context omitted.

I groan every time I have to implement the 15th type-specific loop implementation of what I'd do with a single map or fold in Ruby/Elm/Haskell/JS/TS/Crystal/every other language I use. It's not a lot of effort but it's a lot of mess and cruft.

Check out goderive

linking this for you: https://github.com/awalterschulze/goderive

i wish i could laugh, but i can't. the lengths people will go to work within such an impoverished language, and by means so antithetical to the go philosophy.

Re: Eight years of Go

#219

Post by feelin_googley »

nine_k wrote: post #7

Go is an example of how to be extremely successful by catering to the needs of the project's core audience (well-rounded stdlib, extremely fast GC, short build times, trivial deployment, etc) while paying much less attention to the vocal minority's complaints (generics, package system, etc).

"... trivial deployment, etc.)..."

Does this refer to static binaries?

What amazes me most about Go is that they managed to successfully pitch a C-like systems language that does not promote use of shared libraries. About six years passed before they added an option to create them.

Were there many complaints about the absence of shared libraries originally?

Whenever I have mentioned the benefits of compiling C programs as static binaries and that in some cases with todays hardware one can have enough memory that shared libraries may not be necessary in order to conserve memory (one of the original goals of shared libraries), I have encountered substantial resistance to the idea. Perhaps some folks are interested in shared libraries for reasons other than memory conservation.

Re: Eight years of Go

#220

Post by preordained »

mattmanser wrote: post #196
tqkxzugoaupvwqr wrote: post #89

Earlier quoted context omitted.

In Go’s philosophy most problems are not exceptional. File can’t be opened? This is to be expected on systems with file permissions. The common pattern is for functions to return an error type as last return argument (Go supports returning multiple arguments). Programmers can then handle the problem right then and there if the error is not nil. This approach also helps to keep control flow straight forward. The happy…

It's actually pretty common for a file exception to be exceptional. In all programs I've ever worked on you don't want to have to check useless junk like that and just want the general exception handler to handle it.

This isn't true at all depending on your work. I program software that has to work alongside other programs on busy file systems...failing to read/write a file is not someone else's problem...it needs to be handled, logged, there is potentially a retry and/or notification.
Post reply on HN