Rust will revolutionize ecosystem of high level language?

1

In the past,low level language mean no safety. So people have created high level language for more safety,productivity,easy learn, .. Each high level language has its own ecosystem build on its language, so it has sacrifice the performance, for more reliability.

Rust solve the problem of safety in low level language. But it has problem of productivity to write a program.

Someone will say Rust is high level and productive language, I agree. Here "productivity" and low/high language are a measure relative to other good language. I have change the definition of low/high level language in my question for easier express my idea, don't pay attention.

Why I say Rust is a low level language and no productive in my question? Because I have compared Rust to language like Ocaml,Haskell,Nim. Rust is lower level: in Rust, you should think about memory management every time, unlike with a GC language. This language also have a higher level abstraction. that the language paradigm is closer to the problem to be solved, the code contain zero low level logic. For instance use a advance metaprogramming language like Nim to create a DSL, and express the program really closer of problem to solve.
What I mean "productive". Here, the productivity is effort need to write/transformation/modification and read the program. Rust is maybe productive to write good program, but no productive to read.
I think Rust is less productive compare to this strongly typed and GC language. So some people will prefer to use this languages than Rust for more productivity.
For instance, I can see some people have swith Rust into Nim : We just switched from Rust to Nim for a very large proprietary project I've been... | Hacker News

Interlanguage programming approach allow use the best language for a task. A high level language wrapper around a Rust library. Use a Rust as low level library because Rust is more quick and more safe. Use high level language API because high level language is more productive.
Such approach is used in high performance library in Deep Learning, like TensorFlow: use C as low level language for the performance, use CPython as high level language for data scientist to modelize the logic aspect of program.

This approach has few advantage.

  • It avoid each high level language to rebuild a same feature in its ecosystem based on its own language.
  • It allow combine the performance of low level language with productivity of high level language

I can also see some inconvenient:
Program use a unique language has better portability. For instance, Scala can compile into JVM bytecode and javascript, if I use a java library, the program isn't portable into a browser. So it is better to privilege a pure Scala library.
But this issue don't concern high level language that can run on browser and compile into executable binary. I don't see any reason for this language to code a new library with its own language. Just a wrapper around Rust is enough.

In the futur, all high level language(that support same platform than Rust) 's library will become a wrapper around Rust library?

2

Yeah, it often is a common trope that "write you program in Python, profile, move slow parts to a faster language". This doesn't actually work as well as it might seem.

First, calling from high-level language into low-level language might actually be slower than just coding everything in HLL. Crossing language boundaries is generally a high-overhead operations. Text Buffer Reimplementation, a Visual Studio Code Story is the best example of this effect. So, the trick isn't universal, it works only in domains like ML where you can offload significant batches of work.

Second, adding a second language to the system creates a lot of accidental complexity. A HLL+LLL system might be more costly to maintain than just writing everything in LLL. I don't have a particular short case study in mind here, but it' useful to thing about building, refactoring, and moving code over the boundary as example extra problems this approach brings.

I'd love to see a pair of languages which explicitly acknowledges the cost of interop, and is co-designed with the purpose of making this as seamless as possible. I'd love to see ML-style language implemented on top of a Rust runtime in an open way. I don't think this exist yet. The closest is probably the C+Lua pair.

Another interesting alternative is to have a low-level language which is OK for high-level stuff. And here I think Rust is very unfairly fortunate. Today's landscape of high-level language is pretty crowded with established languages which carry a lot of suboptimal design decisions (absent/poor type systems, complex build systems, unnecessary restricted runtimes). This both makes an entry of a new, better HLL harder, and creates the perception that Rust is a great HLL. So, in today's world, I think there are generally high-level systems which don't need to be written entirely Rust, but are still better written in Rust in their entirety, because today's higher-level languages are not that great, and the benefits of having the entire system in just one language is huge.

28 Likes
3

This question seems to be based on a couple of assumptions that I don't think are entirely true:

  1. The productivity of getting programs written in Rust is lower than some "high level" language or other.

On first encountering Rust that is a reasonable reaction. There is a lot to learn and getting anything to compile can be a pain. But I would say that is more than made up for when one finds ones creations tend to work when they compile and take a lot less testing to ensure everything works fine.

When one has learned the language things start to flow. Much the same as any other language.

  1. That Rust is a low level language.

Well, certainly on can do everything in Rust that on can do in a low level language like C. But I maintain Rust is a far higher level language. On a par with the likes of Python.

I say all this having switched entirely to Rust having spent some years using Javascript.

What is likely missing at this stage is the plethora of comfortable libraries and frameworks that users of the likes of Python and Javascript are used to.

1 Like
4

That's completely subjective. I'm perfectly productive in Rust. In fact I'm much more productive in Rust than I am in Python, JavaScript, C, or C++, because Rust provides strongly-typed abstractions and comes with a wide ecosystem of libraries and excellent dependency management.

10 Likes
5

No, it doesn't. Really. It does have an issue but it's entirely different one. It's managerial one. It doesn't allow one to write a sloppy code. Which is then, inevitably, shipped, because, hey, it looks working, why not ship it?

If you look on how much time you need not to produce some kind of prototype to show on weekly team meeting, but to fix all the bugs then it may, very well, be faster to write in Haskell or Rust than in Python or JavaScript.

Such approach is used in high performance library in Deep Learning, like TensorFlow: use C as low level language for the performance, use CPython as high level language for data scientist to modelize the logic aspect of program.

I wouldn't call CPython a high-level language. It's “sloppy language”, that's it's main advantage. It's easy to write code which works if moon is in right phase and falls apart if you look on the code (or data) funnily. But it's incredibly hard to write correct and reliable code in CPython. Maybe even harder than in C/C++.

This works for TensorFlow because code written in Python there is not a deliverable. Rather the ML-model produced by your python script is deliverable.

Similar story happens with SQL (only there reliability is often desired thus we have specialized guys who know how to implement thing that you need to implement in a safe and efficient way).

In the futur, all high level language(that support same platform than Rust) 's library will become a wrapper around Rust library?

It's very hard to predict. Today most of the code written is somewhere between “awful” and “it's so bad it shouldn't even exists”. The end result is well-known (just the very last example).

If this would continue (because it was deemed cheaper to have bazillion vulnerabilities and lose billions each year rather then write code which works and pay different billions to guys who would write said code) then “sloppy languages” would continue to dominate the landscape and Rust wouldn't make a revolution, if not — then “sloppy languages” would disappear (we may retail something domain-specific, like TI-Basic). Rust would be used more, but again: the revolution would happen not because Rust is so wonderful, but because it's one of the easiest languages to write not-entirely-incorrect code in.

Haskell may be slower than Rust but it's usually fast enough not to require addition of Rust library: if your code is tool slow in Haskell then chances are very high that rewrite in Rust wouldn't save it becuse it may produce only quite limited speedup. And it's usually safer (but then: is the ability to write panic-free code is worth all the complications of using not even raw Haskell, but Haskell with some “safe preamble”?).

So to answer your question: fate of Rust depends less on properties of language, per see, and more on whether these properties are desirable.

You already have them.

Safe Rust is quite high-level language. It's definitely not low-level, you can not work with raw bytes or machine code in it. Joy to use, very quick to write code in, memory-safe and pretty.

Unsafe Rust is the low-level counterpart. You may cause UB, you have to deal with promises to the compiler, null pointers, raw memory and so on. Ugly, hard to reason about, dangerous (in more way than one) and best to be used on “as needed” basis.

And integration is as seamless as you can imagine.

4 Likes
6

That’s true. But it is also true that safe Rust makes a lot of sacrifices at the altar of performance. It seems like it should be possible to do much better still. Here are some things which could work better in a higher-level language:

  • Fewer representation choices. Ideally, T is all you need, deciding between that or &T, &mut T, Box<T>, Rc<T>, Arc<T>, TIndex(usize) is mental overhead.
  • Richer types: functions could be a type, rather than a family of three traits.
  • True separate compilation: monorphisation makes edit-compile loop much slower.
  • Seamless IO — high level programs mostly revolve around IO, and efficient IO shouldn’t be restricted to the stackless subset of the language.
  • Open world assumption: dynamically loading sub programs should have native support
  • Introspectable runtime: heap parsing & live reload are features which again make iteration faster
  • Fault tolerant, distributed runtime: not sure about this one, but it seems that in the modern world some of the Erlang-the-runtime ideas can be pretty core to some applications.
4 Likes
7

While I agree that there could be a place for a higher-level Rust, I'd push back on this one a bit.

The distinction between &mut T and &T is one of the biggest things I miss in "usual" HLLs. GC'd OOP languages in particular are particularly bad for the "I passed an object to something and I have no idea whether it's going to modify it". Wrappers, caches, and such are all a mess without it.

See, for example, how C#'s static analysis tools have historically had a "never have a property that returns an array" lint because the caller can modify the array, and there's nothing in the type system to help with that. (They've since added some ad-hoc types for specific situations.)

Certainly the Arc<T> vs Rc<T> vs Gc<T> distinction isn't fundamental, of course.

12 Likes
8

Yeah, I think there an unfortunate choice here between:

  • programming with mutation is easy, so let’s add complex aliasing rules
  • programming without mutation is easy, so let’s add complex monad transformers

There’s also Erlang’s sweet(?) spot where everything’s immutable, but also there’s actor-global mutable hash table if you want convenient mutation.

3 Likes
9

Ha ha, yeah, there is plenty of room for improvement and new approaches in the future (take a look at Idris, for example). I think one of the biggest contributions of Rust in the long term will be the very high standard it sets for both performance and correctness. The fact that Rust is currently better at correctness than most of the functional languages is quite amazing. It leapfrogged in that sense. But that doesn't mean Rust is the end-all.

10

I'm no expert programmer, but I feel like I'm productive in Rust. In fact I'm probably more productive in Rust than in any other language at this point, even though it was about my fourth language.

I don't think that Rust's learning curve is actually that high when put in terms of everything that it does to help you learn. The compiler is often able to tell you exactly how to fix the code that you wrote. Running cargo doc gives you a great set of documentation for all of your dependencies 99% of the time, clippy helps you learn how to make your code more performant, idiomatic and robust, etc. The Rust Book is excellent. Rustlings is a great starter course to do along with reading the book. There's a great forum here and the discord server usually has someone who can answer questions, too.

I also don't really think of Rust as a low level language. Now don't get me wrong, you can do low level things with it, but for a lot of tasks you will never have to. When was the last time in Rust that you had to manually allocate a static buffer, and then free it later? In C that's pretty common, and I've done it in Zig too. Raw pointers? Nope, not really. Unless you're working on an embedded device with limited resources, an OS kernel or something so critical that it has to keep running even if an allocation fails due to out of memory you're probably never touching any of those concepts directly in Rust.

I can see where this post is coming from, but I would love to see a shift in the public perception that Rust is a difficult to learn low level language. For most of my work I treat it as if it were a high level language, with the exception that I'm also getting acceptable memory usage and speed.

7 Likes
11

Discussions about high level and low level languages often becomes a flame-fests simply because of that conflation: “high-level languages” == “sloppy langues” (which allow you to “kick the can down the road”) and “high-level languages” == “precise language”.

Which is, of course, nonsense because such approach would mean that something like Idris (which is extremely precise) would suddenly become a lower-level language than, IDK, Perl.

Sloppiness is not the only way to make language higher-level. And, in fact, in many cases it's even wrong way to make language high-level.

That's not just my opinion. Simple example: C++ core guidelines and it''s owner type. Type which is specifically and explicitly added to the support library to use it in place of simple T*.

Note: compiler treats it exactly like T*, it's recommended use is when you can not use std::unique_ptr<T> (C++ analogue to Rust's Box which was introduced in C++11) to make program easier to read!

To me the fact that Rust includes &T, &mut T, Box<T>, Rc<T>, Arc<T> makes it higher-level than other so-called “high-level languages“ which make it, basically, impossible to know who owns what.

Same with “three traits“: the fact that Rust have them makes it higher-level than, e.g., C++ which only have std::function which doesn't prevent you from calling closure which captures and destroys object many times.

P.S. What really astonishes me at times is the next step. When somehow another conflation is made: “high-level languages” == “safe languages” vs “low-level languages” == “dangerous languages”. Yeah, right. If they are “safe” then why for every bug in 50 million LOC in linux kernel, sql server and other components of typocal web service written in “low-level”, “dangerous” languages there are usually 10 or 100 bugs in 1 million LOC of Wordpress and plugins? Sorry, but all these “sloppy languages” are not safe, but, in fact, very dangerous. They remove one footgun which plagues C and C++ and then turn around and add dozen of other ones, new and exciting. To make iteration faster, yeah. But do we need these faster iterations if the end results in a buggy mess? That's not a rhetorical question BTW: I really don't know what's better — to be able to “close task in Jira” each day or to spend a week and finish writing the code? I suspect the answer would depend on many things.

1 Like
12

Rust is, importunately, difficult to learn. It forces you to think about things before your program may even start. Long-term it saves time, bu it makes it really hard to learn, initially.

2 Likes
13

I have to strongly and fundamentally disagree with such high level of generalization. I had no difficulty learning Rust at all because I had experience with C, C++ and Haskell. I have several acquaintances also coming from C++ and not finding the ownership-and-borrowing formulation difficult. In fact I encountered several design decisions in the language which struck me as just right and as something I didn't know was possible but it apparently is, in a beautifully-engineered way.

Personal experience varies. "Rust is really hard to learn" is not an absolute truth in itself.

6 Likes
14

I think it is important to acknowledge that while Rust may not be difficult for some to learn, for many it is quite difficult, in spite of the excellent docs, and I do appreciate that difficulty.

1 Like
15

I would say that it would surprise me if someone who knows so-called “Modern C++” and Haskell wouldn't be able to easily learn Rust: these two languages cover about 90% of difficult to grasp Rust areas.

I'm talking about more common case where someone comes from Java, Python, or even after Turbo C++ 3.1 courses (yes, they teach C++ in colleges using Turbo C++ 3.1, this package exist for that reason).

With that, more typical, background (or, better yet, when you try to learn Rust without knowledge of any other language… which is the most objective measure of difficulty) you are basically told to learn about ten new concepts simultaneously before you may write even very simple program.

Sure, if you would pass that “rite of passage” then other things become easier (although you, of course, immediately hit lots of very complicated corner cases, I was needed HRBTs which are considered so complex regular tutorial doesn't even mention their existence in my 2nd or 3rd program), but before you can be able to even cobble together some simple programs you must learn a lot.

While in Java or Python you can go pretty far even without understanding anything, just by gluing random pieces from Stack Overflow together and hitting “resolve” button in IDE… then looking on programs which you wrote and trying to understand them… in Rust that just doesn't work.

2 Likes
16

Thank you @VorfeedCanal @matklad and all people in the thread for your answer. Sorry, I have been unclear in my question.
I see discussion derive into Rust is a is a high level and productive language. And it is better to write directly entire program in Rust .I agree Rust is a high level and productive language. Here "productivity" and low/high language are a measure relative to other good language. I have change the definition of low/high level language in my question for easier express my idea, don't pay attention.

Why I say Rust is a low level language and no productive in my question? Because I have compared Rust to language like Ocaml,Haskell,Nim. Rust is lower level: in Rust, you should think about memory management every time, unlike with a GC language. This language also have a higher level abstraction. that the language paradigm is closer to the problem to be solved, the code contain zero low level logic. For instance use a advance metaprogramming language like Nim to create a DSL, and express the program really closer of problem to solve.
What I mean "productive". Here, the productivity is effort need to write/transformation/modification and read the program. Rust is maybe productive to write good program, but no productive to read.
I think Rust is less productive compare to this strongly typed and GC language. So some people will prefer to use this languages than Rust for more productivity.
For instance, I can see some people have swith Rust into Nim : We just switched from Rust to Nim for a very large proprietary project I've been... | Hacker News

I can see other reason people want use this languages.
For instance if they want a proof of program for critical code, the system need is coded in functional style.
Or if I want use Nim because it has a very advanced metaprogramming feature.
Or if I use python because I want use a python framework.

So, it exists languages better than Rust for some task. For such language, if it has C ABI compatibility. Is it better to wrapper around a Rust library?

The communication between language has an overhead cost, but Rust is more efficient. So maybe that compensate the overhead cost

Interlanguage add development complexity.
For instance, refactoring problem. But the wrapper library don't need to refactor the backend Rust lib.
The debugging is more complicate, you can't use the debugger for Rust lib. But I think it is technically possible implement such an interlanguage Rust debugger. The tooling ecosystem need time to develop.

If interlanguga with Rust doesn't slowe the program, except the development complexity of interlanguage. I don't see any other reason to redevelop a new ecosystem in this high level languages. Rust lib can become the backend lib for this languages.

17

I appreciate this comment and hope that others have a thoughtful pause when reading it as well.

I would agree that there is no one size fits all language, and there may well be situations where another language is useful. You mentioned Nim, and I have played around with it a little bit and found a few features that I really liked. And since Nim compiles to C, it is entirely possible to use it on platforms which Rust doesn't yet support. Obviously the syntax should significantly decrease the learning curve for Python users as well.

Which brings up a good point. I came to Rust with a certain amount of experience with C and a vague familiarity with C++ and found the syntax reasonably close enough to get a bit of a jump on learning. If you were coming to Rust from Python it probably looks very daunting.

At the end of the day I look at it this way. Some languages do indeed make it quick and easy to iterate something quickly. But after getting to a basically working state its going to take much longer to be sure that the program is sound, bug and vulnerability free and optimized than if you had just written it in Rust in the first place. Because Rust takes away a lot of overhead when it comes to correctness and let's you just focus on your program's logic.

1 Like
18

I have to call it out; it's hard to talk about "high-level" and "low-level" languages without bringing up this article: C Is Not a Low-level Language - ACM Queue

And this is the specific quote that I want to highlight:

Computer science pioneer Alan Perlis defined low-level languages this way:

"A programming language is low level when its programs require attention to the irrelevant."

Taking this definition into account, Rust would be considered a low-level language since it does have many instances where it forces an author to make decisions which are irrelevant to the problem being addressed. Choosing between types like the aforementioned T vs &T, &mut T, Box<T>, Rc<T>, Arc<T> is such a case.

On the other hand, David Chisnall argues in his article that though this definition also applies to C, C is not a low-level language precisely because it does not map well to modern hardware. But I'll stick with Perlis's definition and say that Rust and C are both low-level languages; They can both distract you from the task at hand (focusing on program logic) to make you consider how to model the problem in a way that is expressible in the language. This is different from considering how to model a problem in way that is expressible in something like Python, because Python has already decided what kind of pointer you will use. (And you probably cannot change it even if you wanted to.) These will be the kinds of modeling problems that Python shares with Rust and C.

Another point from that article which sticks out in my mind is the closing thought:

There is a common myth in software development that parallel programming is hard. This would come as a surprise to Alan Kay, who was able to teach an actor-model language to young children, with which they wrote working programs with more than 200 threads. It comes as a surprise to Erlang programmers, who commonly write programs with thousands of parallel components.

The actor-model language referenced is Smalltalk-72. Here's what Alan Kay himself had to say about their experiences with teaching children:

The children were chosen from the Palo Alto schools (hardly an average background) and we tended to be much more excited about the successes than the difficulties. In part, what we were seeing was the "hacker phenomenon," that, for any given pursuit, a particular 5% of the population will jump into it naturally, while the 80% or so who can learn it in time do not find it at all natural.

This is quoted from The Early History of Smalltalk (pg. 34-35). This paper is very much worth reading if you are interested in the topic of learning programming languages.

We should be able to draw a pretty clear conclusion here! Some of us fall into the 5% that find these things natural (even painfully obvious). The 80% will need to invest more energy into it, particularly building the library of fundamental knowledge (the literature as Kay put it) to work out solutions:

Namely, for the "80%," it really has to be learned gradually over a period of years in order to build up the structures that need to be there for design and solution look-ahead.

The remaining 15% are out of luck. :woman_shrugging:

I do think it would be very nice if Rust could make these kinds of decisions for us while remaining zero-cost. And I think that we should be open to breaking down the language barrier for the "80%". Perhaps not at the expense of the natural learners, but certainly to the benefit of the majority.

I also caution that looking at teaching Rust through the lens of "C++ programmer vs Python programmer" is not at all the right frame of reference. Some of the most brilliant and natural-programmer thinkers are people who primarily use Python. That doesn't mean they will have a hard time learning Rust. All things being equal, only about 80% of Python programmers will find Rust challenging, right?

4 Likes
19

I think before we may, meaningfully, continue, we should discuss history. Otherwise we would just go, endlessly, in cycles.

Difference between “high-level languages” and “low-level languages” goes back to a time 40-50 years ago. First generation programming languages — machine codes (yes, IBM 1401 had human-readable machine code and you write programs directly in it), second generation — assemblers (firmly ties to the architectures of a particular computer), machine-independent third generation, then fourth generation frees programmer from the needs to think about memory or pointers and with fifth generation programs are written by non-programmers and you no longer talk about code in terms which are specific to the actual hardware implementation of computers. Japanese businessmans take over the world without knowledge of English and history is altered permanently.

That was the vision. If it have been realized then we wouldn't need that talk about “high-level languages” or “low-level languages”. We would talk about 4GL or 5GL (or maybe even 6GL or 7GL).

But… it failed. Utterly and completely. Not only we haven't switched to the 5GL languages, we haven't actually embraced 4GL languages. Leaky abstractions, you know. We are still stuck with 3GLs and DSLs (which can not be, actually, considered 4GL languages because they are not general-purpose languages).

Nope. They allow you to model the problem in a way that is expressive in a computer. Not in any language, but in computer in general. In fact most of them would be needed if you would try to do the same calculations without a computer, just using pen and paper.

Yup. Python have conflated everything. Same as JavaScript and Ruby. Have that worked well? Well, proof is in the pudding, as they say: Python tries to backpedal, JavaScript backpedals, too and Ruby backpedals, of course.

If that's sloppiness is so valuable, if it's really a good thing not to know whether you own the structure or just borrow it, if the fact that function receives dictionary just to look some things there should not be expressed differently from the fact when function receives dictionary for modifications, then why alll sucessfull “high-level languages” eventually grow things like type annotations, const (it was added to C by C committee, it wasn't in K&R C) and Options (like Java Optional or C++ optional)?

The answer is obvious: lack of difference between &T, &mut T, Box<T> and Arc<T> doesn't make Python easier to use. it just makes it sloppier. Makes it possible to kick the can down the road so to speak. Push the decision to the further date. Which makes it a bit easier to learn (not easier to use). That's all.

Because, if you will think about it: &T, &mut T, Box<T> have the exact same representation on machine level. They are even sharing it with Option<&T>, Option<&mut T>, Option<Box<T>>. They are signifying the programmer's intent:

  • Box<T> — I own object T.
    Nobody else has access to it and I can do whatever I want with it.
  • &mut T — I was lended object T.
    While it's in my hands I can do whatever I want and nobody else would interfere.
  • &T — I can look on object T.
    Someone else may be looking, too, but since they couldn't change it while I'm looking… still easy.
  • Arc<T> — danger… shared ownership…
    Someone else may touch that object while I'm looking away. Have to read the documentation to know who, when and how.

Difference between Arc<T> and Rc<T> is not that important but, thankfully, can be ignored: just use Arc<T> everywhere and switch to Rc<T> when program would be fully finished (or maybe never, it's Ok, too).

Indeed. That's why have this proliferation of “sloppy languages”. The end result is, essentially, “the vicious cycle”:

  1. Because people couldn't grasp all the concepts needed to write good code simultaneously “sloppy languages”, “languages for non-software engineers” are invented.
  2. Then, if these languages become popular, larger and larger programs are written in these languages and these requirements (which are still requirements, the fact that it's not enforced by language doesn't mean it's not needed in principle) are understood. Style guides and linters are invented.
  3. Eventually someone says “enough is enough” and tries to add something to the language.
    Since it's not really possible to add it a clear way (existing millions lines of code were written without rules being enforced thus you can not just start enforcing rules unconditionally) and speed of the produced result is still low an attempt to bring “low-level” (but in reality just stricter) language is made.
    But ultimately it's easier to just use so-called “low-level” language because all parties involved have passed the barrier and no longer need to use “sloppy languages” (the few who created the majority of problems and steadfastly refused to learn anything would be fired and would go and tell everyone who may listen that everyone else conspired against them).
  4. New generation of developers arrive and we go to step 1.

And I think that we should be open to breaking down the language barrier for the "80%".

Why? Yes, it's serious question.

Software engineers are about 1.5-2% of US population (and less than that in the rest of the world). If 5% can easily grasp the concepts then there should be enough of them to not need general-purpose “sloppy languages” at all.

And for non-software engineers there are no need to have these “sloppy languages” in principle: you may give them DSLs which would be limited but would be easier to learn and use (precisely because they wouldn't be general-purpose).

Maybe, or maybe not. C++ programmers are special not because they have special attitude, but simply because so much of Rust already is in C++ (only in Rust compiler enforces rules while in C++ it's enforced in C++ standard and not in form “if you break these rules then you program would fail to compile” but in form “if you break these rules then program would turn into pile of goo”).

Haskell, similarly, covers significant percent of what Rust does (only the opposite, functional part: traits, type system and match, etc).

Python and Java also teach you some parts of what Rust requires, but because of their “sloppiness” certain concepts are not teached to all Python programmers (they are teached to some, obviously, if most python programmers wouldn't have used Python as statically typed language an attempt to bring type annotations to it would have been useless).

3 Likes
20

Do you really see that? I mean: today? Your link talks about something which happened more than seven years ago.

Biggest problem with Rust, even today, is the fact that it's unfinished. When you write code you constantly hit the limitations which are nightly-only features (if you are lucky) or just unimplemented RFCs (if you are not lucky).

That's misconception brought by the unfortunate names. You have to think about ownership and mutability, true, but after working with some projects in “high-level languages” I have come to the conclusion that it's, in general, bad idea to use these for anything but throw-away code. Precisely because they don't convey that information.

Heck, even in C I can use “rule of thumb”: const Foo* passes data into the function while Foo* is meant to pass data out. And that simple rule already covers 90% of the APIs.

With Python or JavaScript… the only way to read the documentation… and hope it does contain the answer.

Very often it doesn't and there are dozens of bugs in the bugtracker which can not be fixed and closed because that decision is not made.

I find it… less than ideal.

Seriously? Can you show me any other language which is easier to read? Because so far I have been finding Rust code the easiest language to read.

I often look of into source of standard library if I want to understand how you can express this or that concept and I'm yet to see anything I wouldn't understand (similarly to how I couldn't understand how certain pieces of Python standard library without reading articles and books).

Now, when you write code it may not always be easy, but usually it prevents me from spending time in debugger thus for me that's a good trade-off.

Well, I'm not saying Rust is perfect. It's macrosystem is very advanced, but yeah, it's compile-time reflection is sorely lacking.

But I think it would be better to add appropriate capabilities to Rust rather then try to add any kind of “sloppy language” to the mix to solve these issues long-term.

Short-term… yes, you may need to do that but the shape of the solution would be dictated not by properties of the languages per see, but by the availability of programmers with certain skillset and libraries in different languages.

I would say that if you have someone who knows Rust already and you don't have ready-to-use code in C or C++ then yes, it can be a good choice. If you already have code in C or C++ then the first question to ask is not whether it's hard or easy to interact with Python, but whether it's hard or easy to interact with the existing code in C or C++.

Interoperability between C and Rust is excellent. Between C++ and Rust… it's getting better, but for now it's limited.

Using header-only template-based C++ libraries (which are quite common in C++ world) is very hard.

P.S. The most hilarious relevant discussion which I ever saw was about Python and article named please don't use Python except for small scripts (internal one, sorry). It talks about how Python projects tend to cause problem once the principal author leaves and why, thus, it's not a good idea to wrote anything larger than what you can throw away and rewrite from scratch. Because such “rewrite from scratch” is always happening, sooner or later. But, initially, said article was noting one important exception, certain project written by Guido van Rossum himself. And for a few years discussion centered around that one exception. Then, after few years, when discussion started again and people, again, tried to understand why and how Guido managed to avert the fate there was a note from some newgrad which started with the more-or-less-the-following words: “I am a novice engineer and my opinion wouldn't matter much, probably, but as member of project which is rewriting that piece in Java I can say…” — but it wasn't important what was written after that, the most important part was already said.

1 Like