Hacker News new | past | comments | ask | show | jobs | submit login

I have a totally tangential ramble queued up on this topic.

I like philosophy and I read it as a total amateur. Naming is a big topic in modern philosophy [1] with a huge amount of depth. I think of it in terms of my naïve understanding of Wittgenstein's later work and the idea that the meaning of a word actually comes from its usage within the context of a set of collaborating agents.

If I say to a programmer "use a vector", that will mean something specific if we are writing C++ and I want to use a resizable array. And it could mean something totally different in the context of a 3d rendering engine.

I think of how often I see words like "Context", "Session", "Kernel" and all of their myriad uses.

So I see articles like this as just a pointless argument because we are crossing some boundary between distinct language games. The author of this article thinks "Enum" means one thing. But it is actually the case that "Enum" is unspecified outside of some particular context. And in this case, the author is bringing some outside context and trying to reuse it inappropriately.

1. https://en.wikipedia.org/wiki/Naming_and_Necessity




So I guess you have a point that since Go does not even have enum’s as a formal concept, they can’t suck. But this presumes that the only context where you can criticize Go is the context that only contain’s concepts expressible in Go. This is basically saying “Go does not have enums, therefore it cannot be criticized for lacking enums”.

In the wider context of programming languages, enum is fairly well defined concept. Features like being able to convert a value to a string and do exhaustive checking on switch statements are widely implemented. The iota feature in Go is clearly imitating C’s enum keyword. It is fair to compare Go’s built-in ability to declare an enum-like type against other language’s ability to declare the concept.

To be clear, I’m not saying every language has to have every feature. I’m just saying the lack of a feature in a language is not a sufficient reason to excuse its lack.


“Enumeration” according to a handy dictionary: “the act or process of making or stating a list of things one after another”

I am—for some reason—reminded of philosophers who go looking for metaphysical problems, disputes, etc. where there aren’t any.[1]

https://en.wikipedia.org/wiki/Quietism_(philosophy)


I'm working on an LLM project in Go and the term "context" is overloaded to the hilt--I use it to refer to the LLM context as well as Go's `context.Context` which I'm using all over the place. It's made worse since the most natural plural of context is... context. My solution is to use `ctx` for Go context, `contexts` for arrays of LLM context structs, and `contextPart` for individual context structs.

"model" is another one like that since I'm using it to refer to both data models and ML models. And "prompt" since it can be an LLM prompt or a terminal prompt for the user (this is a CLI tool).

Differentiating all these overlapping terms in ways that aren't super confusing is definitely a challenge.


Context is actually one of my least favorite parts of go. I wish they at least reimplemented it with generics so it’s not just a unlabeled box of maybe some stuff that can also cancel things


Yeah it's definitely a bit of a junk drawer. I'm using it for timeouts, cancelation, and cancelation trees and it's not so bad, but I know it can also be used to pass data around which doesn't strike me as a great idea.


This is the "you're holding it wrong" of linguistic arguments.


To be clear, I'm not saying the author is wrong. The author wants a thing that Go doesn't have (a thing that I would also like to have in Go). He is calling the thing he wants an "Enum". Then he is insinuating that Go actually has the thing he wants but it sucks. It is confusing because Go does have a thing that some people also call "Enum".

What I'm saying is the thing he wants and the thing Go has may share a name but they aren't the same thing. Just like C++ has "vectors" and OpenGL has "vectors" that share some superficial similarities but are ultimately totally different things.

If someone wrote an article that said "OpenGL vectors suck" and then mentioned it missed a bunch of features available in std:vector as justification, most people would recognize this error and dismiss the discussion.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: