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

281–290 of 330 posts

Re: Why Go is doomed to succeed

#281

Post by Merovius »

Elrac wrote: post #216
xamuel wrote: post #166

Earlier quoted context omitted.

>And the simple ability to concatenate strings without first reserving space for the result Not exactly the same thing, but routine string manipulation in C gets considerably easier once you discover a highly underrated function called asprintf (basically combines sprintf and malloc, calculating the buffer size for you).

Woo hoo, thanks for the tip! But I still need to worry about creating a memory leak with this. :(

Also, asprintf is a GNU-extension, so if you want to write portable code, it's a no-go (as for everything usefull in C).

Re: Why Go is doomed to succeed

#282

Post by microtonal »

eropple wrote: post #145
microtonal wrote: post #93

Earlier quoted context omitted.

I find it incredibly primitive, well past the point of "stupid code is impossible to misunderstand" and into "stupid code because the language demands it." Since the parent mentioned C and Java. What are you missing in Go compared to Java besides generics? What are you missing in Go compared to C besides manual memory management? To me, Go seems to have about the same amount of expressiveness as C and Java. The diffe…

> Since the parent mentioned C and Java. What are you missing in Go compared to Java besides generics? That's a clever way to attempt to constrain the conversation away from the elephant in the room. "Other than the bullet in your stomach, how are you feeling?" Not having at least Java-style "dumb" generics, in 2015, is unacceptable; the existence of `go generate` should mortify everybody involved with Go. Not having…

tl;dr: Go is a dumb language because it does not provide enough abstraction. (Or with the underlying tone: Go users are just to dumb to understand superior languages.)

I agree and disagree with all your points. I have written C++ and Prolog professionally for years, then some Java (because employer), with a little Haskell on the side (hobby projects).

I am in a bind when it comes to PLs. I prefer the abstraction of C++ and Haskell (or Prolog for the domains where it fits). On the other hand, it is easier in powerful languages to get complete mismatches between the level of abstraction and the abstractions that are used. To take three widely-used C++ libraries as an example:

- Boost: highly template and template meta-programming driven.

- Qt: basically C++ as C with classes, with moc for signals. Really only templates for collections.

- Xerces/XQilla: 90ies style C++ with global state, and too many Java SingletonFactoryProxies.

In projects where you use different dependencies with different styles, things can get ugly. Also, your policy-based design may not be understandable to your 'C++ is C with classes' colleagues/contributors.

In the end there will always be interaction between expressiveness and maintainability/accessibility. The right abstractions can improve both. Too much magic (page-long type signatures, too many levels of templated indirection, etc.) can make everyone's lives miserable. The graveyard of ugly C++ libraries shows that finding the right abstractions can be hard, even for experienced programmers.

Re: Why Go is doomed to succeed

#283

Post by pjmlp »

pron wrote: post #46
dsymonds wrote: post #37

Earlier quoted context omitted.

It's not hard to find people switching from Java to Go (e.g. http://www.infoworld.com/article/2608571/application-develop... , which I found within 10 seconds of searching). It's true that Go doesn't have a lot of those powerful JVM features that you listed, but as with any engineering trade-off there are lots of people who judge the benefits of Go to be worth the loss of those things.

Of course there are people making the switch, but the numbers are not nearly as substantial at as people switching over from scripting languages (even in nominal figures, let alone percentage) -- which perfectly makes sense. You'll also note that since that article was published, all the advantages listed in in it have either found their way into Java (lambdas, fibers) or to other similar languages like Kotlin (multi…

> Go has the undisputed upper hand when it comes to command-line apps

Only because most developers don't care to look for the JVMs that offer AOT or refuse to use anything other than the OpenJDK.

Re: Why Go is doomed to succeed

#284

Post by microtonal »

Elrac wrote: post #278
microtonal wrote: post #274

Earlier quoted context omitted.

Similarly, hashmaps, while built directly into the language in Go, are a library class in C++. And this is a problem because? (It's actually a weak point of Go that you cannot define them in a library without sacrificing type safety.)

I didn't say it was a problem. I was objecting to "C++ has all that."

Ah, but the standard library (including unordered_map) is part of the C++11 standard.

Re: Why Go is doomed to succeed

#285

Post by Merovius »

nickbauman wrote: post #159
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…

The problem with Go is likely a result of having the kinds of stated goals that it has. The designers of Java deliberately created a language that was for people they didn't trust. The result is a hammer that looks and works like a dildo. So we're likely headed to where the commensurate Go analogy to Java is a hammer that looks and works like a catheter or something? One last analogy. What would you prefer: a pilot w…

The correct analogy (as we are generally not building people) is "Building an aircraft, that needs a pilot with certification and a certain number of flight hours, or building an aircraft that can be flown by any passanger with minimal instructions, if the need arises". In the latter aircraft, you still benefit from an experienced pilot, but at least, if they pass out, get drunk or plainly go rogue, you still have a decent chance of dealing with the situation, instead of just crashing.

Re: Why Go is doomed to succeed

#286

Post by Merovius »

pcwalton wrote: post #193
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…

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 find it counterintuitive, that generics and traits improve speed. I would enjoy a deeper explanation of that :)

Re: Why Go is doomed to succeed

#287

Post by masklinn »

aaggarwal wrote: post #128
masklinn wrote: post #122

Earlier quoted context omitted.

> would it be much easier for Java programmers to move to Go compared to C programmers? Don't know about "very", but there would be very little difficulty moving from java to go. There wouldn't be that much value to it though (startup speed and deployment would be the primary ones, and if those are your concern chances are you're not using java as it's notoriously not great at those). > And, what about python program…

This is helpful. Thanks! I have one more question, how does Go ensure easy concurrency?

It provides built-in lightweight thread abstraction ("goroutines", and "channels" for communication between these).

Beware though, Go uses shared-memory concurrency (as opposed to, say, Erlang) so if you pass a pointer to a mutable structure through a channel the structure won't be copied or moved, both sides will be able to alter it. It does provide a data race detector but it's just that, you have to hit the corruption path while running the detector for it to have a chance, I'm not sure it's 100% even if you do, and I understand it has a non-trivial runtime cost and limitations wrt number of routines it can track.

Re: Why Go is doomed to succeed

#288

Post by Merovius »

lucidguppy2000 wrote: post #188
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.

How does go prevent complexity?

Mostly by making abstractions harder. By making it pointless to think about "what is the best type-hierarchy for this software" or "what is the most general way this problem can be formulated and solved", it forces you to focus and solve the problem at hand, which leads to more straightforward and easier to understand code.

Most people I've seen, that are frustrated with go, are people who want to have an impact on the community by writing a package that a) solves a simple-ish problem with the simplest API possible (e.g. "password-hashing libraries") or b) solves a complicated-ish problem in the most general way possible (e.g. "generic containers" or "graph algorithms"). As go makes both of these very hard, these kinds of people get frustrated with it.

go generally agrees with people who want to solve complicated specific problems, e.g. "I want to find all dead links on a website", because it gives you a relatively straight way from A to B.

Re: Why Go is doomed to succeed

#289

Post by Merovius »

microtonal wrote: post #97
bkeroack wrote: post #8

Earlier quoted context omitted.

I would word it slightly differently--in Go you are free to express yourself in exactly one way: the idiomatic Go way. Anything else will be painful (a good clue is if you find yourself using reflection frequently).

I agree that the number of possible solutions is often smaller than in other languages. But there are still often multiple ways which are considered idiomatic Go (in the sense that they are all widely used). E.g. if you build some iterable type, you could provide iteration via: 1. Go channels: send every value over a channel. 2. Callbacks: provide an iteration function which takes a callback function. 3. Closures: le…

1 is a misconception. Go channels are fundamentally useless for iteration, because you leak goroutines with break or return inside the loop. Same goes for 3 probably. 2 and 4 are the idiomatic ways (and afaict the only ones used in the stdlib).

edit: Okay, 3 should work too, sorry.

Re: Why Go is doomed to succeed

#290

Post by wirrbel »

pjmlp wrote: post #261
mkramlich wrote: post #242

Earlier quoted context omitted.

bingo Google: Go Microsoft: C# Sun/Oracle: Java almost all others: more on their own merits, from developers eyes (Python, Perl, C++, Ruby, Rust, D, Scala, LUA, JS, etc.) a language should have innate merits, of course, but never discount the advantages of having a single corporate entity with lots of cash and focus and a built-in install base of eyes

Let me fix that list CNRI: Python AT&T: C++ Unisys: Perl EPFL: Scala 37signals: Ruby Mozilla: Rust

37signals and ruby? They were involved with Rails, but did they sponsor Ruby?
Post reply on HN