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

Go 2, here we come

blog.golang.org

Post reply on HN
Print view View original

521–530 of 534 posts

Re: Go 2, here we come

#521

Post by Groxx »

int_19h wrote: post #511
Groxx wrote: post #404

Earlier quoted context omitted.

it's true that it's "just syntactic sugar", but in most languages it has call-site contracts that are either part of the signature (`await x()` to unpack the future/coroutine) or implicit (`x()` in an event loop host). and to change something deep in the stack means changing every call site everywhere. that's a huge burden on a library (and thus the entire language ecosystem). it splits the world. to avoid that, you…

Right. You can have callee's parallelism be invisible - but only by adding it to your language (can't be done as a library) and making it be similarly invisibly parallel. And even that only works so long as everybody adopts the same system - goroutines don't play well with Ruby fibers, for example. With the async/await model, you can immediately use it with any language that has callbacks, and then the languages can…

thread interop may be a major contributor to "far more successful in practice", because yea - I agree, it's far more common. I don't know that side of things all that well :|

having spent a fairly significant amount of time in an event-loop system with async/await tho (python coroutines): I don't know if that's a good thing. getting your head around "thou must never block the event loop, lest ye unceremoniously bring the system to its knees" / never using locks / never confusing your loops / etc requires both significant education and and significant care, and when you get it wrong or performance degrades it can be truly horrific to debug.[1] it's nice that it tends to have fewer data races though.

green thread systems though are trivial - your stack looks normal, your tracing tools look normal, your strategies are basically identical (since they tend to context switch at relatively fine-grained points, so your only real concern is heavy func-call-less computation, which is very rare and easily identified). since I don't have to deal with thread interop[2] I'll take that every single time over async/await.

---

[1] I've helped teams which had already spent weeks or months failing to make progress, only to discover what would be an obvious "oops" or compile-time error elsewhere. some languages do this much better, from what I've seen, but CPS javascript and python coroutines and other ones I've used have been awful experiences. basically, again, language-level support is needed, so I broadly still disagree on "just syntactic sugar" for it to be even remotely acceptable.

[2] ....though cgo has been a nightmare. nearly everyone uses it wrong. so I 100% believe that I could switch sides on this in time :)

Re: Go 2, here we come

#522

Post by shakna »

lasagnaphil wrote: post #443
shakna wrote: post #440

Earlier quoted context omitted.

> the interpreter has to check the types of the variables a and b at runtime beform performing the right form of addition (it might be an int, or a string, you dont know) That's not necessarily true. In Scheme, a very dynamic language, the compiler will generally make choices about memory layout of the various values before launching into the evaluation phase. Where safe or possible to do so, it will probably reduce…

Didn't know about Scheme. Thanks for the link!

If you've never met Scheme, then SICP [0, 1, 2] may be something that can change the way you program. It certainly made me better, or at least a deeper understanding.

[0] https://www.youtube.com/watch?v=2Op3QLzMgSY&list=PLE18841CAB...

[1] https://www.amazon.com/Structure-Interpretation-Computer-Pro...

[2] https://web.mit.edu/alexmv/6.037/sicp.pdf

Re: Go 2, here we come

#523

Post by vram22 »

paulddraper wrote: post #281
vram22 wrote: post #103

Earlier quoted context omitted.

> In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs. This is like comparing apples and oranges, or at least, like comparing apples and apple-orange hybrids :) Just saying that Rails (R…

Is this the same type system that famously forces you to cast items in your collections to the universal supertype?

You know well that it is. Add /s or /rhetoric to your question next time :)

Languages can be pretty useful even if they are imperfect, as others have said. And Go is plenty useful. The Stroustrup quote about C++ comes to mind ...

Re: Go 2, here we come

#524

Post by vram22 »

vram22 wrote: post #523
paulddraper wrote: post #281

Earlier quoted context omitted.

Is this the same type system that famously forces you to cast items in your collections to the universal supertype?

You know well that it is. Add /s or /rhetoric to your question next time :) Languages can be pretty useful even if they are imperfect, as others have said. And Go is plenty useful. The Stroustrup quote about C++ comes to mind ...

Here you go:

https://en.wikiquote.org/wiki/Bjarne_Stroustrup

"There are only two kinds of languages: the ones people complain about and the ones nobody uses."

And here's a good set of Q&A from his FAQ; it includes the above quote too:

"Did you really say that?":

http://www.stroustrup.com/bs_faq.html#really-say-that

Re: Go 2, here we come

#525

Post by vram22 »

Stratoscope wrote: post #98
vram22 wrote: post #85

Earlier quoted context omitted.

I seem to remember seeing a few articles about "'$X considered harmful' considered harmful'. Also: Why Functional Programming Matters and Why Why Functional Programming Matters Matters Edit: Just saw the sibling comment by Stratoscope: "we would see all sorts of articles under the title 'X considered harmful' for almost any X, including one titled "Dijkstra considered harmful." :)

And this classic by Scott Meyers of Effective C++ fame: "Considered Harmful" Essays Considered Harmful https://meyerweb.com/eric/comment/chech.html

Thanks, will check that out. I really liked the Effective C++ book by Scott.

There's a good video talk by him titled something like "The Last Thing D Needs".

Re: Go 2, here we come

#526

Post by icholy »

ryeguy wrote: post #347
glangdale wrote: post #339

I'm pretty excited by the idea of Go getting generics. This has always been my deal-breaker issue with Go and I'm glad that what appeared to be a disingenuous "let's pretend to be hunting for the truth until people go away" stance was actually really a hunt for the truth! Goes to show that you shouldn't make snarky snap judgments. As for all the folks claiming they'll leave Go if it gets generics, it's faintly remini…

I really don't get the people opposed to generics. Is there actually a cross between experienced developers who have come from languages that have generics and understand them, yet don't want them in go? If so, why, and what do they use instead? Because go has no compromise-free answer for generics. You either lose type safety, maintainability, or performance. I suspect a lot of the generics hate is due to a large ch…

Coming up with a complex solution is much easier than finding a simple one. Go forces you to find those simple solutions. There are places where generics are the only solution, but they also enable lazy design.

Re: Go 2, here we come

#527

Post by glangdale »

IshKebab wrote: post #357
ryeguy wrote: post #347

Earlier quoted context omitted.

I really don't get the people opposed to generics. Is there actually a cross between experienced developers who have come from languages that have generics and understand them, yet don't want them in go? If so, why, and what do they use instead? Because go has no compromise-free answer for generics. You either lose type safety, maintainability, or performance. I suspect a lot of the generics hate is due to a large ch…

It's people that have seen the abuses of C++ templates. They're very powerful and therefore people tend to want to use them for really complicated things. Look up things like SFINAE and compile time metaprogramming. Templates were not intended for those things. When they work they're ok, but if they go wrong good luck following the 10 line error message. Here's an example from Rust: https://www.reddit.com/r/rust/comm…

Ha ha, "10 line error". [ Puts on Monty Python voice] "What I wouldn't give for a 10 line error..."

Incautious use of the template mechanism - or just a minor typo - has given me couple screenfuls in the past.

Re: Go 2, here we come

#528

Post by [deleted] »

paraditedc wrote: post #393
ryeguy wrote: post #348

Earlier quoted context omitted.

Coincidentally, here's Rust's getting started workflow: - Install Rust - Install VSCode + Rust plugin - Start working

Coincidentally, here's JavaScript's getting started workflow: - Command + Option + J (on Mac+Chrome) - Start writing JavaScript

[deleted]

Re: Go 2, here we come

#529

Post by runeks »

joppy wrote: post #378
jolmg wrote: post #307

Earlier quoted context omitted.

I like how Haskell does it. When you simply write a number like "3" it will infer the type to be "Num a => a" which means it could be any type you have loaded that defines the functions in the typeclass Num: class Num a where (+) :: a -> a -> a (-) :: a -> a -> a (*) :: a -> a -> a negate :: a -> a abs :: a -> a signum :: a -> a fromInteger :: Integer -> a "3.0" would be "Fractional a => a" which means it defines the…

This is a great system for tying in new number types with existing ones, but the lack of explicitness about casting exact types (Integer, Rational) to inexact types (Int, Float) has led to many bugs and confusions for me. Coupled with the fact that so many standard functions (like length, for example) want to return an Int rather than an Integer, it just leads to me spewing ((fromIntegral ___)::Integer) all over my c…

> [...] but the lack of explicitness about casting exact types (Integer, Rational) to inexact types (Int, Float) has led to many bugs and confusions for me.

What do you mean? As far as I'm aware, you always have to explicitly convert exact types to inexact types in Haskell (using "fromIntegral" and "realToFrac").

> Coupled with the fact that so many standard functions (like length, for example) want to return an Int rather than an Integer, it just leads to me spewing ((fromIntegral ___)::Integer) all over my code.

Indeed this is rather annoying. It's this way because of legacy reasons (see https://www.reddit.com/r/haskell/comments/60u10b/do_function...).

Re: Go 2, here we come

#530

Post by zapzupnz »

jimsmart wrote: post #253
zapzupnz wrote: post #107

Earlier quoted context omitted.

Swift can get away with it because the majority of its users are using Xcode which has excellent tools for migrating between versions of Swift, and also interop with Objective-C code. Plus, the current compiler can target a limited number of older versions’ syntax but allowing use of new APIs for some degree of forwards compatibility in large code bases. Whereas I doubt there’s one canonical Go dev environment common…

There’s a tool called fix, it’s already part of the standard Go distribution. In the past (mostly pre 1.0, IIRC?), it’s used to apply changes to one’s codebase when migrating between Go releases that introduce incompatible changes. https://golang.org/cmd/fix/

Can it be used in editors, say VS Code, to provide fix-its or suggestions for improving code on a line-by-line basis? If so, that sounds great. A lot of languages are missing this in their standard distributions and devs must rely on third-party offerings.
Post reply on HN