I’m joining the Go team at Google

Post by bsdetector » Fri, Sep 23, 2016, 2:09 PM UTC

junke wrote: post #85

thwd wrote: post #80

Earlier quoted context omitted.

True, you can discard errors on purpose by assigning them to "_", which is an explicit way of saying "I do not care about this error happening". If you do that and get a panic down the line, you already know where to start debugging. That's much better than having an exception bubble up from deeeeep inside your code with some context-less cryptic message or number, isn't it?

> If you do that and get a panic down the line... No, you don't panic, you are most likely to corrupt your data and maybe continue working as if everything was fine. If you are lucky, your code panics. > ... you already know where to start debugging. Grep all occurrences of "_"? > That's much better than having an exception bubble up from deeeeep inside your code with some context-less cryptic message or number, isn'…

Post by nv-vn » Fri, Sep 23, 2016, 2:13 PM UTC

thwd wrote: post #80

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?

True, you can discard errors on purpose by assigning them to "_", which is an explicit way of saying "I do not care about this error happening". If you do that and get a panic down the line, you already know where to start debugging. That's much better than having an exception bubble up from deeeeep inside your code with some context-less cryptic message or number, isn't it?

Post by Thaxll » Fri, Sep 23, 2016, 2:14 PM UTC

tmpxkdks wrote: post #60

dgb23 wrote: post #54

Earlier quoted context omitted.

Some of the harder more time consuming things in high level programming include abstraction/polymorphism, concurrency and dependency management which are all simpler and clearer in Go than in Java. Think about how many hours you have to invest to learn any of these things in either language.

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

Post by reitanqild » Fri, Sep 23, 2016, 2:24 PM UTC

gravypod wrote: post #77

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.

I think as developers we are so used to pain that we forget how "easy" development can be if we allow people the right tools. If any language had the tooling and development Java did it would hold the market share. It's my opinion that if Rust makes a similar IDE experience (even just using Eclipse's platform) with every feature like code completion, formatting, debugging, the hole 9 yards and integrate Cargo into it…

Post by whamlastxmas » Fri, Sep 23, 2016, 2:29 PM UTC

dagw wrote: post #40

briceb8e wrote: post #36

Earlier quoted context omitted.

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.

Lack of self-confidence if you ask me. How do you figure? Every time I've been asked for a bio for a conference or similar, they've asked for it in third person. Reading bios in conference proceeding in first person would just come across as weird to me.