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

Go: Ten years and climbing

commandcenter.blogspot.com

Post reply on HN
Print view View original

151–160 of 193 posts

Re: Go: Ten years and climbing

#151

Post by aaron-lebo »

kod wrote: post #148
staunch wrote: post #20

One of Larry Wall's slogans for Perl is "Easy things should be easy, and hard things should be possible." In its own way, that's what has made Go the kind of success that Perl once was. Perl was the glue language of the web and Go is the production language of the cloud. I'm actually a bit scared to imagine a world in which Go was not created, given how much success I've personally had with it. Thanks to the entire G…

This is a bad comparison. Core philosophy of Perl is to empower programmers with more than one way to do it. Core philosophy of Go is your coworkers are too stupid to be allowed to have nice things.

Seems like the core philosophy of Go is the end result of Python's "there's one way to do it".

The "Go's design and users are dumb" meme needs to die. It's not even a constructive criticism. It's dishonest, insulting, and it's too bad grown adults and professionals can't see beyond it.

Re: Go: Ten years and climbing

#152

Post by aomix »

flavio81 wrote: post #31
aomix wrote: post #26

I appreciate the ruthless design choices behind Go. Crafting a language so there are as few ways as possible, and preferably one, to solve a problem must be beautiful at a large scale organization. In my experience java codebases in big companies are nightmare factories because of the freedom you get from more similar languages. The Go dream of having a single decent solution to a problem instead of 20 that range fro…

>because of the freedom you get from more similar languages. Is this lack of freedom a good thing?

Unless there is a strong mandate from the top to take time for maintaining and reviewing code I'd say absolutely. Even if those were in place I'd say a strong maybe. Ignoring competency some people just have wildly divergent ways to doing the same thing because of their background. Languages like Java and C++ allow for it because they allow you to do so much. So I agree with the basic tenant of Go that having one way to solve a problem is a huge win for code maintainability and readability. If the one way is clunky and kind of ugly I'm still down for it.

Re: Go: Ten years and climbing

#153

Post by dis-sys »

Karrot_Kream wrote: post #29

Having dealt with enough spaghetti code over the years (just a few of industry experience, and some more years of academia), I understand what Go's strengths are. It's an opinionated language that stops users from being too clever or writing code that's too complex. That said, I've always hated the trends that have brought Golang into popularity. The engineers I've felt who could benefit from Golang the most could al…

> As a simple language to wire pieces together, Golang is fine, but it really doesn't give you the tools (imo) to be productive for anything more complex than simple apps.

I write raft based distributed applications in go, it uses millions of raft clusters concurrently just for its nightly tests. That simple app is not that easy.

Introducing too much of such language X is better/stronger than Y propaganda is not helpful at all.

Re: Go: Ten years and climbing

#154

Post by brightball »

Karrot_Kream wrote: post #29

Having dealt with enough spaghetti code over the years (just a few of industry experience, and some more years of academia), I understand what Go's strengths are. It's an opinionated language that stops users from being too clever or writing code that's too complex. That said, I've always hated the trends that have brought Golang into popularity. The engineers I've felt who could benefit from Golang the most could al…

I like Go as a language, for the decisions and trade offs that they made when creating it and for the cross platform bits. Clearly the performance is sharp too.

I just don't find it particularly productive for full stack web work. API's or other high performance interfaces...great though.

Re: Go: Ten years and climbing

#155

Post by smnplk »

sbov wrote: post #110
chimeracoder wrote: post #38

Earlier quoted context omitted.

> Out of curiosity, what is your take on clojure then ? I have a lot of respect for Clojure, though I don't have much of a use case for it. At the time I tried it, I was annoyed its semantics for '() and nil - they're sort of a hybrid between how Common Lisp does it and how Java does it. Which makes sense - the Common Lisp approach would be a nightmare to implement on top of the JVM while maintaining interoperability…

So would you say this is more about your mindset when programming in LISPs? I like to use Clojure for my side projects and don't seem to feel the same way about my programs as you do. Even as a long time primarily imperative/OO programmer (but who has tried pretty much every language out there, too), Clojure actually feels like one of the most pragmatic languages I've used.

It's the same with me. I didn't have any lisp experience before learning Clojure. I see it as very pragmatic language, the kind that lets you get shit done, it doesn't get in your way. But that said, I can understand why parent compares lisp to art. I would say functional design is art, because you need to put in a lot of effort to learn it.

Re: Go: Ten years and climbing

#156

Post by tptacek »

elgenie wrote: post #96
trgv wrote: post #71

Earlier quoted context omitted.

> I'm a much bigger proponent of languages such as Rust or Haskell which give the developer the _tools_ to ensure their own data integrity, but I guess that says something about me as a developer and why I don't like Golang. This is a little smarmy, don't you think? You seem to come ever-so-close to hinting something like "Go isn't fit for writing real applications." Without getting into what exactly a "real applicat…

That seems to be an intentional misreading. The criticism of Go being presented is that it's intentionally underpowered so as to make it possible for poor developers to verbosely muddle their way through to developing working real applications without actually becoming better.

This is such an old programming language flame war trope that it was probably first written in Aramaic. When I started programming as a teenager and commented on FIDOnet BBS's, people literally said it about assembly language. If for no other reason than to preserve your own dignity, please don't imply that people program in a particular language because they're not good enough to program in other languages.

Re: Go: Ten years and climbing

#157

Post by icholy »

Karrot_Kream wrote: post #29

Having dealt with enough spaghetti code over the years (just a few of industry experience, and some more years of academia), I understand what Go's strengths are. It's an opinionated language that stops users from being too clever or writing code that's too complex. That said, I've always hated the trends that have brought Golang into popularity. The engineers I've felt who could benefit from Golang the most could al…

> We shouldn't need to treat the developer like a toddler to get them to write safe code

You'd be surprised.

Re: Go: Ten years and climbing

#158

Post by tptacek »

user5994461 wrote: post #134
elgenie wrote: post #111

Earlier quoted context omitted.

I personally think Go and Java were developed for the same audience with similar intentions and language designer skill and are going to face the same criticisms. For natural languages, the research seems to indicate that information is transmitted at the same rate when the languages are spoken (e.g. http://muse.jhu.edu/article/449938/pdf ) with faster speaking rates compensating for higher verbosity. In terms of wri…

Yes, go is a replacement for Java. Google couldn't rely forever on sun forever (see the later acquisition by Oracle and lawsuits with Google). Big companies want to own their main tools. It's also to separate itself from the Java crowd, which has a rather poor image to a lot of people that google wants to attract.

Go happens to be a pretty nice replacement for Java in some targeted circumstances, but that is not why Go exists. Go's charter was to address deficiencies of Google's C++ programming environment, not its Java programming environment.

As it happens, outside of (perhaps) Google, C++ serverside development is so rare that Go's strengths aren't very compelling to C++ developers. That Go didn't evolve in the direction its founders expected does not mean that its founders are lying when they explain, clearly and repeatedly, what the original point of the language was.

Re: Go: Ten years and climbing

#159

Post by konart »

lucidone wrote: post #18

Maybe I'm spoiled, but I've had a hard time dipping my toes into Go due to the lack of batteries included frameworks (like Rails or Laravel). Can anyone recommend some resources to give it another shot?

Buffalo I guess, but this is not what Go was build for. This is like asking for a c++ web framework. Yeah, there are some, but generally speaking you don't see people using c++ for building a web app. Components of the app or the inrastructure - yes.

Re: Go: Ten years and climbing

#160

Post by steveklabnik »

e3b0c wrote: post #125
pcwalton wrote: post #121

Earlier quoted context omitted.

We aren't talking about autocompletion. The post upthread describes "the tools to ensure...data integrity": i.e. type system or static analysis features to prevent bugs. That said, if you're trying to argue that autocompletion is more difficult to implement for Rust compared to Go because Go is simpler by some metric, then I disagree there too. Any static language (well, one that doesn't intertwine parsing and semant…

Then I am curious about what makes RLS or the alike so hard to onboard? Common IDE features like reliable and responsive "jump to definition", "Find all references" and "Renaming symbols" are 90% of all I would ask for. Do Rust devs have less attention to the area?

Those three things already work in the RLS. And more: https://www.ncameron.org/blog/what-the-rls-can-do/
Post reply on HN