Live data from Hacker News

Why Go is doomed to succeed

texlution.com

31–40 of 330 posts

Re: Why Go is doomed to succeed

#31
Go seems to be attracting a lot of developers from Python, Ruby and Node because Go offers them the easy path to getting started that they place a premium on, combined with speed, but relatively few people from the order-of-magnitude-larger JVM world. Coming from Java I like that there's a very similar language that I can use for command line applications (a JVM sore-spot) or a simple daemon -- both because it doesn't require warmup and can be delivered as a single native binary -- but I just can't think of giving up the JVM's deep monitoring, low-overhead deep profiling[1], polyglotism[2], dynamic code loading and hot-swapping, and the awesome hacking power that comes with runtime bytecode manipulation[3] for long-running, important server applications.

[1]: Java Flight Recorder is the most powerful low-overhead profiler I've ever seen.

[2]: We use Java, Kotlin and Clojure all in the same project.

[3]: The ability to inject ad-hoc tracing code into your server and then take it out -- all while the server is running at full speed -- or to shadow binary dependencies so they don't clash, or to use (or write) a time-travelling debugger is like having magic powers. Bytecode manipulation is ultimate hackability.

Re: Why Go is doomed to succeed

#32

Earlier quoted context omitted.

I have never used Go before. From the sound of it, it looks like Go hits a sweet spot between C and Java? and of course the Google support is a major factor for a possible success.

> it looks like Go hits a sweet spot between C and Java? If your sweet spot is 90~95% java and 5~10% C.

That's not really my sweet spot, but if it have such a strong inclination towards Java, then would it be much easier for Java programmers to move to Go compared to C programmers?

And, what about python programmers, how would Go be for them?

Re: Why Go is doomed to succeed

#34

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.

Not the parent, but I've read many comments here on HN from users who feel that if a language doesn't include an HTTP server in the standard library, it's not ready for production work. Ridiculous, of course, but that may be what the parent is referring to.

Does Java meet the criterion you're describing here?

Re: Why Go is doomed to succeed

#35
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…

> 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.

Yes, there is more of a learning curve, but I think that's a problem with manual memory management in general. To me, that doesn't mean that the language is "too complex"; rather it means that the space Rust is playing in (and which those other languages are not playing in) is complex.

> As for incomplete, I mostly refered to the tooling and the available library ecosystem.

I've never found Rust lacking in tooling, with the notable exception of the lack of rustfmt (which is being worked on by Nick Cameron and others). I use native profilers and GDB with Rust almost every day, and Cargo is getting pretty mature. The library ecosystem isn't very mature yet, sure, but I wouldn't say that makes the language incomplete.

Re: Why Go is doomed to succeed

#36
I'm a fan of Go and have been using it for a [relatively] long time across various large and small systems.

I really like it.

To me, what's been abundantly clear is that: it's a horrible choice for types of apps a lot of people are using it for. Specifically, systems where ror/django/express/php have traditionally excelled at. I'd say "CRUD", but that's too narrow. The expressiveness and productivity of dynamic languages continues to awe me. This is particularly true for web systems that, on one end, deal with the object-relational mismatch and on the other transforms and outputs json or html.

Go's great, but it feels like we've forgotten some of the pain-driven lessons Hibernate and their ilk taught us.

Re: Why Go is doomed to succeed

#37
post #31

Go seems to be attracting a lot of developers from Python, Ruby and Node because Go offers them the easy path to getting started that they place a premium on, combined with speed, but relatively few people from the order-of-magnitude-larger JVM world. Coming from Java I like that there's a very similar language that I can use for command line applications (a JVM sore-spot) or a simple daemon -- both because it doesn'…

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.

Re: Why Go is doomed to succeed

#38

Earlier quoted context omitted.

> it looks like Go hits a sweet spot between C and Java? If your sweet spot is 90~95% java and 5~10% C.

That's not really my sweet spot, but if it have such a strong inclination towards Java, then would it be much easier for Java programmers to move to Go compared to C programmers? And, what about python programmers, how would Go be for them?

Any decent programmer should be able to switch between {C,Java,Go,Python} without too much difficulty. They each have their own differences and learning curve, but as long as a programmer doesn't identify themselves too tightly as a specific language developer (e.g. some people say "I'm a Java programmer", implying they couldn't possibly learn something else) then it's not hard to pick up Go.

Re: Why Go is doomed to succeed

#40
post #17

> To understands why Go is the way it is you need to know why it came to exist in the first place: "The goals of the Go project were to eliminate the slowness and clumsiness of software development at Google, and thereby to make the process more productive and scalable. The language was designed by and for people who write—and read and debug and maintain—large software systems. source" The problem with this idea is t…

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.

>Yes, there is more of a learning curve, but I think that's a problem with manual memory management in general. To me, that doesn't mean that the language is "too complex"; rather it means that the space Rust is playing in (and which those other languages are not playing in) is complex.

Yes, that's probably the case (Rust caters to more complex needs). Still makes it more difficult to just "dive into it" like you can with Go or Java or Python etc. Of course it's probably much simpler compared to mastering C++ or getting C right without dangerous bugs.

Post reply on HN