Hacker News Reader

Comment by rsj_hn | Hacker News Reader

Meh, the future is higher and higher abstraction layers and higher level business logic with more and more details managed for you by the runtime. If you thought managed memory was good, wait until languages start managing access control, authentication, concurrency and persistence layers for you. The language that boosts productivity for 90% of use cases is going to win over the language that gives you more fine grained control to allow you to handle the remaining 10%.

In that sense, Rust is a good evolution of C down this path, but it remains a systems language, which is an ever-shrinking percentage of the software ecosystem, even if Rust itself is growing as more C programmers try to switch over to a language with more high level features.

View on HN

Sure, but what abstractions? If you look at flattening cpu speeds, we're in a period (probably not forever tho) in which advances in computing will happen at the software level, which raises the priority of concurrency and runtime efficiency. It's those primitives that Rust's abstractions model well. In addition, software has become weaponized and nobody can trust anyone, and Rust's emphasis on safety and security meets that need as well.

There will be no winner. There will be winners.

Rust has a niche, and it is a big one, where a lot of C++ used to be. If you cannot afford GC pauses (all sorts of servers) and need fine control, rust could very well be for you. It will win in that space.

System programming is not a "ever-shrinking percentage of the software ecosystem". It is a constant percentage. As we develop systems we need languages like Rust.

> Meh, the future is higher and higher abstraction layers and higher level business logic with more and more details managed for you by the runtime.

Historically this doesn't seem entirely true. We haven't gotten much higher level than Java, outside of non-eng niches where we haven't gotten much higher level than Python (which is arguably lower level than R, which has been unseated).

So I don't think it holds true that we'll continue to chase a higher abstraction layer. We recognize the cost of doing so, and it hasn't been worth paying so far.

Besides that, Rust is quite capable of providing high level abstractions. I myself am building a sandboxing mechanism in Rust that will be entirely managed for you but with no runtime cost (it's generated statically) - it is Rust's low level power that lets me build such high level abstractions.

> If you thought managed memory was good, wait until languages start managing access control, authentication, concurrency and persistence layers for you.

I heard that pre-Unix mainframe operating systems had a baked-in database rather than a filesystem, Lisp/Smalltalk had persistent images, etc. So I don't know if these abstractions are new, or just going mainstream. Capability-based security systems have been written about in academia for decades (according to https://en.wikipedia.org/wiki/Capability-based_security#Refe...).

Someone has to write the kernel drivers that your abstraction layers and business logic runs on... https://www.usenix.org/system/files/1311_05-08_mickens.pdf

Rust to me makes difficult things that are trivial in C. For example one thing that I don't like about Rust is the fact, that at least with the standard library, memory allocations are hidden in things like calling the constructor of a string. And what if a memory allocation fails?

What's the point of a memory safe language if your whole program could fail for a simple out of memory condition? With C I can allocate all the memory that I need upfront, as a static variable either global (yes, they are not the devil) or inside a single function. That way the compiler can tell me if my program will fit in memory or not.

And yes, I know that in Rust you can avoid using the standard library and you can manage the memory yourself in unsafe blocks. But... what's the point on fighting the language when you can just use C?

All the things that are said about C, it's unsafe, nowadays you have tooling, every decent compiler will warn you if you try to do stupid things.

> All the things that are said about C, it's unsafe, nowadays you have tooling, every decent compiler will warn you if you try to do stupid things.

And yet Microsoft, Mozilla, Google, etc. all peg 70% of the bugs in their C codebases as memory and pointer problems.

Apparently the tooling isn't good enough to stop this.

> What's the point of a memory safe language if your whole program could fail for a simple out of memory condition?

The point is to be able to do more complex things more easily and performantly, while also not introducing trivial security vulnerabilities like buffer overflows.

> But... what's the point on fighting the language when you can just use C?

The point is to learn not to fight it. At that point, the language becomes much more effective to use than C.

Proper C, which is not full of holes and undefined behaviour, also feels like fighting in the beginning. Empirically, it is also a fight that is won much more rarely.

> The language that boosts productivity for 90% of use cases is going to win over the language that gives you more fine grained control to allow you to handle the remaining 10%.

Actually no. The most important qualities for a language to quickly gain popularity are:

* Low barrier to entry

* Who is backing it (Go, Java, C#)

* What platforms it opens up (Swift,ObjC,Kotlin/Java) that require that language.

And Rust has 2. and 3. which is more than Python for instance, which is immensely successful despite only having 1.

Rust has #3 going for it? Which major platforms are Rust-native or Rust-first, as with Java/Kotlin on Android, Javascript on the Web, ObjC/Swift on iOS, et c.?

Opening native development to a big number of people who would have otherwise never touched it.

This may not be obvious at first, but AFAIK the majority of Rust users come from web languages (mostly JavaScript, Ruby and Python) and the fraction of programmers doing native/low-level stuff had been declining for decades and Rust is bringing a lot of new people to it.

(Also webassembly, but it's a much smaller niche at the moment)

I took rapsey's item #3 to mean that languages tend to grow well when they're required—or at the very least considered the first-class option—for accessing a desirable ecosystem or platform, which does seem to be one major way language adoption grows. Not just that they let developers do things they maybe weren't before (but could have been, in another language).

Yes, I think it's literally what was meant in the original comment, but I've given it a slightly broader definition because I think this aspect is a huge factor in Rust's popularity.

Rust can be "native" on any platform that supports C/C++, provided only that the necessary pieces on the LLVM side are in place. There are even folks who will help you deploy Rust on console hardware where no publicly-available support can ever exist because the official C/C++ API's are kept secret and only made available to those who sign highly-restrictive NDA's.

Right, it's portable, but that's not what 3 was about. It's about being required for first-class access to a desirable platform. It's why Objective-C gained strong, renewed interest when iPhone apps in that language were announced. It's why anyone cares about Javascript. It's why Kotlin adoption grew very fast when Google announced support for it on Android, or why Swift went from nothing to fairly high levels of use practically overnight. That kind of thing.

1 is the most important. It also has 3 for machine learning.

Rust barely has 2 and 3. Mozilla never pushed it much and it also is not a huge employer. It has 3 if you strech the definition.

> It also has 3 for machine learning.

Python was popular way before machine learning went mainstream.

> 1 is the most important.

1. is super important, but keep in mind that Python having a much higher barrier to entry than PHP on the web didn't stop it from becoming popular in that field.

Also 1. is really context dependent, and even if Rust has a bigger barrier to entry than Python, it has a much smaller one that its direct competitors (C and C++) because of its documentation, learning material, compiler error messages and dependency management.

Regarding 2. you must have missed the news: Rust is now officially pushed by Microsoft, AWS, Google and Facebook. In fact you'd have difficulties to find languages with stronger corporate backing than Rust today apart from C# and Java.

It's never winner takes all. There is space enough for a whole lot of languages. Keep in mind in the early days of Python it was pushed by Google. They specifically looked and advertised for python developers. That is more of a push than any company ever did for Rust.

Rust barrier to entry compared to C/C++ is debatable. Lots of universities for instance have courses in them. They have a whole lot of books and a large community out there.

I disagree about 2 and Rust. Those companies have projects in them and they are a part of rust foundation. They are however not mass employing Rust developers and only AWS has components for core stuff in Rust. Of course it is debatable for what is a core component.

> Keep in mind in the early days of Python it was pushed by Google.

You know Python is older than Google by several years right? ;) When this happened, Python was older than Rust today.

> That is more of a push than any company ever did for Rust.

Microsoft recently made Rust a officially language for developing Windows Native apps[1] and they've advertised the use of the language quite a bit during the past year. Google just released its new operating system developed with as much Rust as C and C++ combined[2]. Also, Facebook and AWS have hired members of the Rust development team after Mozilla's layoff last year to continue their work on Rust.

[1]: https://blogs.windows.com/windowsdeveloper/2021/05/06/announ... [2]: https://news.ycombinator.com/item?id=27274820

I don't think Rust is the evolution of C. Its a nice thought, just like I like to think im the evolution of [famous well known person].

C++ was the evolution of C and so was Java, but they both turned out to be their own things and C kept on chugging. Rust is a big complicated language, there is nothing C like about it. I see more parallels between Rust and C++ than I do Rust and C.

> If you thought managed memory was good, wait until languages start managing access control, authentication, concurrency and persistence layers for you.

This exists in 4GLs (https://en.m.wikipedia.org/wiki/Fourth-generation_programmin...)

This is a bad take.

In special because the way rust do things now is THE optimal way to work:

Rust is GROWING.

In this step (let's call it the adolescent) is NOT THE TIME to stop for the needs of C, C++, Debian, or anything else that is glacially slow to change, generate BILLONS of losses in this industry, and is arcane as hell...

In fact, I wish it not be that conservative moving forward.

But where is genius all of this? Is that despite the forward momentum it NOT fell "broken by design" at all. Is one of the few tools in my +20 years on the trade that I can update with confidence and that actually NOT DEMAND to change all my code as often as it look like.

So this is the real experience with Rust: All stuff is very carefully considered as much as possible, not major big mistakes, cargo si GOOD!, and because that, update is painless, and still: You don't need to refactor code in each update, you get benefits without major costs (more performance! better internals!), and still can profit for the work of everyone in the community.

P.D: Rust is certainly made with CI-oriented deployment as the preferred way to work. If wanna move forward glacially, I don't see how is that impossible. In fact I bet you can stop updating, wait 2-3 years, do a big refactoring and move along. This is how ACTUALLY was in the past with tools like C# and others, and I pretty sure Rust will make that thing much easier to shallow...

I'd like to see more embedded programming done in Rust instead of C.

Reply on news.ycombinator.com