Live data from Hacker News

Why Go is doomed to succeed

texlution.com

131–140 of 330 posts

Re: Why Go is doomed to succeed

#131
I highly recommend replacing any occurrence of, “Go is just not for you”, with "Go is probably not the right tool for what you're trying to do."

The former can seem, snide or condescending, even when that is 100% not the intent.

I write both C++ and C# frequently. I love both languages. But I deal with people who use either language exclusively and continually gripe about the other. And the proper response is, "it's probably just not the right tool for the thing you're trying to do."

Re: Why Go is doomed to succeed

#132
Is there any "best practice" Go, especially in terms of architecturing apps? I come from a long php background, and spent the past 3 weeks learning and prototyping a Go project. Looking at my code, I definitely have "open source stage fright". Any links/advice/books appreciated.

Re: Why Go is doomed to succeed

#133
post #127

Earlier quoted context omitted.

There are mio and serde respectively for your first two points, and mio in particular is really popular. Regarding thread::scoped, I think that kind of issue isn't unique to Rust (Java, a language with a simpler memory model, has had all kinds of weird corner case bugs, especially around memory and concurrency). It's also, again, more an issue of "safe manual memory management is hard": the simple ways to avoid that…

>>(Java, a language with a simpler memory model, has had all kinds of weird corner case bugs, especially around memory and concurrency Can you point something in particular?

CVE-2012-0507 for example.

Re: Why Go is doomed to succeed

#134

Earlier quoted context omitted.

But you are lucky if your project has a large group of programmers. There is more probably a large group of projects with a small group of programmers. There are also some large projects: Linux, KDE, LibreOffice, VLC, LLVM, etc... and none is written in Go.

>Linux (1991) >KDE (1996) >LibreOffice (based on StarOffice, 6.0 released in 2002) >VLC (2001) >LLVM (2003) I think you have a point r.e there being more smaller projects than large projects with large teams. But this is a terrible argument. Go was released in 2007. Are you being facetious or are you suggesting that porting a mature codebase to Go is that easy? CoreOS was released in 2013 and so was Docker. I know th…

Go was released in late 2009.

Re: Why Go is doomed to succeed

#135
post #81

Earlier quoted context omitted.

I think that's reductive. I'm a "decent programmer". (I think I'm a little better than that, if I'm being honest.) I regularly use Ruby, Scala, C#, and enough bash to choke a horse. Some C++ too, when I have to, but it's not something I ever want to touch. I can't deal with Go. And I don't think it's me--I don't do Haskell because of me , I don't do Go because of it . I find it almost impossible to think in Go. I fin…

That wasn't what I was replying to. aaggarwal was asking how easy it was to move to it. I was saying that it's easy. If you find it too primitive, well, that's a fair opinion, but it's still easy to move to. I think it's hyperbole to claim that you can't work in it.

No, something that's as primitive as Go is quite hard to move to. I understand the language, but I can't think in it and so using it is very far from easy.

Re: Why Go is doomed to succeed

#137
I don't quite buy that a pretty low level language reduces developer fright. In my mind Go is a replacement for C more than the next Python. In that respect it is still intimidating for developers who have never done or done very little low level programming.

Re: Why Go is doomed to succeed

#138
post #75

Earlier quoted context omitted.

Go is particularly well suited to long-running critical server apps. It has fewer GC issues compared to Java and is also simpler language (making it harder to screw things up - Java generics can get very complex).

> It has fewer GC issues compared to Java No, it has more GC issues. It's just that there aren't yet enough libraries and big applications to make that apparent. It hasn't been stressed enough just yet.

I think it's likely that Golang apps won't stress the GC as much as Java does, because of the simple fact that you can't realistically use j.u.c-style concurrent data structures, since you don't have generics. Where the JVM GC really shines is when you're using shared-memory concurrent data structures, which are really great things—however, without generics, programmers just won't use them in the first place.

(I'm not saying this is a negative for Java, BTW; making shared memory data structures both fast and idiomatic is really important if you care about performance of parallel code.)

Re: Why Go is doomed to succeed

#139

Earlier quoted context omitted.

How is Rust incomplete and too complex (especially "incomplete")? Compiler-enforced-correct manual memory management may not be the right choice for every project, of course, but I think "too complex" is too strong of a way to say that. That implies there was a simpler way Rust could have achieved the same goals, and I've never seen anyone suggest one that works.

It's rather that Rust's standard library and third party library support is incomplete. E.g.: - last time I checked there was no option to have non-blocking IO which is a pain. - custom JSON serialization/deserialization from/into custom data structures is extremely painful (for reference, rustc_serialize's Decodable trait). - thread::scoped leaking destructors under certain conditions. This is more of an example of…

> thread::scoped leaking destructors under certain conditions.

Note that this problem is one that has no analogue in other languages.

In most languages, including Rust, you can already "leak" things by putting them into a static hashmap and forgetting about it or sending them to a blocked thread or whatever.

Rust is unique in that it can demarcate types which are bound to a scope. Which gives the auxiliary guarantee that the object would be destroyed in that scope regardless of what happens next (because such objects cannot be returned from the scope or placed into a global hashmap or whatever). There is no analogue for this in other languages. Rust is not "incomplete" for not having this.

The current scoped API depended on this guarantee, but it turns out that there are convoluted ways to bypass the guarantee (so it's not a real guarantee). There's a new design that's been proposed which doesn't need this guarantee.

non-blocking io can be done via mio, and I think using serde for json is easier.

Re: Why Go is doomed to succeed

#140
post #29

Earlier quoted context omitted.

How is Rust incomplete and too complex (especially "incomplete")? Compiler-enforced-correct manual memory management may not be the right choice for every project, of course, but I think "too complex" is too strong of a way to say that. That implies there was a simpler way Rust could have achieved the same goals, and I've never seen anyone suggest one that works.

Well, it's a very common complaint (and I found it to be true when I tried my hand at Rust) that the lifetimes and general scope management can make your life hard -- and certainly harder than conventional GC languages. Rust, as a core language, has a lot more concepts to grok compared to Go or even Java. As for incomplete, I mostly refered to the tooling and the available library ecosystem. Even Go lacks there, and…

Rust is certainly harder to pick up than Go (and possibly Java), but I don't think that makes it any more complex than, say, C++.

The difference is in the learning curve. The concepts Rust forces down your throat are the same ones you'd need to learn in some way in C++ anyway (well, not the same concepts, but similar ones having to do with avoiding segfaults). The difference is that you can write simple programs in C++ whilst blissfully unaware of the perils that come later. On the other hand you sometimes need to understand ownership for even the simplest programs.

But for a larger application, you have the same amount of learning required if you want to responsibly write an app in C++ or in Rust.

When we're talking about using a language for something other than teaching programming newbies, we really don't care about small prime number programs being harder in Rust. We care about how hard it is to write large applications, and I strongly suspect Rust isn't harder than C++ for this.

Oh, by the way, for the most part lifetimes work themselves out[1] without effort from your side. And if you find them complicated, you can always compose the relevant wrapper object (like Rc for refcounted memory management -- almost a GC) and use it. It's a bit more verbose, but it's not hard to grok.

[1]: http://manishearth.github.io/blog/2015/05/03/where-rust-real...

Post reply on HN