Thanks everyone for sharing your thoughts.
I think these are fair concerns (I hated C++'s operator overloading, which
is a similar yet different issue).
In particular, thanks for pointing out Julia.
I heard that Julia is pretty popular among scientists, even though I
haven't used it before.
I will try to get a feel of Julia's experience with Math symbols, and
compare with the issue here.
On Thursday, October 2, 2025 at 4:27:28 AM UTC+8 Axel Wagner wrote:
> On Wed, 1 Oct 2025 at 22:06, Daniel Lockhart <d.f.l...@gmail.com> wrote:
>
>> How do you handle whether a symbol identifier is public or private?
>>
> The same as if you use a language that doesn't have case (like Chinese).
> The conventional solution in those languages is to prefix exported
> identifiers with X (perhaps from "eXported"), as I understand it.
>
> FWIW I fully agree with Dan. I do like that Go allows arbitrary letters in
> identifiers. And I do quite frequently use δ or ε in my code. But only, if
> it is *my* code that is guaranteed not to be inflicted on anyone else. It
> is cute and *I* can easily type and read it and it reads better to me than
> "delta" or "epsilon". But that is outweighed by the downside of other
> people having to copy-paste symbols around when trying to collaborate or
> use my library.
>
> I don't think there is a technical reason why expanding beyond letters and
> digits (and _) would be hard or unreasonable - with some limitations, of
> course, as you still need to be able to lex. But making a language requires
> drawing lines and where to draw those lines is subjective.
>
> And for what it's worth: one relatively objective argument in favour of
> expanding beyond ASCII but not beyond letters is that restricting yourself
> to ASCII gives English a special place and is excluding a lot of other
> languages. Allowing letters is anti-discriminatory on a level that allowing
> symbols isn't.
>
>
>> On 2025-10-01 11:31, robert engels wrote:
>>
>> I agree - if you already allow non-ascii symbols - what’s the difference.
>> It’s up to the owner of the code base to decide if it works better for them
>> or not.
>>
>> On Oct 1, 2025, at 10:24 AM, awaw...@gmail.com <awaw...@gmail.com> wrote:
>>
>> Thanks for chiming in.
>>
>> I wonder could you or others elaborate on why allowing math symbols would
>> make it harder than present to search for?
>> At present, in Go we can already do Japanese hiragana and katagana, not
>> to mention emojis, whose search requirements are no different than Math
>> symbols.
>> In fact, I use the ancient Vim editor (without any plugins) as I'm old
>> fashioned, and Vim doesn't seem to have issues searching for "⊗".
>> I suppose the search experience is even better in VSCode or github.
>>
>> Regarding the concern that:
>> > symbols may be meaningful to the author, code consumers find it harder.
>> At present, Go supports ℏ (reduced Planck constant) and *Δ*p (momentum
>> deviation), which arguably is meaningful not only to authors but also code
>> consumers.
>> ⊗ may seem foreign to most Physics undergraduates, but its meaning is no
>> doubt *universal* among quantum technology practitioners.
>> I appreciate if anyone could provide an example or scenario on code
>> consumers of a quantum related Go package finding it hard to read σX as
>> the Pauli X matrix or ⊗ as the tensor product.
>> In other words, within a specific domain, judiciously chosen special
>> symbols actually help code readability.
>>
>> Sorry if I may sound a bit absurd or combative (I'm sincerely not), but I
>> am just believing that laying out concrete details and examples helps
>> make decisions whether pro or con.
>>
>> On Wednesday, October 1, 2025 at 3:53:54 PM UTC+8 Dan Kortschak wrote:
>>
>>> On Wed, 2025-10-01 at 00:42 -0700, awaw...@gmail.com wrote:
>>> > func ⊗(ops *tensor.Dense) *tensor.Dense {...}
>>>
>>> Please no. Including these make the code much harder to work in as it
>>> is harder to search for and while the symbols may be meaningful to the
>>> author, code consumers find it harder. If you need maths symbols, put
>>> them in the godoc.
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/golang-nuts/39e212d7-a5d1-438f-8116-8e929b835da4n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/39e212d7-a5d1-438f-8116-8e929b835da4n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/golang-nuts/EE71219E-FF34-42BB-BAFF-1D516EDC7DF8%40ix.netcom.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/EE71219E-FF34-42BB-BAFF-1D516EDC7DF8%40ix.netcom.com?utm_medium=email&utm_source=footer>
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts...@googlegroups.com.
>>
> To view this discussion visit
>> https://groups.google.com/d/msgid/golang-nuts/7f185c31-b69e-460f-92c8-65cfab845d39%40gmail.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/7f185c31-b69e-460f-92c8-65cfab845d39%40gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/28712755-a37f-430b-abf8-96179dc55adbn%40googlegroups.com.
