How’s your experience been working with Rust regularly in a professional environment?

I enjoyed it, but I changed jobs and companies a few months ago, and now I do spreadsheets and hold status meetings for a living :P

Still using it for personal projects.

The first link states that Go 2 is TBD and in the event there is a Go 2, interop must be easy.

The second link has Rob Pike state that there probably won’t ever be a Go 2.

I really enjoy Go. I’ve always been inclined towards keeping the actual language simpler to write and read and it’s a very pragmatic language in my opinion.

I’d assume they care because Go was designed to keep the codebase as “neat” and clean as possible when being worked on by many developers. Given enough time and developers, things like unused variables will start to seep in and make the codebase dirtier.

Of course if you’re the only developer working on your own codebase, you’d wonder why they care but you’re also not the main group they were targeting.

> I’d assume they care because Go was designed to keep the codebase as “neat” and clean as possible when being worked on by many developers

So someone’s anal retentive was made into a langage mandate rather than anything actually useful?

> Given enough time and developers, things like unused variables will start to seep in and make the codebase dirtier.

Why are dead variables any dirtier than dead stores? Or unchecked errors?

> Why are dead variables any dirtier than dead stores?

If you mean stores to fresh local variables, I assume that should also count in a proper/ideal implementation of this.

If the idea is for code to be literally WYSISWYG, then your compiler will no longer eliminate variables or code for you, so you have to do it.

In principle, a dead variable in final code is also almost certainly a mistake: either by not including the variable in the computation or for declaring the variable at all. Maybe a little annoying while you're figuring something out, but makes sense in the context of polished code.

> If you mean stores to fresh local variables

I mean stores for which there is no load.

> I assume that should also count in a proper/ideal implementation of this.

It certainly does in a proper implementation, but not in zig. Or go.

> If the idea is for code to be literally WYSISWYG, then your compiler will no longer eliminate variables or code for you, so you have to do it.

That sounds stupid.

> a dead variable in final code is also almost certainly a mistake

See “final code” is the issue at hand. The problem with go is that it specifically does not do that. It has a half-assed implementation which it forces upon you all the time.

> Maybe a little annoying while you're figuring something out

It’s a bloody nuisance when you new figuring things out or in the middle or refactoring something.

> but makes sense in the context of polished code.

There’s a ton more which makes sense “in the context of polished code” which go can’t be arsed to do.

Checking that errors are not implicitly ignored for starters.

> I mean stores for which there is no load.

Stores for which there are no load can still be observable in concurrent scenarios. That's why I specified stores to locals with no load because those are not observable.

> That sounds stupid.

Sounds totally reasonable to me in scenarios where you need the output of the compiler to be very predictable.

i could understand this in 1995, but in 2015? We have peer reviews, and CI. Let's deny warnings there, and allow them during development.

Makes it seem like we’re living in a bubble while others are getting stuff done, isn’t it?

Had to learn FoxPro to support some legacy software. Fun times :)

I really want to learn Rust, but I just don't have enough time in the day to commit to learning it if I'm not going to be able to find a job with it that doesn't involve blockchain or cryptocurrencies.

Can anyone tell me how the general Rust job market looks for you guys outside of things like Indeed?

I think it's a silent market at this point. The company I'm at is using it, and anecdotally, many other companies are as well in small greenfield projects, so I anticipate there will be growing demand for developers that know rust in coming years. The downside of this is that there will be a massive influx of people learning rust, similar to "the python problem". At the moment, most people that know rust are for the most part competent with it, but I fear that may change as the supply side increases.

Not a big job market for sure, but for example the car industry on Germany is ramping up quite a bit!

If you can hold your nose and work for a hyperscaler there's plenty of rust work to go around.

I expected C#/dotnet to make a little more headway considering all of the work being done and released recently, plus the push to make it more cross-platform than it already is.

Microsoft usually has pretty good documentation. Maybe that lowers the need to use SO, which would lower the odds of those developers being active on SO.

28% is still pretty good compared to Java's 33%.

Oh definitely, Microsoft docs are usually very well written. And you're right, those percentages look pretty good.

This looks pretty cool! May I ask what tech stack you use? I always find that info curious.

There's definitely valid criticisms, but a lot of it seems like hate. But I also agree that it's probably a reaction to the earlier hype wave.

I especially find it funny that people assume that people like Rob Pike and Ken Thompson who have published research papers on computer science forgot or misunderstand modern language features. They purposely made their language this way, for better or for worse. They never stated that they were trying to make the next Java. And all of the successful projects that have been released so far written in Go is proof enough that it seems they know what they're doing.

People complain online for a language they won't use instead of using the languages that are "superior" to make useful modern software.