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

"100% of our production system is now running Go"

groups.google.com

Post reply on HN
Print view View original

171–180 of 189 posts

Re: "100% of our production system is now running Go"

#171

Post by dalke »

draegtun wrote: post #97
batista wrote: post #55

Earlier quoted context omitted.

> Furthermore, although Python is a pretty good all-round language, it doesn't really excel at anything in particular, unlike for example Perl which continues to maintain a strong niche in the areas of text processing and system administration, despite its popularity having fallen away in some of the other areas it was formerly strong in. Well, it does excel in scientific computing. Biologists, astronomers and such u…

Ditto for Perl because of BioPerl (used in the Human Genome Project) & PDL (which IIRC was being used somewhere at NASA). links: http://en.wikipedia.org/wiki/BioPerl | http://pdl.perl.org/

I believe Perl in bioinformatics was a combination of three or four factors. At that time, sequence analysis was mostly equivalent to string processing and executing command-line programs. Perl was a natural fit. Bioinformatics work used Suns running Sybase, so the researchers knew the Unix way of doing things, which is what perl builds on. This was the early days of the web, and bioinformatics people were very much into data sharing. They used perl to write CGI programs (both cgi-lib.pl and CGI.pm were written by bioinformatics people), so they had one language which they could use for sequence research, for system administration, and for data sharing.

Other languages evolved through a different path. Chemistry, for example, tends to be more Python related. (I develop software for that field.) I think it's because the chemical graph data structure is harder to write naturally in Perl. Gene expression analysis uses a lot of R.

Re: "100% of our production system is now running Go"

#172

Post by mahmud »

lttlrck wrote: post #145
Evbn wrote: post #57

Earlier quoted context omitted.

My production system is written in 100% bash and some other code run under Bash's control. :-)

Mine is running under 100% control of grub

grub doesn't control anything, it transfers control to the OS and is never contacted or heard from again. More concretely, in the case of Linux, the init task (first task and parent of every other task) function has a "tail" call to cpu_idle which never turns.

http://lxr.free-electrons.com/source/init/main.c?a=arm#L359

Re: "100% of our production system is now running Go"

#173

Post by wapper »

slurgfest wrote: post #156
tjoff wrote: post #93

Earlier quoted context omitted.

I have such a hard time believing how anyone could have believed that C/C++ programmers would switch to a GC-only language just like that. I just can't see Go as an alternative to C or C++, and I'm quite surprised that anyone (especially someone such as Rob Pike) could. Sure there are situations where a program that typically would have been written in C/C++ could benefit from Go (so there is a place for it), but the…

> I have such a hard time believing how anyone could have believed that C/C++ programmers would switch to a GC-only language just like that. Java believed the same thing. Many did switch. The difference today is that most of the people liable to switch already switched to Java. If I could guess, I'd guess that Go is doing a better job at picking up Java programmers than C++ ones.

I've been meaning to ask someone that. If you switch from java to go, is it really such an improvement in non-trivial cases ?

In Go, you'll be doing the C thing : you'll be reimplementing every datastructure from scratch (or use void, also known as interface{}), and have the same memory allocation problems as java. The problem with that is obvious : only experienced C library authors stand any chance of getting complicated trees right the first time (and I still only seen one person get red-black trees insert right first time once*, 3 other university professors and several assistants failed).

And the fact that you need to write those things from scratch everytime means you've got to debug that extremely finicky and difficult code every single time ... and then a junior programmer comes in and says "hey I can get to the internal fields easy, why don't I just" and you're in for an 8 hour debugging session because that causes a crash in the normal insert code, not the actually wrong code.

One thing I did in go that really, really bugged me was sorting a list (sorting a list of strings). I was making it as short as I possibly could without violating style rules ... 70 lines of code. That's ... well that's just not reasonable.

ArrayList x = Lists.newArrayList("b", "c", "d", "a"); Collections.sort(x); System.out.println(x);

Give me the Go equivalent, in less than 50 lines of code. Please. That just has got to have a short solution, right ?

As it stands, I believe Go is good at being a fast conduit for nearly-ready data. A way to write asynchronous servers. If you need complicated algorithms or quick ways to change data operations ... maybe I'm wrong but it just looks like Go is really not going to be your friend.

Re: "100% of our production system is now running Go"

#174

Post by kibwen »

heretohelp wrote: post #168
kibwen wrote: post #126

Earlier quoted context omitted.

(Disclaimer: occasional Rust contributor) I agree, Rust's documentation is really awful at the moment. I mean, there's a reason for it: the syntax and semantics are evolving so fast that any tutorial written right now will be hopelessly out of date in two weeks (note that the official tutorial has been updated regularly, but you can't even tell!), and much of the current stdlib is comprised of quick hacks based on ob…

I would be happy to maintain a newbie's guide, syntax changes and all (I've read the meeting notes, I know what you're talking about) if somebody can help me learn enough Rust to know what I'm talking about. Edit: Fuck it, I'll make a website.

If you do, please post it to the mailing list!

https://mail.mozilla.org/listinfo/rust-dev

Re: "100% of our production system is now running Go"

#175

Post by heretohelp »

kibwen wrote: post #174
heretohelp wrote: post #168

Earlier quoted context omitted.

I would be happy to maintain a newbie's guide, syntax changes and all (I've read the meeting notes, I know what you're talking about) if somebody can help me learn enough Rust to know what I'm talking about. Edit: Fuck it, I'll make a website.

If you do, please post it to the mailing list! https://mail.mozilla.org/listinfo/rust-dev

Sub waiting for mod approval.

Re: "100% of our production system is now running Go"

#176

Post by mogrim »

vetinari wrote: post #167
mogrim wrote: post #162

Earlier quoted context omitted.

Genuine question, from ignorance: How does Go create less garbage than Java? I can certainly appreciate that a lot of the common frameworks used in JEE development may be memory-hogs, but the language itself?

just iterating: for (Object o: collection) { } causes memory allocation. If you are interested, android team at had several talks at Google I/O (not just 2012) about optimizing memory usage.

Cheers, will check those out.

Re: "100% of our production system is now running Go"

#177

Post by Nitramp »

batista wrote: post #158
tptacek wrote: post #153

Earlier quoted context omitted.

If you read this whole subthread, what you basically get is a confirmation of what Rob Pike wrote in his post: a series of objections revolving around things Go doesn't have that C++ does have. Pike's point is that these objections were in hindsight inevitable, because the whole idea behind Go is to simplify the language --- Go is even simpler than ANSI C. The Go team's idea was, look at languages like C++ and replac…

> I personally see no place at all for C++ Application programming in the scale of Photoshop, Word, etc. Video games. All kinds of multimedia apps and video/music editing apps. C is too low level for those kinds of things, and Go too high level. Plus it's not just the language, that's a mistake: it's the whole ecosystem that matters. E.g you're gonna find more experienced C++ programmers to make you the next, say, Ca…

Note that at least Adobe has started to put significant amounts of Lua into their user facing applications, as the glue on top of C++ components.

Outside of the lack of bindings to proper UI frameworks, I couldn't say why you shouldn't write e.g. Word in a higher level language than C++. You might have to be careful with memory usage in some components, maybe even write those in native code, but for the vast majority of interactions something higher level should work, shouldn't it?

After all you can implement something akin to Word in JS + HTML (Google Docs).

Re: "100% of our production system is now running Go"

#178

Post by zedzedzed »

pcwalton wrote: post #140
heretohelp wrote: post #70

Earlier quoted context omitted.

As someone who's tried (and failed) to learn Rust in the past: I'm going to elide any commentary about the syntax for now, as I know why it is the way it is (the type system/annotations). I'm basically just going to expound on one thing for the sake of emphasis. For the love of god make Rust more accessible . I don't mean dumbing down the type system or abandoning regions (I really hope that works out). I mean the fr…

Yes, the docs are awful at the moment. It's mostly a question of making sure things are stable before we commit to writing a lot of docs; we absolutely need better ones. The standard library tends to use the bleeding-edge features more than user Rust code (as it contains implementations of core traits and whatnot), so its churn is high. Despite what others have suggested, I don't think it needs a total rewrite, but v…

(due to be released next week).

I will be eagerly looking forward to that!! Is the 0.4 version a step ahead of the past alphas? Is it finally becomming a beta?

Re: "100% of our production system is now running Go"

#180

Post by kragen »

tptacek wrote: post #152
qznc wrote: post #73

Earlier quoted context omitted.

C++ is better for abstraction, as Go does not have generics yet, and C++ is better for performance. Go is faster to compile. Maybe Go is better for concurrent programming, but this is hard to measure.

One look at the Go standard library contradicts this. Go is perfectly adequate for abstraction.

I think you may be talking past each other. C++ or D templates allow you to express (in a crude, verbose, error-prone way) some kinds of abstractions that are not expressible in Golang or ML. Not sure about C#.

There are certainly lots of abstractions you can express in Golang.

Post reply on HN