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

Why I Don't Want to Learn Go

arantaday.com

Post reply on HN
Print view View original

81–90 of 139 posts

Re: Why I Don't Want to Learn Go

#81

Post by anamax »

jrockway wrote: post #7

Go is designed for large codebases, which is a problem that the author may not have, and so he may not see the benefits. One key feature is that the Go compiler itself is the style guide: it automatically reformats your code to remove style guide violations. This makes it easy to work on a codebase the size of Google's because everything looks like it was written by the same person. We try to do the same thing for C+…

> We try [to make all code look like it was written by the same person] for C++, Java, and Python, but it doesn't work as well because the process is manual.

However, Python, because space is significant, tends to look fairly similar "in the wild". Add minimum adherence to a style guide and you're pretty close to that goal.

Re: Why I Don't Want to Learn Go

#82

Post by stcredzero »

minimax wrote: post #65
smanek wrote: post #31

Earlier quoted context omitted.

It's different, because I'm saying that much system level work has to optimize by not using a garbage collector . I've literally implemented off-heap malloc()/free() in Java because GC is so untenable. I argue that makes a language with has a GC that you can't avoid (as far as I know, it's impossible to allocate an 'object' off-heap in Go) a fairly poor choice for much system level work. Which means, if Go is to find…

I don't think you're getting his point. I can still replace GC with malloc() and we end up with the same criticisms of C that you have of Go and Java. > I'm saying that much system level work has to optimize by not using malloc(). I've literally implemented off-heap malloc()/free() in C because malloc() is so untenable. Anyone who has had to write fast C programs that make a lot of small objects eventually ends up he…

Outside of professionals and core contributors who write performance critical C, most folks haven't done a whole lot of work with a profiler with C programs. One doesn't get performance for free. It's paid for in some way, shape or form. The only thing that's up for grabs is how and when you pay for it. The costliest form of payment is developer hours, which you try not to pay if you can avoid it, though you sometimes can't avoid it.

Re: Why I Don't Want to Learn Go

#83

Post by anamax »

berntb wrote: post #9
heretohelp wrote: post #4

I concur with the concurrer and the author with my own more 'positive' addendum: I just want a cleaned/tarted up C. Something that doesn't make the critical mistakes of Go and Obj-C (adding runtime overhead), but adds optional compile and runtime semantics that can be very helpful and powerful. Some ideas: No GC. This is NOT negotiable. I'm tired of belabouring that point. Give me something nicer than the current C b…

>>No GC. Interesting that you disqualify Objective C? It use reference counting which should have a more predictable memory handling behaviour. Or is the dynamic stuff too much overhead for you? To me, it looks cheap (but I'm a scripter since quite a few years). (Not knowledgeable on this; I'm asking, not making an argument.)

> It use reference counting which should have a more predictable memory handling behaviour.

Correct reference counting in multi-threaded code running on a multi-core machine adds significant cost to a simple pointer copy (aka "add reference").

Re: Why I Don't Want to Learn Go

#84

Post by lclarkmichalek »

dagw wrote: post #80
protomyth wrote: post #73

Earlier quoted context omitted.

Historically, Sun hired John Ousterhout and that didn't turn out terribly well for TCL backing by Sun.

Fair point. Or for a more recent example, Microsoft hiring Simon Peyton-Jones and yet showing no interest in actually using Haskell for anything.

Well IIRC, he's employed by Microsoft Research, which is not really the same as Microsoft proper. And they have used some concepts that are core to Haskell, such as LINQ being a monad, and F# is definitely related (though I don't know if that's an official Microsoft language).

Re: Why I Don't Want to Learn Go

#85

Post by anamax »

alexchamberlain wrote: post #38
heretohelp wrote: post #8

Earlier quoted context omitted.

Nobody believes GC is a bad idea, it's a canard to suggest otherwise. It's that it's a contradiction of terms to say that you are offering a "systems" language but the language in question has non-optional GC. Go isn't competing with C and C++, it's competing with Java and C#.

I believe GC is a bad idea. Programmers should know what their objects are doing.

> Programmers should know what their objects are doing.

Programmers "should" do lots of things, but designing as if they actually do is usually a mistake. (If vehicle passengers behaved appropriately, air bags wouldn't be a good idea.)

It's better to design wrt what programmers actually do or get new programmers.

Re: Why I Don't Want to Learn Go

#86

Post by digamber_kamat »

I think a large portion of online life is already ruled by Google. I will never use Go only because it comes from Google. A mobile with Google's OS, a Google browser and Google for email and now we will also code in a language controlled by Google?

I have nothing against Google, but as a community of web developers our interest lies in diversifying and ensuring that no one gets more powerful than us.

Also looking at the features of Go itself, it seems to me that the languages caters to many needs of Google and not many of us may have those needs.

Re: Why I Don't Want to Learn Go

#87

Post by pcwalton »

masklinn wrote: post #19
heretohelp wrote: post #4

I concur with the concurrer and the author with my own more 'positive' addendum: I just want a cleaned/tarted up C. Something that doesn't make the critical mistakes of Go and Obj-C (adding runtime overhead), but adds optional compile and runtime semantics that can be very helpful and powerful. Some ideas: No GC. This is NOT negotiable. I'm tired of belabouring that point. Give me something nicer than the current C b…

Wasn't bitc trying to do some of that stuff? An other option you might want to look into is Rust[0], especially since the language is still in its early days (0.1) and the developers are more than willing to fix things which don't work. * It does not have bit fields or bounds-checked arrays (which it calls vectors) at this point I think * A bit of GC: it has a reference-counted pointer type, which is task-local, whic…

We're working on improvements to the language (namely, regions and dynamic arenas) to make it possible to not use the reference-counted pointer type at all if you don't want it, while retaining the type safety. Regions have their own set of costs, as we're finding out (mostly due to the annotation burden if you start doing complicated stuff), but I think we'll be in a nice sweet spot. Rust gives you three basic options:

(1) Regions, when you want safe, low-overhead allocation. The downside is a more complex type system. (Usually you don't see the complexity unless you're returning pointers that contain references to the stack, at which point you have to convince the typechecker that you aren't creating dangling pointers by doing so.)

(2) Safe, garbage collected heap allocation. This gives you maximum flexibility at the cost of runtime overhead.

(3) Unsafe pointers. This lets you manage your memory manually, like C++. Of course, this is unsafe.

Also, I suspect we're going to add fixed-length vectors; we've been discussing this quite a bit lately and I think there's general consensus that they should be present in the language in some form.

Re: Why I Don't Want to Learn Go

#88

Post by pcwalton »

heretohelp wrote: post #30
masklinn wrote: post #19

Earlier quoted context omitted.

Wasn't bitc trying to do some of that stuff? An other option you might want to look into is Rust[0], especially since the language is still in its early days (0.1) and the developers are more than willing to fix things which don't work. * It does not have bit fields or bounds-checked arrays (which it calls vectors) at this point I think * A bit of GC: it has a reference-counted pointer type, which is task-local, whic…

Been following Rust and bitc. I'll leave bitc alone and instead comment on Rust: Rust gets a lot closer than Go, but is still straddling this awkward territory between C and Java. I would imagine that Rust would be fantastic for implementing a database or a web browser or anything else equally complexity-management and performance driven. The concurrency and safety semantics seem to make that case even stronger for m…

So we basically use the runtime for three things: (a) the task system, which features lightweight threads like Go or Erlang; (b) stack checks and growth; (c) garbage collection. We used to use it for more, but lately more and more stuff has been moved out of the runtime to be written in Rust itself.

I'd like to see a "runtime-less Rust" myself, because it'd be great if we could implement the Rust runtime in Rust. This might be useful for other things too, such as drivers or libraries to be embedded into other software. (The latter is obviously of interest to us at Mozilla.) Rust programs compiled in this mode would disable the task system, would be vulnerable to stack overflow (although we might be able to mitigate that with guard pages), and would require extra work to avoid leaks, but would be able to run without a runtime.

If anyone is interested in this project, I'd be happy to talk more about it -- we have a ton of stuff on our plate at the moment, so we aren't working on it right now, but I'd be thrilled if anyone was interested and could help.

Re: Why I Don't Want to Learn Go

#89

Post by meepmorp »

lclarkmichalek wrote: post #84
dagw wrote: post #80

Earlier quoted context omitted.

Fair point. Or for a more recent example, Microsoft hiring Simon Peyton-Jones and yet showing no interest in actually using Haskell for anything.

Well IIRC, he's employed by Microsoft Research, which is not really the same as Microsoft proper. And they have used some concepts that are core to Haskell, such as LINQ being a monad, and F# is definitely related (though I don't know if that's an official Microsoft language).

I think F# is largely based on OCaml. I'm not sure what'd make a language official; MS does the development work on it, so I guess that'd be a yes on officialdom?
Post reply on HN