Live data from Hacker News

Go Data Structures: Interfaces (2009)

research.swtch.com

71–80 of 80 posts

Re: Go Data Structures: Interfaces (2009)

#71
post #56

Earlier quoted context omitted.

[flagged]

[flagged]

Never used F#. Looked it up for thread cancellation and it is syntactic sugar similar to defer in Go. Kind of like an await return is a wrapper around f(x) callback.

Been years since I wrote Go code, until last week. Daily has become C#, python, and powershell. Took a day to fall back in and write a tool while learning a new GUI framework. Found the strengths and weaknesses of the GUI.

Personal, I find Go more pleasurable to work with than python and C#. Reality, the project requirements dictate the languages that maybe used. This is the reason why Go was chosen over the others listed and unlisted C, C++, Swift, rust, ...

Which would be a better experience with developing for iOS, Swift or C# or Go? If it was company's main solution or product, Swift, even when I will need to learn it.

>Take a transport, like an HTTP client, send two/three/n requests concurrently

That is business logic. Back end maybe embedded and this could become a DOS attack.

.NET implemented the code to manage task pools so you don't have to. N aysnc is really a set of Z handlers. With syntax sugar.

>Context propagation issues are known

Doesn't a context need to exist for two entities to communicate and no system can exist where context is not shared?

This is the adapter pattern in GoF, which in can be reduced to function g controlling the interactions between function a and b, where function a or b may act upon the agreed upon return type, callback type, or memory type. Address of the return, callback, and memory must be shared either with-in g() or a() and b() .. from CPU register up to system memory address.

>And why would anyone need to bother with explicit synchronization anway?

Dependent on business logic. Including which 3rd party libraries must be used for the solution. Software might be architecture for using Reactive objects which mimic async / await with more well defined and shared behavior. A custom managed thread maybe needed for more accurate time limits or an event loop is needed.

>sleek one-liner.

Be warned, one liners may seem useful, until they need to be debugged. There is a great difference between the two C# Reactive objects:

{

   doing.Where(x => x.CanDo()).Subscribe(x => x.ExtensionDigestion());

   doing.Where(x => {
#if DEBUG // Set ID_WITH_ISSUES_OR_TESTING to the proper ID when developing new user experience or interface. Use for debugging single issue bug that just happens with the same ID or same line of 3rd party product tie-ins.

           if (x.Id == ID_WITH_ISSUES_OR_TESTING) {
                   var i = DateTime.UtcNow();
           }
#endif

           return x.CanDo()
   }
   .Subscribe(x => {
           x.ExtensionDigestion();
   });
}

Re: Go Data Structures: Interfaces (2009)

#72

Earlier quoted context omitted.

[flagged]

Never used F#. Looked it up for thread cancellation and it is syntactic sugar similar to defer in Go. Kind of like an await return is a wrapper around f(x) callback. Been years since I wrote Go code, until last week. Daily has become C#, python, and powershell. Took a day to fall back in and write a tool while learning a new GUI framework. Found the strengths and weaknesses of the GUI. Personal, I find Go more pleasu…

[flagged]

Re: Go Data Structures: Interfaces (2009)

#73
post #51

Earlier quoted context omitted.

And decoding subsequences of UTF-8 code units (bytes) into Unicode scalars (runes), which also forces a copy. But why did Go pick the same syntax for cheap conversions and expensive ones, though? I'd expect this to be a standard function, not a type conversion.

Don't all conversions require copying the value at the level of the language semantics? You can cast a float to an int, but you can't assign an integer value to a float variable (leaving aside whatever optimizations the compiler might make). Casting a float to an int is only cheap because a float is a fixed size. So it seems unsurprising to me that casting a larger value results in a proportionally larger copy.

Most conversions are things like casts to enum types or aliases I think, which never are O(n), like:

    dur := time.Second * time.Duration(2)
    
    headers := http.Header(map[string][]string{})

    httpDir := http.Dir(filepath.Join(parts...))
In all of these cases, it's just a type-cast which is zero-cost, and I think that's what makes it feel surprising that casting between strings/runes specifically incurs more significant computation than any other cast.

Re: Go Data Structures: Interfaces (2009)

#74
post #73
post #51

Earlier quoted context omitted.

Don't all conversions require copying the value at the level of the language semantics? You can cast a float to an int, but you can't assign an integer value to a float variable (leaving aside whatever optimizations the compiler might make). Casting a float to an int is only cheap because a float is a fixed size. So it seems unsurprising to me that casting a larger value results in a proportionally larger copy.

Most conversions are things like casts to enum types or aliases I think, which never are O(n), like: dur := time.Second * time.Duration(2) headers := http.Header(map[string][]string{}) httpDir := http.Dir(filepath.Join(parts...)) In all of these cases, it's just a type-cast which is zero-cost, and I think that's what makes it feel surprising that casting between strings/runes specifically incurs more significant comp…

All of those are copies and hence O(n) in the size of the value copied. This is hidden somewhat because your examples use constants and literals. (As numeric constants aren’t typed in Go the first example arguably doesn’t involve a copy, but the rest do.)

Re: Go Data Structures: Interfaces (2009)

#75
post #43
post #37

Earlier quoted context omitted.

> Python was the first language I made money with. However, these days, I struggle to read and make sense of type-ridden, generic-filled, Pydantic-infested Python code. I'm in the same boat. Python was great when it was a snake. I liked additions like the "with" statement - they were very pythonic. I think it's good when the language evolves, although the direction Python took feels more like grafting - oh people lik…

This is a more elaborate version of how I feel about Python these days. Python is still a much nicer language than something like JS, but it hasn’t been very successful at saying no to things. I like type hints, but it’s easy to go overboard with them. Pydantic and FastAPI are great. The problem is that typenauts and academics coming from other languages are trying to bring every feature under the sun to Python. The…

Okay, but there are people who hate Go but are stuck with it at work, and would like it to be more expressive etc.

Re: Go Data Structures: Interfaces (2009)

#76
post #70
post #69

Earlier quoted context omitted.

> Sorry, but your response seems to be about consistency, or "purity" at some level. > While what Go has may be inconsistent, what functional impact does that have? Same reasons why Go fixed C's: inside-out type declarations, function pointer syntax, ERRNO, headers, macros, signal handling, UB, all the things that technically had no "functional" impact but still directly contributed to consistency, ergonomics, clarit…

> Similar things you'd do with a function without a name - work directly with the data at hand, without having to do the extra round trip to the attic to declare its name or shape. Note that in Alef, tuples are essentially a dual for an aggr, but with unnamed fields. So one always has to (explicitly, or implicitly via inference) declare its 'shape', in terms of number of members, and type of members. So one could dec…

Since func() (A, B) is different from func() (A, B, C), I'd expect first-class tuples to do the same. At which point there would be a lot of similarity between (A, B) and struct{A, B}. Perhaps they should be equivalent? From which "struct{a A, b B} = f()", or even "switch x.(type) { case struct{a A, b B}: ...}", or "case (a A, b B): ..." could follow. It might be too much Rust influence, but it might be a good influence, given there's already a lot of interest in unions/enums/ADTs (but see "start with goals").

The counter-arguments are that "type A struct{}" and "type B struct{}" are different types, and that anonymous structs are seldom found in the wild (likely due to their verbosity), but perhaps this is a chicken-and-egg problem? Go already does local type inference, because "var mypackage.VeryLongThing = mypackage.NewVeryLongThing()" is stupidly repetitive. But there's always a fine balance between code being terse and readable (I will never wrap my head around APL).

Re: Go Data Structures: Interfaces (2009)

#77
post #37

Earlier quoted context omitted.

> Python was the first language I made money with. However, these days, I struggle to read and make sense of type-ridden, generic-filled, Pydantic-infested Python code. I'm in the same boat. Python was great when it was a snake. I liked additions like the "with" statement - they were very pythonic. I think it's good when the language evolves, although the direction Python took feels more like grafting - oh people lik…

Please state you musings about the async. I'm just getting into that right now and I wonder if my misgivings are a result of my age or a fundamental issue with the Python implementation of the concept. Seriously, all and any insight and advice appreciated. Thanks.

If you're having problems with async in languages it isn't your fault.

Spinning off a thread for a single small purpose and trying to synchronize with the result seems fine in theory, but it is a very small piece of the larger puzzle of concurrency and usually gets people into trouble once they realize they need more, because anything more complicated than that one use case becomes very tricky.

Re: Go Data Structures: Interfaces (2009)

#78
post #56

Earlier quoted context omitted.

> Bob Nystrom worked on Dart at Google and wrote the amazing Crafting Interpreters book. Rob Pike referenced this article in his 2023 talk, Go: What We Got Right, What We Got Wrong, while discussing the trade-offs between CSP and coroutine-driven concurrency. I know, which is the exact reason the reply states " uncharacteristically ". And yet, it fails to acknowledge existing terminology and tradeoffs and just states…

[flagged]

You both broke the site guidelines badly in this thread. If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.

Re: Go Data Structures: Interfaces (2009)

#79
post #56

Earlier quoted context omitted.

[flagged]

[flagged]

You both broke the site guidelines badly in this thread. If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.

Re: Go Data Structures: Interfaces (2009)

#80
post #78
post #56

Earlier quoted context omitted.

[flagged]

You both broke the site guidelines badly in this thread. If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.

Are you sure one deserves such lenience:

https://news.ycombinator.com/item?id=41121266

https://news.ycombinator.com/item?id=43009383

https://news.ycombinator.com/item?id=43009595

Post reply on HN