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

The State of Go

talks.golang.org

Post reply on HN
Print view View original

231–240 of 402 posts

Re: The State of Go

#231

Post by steveklabnik »

oscargrouch wrote: post #224
steveklabnik wrote: post #191

Earlier quoted context omitted.

One nice thing about the "rewrite C++ in Rust" is that oh can do it incrementally; we're taking the same approach for Firefox, for example. Out of curiosity, what are the libraries in C++ that you miss in Rust, or would have to re-write?

For me C++ (or Rust) would be the languages to go for Browsers, VM's, Compilers, Game Engines, Glue Code for a OS(platform layer to prepare things for a app to run) etc.. The problem is, there's a lot of code in C++ already for all of this. V8, Dart, Java Vm's in C++, Webkit, Chrome, Firefox in C++, great game engines in C++. Is not that i wouldnt use Rust.. on the contrary. But the problem is, for the usecase i thin…

Cool, totally get this argument. I was mostly curious if you were thinking about something in Rust, but then found the libraries lacking, as we're trying to work on filling in gaps here.

Re: The State of Go

#232

Post by sjellis »

tejasmanohar wrote: post #145
Taek wrote: post #137

Earlier quoted context omitted.

In my experience writing go is very fast and reading go is also very fast. The language was designed to be very comfortable, and they did a great job with that. You sit down to write something and you don't have to think too much about the best way to tackle the problem, the lines of code just flow from your fingertips. There's mostly one way to do everything, which makes doing things easy. Code review is much the sa…

I feel the same. Go is a different type of terse. I think terseness goes beyond the number of lines. When I skim Go code, I can grasp the meaning of it very quickly.

I've seen talks where Rob Pike describes Go as being "light on the page" vs. "noisy", meaning (I think) that it doesn't have lots of sigils and annotation bits around the code.

Re: The State of Go

#233

Post by mseepgood »

vvanders wrote: post #228
pjmlp wrote: post #172

Earlier quoted context omitted.

> To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language. Having a GC doesn't forbid that, in very specific cases. Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, System C#, Swift, D are all examples of such languages.

I never said anything about having a GC, just that if you can't poke directly at memory when you need to then you're going to have a heck of a time working on the Systems Programming space.

> if you can't poke directly at memory when you need to then you're going to have a heck of a time working on the Systems Programming space

That's possible in go with unsafe.Pointer. Go's runtime, GC and memory allocator are written in Go and make use of this.

Re: The State of Go

#234

Post by dtzur »

mattnewton wrote: post #93
DrBazza wrote: post #42

Given some of the comments, I'll make the same comment I've made before: Stroustrup is right, there are languages that people complain about, and languages that no-one uses. Go is now firmly in the former camp. I'm a C++ dev, and I really enjoy using Go. If you don't like what it does or how it does it, it's not for you. Either way, people are out there using it, making systems from it, and generally getting on with…

Idk if that's such a clean binary, one of my favorite languages is Haskell, and people both complain about that and don't use it :)

Imagine I gave you reddit gold

Re: The State of Go

#235

Post by dvirsky »

Retric wrote: post #205
dvirsky wrote: post #162

Earlier quoted context omitted.

But Go really does encourage good practices. I came to Go after programming in C, C++, Java and a bunch of dynamically typed languages. After a couple of years with Go I returned to C (and a bit to Java). And I'm writing better code in those languages now. Now, part of it is natural progress probably. But especially when I'm writing C, I can tell that I'm writing it much better than before because I'm adopting back s…

I suspect every time you move to a different language family you learn new things. I did C/C++ and Java then worked with an old Pascal codebase of all things that IMO taught me more than most other languages. Even XSLT taught me quite a bit.

I can't say that Java has improved me in any language, but Go and Python have improved my Java. But any time you learn new idioms in a new language, your understanding of programming gets better I suppose.

Re: The State of Go

#236

Post by dvirsky »

watwut wrote: post #226
dvirsky wrote: post #162

Earlier quoted context omitted.

But Go really does encourage good practices. I came to Go after programming in C, C++, Java and a bunch of dynamically typed languages. After a couple of years with Go I returned to C (and a bit to Java). And I'm writing better code in those languages now. Now, part of it is natural progress probably. But especially when I'm writing C, I can tell that I'm writing it much better than before because I'm adopting back s…

Is there a good resource where those good transferable go idioms are written? I dont think I will have time to learn go anytime soon, but would definitely spent time with an article or something like that.

Not that I know of, but Go is super easy to learn. You will get a grip of the basics and be productive over a few hours or weekend at most, and one or two hobby projects later you'll learn to appreciate the stuff I'm talking about.

BTW I've only felt I really knew the language and its inner workings and idioms deeply - after much longer, maybe a year and 2-3 big projects. But you get very productive very fast.

Re: The State of Go

#237

Post by kibwen »

zzzcpan wrote: post #179
sidlls wrote: post #164

Earlier quoted context omitted.

And further, in my view, if manual memory management is extraordinarily difficult a language is not necessarily a good candidate for systems programming.

You can relatively easily get to manual memory management using Go's runtime, i.e. access those runtime·sysAlloc(), runtime·sysFree() functions directly, the way Go accesses syscalls in the external sys package [1]. It's like ten lines of code, nothing extraordinarily difficult. [1] https://github.com/golang/sys/blob/master/unix/asm_linux_amd...

The difficulty of manually managing memory isn't necessarily to do with how many lines of code it takes to allocate or deallocate. The difficulty is in managing the scope of the rest of the program that is now susceptible to memory errors, which extends far beyond those initial ten lines of code if encapsulation is done inexpertly.

Re: The State of Go

#238

Post by sagichmal »

Cthulhu_ wrote: post #165
skybrian wrote: post #83

Earlier quoted context omitted.

The preference for maps and folds looks like a fad to me. I can use them but I don't think it makes the code any easier to understand, just different.

It does though. Maps and folds - and functional programming in general - focuses on the /what/. For-loops on the other hand tell the compiler / cpu the /how/. Summing is a nice example. A naive for-loop will just iterate through the list, keep a variable around, add the next item in the list to it. In functional programming (or with a reduce), you tell it to sum in a more concise way - but more importantly, you don't…

Yes, that's exactly right. And Go takes a relatively strict stance on making the _how_ obvious to the programmer. It goes out of its way to avoid hiding O(n^k) loops behind language sugar like map or fold, for example.

Re: The State of Go

#239

Post by eeZah7Ux »

prodigal_erik wrote: post #173
omginternets wrote: post #160

Earlier quoted context omitted.

>Go is a useful language, but it's a language that has purposefully stripped out all the magic. People like magic, they miss it. Agreed, and I'd further argue: 1) most people driving Ferraris aren't skilled enough to drive them properly 2) most people driving Ferraris have no need to corner at 120 MPH 3) most people driving Ferraris are just trying to show off 4) most people driving Ferraris are more likely to hurt t…

It's an apt metaphor. Much like programming, there are a hell of a lot of people driving who really shouldn't be.

Then there should be programming licenses:

Level 1: let interns use Go(-karts), like their parents did with Basic.

Level 2: most languages. Proper training required and you still have to be careful.

Level 3: C, C++, critical code, kernels, crypto code. Training a commercial airline pilot takes years; and while this stuff is not hip enough for some, there's plenty of demand.

Re: The State of Go

#240

Post by pjmlp »

vvanders wrote: post #228
pjmlp wrote: post #172

Earlier quoted context omitted.

> To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language. Having a GC doesn't forbid that, in very specific cases. Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, System C#, Swift, D are all examples of such languages.

I never said anything about having a GC, just that if you can't poke directly at memory when you need to then you're going to have a heck of a time working on the Systems Programming space.

As mseepgood already replied, you can do that in Go.
Post reply on HN