keywords VS go

> I'm not sure here how you differentiate minimalist from restrictive.

The flexibility of the language and its syntax. The more constructs are syntactic, the less minimalistic it is, and Go is a very syntactic language.

> I've always considered Go to be minimalist in terms of available tokens to the programmer: https://github.com/e3b0c442/keywords/blob/main/chart.png

No language on this chart has even a passing resemblance to minimalistic. I don't think anything does when it reaches double digit keywords.

For reference, I believe Smalltalk has 6.

And forth is more complicated because it doesn't really have keywords at all, and barely any syntax, instead it has assembly-coded / runtime-provided words (~functions) and variables. SectorForth (https://github.com/cesarblum/sectorforth/) is down to 8 builtin words, 2 IO words, and 5 variables (milliforth packs those behind a word instead). And so far 2 of the words have been found unnecessary / redundant.

> I like Rust's pragmatism.

Me too.

But Scala is also a very pragmatic language. If you want something academic go for Haskell.

> Allow limited operator overload.

Nitpick: Scala does not have any operators. So it doesn't have operator overloading at all.

Scala simulates operators by infix method syntax.

Instead of writing `1.+(2)` you can just write `1 + 2`. But the later is the same method call as the first one!

> Eschew HKT for a simpler abstractions.

AFAIK HKTs are more or less "just postponed" in Rust, AFAIK.

People would like to add them of course. The discussion goes on forever by now. Some small insight (there is much more when you look for it):

https://github.com/rust-lang/rfcs/issues/324

https://internals.rust-lang.org/t/higher-kinded-types-the-di...

> Don't go in the deep end with type power, nor too much in opposite direction and avoid any complicated feature.

While having a full ML style type system with afine types on top, and quite some other type level mechanics up to singleton types?

Sure sure, no power in here. :-)

> The more powerful feature the more abusable it is, and Scala loves the power at all cost.

Everything is "abusable". This is not an argument.

But that Scala loves power at all cost is simply not true. The contrary is.

Just to cite one of the most influential post in Scala land of all times:

https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofL...

This, and the BDFL constantly complaining about unnecessary complex code people write speaks for itself.

Scala lately even reduced the power of some features just to prevent "abuse". (Which is partly an overreaction; but that's another story).

> Why would anyone care? The more flexible/powerful something is the harder it will be to parse by humans and tooling.

That's also not true.

Scala has a very small and simple syntax (despite all the language features).

Scala is on the surface much much simpler and much more regular then Rust!

https://github.com/e3b0c442/keywords

(You could also compare the language grammars. This would be even more in favor of Scala in this regard).

Scala 3 looks even almost like Python!

https://docs.scala-lang.org/scala3/book/scala-for-python-dev...

> Plus Scala has the big deal breaker. GC and no custom primitive types.

What a "deal breaker"?

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

You've seen this here in the thread?

Also:

https://docs.scala-lang.org/overviews/core/value-classes.htm...

As soon as Valhalla lands in JVM-land this will be full blown value types without any limitations.

And in Scala Native you can have of course native structs today. (Only that Scala Native isn't ready for prime time just now).

In the long run Scala Native could also run without GC. The Caprese project will bring something that is more powerful than Rust lifetimes. Lifetimes will fall out as a special case of a more general concept.

> > Besides that: The Rust people are looking envious. I've read about some ideas that were more or less a direct copy of Scala's implicits.

> What do you mean exactly?

Implicits get discussed every now and than in Rust land. Even the above Rust internals discussion start with them.

Or this here:

https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capa...

Also I've once read something that looked like a brain storming for future Rust features. They came up with more or less implicits (only that they didn't call them like that, so I can't find this any more, didn't bookmark it).

Someone even once proposed directly Scala's implicits for Rust. But this went nowhere as the other people on the forum actually didn't understand them (which was no wonder as the example was quite terrible and the proponent was not really experienced with Scala so couldn't explain it well). People came than to quite wrong conclusions (some of them even mixed implicits in general even the dreaded implicit conversions, which were in fact mostly overused and caused trouble in Scala; but things got redesigned exactly because of that).

Check out: https://github.com/e3b0c442/keywords

In order to actually answer your question in some form: Here’s a list of programming languages ranked by number of keywords.. Looking at this list, consider that PHP used to be considered a beginner friendly language and that Java is often chosen as the first language for new CS students. Your question seems to be difficult to answer!

The description indicates it is not production ready, and is archived at the same time.

If you pull all stops in each respective language, C# will always end up winning at parsing text as it offers C structs, pointers, zero-cost interop, Rust-style struct generics, cross-platform SIMD API and simply has better compiler. You can win back some performance in Go by writing hot parts in Go's ASM dialect at much greater effort for a specific platform.

For example, Go has to resort to this https://github.com/golang/go/blob/4ed358b57efdad9ed710be7f4f... in order to efficiently scan memory, while in C# you write the following once and it compiles to all supported ISAs with their respective SIMD instructions for a given vector width: https://github.com/dotnet/runtime/blob/56e67a7aacb8a644cc6b8... (there is a lot of code because C# covers much wider range of scenarios and does not accept sacrificing performance in odd lengths and edge cases, which Go does).

Another example is computing CRC32: you have to write ASM for Go https://github.com/golang/go/blob/4ed358b57efdad9ed710be7f4f..., in C# you simply write standard vectorized routine once https://github.com/dotnet/runtime/blob/56e67a7aacb8a644cc6b8... (its codegen is competitive with hand-intrinsified C++ code).

There is a lot more of this. Performance and low-level primitives to achieve it have been an area of focus of .NET for a long time, so it is disheartening to see one tenth of effort in Go to receive so much spotlight.

A Discussion about including this package in Go as encoding/json/v2 has been started on the Go Github project on 2023-10-05. Please provide your feedback there.

I like the Principles section. Very measured and practical approach to releasing new stdlib packages. https://go.dev/blog/randv2#principles

The end of the post they mention that an encoding/json/v2 package is in the works: https://github.com/golang/go/discussions/63397

There used to be the GO FIPS branch :

https://github.com/golang/go/tree/dev.boringcrypto/misc/bori...

But it looks dead.

And it looks like https://github.com/golang-fips/go as well.

I'm not sure what exactly you mean by acknowledgement, but here are some counterexamples:

- A proposal for sum types by a Go team member: https://github.com/golang/go/issues/57644

- The community proposal with some comments from the Go team: https://github.com/golang/go/issues/19412

Here are some excerpts from the latest Go survey [1]:

- "The top responses in the closed-form were learning how to write Go effectively (15%) and the verbosity of error handling (13%)."

- "The most common response mentioned Go’s type system, and often asked specifically for enums, option types, or sum types in Go."

I think the problem is not the lack of will on the part of the Go team, but rather that these issues are not easy to fix in a way that fits the language and doesn't cause too many issues with backwards compatibility.

[1]: https://go.dev/blog/survey2024-h1-results

Now, I’m not going to use C++ again; I left that chapter years ago, and it’s not going to happen. C++ isn’t memory safe and easy to use and would require extended time for developers to adapt. Rust is the new kid on the block, but I’ve heard mixed opinions about its developer experience, and there aren’t many libraries around it yet. LLRD is too new for my taste, but **Go** caught my attention.

Generative AI development has been democratised, thanks to powerful Machine Learning models (specifically Large Language Models such as Claude, Meta's LLama 2, etc.) being exposed by managed platforms/services as API calls. This frees developers from the infrastructure concerns and lets them focus on the core business problems. This also means that developers are free to use the programming language best suited for their solution. Python has typically been the go-to language when it comes to AI/ML solutions, but there is more flexibility in this area. In this post you will see how to leverage the Go programming language to use Vector Databases and techniques such as Retrieval Augmented Generation (RAG) with langchaingo. If you are a Go developer who wants to how to build learn generative AI applications, you are in the right place!

net/http: add methods and path variables to ServeMux patterns Discussion about ServeMux enhancements

Make sure you have Go installed https://go.dev/.