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

91–100 of 144 posts

Re: The Reliability of Go

#91

Post by bad_user »

awj wrote: post #87
bentcorner wrote: post #75

Earlier quoted context omitted.

> It's all well and good writing Go's compiler in Go, but then how are you going to compile it? A language needs to reach a certain threshold before it becomes possible to write a compiler in it's own language. Is Go not at this point yet? I only have casual knowledge of the language, but it sure sounds like it is capable of building itself.

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.

Re: The Reliability of Go

#92

Post by [deleted] »

16s wrote: post #57
jackielii wrote: post #43

Earlier quoted context omitted.

Go is open source: http://golang.org/LICENSE

I never mentioned closed source or open source in my comment. I mentioned "corporate" languages. Go is Google's just as much as .Net is Microsoft's.

[deleted]

Re: The Reliability of Go

#93

Post by awj »

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.

Yes, it's more complicated, but it doesn't really have much in the way of demands on the language used for implementation. It may royally suck to do, but you can write a compiler with nothing more than logic, data structures, and file I/O. That was my point.

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

Sure, but you'll need to pull people away to do that and will either have to stop your C-based compiler effort or resign yourself to prolonging the Go-based compiler development by playing catchup. In the meantime you aren't really as productive as you could have been. Go seems like it's about to slow down on language-level changes, which is the perfect time to start working on a Go-based compiler.

Re: The Reliability of Go

#94

Post by jff »

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

Re: The Reliability of Go

#95

Post by rbehrends »

pjmlp wrote: post #80
rbehrends wrote: post #74

Earlier quoted context omitted.

> With C and C++ and Python and Ruby and Perl we have freedom. With Go, .Net and Java, etc. we do not. Unfortunately, there is an important language design space that is not covered by C, C++, Python, Ruby, and Perl, which is that of statically typed, imperative languages with automatic memory management. C/C++ give you static typing, but not automatic memory management; Python, Ruby, and Perl give you automatic memo…

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.

Re: The Reliability of Go

#96

Post by kamaal »

waterside81 wrote: post #72

We moved a huge chunk of our code from Python to Go. We have one simple Go binary that just listens on a certain port and API requests from our Django app are proxied to the Go instance running. No issues, no panics, no memory leaks. It's pretty amazing to see a long running process never growing in memory (well, if you're coming from the Python world at least, I'm sure the JVM is pretty solid at keeping it's place n…

How good is Go, as a replacement for Java?

Re: The Reliability of Go

#97

Post by bvdbijl »

Roboprog wrote: post #69
coldtea wrote: post #56

Earlier quoted context omitted.

> On the Python script, it sounds like the performance problems were more likely than not caused by inadequate use of any concurrency features rather than an inherent problem with Python The Language. "Inadequate concurrency features" IS an inherent problem with Python The Language. (Notice I didn't say "inadequate use of concurrency features", I said "inadequate concurrency features").

It's been a while, but I remember that Python threads run into a global interpreter lock quite often, yes?

Yes, unless your code is very I/O bound using threads won't speed up your Python application

Re: The Reliability of Go

#98

Post by Rooki »

bentcorner wrote: post #75
laumars wrote: post #53

Earlier quoted context omitted.

> I'm sorry, but the world does not need another company-controlled, corporate programming language. .Net (Microsoft), Java (Oracle) and now Go (google). .NET isn't a language and Java and Go are both open (but with the main contributers being employees from the aforementioned corporations). > All of these compilers or JIT interpreters are implemented in C or C++ (which are open languages with ISO standards). Layers…

> It's all well and good writing Go's compiler in Go, but then how are you going to compile it? A language needs to reach a certain threshold before it becomes possible to write a compiler in it's own language. Is Go not at this point yet? I only have casual knowledge of the language, but it sure sounds like it is capable of building itself.

See https://github.com/axw/llgo for a 3rd party implementation based on LLVM that's fairly far along.

Re: The Reliability of Go

#99

Post by 0xdeadbeefbabe »

kenkam wrote: post #11
elithrar wrote: post #8

Earlier quoted context omitted.

> He implemented it in Go, but he could have implemented it in any other language I assume he used Go's concurrency features, although he could have articulated on that. > Where did he find the programmers I don't think you explicitly need to hire new programmers. If you have capable, existing programmers, the learning curve is pretty minimal for something like Go.

I agree with not needing to hire new devs, but convincing management and the business to move to a new, untried system with current devs is no trivial feat. It would be nice if he could expand on how that came about.

No trivial feat? It seems to me that managers would be more willing to gamble than a typical programmer. But I still agree with you. I'd like to see a post about how someone switched to go from cobol.

Re: The Reliability of Go

#100

Post by 0xdeadbeefbabe »

rubinelli wrote: post #25
kenkam wrote: post #11

Earlier quoted context omitted.

I agree with not needing to hire new devs, but convincing management and the business to move to a new, untried system with current devs is no trivial feat. It would be nice if he could expand on how that came about.

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.
Post reply on HN