alt.hn

I don't know why it's still like that but that's the original reasoning.

by treyd

Personally I can't say when I was last actually aware of syntax highlighting. The only time I'm actively engaged with it is to change the default low contrast comment color that a lot of themes have (for some reason, as if comments are unimportant / noise) to something better. For Go, I don't really notice when it has or doesn't have syntax highlighting, at least not on e.g. go's website.

by Cthulhu_

I think the lack of syntax highlighting was one reason for that. It makes you think more about the code you write and how it should compose, while a fully fledged IDE encourages you to just throw more code at the problem.

I think the ACME way should be used for love of code and ideally when you want to create libraries that stand the test of time. When you just want to get things done fast bring the full IDE and now some LLM vibes and it’s done.

by theplumber

I wonder if the Go fonts has been created just to get a trademark on the "Go" word...

by dolmen

    #blog .Article[data-slug='/blog/go-fonts'] code {
      font-family: 'Go Mono', monospace;
    }
    #blog pre,
    #blog code {
      font-family: monospace;
    }

However I’ve not had much success running it on CI, with at least the 1.27rcs. I encountered some panic deep within staticcheck, and ended up turning off that specific linter on CI (better than not running it at all).

There was a tracking issue for go1.27 support at [1]. However that is now closed, which might imply that it should be working.

[1] https://github.com/golangci/golangci-lint/issues/6643

by tkw01536

I just had excellent success migrating a go code base to rust completely AI driven. It led to a healthy performance boost too, as now I don’t need to worry about GC pressure contortions.

by drivebyhooting

It's funny that you and many others have found the introduction of "generics" in Go to be highly valuable, considering one of the motivations for Go's existence was:

  Its designers were primarily motivated by their shared dislike of C++[0]

  DDJ: In the presentation before the awarding of the Japan 
  Prize today, you were quoted on the distinction between 
  reasearch and development. [The former, Thompson stated, 
  was directionless, whereas development had a specific goal 
  in mind.] So in that context, is Go experimental?
  
  KT: Yes. When the three of us [Thompson, Rob Pike, and 
  Robert Griesemer] got started, it was pure research. The 
  three of us got together and decided that we hated C++. 
  [laughter] [2]

0 - https://en.wikipedia.org/wiki/Go_(programming_language)#Hist...

1 - https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

2 - https://web.archive.org/web/20110521080746/http://drdobbs.co...

by AdieuToLogic

  Generics may well be added at some point. We don't feel an 
  urgency for them, although we understand some programmers 
  do.
  
  Generics are convenient but they come at a cost in 
  complexity in the type system and run-time. We haven't yet 
  found a design that gives value proportionate to the 
  complexity, although we continue to think about it. 
  Meanwhile, Go's built-in maps and slices, plus the ability 
  to use the empty interface to construct containers (with 
  explicit unboxing) mean in many cases it is possible to 
  write code that does what generics would enable, if less 
  smoothly. 

  The Go 1.18 release added type parameters to the language. 
  This permits a form of polymorphic or generic programming.

  We haven't yet found a design that gives value
  proportionate to the complexity ...

  Notice that Robert said C was the starting point, not C++.
  I'm not certain but I believe he meant C proper, especially
  because Ken was there. But it's also true that, in the end,
  we didn't really start from C. We built from scratch,
  borrowing only minor things like operators and brace
  brackets and a few common keywords.

  In the end of course it came out quite different from
  either C or C++. More different even than many realize. I
  made a list of significant simplifications in Go over C and
  C++:

  ...

  - no templates

  ...

The original Go team was trying to avoid this:

"Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more [...] actively borrow features from one another. They are converging into a single huge language." [0]

That team has since moved on, and now Go has begun to join that convergence.

The problem is that most programmers seem to want to write Java, more-or-less. New, simpler languages come along, but once they get popular, the pressure is on to turn them into Java-likes. It happened to Python and now it’s happening to Go. It takes a strong will for language maintainers to say “no”, and their language will suffer in popularity as a result - see, for example, Ruby.

[0] https://go.dev/talks/2015/simplicity-is-complicated.slide#5

by pansa2

A goroutine that has to be killed (no other way to tell it to stop) is a bug.

by dolmen

The tl;dr boils down to a combination of valuing both compilation speed and execution speed.

by nrr

I have run both Go and Python backends in production for years. There is an entire class of bugs present in Python services (missing error handling) that simply does not happen in my Go services.

Python puts the burden of knowing what exception types a function call will raise on the caller, in Go I just check for err. Even if I do not anticipate every failure mode the Go call will raise, I will always log the error and handle it in a controlled manner. I couldn’t count the number of times I’ve encountered an unhandled exception in my Python code, and often in such a case the logging will be lacklustre because you will just see a huge stack trace, but lose the contextual logging I would have automatically added in Go.

Perhaps a syntactic sugar is in order to reduce verbosity.

by Arbortheus

I try to avoid exceptions, is there any better ways? (Variant looks a bit more complicated but could be a totally OK alternative)

by kajika91