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

131–140 of 144 posts

Re: The Reliability of Go

#131

Post by 0xdeadbeefbabe »

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

Yeah not enough Object for 96, but still it feels like an old language to me.

Re: The Reliability of Go

#132

Post by B-Con »

stefantalpalaru wrote: post #129
jff wrote: post #94

Earlier quoted context omitted.

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.

Yep. Coupled with the fact that 32-bit applications can still marginally outperform equivalent 64-bit applications, those who have little RAM/CPU are still recommended to choose 32-bit over 64-bit.

Re: The Reliability of Go

#133

Post by bjeanes »

pjmlp wrote: post #121
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…

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

"concurrent by design" != "can be concurrent / has threads"

Re: The Reliability of Go

#134

Post by tacticus »

Symmetry wrote: post #125
jff wrote: post #94

Earlier quoted context omitted.

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.

They have stopped doing this for quite some time iirc.

still a stupid move on their behalf (as is the market segmentation of AES-ni stuff)

Re: The Reliability of Go

#135

Post by bad_user »

gngeal wrote: post #128
bad_user wrote: post #91

Earlier quoted context omitted.

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…

In terms of lines of code, I'm sure that things like OMeta are pretty small, but that doesn't mean the implementation is not complicated. And I'm not that familiar with the *Meta stuff, but AFAIK that stuff is just the frontend, whereas on the backend (the logic for generating the machine code / bytecode) things can get messy and complicated.

Also, I'm sure that the Go implementation is right now simple, but every mainstream compiler quickly evolves towards doing more and more AOT optimizations, like for performance or for better error messages. Again, performance optimizations can get really complicated and messy.

Re: The Reliability of Go

#136

Post by pjmlp »

bjeanes wrote: post #133
pjmlp wrote: post #121

Earlier quoted context omitted.

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

"concurrent by design" != "can be concurrent / has threads"

Not all Java implementations map language threads to OS threads.

The implementations that use green threads are no different than go-routines, which were seen for the first time in Modula-2 just as information.

Re: The Reliability of Go

#137

Post by koraytaylan »

first I saw go I thought meh but with so many people saying good things about it makes go inevitably more interesting day after day. however I just feel like it's going to be like mongo. when it first got popular, people all moved to mongo as it miraculously solving all the problems. same thing happening with go now and after sudden disappear of all the mongo evangelists, this makes me doubtful about go obviously.

Re: The Reliability of Go

#138

Post by mahmoudhossam »

jebblue wrote: post #130
eridius wrote: post #119

Earlier quoted context omitted.

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.

Actually, LibreOffice is trying to get rid of the Java dependency for a while now[1].

[1]: http://www.developer.com/open/libreoffice-3.3-frees-open-sou...

Re: The Reliability of Go

#139

Post by jebblue »

mahmoudhossam wrote: post #138
jebblue wrote: post #130

Earlier quoted context omitted.

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.

Actually, LibreOffice is trying to get rid of the Java dependency for a while now[1]. [1]: http://www.developer.com/open/libreoffice-3.3-frees-open-sou...

Interesting, it sounds like LibreOffice is becoming a mish-mash of technologies (search this page for Java):

http://www.libreoffice.org/download/4-0-new-features-and-fix...

Re: The Reliability of Go

#140

Post by wtbob »

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

Well, Limbo existed in 1995, but it got nowhere…
Post reply on HN