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

A little Golang way

aerofs.com

Post reply on HN
Print view View original

181–190 of 194 posts

Re: A little Golang way

#181

Post by omginternets »

nickpsecurity wrote: post #160
omginternets wrote: post #150

Earlier quoted context omitted.

One of my colleagues (a Paris Politechnique guy, so very much a mathematical purist) was recently going on and on about the beauty of lisp, and how much better it was than C (on a formal level, of course). I think Go sits on the opposite end of the spectrum. It's a hacker's language, not a mathematician's language. It's ugly and very useful.

" It's a hacker's language, not a mathematician's language. It's ugly and very useful." Lmao. That's exactly what hackers said about LISP. That people can often emulate a language or even paradigm (eg OOP) within the original language using macro's shows it. Strange enough, LISP can modify itself to do whatever modern languages are doing with similar productivity. It doesn't work vice versa. On top of it, the LISP co…

The language was a bit hyperbolic, but the point was rather that you shouldn't expect mathematical purity from Go.

Lisp is a great language. This wasn't meant to be a jab at lisp.

Re: A little Golang way

#182

Post by [deleted] »

nickpsecurity wrote: post #160
omginternets wrote: post #150

Earlier quoted context omitted.

One of my colleagues (a Paris Politechnique guy, so very much a mathematical purist) was recently going on and on about the beauty of lisp, and how much better it was than C (on a formal level, of course). I think Go sits on the opposite end of the spectrum. It's a hacker's language, not a mathematician's language. It's ugly and very useful.

" It's a hacker's language, not a mathematician's language. It's ugly and very useful." Lmao. That's exactly what hackers said about LISP. That people can often emulate a language or even paradigm (eg OOP) within the original language using macro's shows it. Strange enough, LISP can modify itself to do whatever modern languages are doing with similar productivity. It doesn't work vice versa. On top of it, the LISP co…

[deleted]

Re: A little Golang way

#183

Post by nickpsecurity »

omginternets wrote: post #181
nickpsecurity wrote: post #160

Earlier quoted context omitted.

" It's a hacker's language, not a mathematician's language. It's ugly and very useful." Lmao. That's exactly what hackers said about LISP. That people can often emulate a language or even paradigm (eg OOP) within the original language using macro's shows it. Strange enough, LISP can modify itself to do whatever modern languages are doing with similar productivity. It doesn't work vice versa. On top of it, the LISP co…

The language was a bit hyperbolic, but the point was rather that you shouldn't expect mathematical purity from Go. Lisp is a great language. This wasn't meant to be a jab at lisp.

Oh, yeah, I'd never put Go into any mathematical category. It's more about practical purity and simplicity like the languages that inspired it. My gripe with go was that it was a clean-slate, modern language that didn't adopt any of the awesome things PL community invented since the 80's.

Julia seems to be the best example of a clean-slate language that tries to combine all the best features and attributes of various languages with good effect. Also beats Go and many other languages on various benchmarks despite dynamic typing. I'd like to see some application-server or RDBMS type of benchmarks, though, as Julia was designed for the mathematical stuff. Might not perform as well but should still be good.

http://julialang.org/

Re: A little Golang way

#184

Post by acconsta »

pcwalton wrote: post #170
krakensden wrote: post #168

Earlier quoted context omitted.

A higher cost for context switching. Lots of people work on apps with lots of i/o, and there is a long history of coroutine/callback/green thread architectures beating the pants off of thread per request architectures.

No, the context switching overhead tends to be minimal if you're using a well-tuned kernel. You're doing a context switch to the kernel for I/O in the first place, and in a green thread model you have to do a userspace context switch in addition to the context switch the kernel imposes to get back into your scheduler.

Are there benchmarks to support that? JVM greenthreads vs. linux user threads, for example?

Re: A little Golang way

#185

Post by ansible »

Scramblejams wrote: post #176
Scramblejams wrote: post #174

Earlier quoted context omitted.

Thanks for the tip, stackless coroutines are new to me. Any of that on the Rust roadmap?

Am I correct that coroutines are intrinsically non-preemptive? If so, I'll need to keep looking.

Am I correct that coroutines are intrinsically non-preemptive? If so, I'll need to keep looking.

That's usually the case. Coroutines have their uses, but having used goroutines, that is my current preference.

Re: A little Golang way

#186

Post by pcwalton »

ansible wrote: post #185
Scramblejams wrote: post #176

Earlier quoted context omitted.

Am I correct that coroutines are intrinsically non-preemptive? If so, I'll need to keep looking.

Am I correct that coroutines are intrinsically non-preemptive? If so, I'll need to keep looking. That's usually the case. Coroutines have their uses, but having used goroutines, that is my current preference.

Coroutines are preemptible at I/O boundaries or manual synchronization points. Those synchronization points could be inserted by the compiler, but if you do that you're back into goroutine land, which typically isn't better than 1:1. In particular, it seems quite difficult to achieve scalability to millions of threads with "true" preemption, which requires either stacks or aggressive CPS transformation.

Re: A little Golang way

#187

Post by pcwalton »

acconsta wrote: post #184
pcwalton wrote: post #170

Earlier quoted context omitted.

No, the context switching overhead tends to be minimal if you're using a well-tuned kernel. You're doing a context switch to the kernel for I/O in the first place, and in a green thread model you have to do a userspace context switch in addition to the context switch the kernel imposes to get back into your scheduler.

Are there benchmarks to support that? JVM greenthreads vs. linux user threads, for example?

Both the JVM and Linux pthreads are 1:1.

Re: A little Golang way

#188

Post by ansible »

stesch wrote: post #177
patio11 wrote: post #32

Earlier quoted context omitted.

You're probably being downvoted for off-topicness, FYI, since this comment is equally germane to any mention of Go. That said, I feel it is a comment in good faith and deserves an answer. Question #1: How invested should you model Google as being in Go's future? Answer: Extraordinarily invested. They have a whole lot of code written in it, most of which the world will never hear about, and which powers services that…

I'm not sure if this will help me. I guess I'm in a programmer midlife crisis. Every new thing is potentially a waste of time because you can't predict if it is still around in 2 years. And with Google you know that they invest millions of dollars in projects and then abandon them. Would I be better off maintaining decade old COBOL projects? Sometimes I think so. Other times I'm glad I can chose the technology I want…

You can never stop learning. Go is my current 'thing', at least for personal projects. But who knows what the landscape will be like in 5 years or 10.

For a while I though Haskell was the most awesome thing. Good Haskell code has a timeless quality to it (in a couple senses of the word). But I found adapting my thinking to it difficult, and it wasn't likely to be something I'd use at work then or now.

Re: A little Golang way

#189

Post by ansible »

aikah wrote: post #81
shocks wrote: post #28

Earlier quoted context omitted.

Go is a programming language born out of Google for sure, but that does not mean it depends on Google. It's a community project after all.

> It's a community project after all. It is absolutely not a community project. Go governance is a 100% @ Google . There is no go committee or go working group outside Google. It's backed by one company that has full control over it. Sure it's open-source, but good luck with a fork. How can anybody be so misleading about that fact ? What did make you think Go is a "community project" ? > but that does not mean it dep…

I still want to know what made you think Go is a "community project".

Well, the main developers do listen to the community.

Any project can fork, if there are enough people who are very dissatisfied with the current management.

I'm not aware of any serious grumblings about such a fork though. Why?

The core team is very good, and very narrowly focused. They've communicated clearly on nearly every issue as to what they're doing, and why. It seems clear that they are intent on making the best possible tool that fits with their particular vision. There are people who agree with this vision, and broadly support their efforts. And then there are people who really don't like their vision, and wander off to use Rust or something else.

The core team has enormous respect from the existing golang community. If Google suddenly laid off the developers (or just switched them to something else) or otherwise dramatically changed direction in their support for the project, the community would move in quickly to help out the situation.

I could see people getting together to form a non-profit foundation that could at least pay for a few guys to continue to work on Go full-time. But currently, there is no apparent need, so it hasn't been done. Google is willing to pay substantially for the development, and I don't see gophers complaining about that.

Re: A little Golang way

#190

Post by serge2k »

chimeracoder wrote: post #57
pcwalton wrote: post #53

Earlier quoted context omitted.

> Because the tooling was a first-class design goal, a number of the problems that traditional design patterns were created to address are less problematic in Go code[1]. > [1] Again: gofmt… What does gofmt have to do with design patterns? gofmt is about code formatting. Design patterns are about abstraction and expressiveness. A code formatting tool does nothing to address abstraction and expressiveness of the langu…

> gofmt is about code formatting. Design patterns are about abstraction and expressiveness. First, gofmt can do more than code formatting, such as applying simplifying code transformations that are semantically equivalent. Second, code formatting and design patterns are indeed related, because the way code is laid out in text is the way that design patterns are expressed. The layout of code affects how abstractions a…

You picked gofmt because go fans can't get over their amazement that a code formatting tool exists.

Did you all write your code in notepad before?

Post reply on HN