15 ms·

I'm watching with both amazement and amusement how Rust is undergoing the exact same process we went through with C++ in the late '80s and early '90s, pushing t

by pron 5y ago

I'm watching with both amazement and amusement how Rust is undergoing the exact same process we went through with C++ in the late '80s and early '90s, pushing the belief that the same language should be used for both low-level and high-level programming. Back then, just as it is now, that idea was sold by programmers who are on the more capable end of the spectrum and who also enjoy spending a lot of time thinking about clever ways to express programs in a rich programming language. Then, as now, they were people who hadn't had much contact with the average software developer and with the realities of software mass-production. The few of them who had, also tried convincing the industry that the system should change, and that software should be developed by small elite groups who are masters of the discipline as well as discipline (I'm not talking about the people who like Rust, or C++, for that matter, for low-level programming, but about those who try to sell low-level programming for application development), but, of course, the economics always win. Those who go down that path will experience the same disillusionment we did, and end up with applications that end up costing so much more to maintain if only because of the cost of the maintainers they require. Software costs work better when low-level and high-level programming are kept separate. The former is costlier but tends to be both smaller in size and in prevalence, while the latter is the opposite. Of course, the number of people who make that mistake of mixing high- and low-level programming won't be nearly as high now as it was back then -- many of us have learned our lesson -- but it would still be interesting to watch this unfold again, even at a small scale. And, thirty years from now, some will be telling us why, while using Rust for high-level programming was indeed, a costly mistake, Muju is completely different, and this time a low-level language really and truly is appropriate for application programming.

layoutIfNeeded 5y ago
Every generation must go through these cycles. Visual programming, no-code solutions, thin clients, thick clients, static typing, duck typing, functional programming, etc. Time is a flat circle.
dathinab 5y ago
> more capable end of the spectrum Actually rust is a grate language for programmers of the less capable end of the spectrum. While it allows clever abstractions it generally discouraged and recommended to write simple code. The borrow checker might seem like a clever abstraction, but it's just a build in code analytics tool you should use anyway when using C or C++ or well any language, and it generally nudges you to better structured code. > Then, as now, they were people who hadn't had much contact with the average software developer and with the realities of software mass-production. Except that more than just a few decisions in the rust design process where strongly influenced by the feedback of average developers, including people which just got started with programming. Wrt. C++ I can completely agree, it's a completely over engineered language with endless gotchas with silently sneak into you code without you noticing and potentially causing UB if compiled with some compiler in some optimization levels for some target. Making such bugs completely bonkers to track down. On the other hand in (safe) rust many of the problems user have come from the language helping you to not run into any of this and other bugs. And all "hidden" complexity rust has is normally designed in a way so that you don't need to know it to use rust or even things related to it as long as you don't want to create some low level primitives which involve unsafe code.
- pron 5y ago
  That is exactly what we thought about C++. We, too, believed that C++ fixed all those problems with both low-level programming in C, and the "messy" programming of the "application generators" of the time; it lets you clearly express intent and yet helps you avoid shooting yourself in the foot as happens in C. Anyone who truly believes that Rust is a great language for the average applications developer, clearly has not met one.
  - est31 5y ago
    I think you have a point that yes, programming languages depend on the domain a program is in. If the program only handles up to 10k customers, it can be programmed in javascript and can indeed keep its entire database in RAM. sqlite even has a mode for this. A LOT of custom software is in this "small" domain. However, when you get to millions or billions, maybe you have to optimize and create a backend. What should this backend be written in? Previously the answer might have been C++. But now it's Rust. Personally, being a Rust enthusiast, I think that Rust's benefits don't just unleash when you think about performance, but also when you think about large codebases. Such codebases are usually the scene for refactorings. In a dynamic language like js, these are extremely hard to pull off. In Rust, the compiler won't stop yelling at you until you have cleanly finished the refactor. I love refactoring Rust codebases, even ones I didn't write, while in C++ or other languages it's extremely annoying. And note that while C++ enthusiasts might have believed that everything should be C++, not everyone followed them. Many people still stayed with C. Many still do even with Rust around. But there is a small group of people for whom Rust is such a great improvement that they take the portability cost and switch to Rust. Linus is heavily anti C++ for example, but he's open to adding Rust to the kernel.
    - golergka 5y ago
      > However, when you get to millions or billions, maybe you have to optimize and create a backend. What should this backend be written in? Previously the answer might have been C++. But now it's Rust. Neither Facebook, nor Instagram or Slack are primarily built on C++ or Rust though. And many other products that I can't as confidently remember from the top of my head aren't.
mjw1007 5y ago
I observe that the last sentence of your first paragraph is strongly at variance with the Rust leadership's self-image. (See for example the "Empowerment, empowerment everywhere" RustConf 2020 keynote.)
- deleted 5y ago
  [deleted]
geofft 5y ago
"Software should be developed by small elite groups" is pretty much the opposite of the Rust developers' goal. I do agree with you that it's a bad goal to have, which is why I'm optimistic about Rust's success.
- deleted 5y ago
  [deleted]
ta_ca 5y ago
didn't lisp prove the opposite? you can go lower than c and higher than any language we currently have in the same language?
- hu3 5y ago
  Yes but where is Lisp market share? It's mostly an academic language these days. If anything Lisp current adoption proves that aiming to tackle both ends of the spectrum in a single language might not be a good idea.
  - ta_ca 5y ago
    do adoption or market share matter in this context? if you can have best of the both worlds why would you want to deal with an another language?
    - astrange 5y ago
      There are downsides to using the most powerful option at all times. https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power Also, Lisp is the most powerful at constructing programs but that means it's the least powerful in the field of making sure your program actually does what you wanted it to - that's what types, borrow checking, proof assistants and so on are for. (Some people think Lisp is declarative because it's homoiconic but that's not true - you can't find out what a Lisp macro does without executing it.)
the__alchemist 5y ago
I do mostly embedded programming. Performance and ability to access memory directly is critical! But I like taking advantage of modern tooling, and abstractions like pattern matching, traits etc, and clear syntax. Changing languages through an FFI barrier would add complications.
twic 5y ago
There's something to this. Rust was built to do low-level programming well, and as a result it's quite hard. It's fundamentally more work to do things than in a GC'd language of similar modernity. That's a perfectly reasonable tradeoff. But somehow, Rust got cool, and now a large fraction of its community wants to use it to write web services. So there's a lot of gravity dragging the ecosystem, and even the standard library and the language, in that direction. Even though it is a poor choice for almost all web services. One day, the shine will wear off, and it will be easy to see that it's a poor choice for almost all web services, and we will feel some regret over the amount of time and energy that went into building in that direction.
- the__alchemist 5y ago
  Agreed - I built a rust frontend framework, and tried to use it on the backend for a while. Ended up switching back to Python and Javascript for web - I use rust for embedded mostly now.
- hu3 5y ago
  Like Uber, some do manage to avoid the pitfall of trying to shoehorn hard languages everywhere. I recently learned their microservice fleet is almost entirely in Go [1]. Could also have been C#, Java, Python or Node but the point is it is not Rust or C++. Probably for the reasons you stated. [1] https://news.ycombinator.com/item?id=27120689 https://news.ycombinator.com/item?id=27120689
  - littlestymaar 5y ago
    For companies like Uber, Rust would probably be a good fit if they started today: at this scale you spend more time optimizing some otherwise simple logic in order to scale up without wasting too much resources. Go has a decent optimization story, thanks to the escape analysis diagnostic which makes it quite straightforward to avoid many allocations (much more easily than in C# for instance, even if it's also doable in C# indeed), but Rust takes it step farther, and you'll have better performance to begin with, which will drastically reduce your scaling effort. For instance, look at what Cloudflare ended up doing to get Go working as they wanted: https://blog.cloudflare.com/go-dont-collect-my-garbage/ https://blog.cloudflare.com/go-dont-collect-my-garbage/ Rust will never be a competitor to Python or PHP (but it can enhance them, because making a native extension in Rust in way easier than in C, especially for people with a web back-end background and little C experience), but Go is losing a lot of appeal now that Rust is here ready for prime time.
llogiq 5y ago
Well, I have been writing both high and low level code in Rust, and I must admit I've been happily falling into that "trap". The nice thing about Rust for high level software is that it lets us specify interfaces in a way that makes them actually usable without delving into the low level details. A lot of things that are hand waved away in C++ (who owns this? How long does this need to be alive? Can I mutate this?) are completely explicit in a Rust interface. And Rust's type system is strong enough to express a lot of rules that no one would want to write down in C++ (because overriding them is just one cast away), allowing us to write hard-to-misuse libraries. Coding on top of such libraries is a really fun experience. That's why I call Rust an all level language.
- pron 5y ago
  Different languages appeal to different people, and there is no doubt some individual programmers will find Rust appealing even for application programming, just as some found C++ appealing for similar purposes. But a CIO of, say, an insurance company who decides that internal applications will be written in Rust would be making a very imprudent financial decision.
himujjal 5y ago
Rust is not at all a high-level language in any sense and will not replace the places Kotlin, Go, TypeScript etc occupy. If I wanted to write a super-fast server with some time constraints, I would choose Go without thinking twice. Go is fast enough. Rust is only needed when you need things to be super-duper fast and memory efficient. Those two criterias are the only reasons to use Rust.
daniel42__ 5y ago
why do high-level languages almost always run inside an interpreter/vm? (except swift/go) is it a good or a bad thing?

by pron 5y ago

layoutIfNeeded 5y ago

Every generation must go through these cycles. Visual programming, no-code solutions, thin clients, thick clients, static typing, duck typing, functional programming, etc. Time is a flat circle.

dathinab 5y ago

> more capable end of the spectrum Actually rust is a grate language for programmers of the less capable end of the spectrum. While it allows clever abstractions it generally discouraged and recommended to write simple code. The borrow checker might seem like a clever abstraction, but it's just a build in code analytics tool you should use anyway when using C or C++ or well any language, and it generally nudges you to better structured code. > Then, as now, they were people who hadn't had much contact with the average software developer and with the realities of software mass-production. Except that more than just a few decisions in the rust design process where strongly influenced by the feedback of average developers, including people which just got started with programming. Wrt. C++ I can completely agree, it's a completely over engineered language with endless gotchas with silently sneak into you code without you noticing and potentially causing UB if compiled with some compiler in some optimization levels for some target. Making such bugs completely bonkers to track down. On the other hand in (safe) rust many of the problems user have come from the language helping you to not run into any of this and other bugs. And all "hidden" complexity rust has is normally designed in a way so that you don't need to know it to use rust or even things related to it as long as you don't want to create some low level primitives which involve unsafe code.

pron 5y ago
That is exactly what we thought about C++. We, too, believed that C++ fixed all those problems with both low-level programming in C, and the "messy" programming of the "application generators" of the time; it lets you clearly express intent and yet helps you avoid shooting yourself in the foot as happens in C. Anyone who truly believes that Rust is a great language for the average applications developer, clearly has not met one.
- est31 5y ago
  I think you have a point that yes, programming languages depend on the domain a program is in. If the program only handles up to 10k customers, it can be programmed in javascript and can indeed keep its entire database in RAM. sqlite even has a mode for this. A LOT of custom software is in this "small" domain. However, when you get to millions or billions, maybe you have to optimize and create a backend. What should this backend be written in? Previously the answer might have been C++. But now it's Rust. Personally, being a Rust enthusiast, I think that Rust's benefits don't just unleash when you think about performance, but also when you think about large codebases. Such codebases are usually the scene for refactorings. In a dynamic language like js, these are extremely hard to pull off. In Rust, the compiler won't stop yelling at you until you have cleanly finished the refactor. I love refactoring Rust codebases, even ones I didn't write, while in C++ or other languages it's extremely annoying. And note that while C++ enthusiasts might have believed that everything should be C++, not everyone followed them. Many people still stayed with C. Many still do even with Rust around. But there is a small group of people for whom Rust is such a great improvement that they take the portability cost and switch to Rust. Linus is heavily anti C++ for example, but he's open to adding Rust to the kernel.
  - golergka 5y ago
    > However, when you get to millions or billions, maybe you have to optimize and create a backend. What should this backend be written in? Previously the answer might have been C++. But now it's Rust. Neither Facebook, nor Instagram or Slack are primarily built on C++ or Rust though. And many other products that I can't as confidently remember from the top of my head aren't.

mjw1007 5y ago

I observe that the last sentence of your first paragraph is strongly at variance with the Rust leadership's self-image. (See for example the "Empowerment, empowerment everywhere" RustConf 2020 keynote.)

deleted 5y ago
[deleted]

geofft 5y ago

"Software should be developed by small elite groups" is pretty much the opposite of the Rust developers' goal. I do agree with you that it's a bad goal to have, which is why I'm optimistic about Rust's success.

deleted 5y ago
[deleted]

ta_ca 5y ago

didn't lisp prove the opposite? you can go lower than c and higher than any language we currently have in the same language?

hu3 5y ago
Yes but where is Lisp market share? It's mostly an academic language these days. If anything Lisp current adoption proves that aiming to tackle both ends of the spectrum in a single language might not be a good idea.
- ta_ca 5y ago
  do adoption or market share matter in this context? if you can have best of the both worlds why would you want to deal with an another language?
  - astrange 5y ago
    There are downsides to using the most powerful option at all times. https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power Also, Lisp is the most powerful at constructing programs but that means it's the least powerful in the field of making sure your program actually does what you wanted it to - that's what types, borrow checking, proof assistants and so on are for. (Some people think Lisp is declarative because it's homoiconic but that's not true - you can't find out what a Lisp macro does without executing it.)

the__alchemist 5y ago

I do mostly embedded programming. Performance and ability to access memory directly is critical! But I like taking advantage of modern tooling, and abstractions like pattern matching, traits etc, and clear syntax. Changing languages through an FFI barrier would add complications.

twic 5y ago

There's something to this. Rust was built to do low-level programming well, and as a result it's quite hard. It's fundamentally more work to do things than in a GC'd language of similar modernity. That's a perfectly reasonable tradeoff. But somehow, Rust got cool, and now a large fraction of its community wants to use it to write web services. So there's a lot of gravity dragging the ecosystem, and even the standard library and the language, in that direction. Even though it is a poor choice for almost all web services. One day, the shine will wear off, and it will be easy to see that it's a poor choice for almost all web services, and we will feel some regret over the amount of time and energy that went into building in that direction.

the__alchemist 5y ago
Agreed - I built a rust frontend framework, and tried to use it on the backend for a while. Ended up switching back to Python and Javascript for web - I use rust for embedded mostly now.
hu3 5y ago
Like Uber, some do manage to avoid the pitfall of trying to shoehorn hard languages everywhere. I recently learned their microservice fleet is almost entirely in Go [1]. Could also have been C#, Java, Python or Node but the point is it is not Rust or C++. Probably for the reasons you stated. [1] https://news.ycombinator.com/item?id=27120689 https://news.ycombinator.com/item?id=27120689
- littlestymaar 5y ago
  For companies like Uber, Rust would probably be a good fit if they started today: at this scale you spend more time optimizing some otherwise simple logic in order to scale up without wasting too much resources. Go has a decent optimization story, thanks to the escape analysis diagnostic which makes it quite straightforward to avoid many allocations (much more easily than in C# for instance, even if it's also doable in C# indeed), but Rust takes it step farther, and you'll have better performance to begin with, which will drastically reduce your scaling effort. For instance, look at what Cloudflare ended up doing to get Go working as they wanted: https://blog.cloudflare.com/go-dont-collect-my-garbage/ https://blog.cloudflare.com/go-dont-collect-my-garbage/ Rust will never be a competitor to Python or PHP (but it can enhance them, because making a native extension in Rust in way easier than in C, especially for people with a web back-end background and little C experience), but Go is losing a lot of appeal now that Rust is here ready for prime time.

llogiq 5y ago

Well, I have been writing both high and low level code in Rust, and I must admit I've been happily falling into that "trap". The nice thing about Rust for high level software is that it lets us specify interfaces in a way that makes them actually usable without delving into the low level details. A lot of things that are hand waved away in C++ (who owns this? How long does this need to be alive? Can I mutate this?) are completely explicit in a Rust interface. And Rust's type system is strong enough to express a lot of rules that no one would want to write down in C++ (because overriding them is just one cast away), allowing us to write hard-to-misuse libraries. Coding on top of such libraries is a really fun experience. That's why I call Rust an all level language.

pron 5y ago
Different languages appeal to different people, and there is no doubt some individual programmers will find Rust appealing even for application programming, just as some found C++ appealing for similar purposes. But a CIO of, say, an insurance company who decides that internal applications will be written in Rust would be making a very imprudent financial decision.

himujjal 5y ago

Rust is not at all a high-level language in any sense and will not replace the places Kotlin, Go, TypeScript etc occupy. If I wanted to write a super-fast server with some time constraints, I would choose Go without thinking twice. Go is fast enough. Rust is only needed when you need things to be super-duper fast and memory efficient. Those two criterias are the only reasons to use Rust.

daniel42__ 5y ago

why do high-level languages almost always run inside an interpreter/vm? (except swift/go) is it a good or a bad thing?