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

I’m joining the Go team at Google

spf13.com

Post reply on HN
Print view View original

151–160 of 211 posts

Re: I’m joining the Go team at Google

#151

Post by dragonwriter »

pcwalton wrote: post #145
jerf wrote: post #66

Earlier quoted context omitted.

Go's big success, in my opinion, was to fuse the lightweight, spawn a million threads we don't care, style of programming to conventional imperative, conventional static-type programming. I know of several other runtimes that had that lightweight threading capability, I've been using them since years before Go was even a thing, but they all required programmers to learn a new paradigm. At times, a radically new parad…

> I know of several other runtimes that had that lightweight threading capability, I've been using them since years before Go was even a thing, but they all required programmers to learn a new paradigm. One of those runtimes is Ruby (Ruby uses lightweight threads, not OS threads), and Ruby is not a new paradigm.

Ruby (that is, the main implementation, from 1.9 on) uses OS threads with a global lock so that only one thread running Ruby code is executing at a time in a process, same as, e.g., Python.

Up through 1.8.x, Ruby used N:1 lightweight threads (multiple lightweight threads on one OS threads.)

Go uses M:N threading (multiple lightweight threads, which may be distributed among 1 or more OS threads.)

M:N threading is a different model than either the Ruby 1.9+ model (1:1 threading on OS threads with a global lock) or the older Ruby approach (N:1 threading), or even the JRuby approach (1:1 threading on OS threads with no global lock.)

Re: I’m joining the Go team at Google

#152

Post by pmarreck »

javajavaj wrote: post #110
pmarreck wrote: post #63

Earlier quoted context omitted.

How does treating them as values force you to deal with them (except on principle)? Does the language force you to check the return value of every line of code? And the checking would only encompass expected errors, not unexpected ones, no? The unexpected ones (read: bugs) would simply be swallowed up and the actual problem would finally turn up far away in some other stack scope, no?

Dave Cheney gave a talk about error handling in Go that sheds some light on how the Go community thinks about errors: https://www.youtube.com/watch?v=lsBF58Q-DnY

I watched this, and what I saw was a heck of a lot of information about how to extract information from error values and percolate them together up to a handler, all of which would automatically be present in your everyday stack trace in a language that actually threw unexpected runtime errors. ;)

I frankly don't see how this is OK, nor better. Errors are real in the sense that they are evidence that the programmer's mental model of state did not line up with the actual state (usually in some corner case). There is literally NO circumstance in which being in a programmer-unknown state (yet still "alive" so to speak) is better than being in a programmer-known-and-accounted-for state. (For an example of being in a programmer-unknown yet alive state, see: Every Security Hole Ever.) This is why "throwing" is appropriate, no matter how much the Go creator didn't like it. If even a single runtime error goes undetected/unhandled, you will end up further and further into an unknown state due to state corruption, and your behavior will soon become completely nondeterministic (or at least, nondeterministic-appearing). Losing determinism is the first step on the road to dragons.

I literally can't see how this wouldn't happen, and what I AM seeing is a lot of chatter in Go communities about how to manage this problem, when the solution is already there: Just fucking throw a stack trace. Or, even better, do what Erlang/Elixir do: Throw it, log it, and have a supervisor process kill it and restart it, all in 1 millisecond or less. If the error keeps happening above a certain threshold rate, kill and restart the supervisor as well. The reason this works (and has resulted in the INSANE uptimes that Erlang-backed services have) is that it resets state to programmer-known conditions.

Re: I’m joining the Go team at Google

#153

Post by sandGorgon »

sdegutis wrote: post #57
gravypod wrote: post #43

Earlier quoted context omitted.

In general make good tooling and others will come. Look at Java/Eclipse

Can confirm. At work we're moving from Clojure 8 to Java 8 partially because IntelliJ is amazing and partially because Java 8 plus the right libraries is close enough to Clojure anyway, except much faster.

whoa!! this is huge - can you talk a bit more about your stack please. This is the first time I have heard something like this - what libraries, code style, etc would get you the same "feel" as clojure ?

Re: I’m joining the Go team at Google

#154

Post by petre »

jnordwick wrote: post #19
XorNot wrote: post #12

* Interfaces which can have fields would be really, really great. * A rust-style borrow checker would make dealing with channels and pointers a lot safer. * Equality operations for slices would clean up some ugly parts of the standard net library (addresses are []byte, so a direct x == y doesn't work but seems like it should). * Closed enum sets: some ability to setup an enum type which can be "complete" when used in…

My two Golang pet peeves, not very important either: -still no math.round WTF? -make() should be syntax and not this quasi-function that takes this vast array of argument types, and while you're at it, you should just rename it `new`, because that's what it is.

Haha, no number rounding function/method in the standard math lib? And I thought Dlang missing a BigFloat type was a deal breaker.

Re: I’m joining the Go team at Google

#155

Post by dmix »

Jgrubb wrote: post #135

I interviewed at Mongo a long time ago for a Drupal developer position. It was strange, they took me through a bunch of whiteboard algorithm crap that had nothing to do with Drupal. Obviously they weren't Drupal devs and didn't know how to interview for one so they just gave me the standard CS stuff. Obviously I was a Drupal dev so I didn't know shit about actual CS topics. I failed hard and learned a lot from it. St…

> they took me through a bunch of whiteboard algorithm crap that had nothing to do with Drupal.

Oh I hate that type of interview. I had a similar experience getting interviewed for a front-end dev position by two backend devs at a consumer VPN company in Toronto who asked me to write common CS algorithms while they both sat there staring at me.

Even ignoring the total lack of connection between the content of the algo with the job in question, I've never coded like that in my life. Largely because I also never took a CS course and didn't bothered to study cliche interview questions because I don't apply to big cos. But most importantly, I don't solve problems on the spot in front of other people IRL, so what aptitude are they testing for exactly?

I'm an introvert who always codes with headphones on and likes to spend time thinking through problems on my own - but can also work with other devs to solve problems when needed. I also had OSS projects, private repos I could show them, and live production apps with tens of thousands of visitors I built myself to point to my aptitude. That's been more than enough for other smart teams to hire me. It's also the content I look for most when I've hired people myself.

The non-technical founder also never told me ahead of time they were going to do this type of interview so I was surprised when they sat me down.

Also during a telephone interview with their other semi-technical founder asked me to describe how NAT works (yes asking a front-end dev to describe network implementation details). I figured he was just confused about what I would be doing for them... then I showed up to meet the two backend devs the next day.

I just walked out of the interview and told the founder his hiring process was silly, even though I liked the company (product). I'm happy I did.

I should note that I'm not against the idea of measuring aptitude during the hiring process, if companies want to be thorough. For example. during another interview process with a different company a dev team gave me a problem to solve (with ample warning before I arrived that day) and let me solve it on my own, using my own laptop in a quiet room, while they went back to work at their own desks for an hour or two (taking however long I needed). I was fine with that process and it worked out. There was also a collaborative element to it as well. That was a test better grounded in the reality of software development.

Re: I’m joining the Go team at Google

#156

Post by _ph_ »

vvanders wrote: post #122
weberc2 wrote: post #120

Earlier quoted context omitted.

> You don't have control over what goes on the stack/heap You do have this control. There is escape analysis, but I've never had to dance with it to make it put things on the stack when I need them to. I can get very close to C speeds with Go without much effort.

Can I say X is a value-type(or better annotate it in declaration)? If not then I don't have that control. Your compiler doesn't know your data access patterns, dataset size or a myriad of other factors that you need to tune if you really want to get full utilization from your hardware. To be clear I'm talking about ~5% of software out there, but when you need it you really need it.

Yes, the distinction between value and pointer types is explicit in the language, so you have all the control. This is, why you also have more control about the memory layout than in Java, which makes a huge difference in performance.

Re: I’m joining the Go team at Google

#157

Post by _ph_ »

pjmlp wrote: post #126
weberc2 wrote: post #125

Earlier quoted context omitted.

Think of all the hours you save not having to work around the misfeatures available out of the box in other languages. I know, you don't make mistakes or use those nasty features, but think of your coworkers .

My coworkers are savvy enough to handle those features.

Then you are a very lucky person. For the rest of us, it is very good to have a manageable language at hand.

Re: I’m joining the Go team at Google

#158

Post by gravypod »

sandGorgon wrote: post #153
sdegutis wrote: post #57

Earlier quoted context omitted.

Can confirm. At work we're moving from Clojure 8 to Java 8 partially because IntelliJ is amazing and partially because Java 8 plus the right libraries is close enough to Clojure anyway, except much faster.

whoa!! this is huge - can you talk a bit more about your stack please. This is the first time I have heard something like this - what libraries, code style, etc would get you the same "feel" as clojure ?

I'm assuming Lombok and using the new Lambdas. Maybe even a fibers library.

Re: I’m joining the Go team at Google

#159

Post by packetslave »

briceb8e wrote: post #36
coriny wrote: post #11

Earlier quoted context omitted.

As a habit it is bad, but this is actually standard for short bios. It allows it to be dropped in place directly for conferences, PR shots, news articles, etc without any rewrite.

Great to make it look like someone took the time to do a bio about you because you're important, while it's just you writing. Lack of self-confidence if you ask me.

pretty sure nobody asked you

Re: I’m joining the Go team at Google

#160

Post by jeremiep »

Thaxll wrote: post #95
tmpxkdks wrote: post #60

Earlier quoted context omitted.

> abstraction/polymorphism, concurrency and dependency management which are all simpler and clearer in Go than in Java Really? A lot of copy/pasted code, generics replaced with casts on empty interfaces, poor support for collections, only very primitive concurrency tools, and so on... I can understand that simplicity is good for small CLI/network tools, but it is hardly an alternative for really big applications wher…

Your big application shouldn't be that big first?

So you're saying we shouldn't have operating systems, browsers, video games and all that good stuff?

Most actual engineering is very far from writing a dumb server for yet another CRUD app :)

Post reply on HN