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

Why Go is doomed to succeed

texlution.com

Post reply on HN
Print view View original

201–210 of 330 posts

Re: Why Go is doomed to succeed

#201

Post by laumars »

maffyoo wrote: post #192
laumars wrote: post #184

Earlier quoted context omitted.

In some situations, yes. But Java can suffer from similar complexity and maintainability issues too. Go, for all it's short comings and missing features, is closer to the "instant gratification" state that Python and it's ilk enjoy while having performance closer to that of Java. I'm not trying to say one language is better or worse than the other though. Just my observations as to why Go is gaining popularity.

I think its a bit premature to predict critical mass for Go and maybe your python comparison is a reasonable prediction of where Go will finish up.

> I think its a bit premature to predict critical mass for Go

If Go was only used by it's sponsoring company and a few "language-whores" on non-critical systems, then I might have agreed with you. But in spite of Go being one of the "new kids on the block", there are already quite a few sizeable projects and organisations outside of Google who are using Go for fundamental parts of their software stack (eg Cloudflare, Canonical and Docker).

So like or loathe the language, I'd argue that it's already reached critical mass.

Re: Why Go is doomed to succeed

#202

Post by pcwalton »

mentat wrote: post #199
pcwalton wrote: post #193

Earlier quoted context omitted.

That last paragraph is ridiculous. Name one feature in Rust that you think is too much complexity and I'll tell you where I need it to get my job done in Servo. Without generics and traits, for example, there would literally be no reason for Servo to exist, because it would be too slow. Performance is not optional . Safety is not optional . They are my job . If I opposed language features that are needed for competit…

I don't read his/her criticism that way. It's that users of Rust tend to make over complex systems.

Then let me be clear: contrary to the parent comment, Rust is not "for" people who do that. Rust is for people who have a job to do.

Re: Why Go is doomed to succeed

#203

Post by kibwen »

Animats wrote: post #154

It's very clear what Go is for. Go is for the kind of stuff Google runs on their servers. C++ is too complex, too unsafe, and too hard to maintain, and Python is too slow. (Remember that "slow" at that scale means "we have to add another acre of servers.") Go is an OK language for server-side stuff. It's not perfect. The concurrency isn't as airtight as its proponents originally claimed. Reflection and type "interfac…

  > Rust is for people who debate language semantics on 
  > Lambda the Ultimate and program in Haskell for fun. Go 
  > is for people who have a job to do.
This is a mischaracterization of Rust to the point of incredulity. I've been talking to companies experimenting with Rust and all the engineers I've spoken to have praised Rust for its ability to let them do their jobs with confidence. These engineers are in domains where GC is intolerable and C++ is considered too much of a risk (in fact, one of my biggest surprises in this current endeavor is discovering how few people in industry will describe themselves as comfortable with C++ to the point of being willing to use it in greenfield projects with confidence). Without Rust, these companies would be forced to buy more hardware to throw hardware at the problem or hire C++ specialists to throw at the problem; fortunately Rust threads the needle and provides extreme business value.

Rust was created to solve a specific pain point. It's not some language that sprang fully-formed and perfectly-designed out of the ether. It solves problems that no other language even attempts to solve (no, Ada doesn't do what Rust does (and likewise, Rust doesn't do what Ada does)), and the mechanisms that it uses to do that took years of iteration and concerted effort on large codebases.

Not everyone needs to be working at the level that Rust does, and I think that's great. I'm a polyglot programmer myself, and I like Rust because at last there exists a language that lets me perform at the level of C with the same level of memory correctness that I expect from Python (or really, any language designed post-1995).

Re: Why Go is doomed to succeed

#204

Post by kibwen »

mentat wrote: post #199
pcwalton wrote: post #193

Earlier quoted context omitted.

That last paragraph is ridiculous. Name one feature in Rust that you think is too much complexity and I'll tell you where I need it to get my job done in Servo. Without generics and traits, for example, there would literally be no reason for Servo to exist, because it would be too slow. Performance is not optional . Safety is not optional . They are my job . If I opposed language features that are needed for competit…

I don't read his/her criticism that way. It's that users of Rust tend to make over complex systems.

Can you provide an example of Rust users making overly-complex systems? Rust is a systems language, and systems themselves have intrinsic complexity that language designers must either choose to ignore or tackle. Scripting languages have the luxury of removing complexity by ignoring systems concerns so you don't have to care that your language is, say, copying strings around like a maniac behind your back. But somebody has to compete at the bottom of the stack, and while you can still seek ergonomic wins there's an enormous amount of essential complexity that can't be abstracted away.

Re: Why Go is doomed to succeed

#205

Post by antod »

tptacek wrote: post #45
vezzy-fnord wrote: post #10

Go is doomed to succeed because it extends the mental model of C with a concurrency model that finds a decent compromise between power and ease of use, makes the typing less prone to subversion, adds memory safety via GC, uses a structural subtyping system through interfaces that brings many OO-like benefits while still keeping to the C struct way of thinking, first-class functions, various syntactic rough edges clea…

I'm a 90's C programmer and a Golang programmer now, and while there's some truth to this, it's reductive. A 2000s-era C programmer would not write socket code that worked the way net.Conn does. While C code gave us the "pipes and filters" abstraction of Unix, they are not an idiom in C code --- in fact, Golang's reader/writer interfaces feel more like a refinement of Java than a modernization of C. Golang feels very…

> Golang feels very much like an offspring of Java and Python to me.

To me when people compare Go to Python, I can't help feeling that means quite an old version of Python (eg 1.5) in terms of expressivity and higher level features.

Python 1.5 was quite a small straight forward language compared to today. Which seems like the goals Go has.

Re: Why Go is doomed to succeed

#206

Post by kibwen »

neverminder wrote: post #162
Animats wrote: post #154

It's very clear what Go is for. Go is for the kind of stuff Google runs on their servers. C++ is too complex, too unsafe, and too hard to maintain, and Python is too slow. (Remember that "slow" at that scale means "we have to add another acre of servers.") Go is an OK language for server-side stuff. It's not perfect. The concurrency isn't as airtight as its proponents originally claimed. Reflection and type "interfac…

I brought Rust into my job for some non-essential stuff and so far it obliterated my usual tools (Scala, Python to be more specific) in shear speed and low memory consumption. I've written no more than a thousand LOC of it and most of it is still clumsy bearing it mind the fact that I'm new to it, but the potential that it has cannot be denied. To me it's a missing link I was waiting for - a low level language that f…

I'm currently reaching out to people using Rust for their jobs so that we can establish a more formal relationship with corporate users, and I'd love to hear more about your use cases. :) My email is on my profile page here.

Re: Why Go is doomed to succeed

#207

Post by tantalic »

jamesfisher wrote: post #115
dawkins wrote: post #5

"Go won’t let you abstract yourself in the foot." :)

What a strange idea. The whole point of a programming language is to enable abstraction. I suppose assembler doesn't let you "abstract yourself in the foot" (whatever that means) either.

The whole point of a gun is to enable shooting.

Re: Why Go is doomed to succeed

#208

Post by icedchai »

rifung wrote: post #20
nobullet wrote: post #9

Earlier quoted context omitted.

What's wrong with JVM?

Someone correct me if I'm wrong but I think not using the JVM makes deployments much simpler. At least that was one of the benefits a team at Amazon stated about switching to Go while I was there

In practice, it doesn't make much difference.

You install the JVM once and rarely upgrade it.

You build and distribute your Java apps as fat jars (meaning, all dependencies bundled.)

Re: Why Go is doomed to succeed

#210

Post by klibertp »

Elrac wrote: post #142
okasaki wrote: post #129

Earlier quoted context omitted.

Well, C++ has all of that.

Only for small values of "all." The magic of concatenation and auto-conversion of strings that's baked into the Java compiler and, to a lesser extent, the Go compiler, is missing in C++ - not vital but convenient. Similarly, hashmaps, while built directly into the language in Go, are a library class in C++. Finally, garbage collection will likely never be part of C++.

What do you mean by "the magic concatenation and auto-conversion of strings"?

Also, having a map implemented in a library is a Good Thing. It means that your language is extensible and expressive enough for this. AFAIK Go is - by design - not that extensible.

Post reply on HN