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

121–130 of 144 posts

Re: The Reliability of Go

#121

Post by pjmlp »

beatgammit wrote: post #101
kamaal wrote: post #96

Earlier quoted context omitted.

How good is Go, as a replacement for Java?

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…

> * no VM, only a run-time (cross-compiling is trivial though)

There are native code compilers available for Java.

> * concurrent by design

Java was there first

Re: The Reliability of Go

#122

Post by pkulak »

malodyets wrote: post #115
pkulak wrote: post #109

Earlier quoted context omitted.

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?

Haha, yes, thanks. I added quotes.

Re: The Reliability of Go

#123

Post by pjmlp »

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

Oberon and Oberon-2 were available in 1991, which Go takes the method syntax and package concepts from.

GC enabled system programming languages, which failed most likely due to the Pascal syntax.

Re: The Reliability of Go

#124

Post by Jtsummers »

moshberm wrote: post #120

What happens if Google decides to send Go the way of the RSS reader, the SMS search, and the dinosaur?

Nothing, it's not a service. The code is already out there along with the documentation and language spec. The worst they can do is:

1. Cancel their future contributions.

2. Create a closed source fork (is this feasible with the license if they don't control what others have contributed?)

In the worst case, if there aren't enough go enthusiasts it goes the way of other niche languages. Since the supporters seem to be active enough, I doubt that'll happen.

Re: The Reliability of Go

#125

Post by Symmetry »

jff wrote: post #94
raverbashing wrote: post #10

I remember some time ago a complaint about Go having some bugs on 32-bit machines (something related to the GC) So yes, if you have control over your environment it may be a better choice But the biggest issue with 'less than mainstream' languages are libraries. Things like DB connectors, protocol libraries (SOAP for example - yes, unfortunately this is necessary for some 3rd part services), etc Heck, even for Python…

Why, oh why, would anyone be running x86 hardware in this Year of Our Lord Two Thousand and Thirteen? It's been what, 10 fucking years that we've had AMD64 now, you can get free 64-bit systems from the curbside, just toss that goddamn PIII and get with the 21st century. Maybe then people can stop posting "Well, Go on 386 architecture has bugs, so don't use it for anything."

Intel fuses off x86-64 on some chips it sells for reasons of market segmentation.

Re: The Reliability of Go

#126

Post by gngeal »

0xdeadbeefbabe wrote: post #100
rubinelli wrote: post #25

Earlier quoted context omitted.

Go has the advantage of being "Google's language." This may sound stupid, but this credibility-by-association is a very important factor for a non-technical manager.

Go puts the Go in Google.

Without Go, you'd only ogle Google.

Re: The Reliability of Go

#127

Post by gngeal »

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…

All of these compilers or JIT interpreters are implemented in C or C++ (which are open languages with ISO standards).

Technically, if I'm not mistaken, Go is (currently!) implemented in Plan 9 C, which is not the same thing as ISO C.

Also, Go is very different from .NET and Java. For starters, it was published in source pretty soon after it had been announced. You have your freedom right there.

Re: The Reliability of Go

#128

Post by gngeal »

bad_user wrote: post #91
awj wrote: post #87

Earlier quoted context omitted.

Considering people are writing web servers and all sorts of other things in it, I'm sure it's suitable for writing a compiler. Technically all you really need is logic, some data structures, and low level file I/O. If you're going to spit out asm and let someone else deal with that, then all you need is normal file I/O. It seems like Go is trying to capitalize on the momentum they have. Improvements to the language a…

Actually a language compiler is more complicated than a web server when speaking about the data-structures and the algorithms used and represents the best test that you can have for a programming language. Also, you would want a compiler written in a high-level language (versus C) precisely because you want to speed up the development of new features.

Actually a language compiler is more complicated than a web server when speaking about the data-structures and the algorithms used

That would depend on how much of the web environment you want to reproduce and what language we're talking about. The original Oberon fit into some 5500 lines of code, if I'm not mistaken. That's sort of smaller than Apache httpd. It's even smaller than nginx and lighttpd. And we're still talking about pretty weak languages, have you seen some of the self-hosting metacompiler stuff? (META-II, TREE-META, OMeta etc.) Don't forget that the design of the reference Go implementation is actually pretty close to the Oberon tradition of making things simple.

Re: The Reliability of Go

#129

Post by stefantalpalaru »

jff wrote: post #94
raverbashing wrote: post #10

I remember some time ago a complaint about Go having some bugs on 32-bit machines (something related to the GC) So yes, if you have control over your environment it may be a better choice But the biggest issue with 'less than mainstream' languages are libraries. Things like DB connectors, protocol libraries (SOAP for example - yes, unfortunately this is necessary for some 3rd part services), etc Heck, even for Python…

Why, oh why, would anyone be running x86 hardware in this Year of Our Lord Two Thousand and Thirteen? It's been what, 10 fucking years that we've had AMD64 now, you can get free 64-bit systems from the curbside, just toss that goddamn PIII and get with the 21st century. Maybe then people can stop posting "Well, Go on 386 architecture has bugs, so don't use it for anything."

Small VPS instances with little RAM available.

Re: The Reliability of Go

#130

Post by jebblue »

eridius wrote: post #119
jebblue wrote: post #108

Earlier quoted context omitted.

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

Ok, you have a good point. I'll instead list Open Office and LibreOffice and Symphony and Lotus Notes. Those are hugely complex GUI's and work as good as or better than anything proprietary out there in the same class pf products.
Post reply on HN