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

Seven years of Go

blog.golang.org

Post reply on HN
Print view View original

301–310 of 318 posts

Re: Seven years of Go

#301

Post by weberc2 »

pjmlp wrote: post #285
weberc2 wrote: post #263

Earlier quoted context omitted.

> Goroutines are coroutines. Traditionally, "coroutine" has been used to refer to a userspace concurrency unit that is not multiplexed and which requires explicit yielding. Mostly I'm grumpy about broadening a previously precise definition. > So while one must restrict ourselves with the co-routine scheduler provided by the Go runtime and to the yield points managed by it, with generalized async/await it is possible…

So what would you call coroutines that multiplex at API calls like NT fibers, or many green threads libraries. Or for that matter, coroutines on Active Oberon, which are just multiplexed as in Go.

I would call them fibers and green threads, respectively. No idea about Active Oberon.

Re: Seven years of Go

#302

Post by weberc2 »

notduncansmith wrote: post #274
weberc2 wrote: post #212

Earlier quoted context omitted.

Not cross platform last I checked.

I guess no Windows support could be a dealbreaker, but it's definitely "cross-platform" in several senses.

That isn't cross-platform in the senses I care about. I'm sure libmill is great and I wish it the best.

Re: Seven years of Go

#303

Post by weberc2 »

di4na wrote: post #270
weberc2 wrote: post #265

Earlier quoted context omitted.

I don't dispute that they exist, I dispute the economics of finding them compared to finding or training new Go developers. Frankly, no one is going to replace their entire team and start a hiring campaign because Haskell or Erlang (arguably) make concurrency slightly easier than Go.

You would be surprised by the result. Economically it make sense. And i would argue that production ready Elixir/erlang is easier to teach than production ready Go.

Still, I'm fairly risk averse. I'll wait for the inevitable explosion of Erlang/etc shops to take off before I jump on board.

Re: Seven years of Go

#304

Post by the_af »

candiodari wrote: post #294
keymone wrote: post #292

Earlier quoted context omitted.

i don't get what is not simple about ternary operator? why is if statement that necessitates multiple assignment statements, involves scoping rules and is objectively bloated for trivial cases, why is it considered simpler? it sure is easier to get than an operator due to proximity to natural language, but why tend to people that can't grasp that a statement can be represented as an expression?

As a general principle, everything else being equal, less information density is simpler. Ternary operator is quite dense. Think about it: algebra (most of it) is just simple concepts incredibly densely written down and recursively applied. There are very few really complex parts in it, by which I mean there's very few individual steps that take long to understand, there's just so bloody many of them and they link to…

But everything else is not equal; the if-else construct is less clear, more error prone, and you must read it fully to make sure all branches are assignments and that it's therefore logically equivalent to an assignment.

Re: Seven years of Go

#305

Post by grayrest »

greendragon wrote: post #277
grayrest wrote: post #264

Earlier quoted context omitted.

> I understand but I can't really agree since things like typos and type fails pretty much never happen to me, at least in production. The typos / type fail comments are shorthand for the real complaint, which is that a long-maintained large dynamic language codebase requires continuous vigilance. I've worked in dynamic languages for most of my career (Python, JS, Clojure) and typos/type-fails are pretty rare but if…

I see nothing false in rewording your statement to "a long-maintained large codebase requires continuous vigilance". Typing doesn't seem to matter with this. At least to the extent that we believe typing doesn't have a meaningful impact on the expected size, lifetime, and complexity of a codebase to solve an arbitrary problem. (With better type systems around it is neat to see statically typed languages quite signifi…

> I also spend/waste a lot of time, probably the most time in total, tracking down complex issues that got past the type system and existing tests and code reviews

Nobody will argue against you on this. The static/dynamic debate, as I understand it, is about whether typing and design constraints typing impose are worth the reduction in simple issues. Reasonable people can choose both and my personal take is that I think types are worth it given a good type system for a long-maintained project. You get more people coming on board and I think types are most useful in that situation.

generics and sum types

> how does it square with people like the author of Clojure? Is he just a god-tier outlier?

I happened to be in a group Rich joined for lunch at the last Clojure Conj and we talked about typed functional languages. The short story is that he doesn't think types are worth the tradeoffs. At the time Clojure had just introduced transients and he mentioned the numerous typed functional language blog posts about the feature and that most were incorrectly typed. He gives specific examples at the end of Simple Made Easy and reiterated many of them those during the discussion.

I think we'd agree that, libraries and architecture matter more than language but I do think language influences the abstractions the library can provide. My post wasn't really meant to argue the superiority of types in all situations but rather a specific response to the sentiment of "why do people always bring up typos when I never run into them"?

Re: Seven years of Go

#306

Post by tigershark »

weberc2 wrote: post #102
wyager wrote: post #91

Earlier quoted context omitted.

How is Go safer than, say, Java? It doesn't really do anything particularly useful or interesting on the safety front; it's type system is weak, it has null pointers, its error management mechanisms are mediocre.

It's not safer than Java. The selling point over Java is developer friendliness (simpler language, tooling, dependency management, deployment, etc).

no. I really don't like java, but you really can't tell that go has better tooling and it is more developer friendly. it's an outright lie. java tooling is very mature and has solutions that no other language that I know can use. (Spock framework above all, it is written in groovy but it is perfectly integrated in java and still I haven't find anything nearly comparable in any other language). show me some BDD framework in go, just as an example.

Re: Seven years of Go

#307

Post by masklinn »

agnivade wrote: post #287
fizzbatter wrote: post #8

So, i was a Go developer for ~4 years, then for the last 4 months or so i've been learning and using Rust. The pure joy of some things with Rust was astounding. Now, i joined a new job and they're in need of a new language for some backend tasks - the choice was mine. Rust or Go? The backend tasks were heavy API servers - nothing amazing, we don't do groundbreaking work. Python was their existing language, but they w…

> 3. Package management. This is being taken care of. A package management committee has been formed and they will come up with a prototype tool in Go 1.8. https://docs.google.com/document/d/1qnmjwfMmvSCDaY4jxPmLAcca... > 4. Enums. Doesn't the iota identifier solve it for you ? It pretty much covers all my enum use cases.

> Doesn't the iota identifier solve it for you ?

They're talking about sum types (aka tagged unions aka variant record), where you have a proper type with a closed set of variants (which can be checked for completeness by the compiler) and optional associated data (possibly of different types for each variant).

Iota isn't even a step up from C's enums, it doesn't come close to what you can find in ML descendants (such as Rust or Swift for the most recent ones).

Re: Seven years of Go

#308

Post by aikah »

stcredzero wrote: post #242
pcwalton wrote: post #238

Earlier quoted context omitted.

And that's clearly the case with generics.

You're seriously saying that generically? All languages should simply have them? Not so sure you should dismiss the context like that.

> You're seriously saying that generically? All languages should simply have them? Not so sure you should dismiss the context like that.

Point me to a successful statically typed language born after 2005 that doesn't have some form of generics. Go has generics by the way, you just can define your own in user land, which is a stupid limitation.

Re: Seven years of Go

#309

Post by mjburgess »

defgeneric wrote: post #290
lomnakkus wrote: post #235

Earlier quoted context omitted.

> While I'd like to have generics in go, one of the upsides of the lack of generics is that your code becomes less idiosyncratic and more idiomatic. That sounds like a deepity[1] if ever I've heard one. Just to add something a little more substantive: It may not be obvious at first sight (esp. in e.g. C++ or Java), but 'generics'/'parametric polymorphism' can actually incredibly powerful at restricting what your prog…

> That sounds like a deepity[1] if ever I've heard one. Your code becomes less peculiar to you and more in line with the peculiarities of the language as it's used by most people. Shallow enough? Don't let an allergy to postmodernism become an allergy to a turned phrase. Not sure what the rest of your comment has to do with my point, which was about, if you like, the pragmatics of programming. Not concerned with the…

In my experience Haskell-people are not insuffereable, but have a history of a rather academic humility in the same manner that, historically, the ruby community used to.

Perhaps this is changing, but my guess is the prior comment was by a person who appeals to Haskell more often than uses it.

Re: Seven years of Go

#310

Post by vorg »

tigershark wrote: post #306
weberc2 wrote: post #102

Earlier quoted context omitted.

It's not safer than Java. The selling point over Java is developer friendliness (simpler language, tooling, dependency management, deployment, etc).

no. I really don't like java, but you really can't tell that go has better tooling and it is more developer friendly. it's an outright lie. java tooling is very mature and has solutions that no other language that I know can use. (Spock framework above all, it is written in groovy but it is perfectly integrated in java and still I haven't find anything nearly comparable in any other language). show me some BDD framew…

> Spock framework above all, it is written in groovy

You're the one who's telling an "outright lie" (as you put it). I just downloaded and unzipped Spock from Github, and looked through its directory structure. Virtually all of it is written in Java, not Apache Groovy. There's only a few little files written in Groovy.

Perhaps you're confusing its source language with the language users of Spock write their test scripts in. In real life, Groovy is used for the JVM in the same way Bash is used for Linux, like writing glue code and build files. The statically typed stuff added in Groovy 2.x isn't used much at all, and virtually no-one would use Groovy to build actual systems. All software I know of that provides Groovy to users, like Grails, Gradle, and Spock, is itself written in Java.

Post reply on HN