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

The Reliability of Go

andrewwdeane.blogspot.com

Post reply on HN
Print view View original

111–120 of 144 posts

Re: The Reliability of Go

#111

Post by [deleted] »

jebblue wrote: post #108
beatgammit wrote: post #101

Earlier quoted context omitted.

What do you mean "replacement for Java"? It's a completely different language: * no classes (only structs and embedding) * no VM, only a run-time (cross-compiling is trivial though) * hardly anything is an object * no exceptions * concurrent by design It's quite possibly the most distant language from Java in the procedural world, which I think is a good thing. It forces you to rethink your data and their interaction…

>> I think Go is a great language and works in most of the spaces where Java lives, except maybe GUIs, but Java was never any good at that anyway. Eclipse is the world's most popular IDE it's written in Java, Minecraft one of the most popular Indie games ever made was written in Java. What gives you the impression that Java isn't good for GUI's? It's great for GUIs and it's cross platform from the start.

[deleted]

Re: The Reliability of Go

#112

Post by j_s »

Stephen_C wrote: post #47
j_s wrote: post #27

Earlier quoted context omitted.

Would be interesting to hear the details on management's side of the story: 'This guy re-wrote all our stuff in the new hotness then left the company'

Well what sort of story are you expecting to hear? Without going into detail it's not really that exciting. There was a requirement for high volume/through put messaging component in our infrastructure. That technological requirement (along with non functional requirements e.g. development time/costs) was more than adequately met by a program(s) written by a team member written in Go. Was it an opportunity to further…

Glad to hear it worked out well; there are many times where it doesn't. Thanks for taking the time to share an overview.

Re: The Reliability of Go

#113

Post by rubinelli »

0xdeadbeefbabe wrote: post #106
kamaal wrote: post #96

Earlier quoted context omitted.

How good is Go, as a replacement for Java?

The real downside of go is that it didn't exist when Java arrived. It would have made a much better intro to CS language than Java. Then Android wouldn't have decided to use Java because so many new programmers used it in school.

Java, more specifically the JVM, was a a godsend. Develop everything in your Windows 98, then upload it to some big-iron Sun server, knowing it will run, without cross-compilation headaches.

And yes, at first, it was dog-slow, but it was the kind of dog that you could drag behind the barn when things got out of hand. Apache+PHP or (yuck) classic ASP would just bring the whole machine down on a bad day. This isn't much of an issue today, because first other languages/runtimes improved, second we have more robust monitors in place, and third the "machine" is more often already virtual and more easily recyclable.

Re: The Reliability of Go

#114

Post by exch »

tezza wrote: post #86
exch wrote: post #73

Earlier quoted context omitted.

As a practical example to 4ad's answer, here is the result of NULL-pointer dereference on the C code on my system (Arch Linux 3.9.2-1-ARCH). It does yield a SEGFAULT: http://play.golang.org/p/uoBKsRIJB7

Thanks exch, that's really decent of you to construct an example. I wonder that if there are multiple threads / goroutines are their callchains also printed ?

It seems it doesn't go into a lot of detail as to the call-chain for each running goroutine, but this example may just not be very suitable to properly test it. Either way, here is the same deal with a bunch of running goroutines.

http://play.golang.org/p/GQxdXpWdZD

Re: The Reliability of Go

#115

Post by malodyets »

pkulak wrote: post #109
0xdeadbeefbabe wrote: post #106

Earlier quoted context omitted.

The real downside of go is that it didn't exist when Java arrived. It would have made a much better intro to CS language than Java. Then Android wouldn't have decided to use Java because so many new programmers used it in school.

I don't think Go could have existed in 1996. It feels like a reaction to Java, in some sense. And even if it was built, exactly as it is now, in 1996, it probably would have gone no where. "It doesn't even have object inheritance! And what do we need all these concurrency things for? Windows has only had preemptive multitasking for a year, and multi-core is still a decade away."

Your second paragraph quotes a fictitious someone in 1996, right?

Re: The Reliability of Go

#116

Post by msbarnett »

jebblue wrote: post #108
beatgammit wrote: post #101

Earlier quoted context omitted.

What do you mean "replacement for Java"? It's a completely different language: * no classes (only structs and embedding) * no VM, only a run-time (cross-compiling is trivial though) * hardly anything is an object * no exceptions * concurrent by design It's quite possibly the most distant language from Java in the procedural world, which I think is a good thing. It forces you to rethink your data and their interaction…

>> I think Go is a great language and works in most of the spaces where Java lives, except maybe GUIs, but Java was never any good at that anyway. Eclipse is the world's most popular IDE it's written in Java, Minecraft one of the most popular Indie games ever made was written in Java. What gives you the impression that Java isn't good for GUI's? It's great for GUIs and it's cross platform from the start.

If Eclipse is evidence that Java is good at GUIs, I shudder to think what the output of something bad at them must be like to use.

edit: to give you a constructive response: Eclipse is an excellent illustration of how godawful Java is at GUIs. It chugs horribly on even high end hardware because of Java's interminable GC pauses getting in the way of interactive response times. It looks native nowhere, and somehow contrives to feel even more alien than it looks. It manifests platform dependent UI bugs, completely defeating every last shred of its claimed "write a GUI once, deploy it anywhere" advantages.

Re: The Reliability of Go

#117

Post by binarycrusader »

16s wrote: post #39

I'm sorry, but the world does not need another company-controlled, corporate programming language. .Net (Microsoft), Java (Oracle) and now Go (google). All of these compilers or JIT interpreters are implemented in C or C++ (which are open languages with ISO standards). It bothers me to no end to see corporations taking control of the fundamental building blocks (programming languages) of technology and then to see te…

Not quite true.

Microsoft has an undue amount of influence over both C and C++ thanks to the Windows platform and their questionable lack of full support for the relevant language standards.

Ultimately, what controls a language is who controls the market and who employs most of the people implementing the most popular compilers/interpreters for it.

The only reason C++ lives on is because platform holders have been willing to support it; and those platform holders are large corporations.

Re: The Reliability of Go

#118

Post by pjmlp »

rbehrends wrote: post #95
pjmlp wrote: post #80

Earlier quoted context omitted.

Oberon, Oberon-2, Component Pascal, Active Oberon, Modula-3, ...

Is this agreement or disagreement? Because all these languages don't have high critical mass, long term support, or a great ecosystem.

Sorry, I missed your comment

> And unfortunately, while there are quite a few languages with these features, only few have the critical mass, long term support, and infrastructure to justify investing in them for serious development.

So I guess I agree with you.

I started coding in 1986, on those days C was just another language and OS were written in Assembly, PL/I, Pascal, Modula-2 and probably many others we never heard of.

I always used C only when required to do so, hoping a stronger type language would take its place. And jumped into C++ as a better C as soon I discovered the language in 1992, but given its C roots many problems still persist nonetheless.

The problem is that a language to gain critical mass needs a corporation that pushes it into the mainstream, or a framework/library that makes developers want to use the language.

Re: The Reliability of Go

#119

Post by eridius »

jebblue wrote: post #108
beatgammit wrote: post #101

Earlier quoted context omitted.

What do you mean "replacement for Java"? It's a completely different language: * no classes (only structs and embedding) * no VM, only a run-time (cross-compiling is trivial though) * hardly anything is an object * no exceptions * concurrent by design It's quite possibly the most distant language from Java in the procedural world, which I think is a good thing. It forces you to rethink your data and their interaction…

>> I think Go is a great language and works in most of the spaces where Java lives, except maybe GUIs, but Java was never any good at that anyway. Eclipse is the world's most popular IDE it's written in Java, Minecraft one of the most popular Indie games ever made was written in Java. What gives you the impression that Java isn't good for GUI's? It's great for GUIs and it's cross platform from the start.

If you want to make the argument that Java is good for GUI's, feel free, but you just picked the two worst examples I could possibly think of. As a Mac user, the UI for Eclipse is such a huge turn-off that it soured me on Java as a whole (back before I really knew anything about Java; today, there's plenty of other stuff to dislike besides the GUI toolkit). And Minecraft? That's not a UI, that's an OpenGL game. Nothing about the custom OpenGL-based UI it presents to users says anything about Java, or has any bearing on other Java apps you might write.
Post reply on HN