rust VS go

There are three. The official one, mrustc (no borrow checker, but can essentially compile the official rustc) and GCC (can't really compile anything substantial yet). Only rustc is production-ready though.

By following this issue to this issue comment, I think the reason is the sheer complexity of tuple struct constructor: * The syntax of tuple struct constructor is the same as either a function call or a constant, so to make life easier, the rust devs made it a function or a constant, i.e. declaring a tuple struct with pub fields also fills the value namespace with a function or constant. * Named field struct constructor is cannot be mistaken for a function call, so rust devs are free to let user construct them with type aliases.

Relevant rustc issue

Not that hard if you're writing Rust: https://github.com/rust-lang/rust/pull/29837 and the like.

Love the article.

In my mind I see the problem of dynamic linking in rust to have a bunch of overlap with the "I want this rust library to be exposed in my higher level GC'd language with minimal safety/handwritten bindings" problem.

My hunch is that the lack of expressiveness of the C ABI is holding back both. the thing I'd love to see some sort of "higher level than the C ABI" come out. And something like `wasm-bindgen`[0] to exist for more languages.

Here's a link to the rust "interopable_api" proposal! I don't understand all the implications, but it seems to be in the right direction https://github.com/rust-lang/rust/pull/105586

[0]https://rustwasm.github.io/docs/wasm-bindgen/

GitHub issue tracking implementation of RFC 2005: https://github.com/rust-lang/rust/issues/42640

The "Why Rust" section just under that slogan makes it clear enough what sort of language it is and whether it might suit your needs. It can't be done in a headline ... https://www.rust-lang.org/

Glad you like it 🙂 https://github.com/rust-lang/rust/pull/58530

It was interesting to look directly at the source code linked in the article for stack unwiding [1]. In particular, it's neat to see how thoroughly documented this file is. Reminds me of poking around the SQLite codebase.

[1] https://github.com/golang/go/blob/6b8b7823c7fd9f3f2317f65712...

Do you believe they faked the commit times on https://github.com/golang/go/issues/53644 , which added the behavior required for the fix six months before the sr.ht announcement?

> Just a simple "I'm looking in to it" would have sufficed.

Like Katie did at https://github.com/golang/go/issues/44577#issuecomment-85692... ?

> There was some discussion, and then just ... nothing.

Nothing except the reuse flag later getting implemented at https://github.com/golang/go/issues/53644 ?

"We don't have have to go into the details of this" is disingenuous. We can't go into this because he was banned in violation of their own policies for a second time.

You can carry all the water you want for the Go people, but their handling of this is unprofessional, and it's not the first time they've treated non-Googlers with utter disrespect for no particular gain. This behavior dates back at least as far as issue #9 in their original bug tracker[1], when the most they could muster for their part was the "Unfortunate" bug label, presumably as in "it's unfortunate for you that we're going to do whatever the hell we want."

Go's biggest problem isn't generics, or modules, or the infrastructure, or any other technical issue; it's that the creators are the worst sort of ivory-tower academics who have never had to cooprate with anyone outside their friend circle. They get away with it because they ensconce themselves as a club in organizations who can afford to pay people to work in DevRel vacuums, and I'm sure they consider themselves very successful, but Go is easily the most toxically-run language project since the BFDL days of glibc.

I have it easy, since I have the autonomy to decide never to get involved with these people, but not everyone has that privilege, and you're not doing the situation any favors by torchbearing for jerks.

https://github.com/golang/go/issues/9

After I got everything working, I took a break over the weekend, and between Sunday and Monday, I finished rewriting the program using the Go programming language.

https://stackoverflow.com/a/73932230/312907 I found this answer.

I can't find the original announcement, but I found the accepted Go proposal: https://github.com/golang/go/issues/24543

I remember that being the straw that made me drop Elixir (which I love, to be clear). Go excels in many, many places where Elixir does, but it's way faster.

I do think Elixir has immutability on their side, which is huge for new developers, but there are way less developers in Elixir than Go, so the end result doesn't change unfortunately.

Podman is an engine for virtualization to create and maintain containers on virtual machines. It is developed by Red Hat and published as an open source software (OSS) under Apache License v2.0. The source code is written in Golang.

The good news: vscode will have it, too. There is no precise release date yet, but it will be coming: https://github.com/golang/go/issues/56695

~$ wget https://go.dev/dl/go1.19.5.linux-amd64.tar.gz ~$ sudo tar xzvf go1.19.5.linux-amd64.tar.gz -C /usr/local/ ~$ export PATH=$PATH:/usr/local/go/bin ~$ source ~/.bashrc