rust VS go

TensorFlow has language support for TypeScript well as Rust.

Thank you for the restponse! With tensorflow I am probably better of with something like; [tensorflow rust bindings](https://github.com/tensorflow/rust/tree/master/src). But I believe some useful extensions are still written in python for example; [TFDV](https://github.com/tensorflow/data-validation).. and how about scikit-learn or even something that is simpler like fb-prophet that is entirely written in python?

Tensorflow bindings exist, technically, but they're in a pretty rough state AFAIK.

tensorflow/rust (Rust): Rust language bindings for TensorFlow

Unfortunately it was rejected. I'm not sure what it's successor is. (meta issue, front runner)

> There is something in video games called minmaxing, which is where you maximize one attribute at the expense of all of the others. For me C++, and now Rust, feel like they are guilty of this with their weight on zero-cost abstractions.

> I think it was literally just meant to be the bare minimum to try to solve the most important parts of the problem, and at that it succeeds.

In other words, it's the cost effectiveness of a language feature. You want features to provide as much value for as little cost as possible. This is what Go's going for; to paraphrase Russ Cox - "If a feature is not clearly above the bar, it's below it." [1].

> Just as reducing programming language complexity doesn’t remove it, but only moves it around, removing runtime cost doesn’t remove it either. And the problem here isn’t that compile time isn’t a better time than runtime; it’s the hidden costs that suck. Sure, maybe the compile times in Rust will improve, and maybe it’s not even that big of a deal. But every little feature the language has puts some additional stress on the ecosystem. The language server has to bear this load, for example.

The worst hidden cost that's often missed is the impact on the programmer.

Take Python's controversial walrus operator [2]. If you look at the reasoning and the examples, the change seems reasonable. But consider that once the feature gets implemented, every single Python programmer will have to learn what it does in order to be able to read others' code. Does this feature provide enough to justify this weight? Undoubtedly not. Of course, it got implemented anyway, because the impact of making the code slightly more readable in some cases is clearly visible, but the cost incurred on every single programmer's mind is not.

This is how languages reach untenable levels of complexity. By the time you realize your language is getting complex you're 20 features in and it's too late to turn back. "A frog dropped in a pot of boiling water will jump out of the pot to save his own life. If the frog is put into cool water and slowly brought to a boil, he will remain there until he is cooked through."

[1]: https://github.com/golang/go/discussions/47203#discussioncom...

[2]: https://www.python.org/dev/peps/pep-0572/#abstract

x/dl/version: installer shouldn't create a new subdirectory of $HOME #26520

This is described in detail at https://github.com/golang/go/wiki/CommonMistakes

Such as common constraints package for generic, they are ready to start with after thinking and using Generic in period: https://github.com/golang/go/issues/50792

https://github.com/golang/go/issues/50726 was recent and IIRC there were some more bugs related to this a while ago.

There seems to be a general misunderstanding in this thread, that this is about having additional type parameters on methods. It's not. That particular sentence refers to this issue, about having local type-declarations in generic functions. That's simply a bug, which is intended to get fixed by go 1.19.

This seems to be the most interesting issue.

Dispise the language seems a bit harsh, I just think the Go community makes a lot of weird design decisions. For the longest time generics and the try function were super obvious ways to improve the language but the community was hell bent against improving the language to maintain simplicity.