Google Engineers Lift The Lid On Carbon - A Hopeful Successor To C++

[nist]

I have only one question: why compiler missing options and features are (programming) language failures?

[sinepgib]

I have only one question: why compiler missing options and features are (programming) language failures?

On a practical level, because languages are only useful if you can use them. If a feature is possible but it doesn't exist, it's entirely irrelevant if it's the language's fault, it will make the language fail anyway. Whatever the specification says is worthless if tools are shit.
On a philosophical level, it depends, sometimes it will be a language failure (C will never implement borrow checking because of how the language is (un)defined, not because GCC is not a good compiler for it), sometimes it will not be (nothing in Python itself stops you from having a sane dependency management solution, it's strictly a community problem).

[darkonix]

Regarding your statement with Rust and the Linux kernel:
1) When it does happen, it will be flagged as EXPERIMENTAL, and since Linus is quite practical, I would bet that if there is not big improvement (performance, ease of maintence and such) and he will require demonstrative proof, that it very well might just get dropped to reduce the overall complexity of the development system which is pretty keen on if I am reading between the lines of his statements.

That's the current status. It is an experimental branch not yet merged. Not sure if Linus idea is to keep it experimental after merging it and release it with a new kernel. He said that's probably going to be soon-ish.

2) Though the use of the kernel itself is big, the number of developers doing core development including drivers is quite small in the overall headcount within the industry so again the impact is not as big as you seem to think.

You are probably right but the impact is not in the numbers but that Linus and the rest of the Linux kernel team consider Rust good enough to be included in the kernel, even if experimentally. Until now it was only C and some assembler. C++ would never get this chance.

[darkonix]

Let me quote someone else: "I've written C and C++ professionally, also used Go and Rust on hobby projects. Rust, by far, was the hardest to learn and get something useable out of it. Because of that, I would never recommend someone put it into production unless they have a very specific use case that Go could not handle. The onboarding costs would be just too much."

You mean like Discord did a few years ago? https://discord.com/blog/why-discord...rom-go-to-rust

Notable quote:
"Remarkably, we had only put very basic thought into optimization as the Rust version was written. Even with just basic optimization, Rust was able to outperform the hyper hand-tuned Go version. This is a huge testament to how easy it is to write efficient programs with Rust compared to the deep dive we had to do with Go."

By the way, I don't say Rust is not harder than some other languages to learn, but it seems to be worth the investment for some use cases. As alwyas, use the right tool for the job.

[Raka555]

You mean like Discord did a few years ago? https://discord.com/blog/why-discord...rom-go-to-rust

Notable quote:
"Remarkably, we had only put very basic thought into optimization as the Rust version was written. Even with just basic optimization, Rust was able to outperform the hyper hand-tuned Go version. This is a huge testament to how easy it is to write efficient programs with Rust compared to the deep dive we had to do with Go."

By the way, I don't say Rust is not harder than some other languages to learn, but it seems to be worth the investment for some use cases. As alwyas, use the right tool for the job.

I agree about the right tool for the right job.

Your quote is actually a testament at how garbage collection/automatic memory management makes a language slow.
Optimising GC languages always ends in somehow circumventing/tricking/disabling the GC.

[cj.wijtmans]

Ah more people who are too retarded to program in c++ reinventing the wheel.

[uxmkt]

There kind of has been a mass exodus of C++ users to Rust.

That's easy to say when no verifiable source is provided.

If anything, the exodus is from C to Rust. After e.g. the Apple "goto fail" debacle, maybe people finally started to realize that a few select programming features are just too good to ignore, e.g. destructors. In GCC for example, there is __attribute__((cleanup(x))). But those people are too afraid to admit they could have had $feature with most languages other than C for years. The only credit they get is that FFI for languages outside the realm of GCC sucks most of the time.

The simple fact of the matter is that C++ can't be cleaned up,

"Clean your room!" "But it is tidy."
Those who don't understand $x are quick to call for a cancellation of $x.

[benjiro]

Let me quote someone else: "I've written C and C++ professionally, also used Go and Rust on hobby projects. Rust, by far, was the hardest to learn and get something useable out of it. Because of that, I would never recommend someone put it into production unless they have a very specific use case that Go could not handle. The onboarding costs would be just too much."

I spend several months learning Crystal, then Rust, then dLang and so many other. Close to a year probably on difference languages and projects. Ironically, I ignored Go during that time, Now, all i do is write Go ... the irony ... its extreme powerful but at the same time simple. I am writing things unfeasonable with PHP and loving it every day. Message brokers, Caching, Multithreading file processing, compiling Win or Linux version with 2 keystrokes, binary transport layers, microservice galore, ... o ... and so easy to find issues.

Rust ... while i got the hang of it after spending a few months on it alone. It was simply too complex for most of my tasks. The lacking community packages ( for my needs ) also did not help. And my god, LLVM is so fying slow to quick compile and check things. Just running Go with its 0.5sec compile time on this huge project (barely hitting 15%, on a 3900x)... F5 (compile), check output, F6 stop, make a few chances, F5, plop ....

I do not understand why people can stand Rust when its compile times grows. And they grow fast!

You mean like Discord did a few years ago? https://discord.com/blog/why-discord...rom-go-to-rust

Notable quote:
"Remarkably, we had only put very basic thought into optimization as the Rust version was written. Even with just basic optimization, Rust was able to outperform the hyper hand-tuned Go version. This is a huge testament to how easy it is to write efficient programs with Rust compared to the deep dive we had to do with Go."

By the way, I don't say Rust is not harder than some other languages to learn, but it seems to be worth the investment for some use cases. As alwyas, use the right tool for the job.

The problem with that type of stupid analysis, and that is what it is, is that people equal speed with production speed. When it not...

Take Go and Rust, use both in a Web Dev job and you will notice that the cases where Rust its amazing speed, is simply not there. Because other components are stalling your project like DB rountrips, storage access, client response/response, latency, ... Its like driving a nice BMW and a Ferrari. Sure, that Ferrari goes very fast, but what is the point when your driving on a highway with constant traffic around you. Did you gain anything from driving a car that is harder to handle, has a higher maintenance cost but gain very little with that speed advance on the same road as where the other cars drive?

Rust has its uses but people need to stop looking at Rust and Go like they exist in the same space. They do NOT. Go thrives for web development, micro services, cli programs, etc. Rust has much more use in low level ( aka Kernel drivers ), and other domains that overlap with C++. You do not see people using C++ for web development, nor do you see people compare C++ To PHP for web development because only a total idiot that has no concept of time = money, will write websites in C++. Fuck ... The cost of a single dev alone is the difference between running 10 to 30 times more servers. Let alone the issue of replacement. Trust me, seen that song and dance in real life, how a company lost easily 1M in revenue because a project was in a language where we had difficulty finding people for ( at the time ), when that dev quit.

In my opinion Rust dev's need to grow up and stop comparing to projects that are not their focus. Its like a constant envy of other languages triggers them and they need to constantly validate themselves by trying to go around with their stupid "lets rewrite it in rust" < Gets tiresome VERY FAST seeing those idiots around! I am amazed how many times people keep telling how nice Rust community is but outside their own community they are like annoying mosquitos.

From my perspective ... I can easily find a well paid Go job but Rust jobs are very rare. Trust me, i looked in my local market. Its a 12 to 1 ratio. And most of those are not specific jobs but the typical "if you know C++, Rust, ..." entries, where the job is not even Rust focused.

Reality is, Rust is a nice language for a specific market. But has nothing to do with Go. Its frankly less useful to put on my CV, then several other languages. Very few companies need this specialization and require more volume of work, even if the language is not as fast, then a very fast language. Server and hardware is cheap, that is the reality. Especially compared to developer time. Being faster is only useful, if you can leverage it and really have a need for it. Else people simply use more hardware, that tends to be way cheaper then developer time. The days of focused software where you tried to save every KB and needed to invent tricks to gain a few percentage... That now only applies to very specific programs. And memory safe? GC have been doing a great job for decades now.

[sinepgib]

Reality is, Rust is a nice language for a specific market. But has nothing to do with Go.

I think the issue comes from what Go intended to replace versus what it actually replaced.
When Rob Pike and company created Go, they meant it as a replacement for C, that's how they marketed at the time. In reality, it ended up being a more suitable replacement for scripting languages used for web development. But because it was intended as a C replacement, Rust advocates tend to think they actually compete in the same space, when they absolutely don't.

[andreano]

I visit a job board and see the following numbers:
c++ - 138
python - 182
java - 235
c# - 199
golang - 52
rust - 5

Who in their sane mind wants to get 5 job proposals instead of hundreds? So almost none will invest time into learning Rust. The same goes from the company perspective: Do you want your product to get locked into a not widespread technology and hard-to-find developers?

Said my former employer, and he was wrong. There are few Rust jobs, precisely because they get taken.