Why Rust Is the Future(scalac.io)
scalac.io
Why Rust Is the Future
https://scalac.io/blog/5-reasons-why-rust-is-the-future-rust-functional-programming/
69 comments
I used to mark assignments for a 4th year concurrency programming course taught in Rust. There were definitely a lot of buggy programs written in Rust like deadlocks, starvation, etc.
>> One of the biggest issues that are plaguing the developers are memory management issues.
> ...not an issue in any garbage collected language.
I pretty strongly disagree. It’s less of an issue in strongly typed languages but definitely null references and (arguably) type/encoding runtime errors are memory management issues much more common in garage collected languages.
What I love about Haskell (thousands of hours) and to a lesser degree rust (hundreds of hours) over most languages is that they are very expressive while at the same time the compiler catches what feels like 20x as many mistakes as I’d get from python or modern JavaScript.
Then it also runs faster, on a smaller footprint than most other stacks.
Both Haskell (and to a lesser degree) rust are much harder to learn than python/ruby/js but rust is probably on-par with c++ or java.
> ...not an issue in any garbage collected language.
I pretty strongly disagree. It’s less of an issue in strongly typed languages but definitely null references and (arguably) type/encoding runtime errors are memory management issues much more common in garage collected languages.
What I love about Haskell (thousands of hours) and to a lesser degree rust (hundreds of hours) over most languages is that they are very expressive while at the same time the compiler catches what feels like 20x as many mistakes as I’d get from python or modern JavaScript.
Then it also runs faster, on a smaller footprint than most other stacks.
Both Haskell (and to a lesser degree) rust are much harder to learn than python/ruby/js but rust is probably on-par with c++ or java.
Since you're comparing Haskell and Rust, what do you think about functional style programming in Rust? Can you do similar things in Rust as you can in Haskell or is the lack of GC limiting here? (I suppose that Haskell has important reasons to have a GC).
I guess I can't say much about it. I am barely past a beginner as far as Rust goes, but I have not seen much embracing a functional style.
In fact with the emphasis on (mutable) references vs values; it seems to pretty much encourage the antithesis of functional programming.
What I really love about functional programming is the simplicity of understanding what is going on from looking at the code; functional programming does that by guaranteeing a "function" is always-and-only acting in a specific, simple way. Rust does it (not quite as strictly to my learning-eye) with forcing the tediousness of references/mutability up to the signatures.
In fact with the emphasis on (mutable) references vs values; it seems to pretty much encourage the antithesis of functional programming.
What I really love about functional programming is the simplicity of understanding what is going on from looking at the code; functional programming does that by guaranteeing a "function" is always-and-only acting in a specific, simple way. Rust does it (not quite as strictly to my learning-eye) with forcing the tediousness of references/mutability up to the signatures.
> Rust deserves better promotion than such a fluff piece.
Agreed.
Agreed.
> Lol, yeah right.
It's a comparison with C++, where Rust is generally viewed as easier to learn. So OP has a valid point there.
It's a comparison with C++, where Rust is generally viewed as easier to learn. So OP has a valid point there.
About the Author:
"DARIA KARASEK Marketing Hero at Scalac. I strongly believe in creating opportunities rather than waiting for them to come. As befits Scalac team member I'm a hard worker, I always try to do the right thing and have a lot of fun! I'm an awesome friend and content writer, in that order. "
I imagine this kind of utter fluff would be entirely ignorable except when it is about Rust.
"DARIA KARASEK Marketing Hero at Scalac. I strongly believe in creating opportunities rather than waiting for them to come. As befits Scalac team member I'm a hard worker, I always try to do the right thing and have a lot of fun! I'm an awesome friend and content writer, in that order. "
I imagine this kind of utter fluff would be entirely ignorable except when it is about Rust.
+1. Why the heck are we upvoting and discussing the most generic content marketing fluff? It’s not like there aren’t well-written thoughtful pieces discussing Rust.
I'm a fan of Rust and this type of fluff shouldn't even make it on to the front page of hacker news. It's a clickbait title that's been editorialized as well.
I understand comparing Rust to C++ and Go, maybe even Java but Python? Python is a totally different niche and including it in this comparision kinda makes me question the whole articles intention and assessment.
This is indeed a superficial article:
> Rust vs Python: advantages
> Rust is well-designed. Rust allows for putting statements in a lambda and everything is an expression, so it’s easier to compose particular parts of the language. Python lacks it. Rust doesn’t have classes so the object orientation is not as evolved as it is in Python. Python also comes across with the necessity of writing more tests, production outages, or runtime crashes. Rust makes it less expensive to identify and fix possible bugs.
> Rust vs Python: advantages
> Rust is well-designed. Rust allows for putting statements in a lambda and everything is an expression, so it’s easier to compose particular parts of the language. Python lacks it. Rust doesn’t have classes so the object orientation is not as evolved as it is in Python. Python also comes across with the necessity of writing more tests, production outages, or runtime crashes. Rust makes it less expensive to identify and fix possible bugs.
Rust definitely has advantages for safety and correctness.
Those advantages come at a cost, specifically in terseness and readability, which are both _strengths_ of Python. As a result, they're very different tools, and comparing them shows that the author doesn't grasp their relative strengths and how those apply to their typical use cases.
Those advantages come at a cost, specifically in terseness and readability, which are both _strengths_ of Python. As a result, they're very different tools, and comparing them shows that the author doesn't grasp their relative strengths and how those apply to their typical use cases.
Python may be "terse and readable" when you're only dealing with very simple scripts, but the advantage quickly disappears in larger programs, where issues of modularization and, yes, correctness become paramount. It's choosing the wrong tradeoff in the first place. Rust makes the opposite choice, a small tradeoff in readability when starting out, in exchange for a long-term gain.
Not every project is large, there are plenty of things that don't need the burdens that larger projects place on the code to just get things done and get them done well.
I do agree that the article has issues, but I have found Rust to be a surprisingly good replacement for a lot of my Python use-cases. For example, I’ve been using actix-web and more recently axum for little servers that I would have previously written in Flask. I’ve also ported over some data munging jobs —- using serde feels like having superpowers.
And in tasks like these, I usually don’t even miss having a garbage collector, and rarely need lifetime annotations.
And in tasks like these, I usually don’t even miss having a garbage collector, and rarely need lifetime annotations.
Could you expand on this a bit? What did you like about the switch and what not?
Just in case: I didn't want to imply there are no use cases which overlap, only that in general the use cases for both languages are very different.
Just in case: I didn't want to imply there are no use cases which overlap, only that in general the use cases for both languages are very different.
I like how much the compiler helps me. I find it to be a tax on my productivity for about the first 1500 LOC of a project, but once I get beyond that, the compiler is an indispensable aid for refactoring in a way that Python’s type system (even with annotations) just isn’t rich enough to enable. For example, if I add a variant to an enum, my editor will immediately show me all the places that variant needs to be handled.
I find cargo more productive than Python’s package management, where I have to manually manage environments and requirements.txt files.
Things I like less: less “batteries included”, so I spend more time evaluating libraries and wondering if a github project hasn’t been touched since 2019 because it just works, or because the maintainer got bored. The learning curve is steep at times, and involved being blocked on pleasing the compiler.
I find cargo more productive than Python’s package management, where I have to manually manage environments and requirements.txt files.
Things I like less: less “batteries included”, so I spend more time evaluating libraries and wondering if a github project hasn’t been touched since 2019 because it just works, or because the maintainer got bored. The learning curve is steep at times, and involved being blocked on pleasing the compiler.
Thank you for your insights!
Actually the future is a language that best fits YOUR needs.
After many years of programming I agree with this so much. I know now that if I need to do heavy I/O and JSON work Node.js is a no brainier. Need concurrency with a fast execution/compilation within a single binary? Go is amazing in that regard. Need to stay on the Microsoft stack and interop with legacy APIs? C# will more than likely fit the bill. There’s just so many languages and they each excel at different things. I no longer have the mentality where one size fits all.
Heavy I/O in Node.js? And what the heck is JSON work and why can't any language do that?
And of course, Rust is not a one-size-fits-all language. For starters it doesn't have a garbage collector. But it is type-safe. And that alone will pay a huge dividend down the road if you choose it today.
And of course, Rust is not a one-size-fits-all language. For starters it doesn't have a garbage collector. But it is type-safe. And that alone will pay a huge dividend down the road if you choose it today.
Any language can do JSON serialization. Whether it's an enjoyable experience is another topic.
Having to deal with JSON in Go is a massive pain comparatively. It's just way easier to do it in Node.js. I'm having to do this kind of work right now, where I'm leveraging a third-party API that has horrendous JSON responses and I'm having to convert it to a normalized JSON structure so that I can use it within my own app. I keep wishing I would have just gone with Node.js instead of Go but now I'm too far deep.
By I/O, I meant that basically anything that requires you to wait for a response is really easy in Node.js. In particular handling HTTP requests is dead simple.
My point being that I'll pick different tools for different jobs. Go is really nice when I have little control over the environment and architecture, such as with AWS Lambda. The ability to compile a binary specifically for that architecture without needing to deal with `node-gyp` in Node.js is attractive to me. But I'll weigh the pros and cons of going with each of these different tools that I'm comfortable with.
Having to deal with JSON in Go is a massive pain comparatively. It's just way easier to do it in Node.js. I'm having to do this kind of work right now, where I'm leveraging a third-party API that has horrendous JSON responses and I'm having to convert it to a normalized JSON structure so that I can use it within my own app. I keep wishing I would have just gone with Node.js instead of Go but now I'm too far deep.
By I/O, I meant that basically anything that requires you to wait for a response is really easy in Node.js. In particular handling HTTP requests is dead simple.
My point being that I'll pick different tools for different jobs. Go is really nice when I have little control over the environment and architecture, such as with AWS Lambda. The ability to compile a binary specifically for that architecture without needing to deal with `node-gyp` in Node.js is attractive to me. But I'll weigh the pros and cons of going with each of these different tools that I'm comfortable with.
I totally get this. At the same time, as software developers we also need to be aware of industry trends, at least if we want to maximize our salary/career (whether you should do that is a whole different conversation). (Maybe this is a no-op comment if you expand what "YOUR needs" means.)
That means that you are looking at a few dimensions when determining what language to solve problems:
That means that you are looking at a few dimensions when determining what language to solve problems:
* can it solve the problem
* can I use it to solve the problem
* am I creating an issue by using it (for the team short term, for the company long term)
* how does using it make me a better developer
Which is why I look forward to spending the send half of the 2020's writing WASM by hand that gets JIT-compiled into machine code and then executed in the best implementation of Hypertalk I can get my hands on.
This whole thread (at the time of writing) ignores the hard part of dealing with large groups of people and interpersonal relationships. In such a context, what good does telling people to follow their heart do?
Yes, that's always the answer. Use the tool best suited for the task in front of you.
Which turns out to be Rust in an ever increasingly many situations.
Rust is going to eat into Java, C#, and Golang marketshare for services soon. The tooling for writing these is fantastic, and there's a single deployable binary with no GC.
Rust is going to eat into Java, C#, and Golang marketshare for services soon. The tooling for writing these is fantastic, and there's a single deployable binary with no GC.
Rust makes it way to hard to do anything practical with async, i find it hard to believe it would compete with those languages. If youre already in a situtation where you can already make do with gc whats there to gain by getting rid of it?
Sorry to burst this bubble, but all 3 languages you mentioned won't lose any space for Rust for backends. Rust can only dream to come close to have tooling as nice as C#, Go and Java. Productivity wise, Rust is just not as good as the other languages you mentioned.
async on Rust is a pain in the ass. For your hot path, sure use Rust, otherwise no one cares about a GC language as long as it's productive and can get the job done faster.
async on Rust is a pain in the ass. For your hot path, sure use Rust, otherwise no one cares about a GC language as long as it's productive and can get the job done faster.
How is async Rust a pain in the ass?
I've got actix handlers with various async database workloads, singleton LRU reloading caches, service calls, etc. It's a breeze. I'm no more productive in Java.
I've got actix handlers with various async database workloads, singleton LRU reloading caches, service calls, etc. It's a breeze. I'm no more productive in Java.
Huh?
Rust allows for putting statements in a lambda and everything is an expression,
so it’s easier to compose particular parts of the language. Python lacks it.
Rust doesn’t have classes so the object orientation is not as evolved as it is
in Python. Python also comes across with the necessity of writing more tests,
production outages, or runtime crashes. Rust makes it less expensive to identify
and fix possible bugs.
They're right that Rust is expression-oriented and Python is statement-oriented, and that expression-oriented languages allow for composing certain things more easily. I don't think it's a big deal, but it is correct.
I think the second point about classes/object orientation is... odd. I think they might not understand traits? Which is a pretty big thing to miss out on in a comparison like this.
The point about tests is probably to do with Rust having static checks (type-checking, borrow-checking, etc.) versus Python not having these. And although you can do some static checks in Python with external tools like mypy, the type system is less expressive and easier to coerce than Rust's, so I do think you'll end up with more tests out of necessity.
I think the second point about classes/object orientation is... odd. I think they might not understand traits? Which is a pretty big thing to miss out on in a comparison like this.
The point about tests is probably to do with Rust having static checks (type-checking, borrow-checking, etc.) versus Python not having these. And although you can do some static checks in Python with external tools like mypy, the type system is less expressive and easier to coerce than Rust's, so I do think you'll end up with more tests out of necessity.
Yes they're right about Rust being expression-oriented and allowing you to compose certain things more easily (in theory - in practice I don't see this being used a lot in Rust outside of match expressions). I read the overall comment as 'Rust is more expressive and composable than python' which doesn't feel correct - by design - mainly because of strong typing and safety checks. I didn't understand the statement about lambdas since to me Python and Rust lambdas are practically equivalent. It came across as if they read about Rust and Python without really being familiar with at least one of them.
> Python also comes across with the necessity of writing more tests,
production outages, or runtime crashes
This made me literally laugh out loud.
This made me literally laugh out loud.
In the past 5 years there’s been 1 rust job in my region of Denmark. It listed rust as a “nice to have”. I think it fares better in the Copenhagen region, but not by much.
This is not to rant on Rust, but betting on it having a brighter future than any of the other languages that came and went during the past two decades is probably a risky bet. Of course we’re lucky enough to be in a line of work where you can probably work with Rust for the next 50 years if you want to, but to “hype” it as the future language is just too silly and too vague for the front page of HN in my opinion.
I mean, Ruby was future, then Go was the future, now Rust is the future (add any other hyped languages you want, and here we are programming in JavaScript, Python, C++, JAVA, COBOL, PHP, C# and other “boring” languages that are probably older than some of the people who read HN, and that just isn’t likely to change much is it?
This is not to rant on Rust, but betting on it having a brighter future than any of the other languages that came and went during the past two decades is probably a risky bet. Of course we’re lucky enough to be in a line of work where you can probably work with Rust for the next 50 years if you want to, but to “hype” it as the future language is just too silly and too vague for the front page of HN in my opinion.
I mean, Ruby was future, then Go was the future, now Rust is the future (add any other hyped languages you want, and here we are programming in JavaScript, Python, C++, JAVA, COBOL, PHP, C# and other “boring” languages that are probably older than some of the people who read HN, and that just isn’t likely to change much is it?
> In the past 5 years there’s been 1 rust job in my region of Denmark. It listed rust as a “nice to have”. I think it fares better in the Copenhagen region, but not by much.
This is pretty much what killed me on it, and I think the leadership and community really don't understand that commodity development is important to language growth.
I like Rust and it opens up some interesting domains I don't get to play with much, but it's a considerable effort to learn it when I know there are zero real opportunities to use it professionally. I keep hearing hype about how this or that big giant company is using it, but none of them are hiring for it: it seems quite a few are just shifting internal C/C++ teams to Rust. The rare public openings are either a) demand extremely senior C/C++ level dev experience, or b) vague crypto/blockchain startups that reek of fly-by-night scams.
Far from the hope of "democratizing" systems programming, it seems like the industry has instead closed ranks around it and used it as a further gatekeeping tool to keep out entry or even journeyman level experience, and certainly anyone not already bathed in the old C languages.
I thought Rust was supposed to free us from C?
This is pretty much what killed me on it, and I think the leadership and community really don't understand that commodity development is important to language growth.
I like Rust and it opens up some interesting domains I don't get to play with much, but it's a considerable effort to learn it when I know there are zero real opportunities to use it professionally. I keep hearing hype about how this or that big giant company is using it, but none of them are hiring for it: it seems quite a few are just shifting internal C/C++ teams to Rust. The rare public openings are either a) demand extremely senior C/C++ level dev experience, or b) vague crypto/blockchain startups that reek of fly-by-night scams.
Far from the hope of "democratizing" systems programming, it seems like the industry has instead closed ranks around it and used it as a further gatekeeping tool to keep out entry or even journeyman level experience, and certainly anyone not already bathed in the old C languages.
I thought Rust was supposed to free us from C?
> and other “boring” languages that are probably older than some of the people who read HN
I can't remember who said this, but "use boring technology" is a well used strategy. Why take the risk with a new programming language when they old ones are well understood and offer a large hiring pool?
I won't be taking the time to learn rust until the jobs are there for them. It's a chicken and egg problem I know.
I can't remember who said this, but "use boring technology" is a well used strategy. Why take the risk with a new programming language when they old ones are well understood and offer a large hiring pool?
I won't be taking the time to learn rust until the jobs are there for them. It's a chicken and egg problem I know.
I think Rust is the future for performance sensitive applications certainly. For applications where performance doesn't matter or where you don't plan to use parallelism it isn't. I will say I think any language without some form of algebraic data types is dead in the water.
Any language I choose to use today has to have sum types and protection from null pointer errors, anything else is just not acceptable.
Any language I choose to use today has to have sum types and protection from null pointer errors, anything else is just not acceptable.
Flagged, as the article could be generated by GPT-3. A superficial "analysis" that provides no insight.
A bit too fanboy, perhaps.
After over a year of Rust, writing a client for a virtual world, I'm moderately happy with it. But not uncritical.
- The safety system is quite good. I haven't had to use a debugger on my own code. The one time I needed a debugger, the problem was unsafe code in a library I was using.
- Some kinds of data structures are difficult in Rust. Rust tries to be a functional language, sort of, in that it favors move semantics. If your problem really does involve complex in-memory state (I have a big 3D world to manage) there are substantial pain points. The lack of back pointers is a big problem. It's possible to work around this with reference-counted forward pointers and weak reference-counted back pointers. But the borrow checker doesn't help with that, and you can fail on double-borrow or double-lock situations at run time. When that occurs, it usually means a sizable redesign is needed. What's needed is single ownership with safe back pointers and compile time checking. This is a tough theoretical problem, because you have to prevent double mutable borrows by static analysis, but some people are thinking about it.
- When you've painted yourself into a corner in data structure design, it's often tempting to use "unsafe" to get out. I see too much of that in libraries. I don't use "unsafe" at all in my own code, and now and then I have to go and rewrite something to avoid it.
- Rust is overkill for many applications. Especially web services. For most web back-end stuff, Go is easier. Go also has all the libraries for web back-end stuff, mostly written and used by Google. So they're well-exercised and debugged. Also, goroutines, which are lightweight but preeemptable, avoid the problems of "async", where you have to be very careful about not being compute-bound for too long.
- After a lot of churn in the early years, error handling seems to have settled down to something reasonable.
- The "async everywhere" crowd needs to be restrained from making "async" mandatory in libraries. Their model is mostly applicable to web back-end systems where a large number of slow concurrent sessions have to be handled, those sessions don't interact with each other much, and there's not too much compute-bound work. Not everything is web back end.
After over a year of Rust, writing a client for a virtual world, I'm moderately happy with it. But not uncritical.
- The safety system is quite good. I haven't had to use a debugger on my own code. The one time I needed a debugger, the problem was unsafe code in a library I was using.
- Some kinds of data structures are difficult in Rust. Rust tries to be a functional language, sort of, in that it favors move semantics. If your problem really does involve complex in-memory state (I have a big 3D world to manage) there are substantial pain points. The lack of back pointers is a big problem. It's possible to work around this with reference-counted forward pointers and weak reference-counted back pointers. But the borrow checker doesn't help with that, and you can fail on double-borrow or double-lock situations at run time. When that occurs, it usually means a sizable redesign is needed. What's needed is single ownership with safe back pointers and compile time checking. This is a tough theoretical problem, because you have to prevent double mutable borrows by static analysis, but some people are thinking about it.
- When you've painted yourself into a corner in data structure design, it's often tempting to use "unsafe" to get out. I see too much of that in libraries. I don't use "unsafe" at all in my own code, and now and then I have to go and rewrite something to avoid it.
- Rust is overkill for many applications. Especially web services. For most web back-end stuff, Go is easier. Go also has all the libraries for web back-end stuff, mostly written and used by Google. So they're well-exercised and debugged. Also, goroutines, which are lightweight but preeemptable, avoid the problems of "async", where you have to be very careful about not being compute-bound for too long.
- After a lot of churn in the early years, error handling seems to have settled down to something reasonable.
- The "async everywhere" crowd needs to be restrained from making "async" mandatory in libraries. Their model is mostly applicable to web back-end systems where a large number of slow concurrent sessions have to be handled, those sessions don't interact with each other much, and there's not too much compute-bound work. Not everything is web back end.
> Also, goroutines, which are lightweight but preeemptable, avoid the problems of "async", where you have to be very careful about not being compute-bound for too long.
You know what else is lightweight and preemptable? Threads. Yes, really. Unless you're on weird platforms like Windows, you can just use threads.
> making "async" mandatory in libraries
AIUI, Rust includes a simple `block_on()` feature so that you can use any async library in a sync context. The old "function color" issue is greatly mitigated in Rust.
You know what else is lightweight and preemptable? Threads. Yes, really. Unless you're on weird platforms like Windows, you can just use threads.
> making "async" mandatory in libraries
AIUI, Rust includes a simple `block_on()` feature so that you can use any async library in a sync context. The old "function color" issue is greatly mitigated in Rust.
[deleted]
Ive started writing shared libraries in Rust instead of C++, especially for mobile applications.
Aside from that, I don’t believe Rust is the future. Rust is not the language for prototyping and iterating quickly. I’ve been writing Rust for 1.5 years now, and I still deal with a lot of issues wrestling with the compiler and borrow checker and dealing with lifetimes.
That article comparing Rust to Java - that Rust being simply faster - that somehow making it the future - this is laughable. Not every piece of code is trying to optimize for speed. And a decent chunk of code many people write doesn’t require advanced C++ knowledge. It’s actually faster to learn C++ IMO than Rust for these use cases.
I do enjoy writing Rust. The IDE support has gotten much better. The documentation is “good”. There are really good libraries too.. which is super critical imo.
But saying Rust is the “future” and comparing it to Python or Java is funny.
I tried writing a linked list in Rust and my first thought was “wtf”.
Aside from that, I don’t believe Rust is the future. Rust is not the language for prototyping and iterating quickly. I’ve been writing Rust for 1.5 years now, and I still deal with a lot of issues wrestling with the compiler and borrow checker and dealing with lifetimes.
That article comparing Rust to Java - that Rust being simply faster - that somehow making it the future - this is laughable. Not every piece of code is trying to optimize for speed. And a decent chunk of code many people write doesn’t require advanced C++ knowledge. It’s actually faster to learn C++ IMO than Rust for these use cases.
I do enjoy writing Rust. The IDE support has gotten much better. The documentation is “good”. There are really good libraries too.. which is super critical imo.
But saying Rust is the “future” and comparing it to Python or Java is funny.
I tried writing a linked list in Rust and my first thought was “wtf”.
> Rust is not the language for prototyping and iterating quickly.
You might think so, but that would be overlooking one key advantage of using Rust for iterative prototyping: you don't have to worry about a hacked-together prototype being used in production! Stuff like that happens all the time, and relying on a language like Rust with its focus on safe refactoring can be a life-saver.
You might think so, but that would be overlooking one key advantage of using Rust for iterative prototyping: you don't have to worry about a hacked-together prototype being used in production! Stuff like that happens all the time, and relying on a language like Rust with its focus on safe refactoring can be a life-saver.
Im wondering if rust has broken out of just being a thing for passionate users yet? Like how is rust working for people who program but aren't programing language obsessed nerds, people who don't "love" languages. I work with c++ at work, 1 or 2 seem to be passionate about rust, but the rest seem ok with c and c++. I guess it seems like there an echo chamber?
Also this article seems to just be pandering and rehashing common thoughts already. Like yeah its safe and no gc. We know this? I guess its weird timing how did this end up in the #1 spot.
Id like to hear more rational, neutral, non-biased thoughts about rust and its use. I know they're out there, Ive heard these kinds of opinions about rust in real life conversations, I dont think they're out their blogging, if they are idk especially critical things are being put out there. Rust users still seem to really evangelize it
Also this article seems to just be pandering and rehashing common thoughts already. Like yeah its safe and no gc. We know this? I guess its weird timing how did this end up in the #1 spot.
Id like to hear more rational, neutral, non-biased thoughts about rust and its use. I know they're out there, Ive heard these kinds of opinions about rust in real life conversations, I dont think they're out their blogging, if they are idk especially critical things are being put out there. Rust users still seem to really evangelize it
Its all very well writing an evidently biased blog as to why Rust is the future.
However, the elephant in the room is Rust's sheer complexity.
I will give you my anecdotal experience ...
About two years ago, I was getting tired of shell scripts. Not because I didn't know how to write them properly, but because it was always invariably a messy kludge of fixes and hacks strung together in a safe(ish) manner.
Python, the cool-kid of the day was ruled out. Both for personal reasons (I think the space-sentsive nature of Python is dumb), and for practical reasons (dependencies in python is a mess).
So it was between Go and Rust. Both of which could compile into cross-platform dependency-free binaries for ease of distribution around infrastructure.
As it happens, I had a Real World (TM) project, and so what better opportunity than to hack together some spaghetti code for a proof of concept.
My first call was Rust. I wanted to like Rust, I really did. But I found it simply impenetrable as a language, hard to make progress, even in "spaghetti" mode. "The book" was well written, but it was hard to translate it into "real world". I also disliked the "everything is a dependency" and really felt a lot more should be included in "core".
I then went to Go. With Go, I found an approachable language with a more substancial "core" library. The tooling was good (even better with GoLand IDE). And I was able to hack together a not insubstancial "spaghetti" project in less than a week, which then encouraged me to start learning how to tidy it up into something more professional looking.
Yes, Go is not perfect, e.g. I particularly dislike the repetitive and verbose error handling ("if err !=nil") and can't help feeling there could be a "better way". But now I've done a number of projects with it, using all sorts of complexities such as cloud and crypto, I feel Go's benefits outweigh any minor disadvantages.
However, the elephant in the room is Rust's sheer complexity.
I will give you my anecdotal experience ...
About two years ago, I was getting tired of shell scripts. Not because I didn't know how to write them properly, but because it was always invariably a messy kludge of fixes and hacks strung together in a safe(ish) manner.
Python, the cool-kid of the day was ruled out. Both for personal reasons (I think the space-sentsive nature of Python is dumb), and for practical reasons (dependencies in python is a mess).
So it was between Go and Rust. Both of which could compile into cross-platform dependency-free binaries for ease of distribution around infrastructure.
As it happens, I had a Real World (TM) project, and so what better opportunity than to hack together some spaghetti code for a proof of concept.
My first call was Rust. I wanted to like Rust, I really did. But I found it simply impenetrable as a language, hard to make progress, even in "spaghetti" mode. "The book" was well written, but it was hard to translate it into "real world". I also disliked the "everything is a dependency" and really felt a lot more should be included in "core".
I then went to Go. With Go, I found an approachable language with a more substancial "core" library. The tooling was good (even better with GoLand IDE). And I was able to hack together a not insubstancial "spaghetti" project in less than a week, which then encouraged me to start learning how to tidy it up into something more professional looking.
Yes, Go is not perfect, e.g. I particularly dislike the repetitive and verbose error handling ("if err !=nil") and can't help feeling there could be a "better way". But now I've done a number of projects with it, using all sorts of complexities such as cloud and crypto, I feel Go's benefits outweigh any minor disadvantages.
>>> Python, the cool-kid of the day was ruled out. Both for personal reasons (I think the space-sentsive nature of Python is dumb), and for practical reasons (dependencies in python is a mess).
You can use pyinstaller or Nutika for python. I've used pyinstaller but I'm not sure of the cross platform part of pyinstaller. I have not tried Nutika out (hopefully soon). Pyinstaller creates a binary with the python executable in it. Nutika compiles to native binary code. Either way you have a single file to deploy and run.
You can use pyinstaller or Nutika for python. I've used pyinstaller but I'm not sure of the cross platform part of pyinstaller. I have not tried Nutika out (hopefully soon). Pyinstaller creates a binary with the python executable in it. Nutika compiles to native binary code. Either way you have a single file to deploy and run.
If your choice of language is restricted to what you can learn to use in a couple of hours your options will be limited and sub optimal. So yes, if you don't know Rust and you only have 2 hours to learn the tool you need for the job Rust is a bad choice.
However if you are planning to program as a career and building software is your trade, Rust is an excellent choice. Rust helps you build programs that are correct. Go lets people that expect languages should be able to be learned in an afternoon program.
However if you are planning to program as a career and building software is your trade, Rust is an excellent choice. Rust helps you build programs that are correct. Go lets people that expect languages should be able to be learned in an afternoon program.
The article is very one sided.
Saying that Rust is better than Python because "Rust is well designed" is a bit of a fallacy.
Specially since these are languages that serve very different purposes and have different priorities.
Saying that Rust is better than Python because "Rust is well designed" is a bit of a fallacy.
Specially since these are languages that serve very different purposes and have different priorities.
There are many biased yet interesting blogs and talks about how Rust is the future of programming for domain XYZ. This article is not one of them. Breathless 90's-era posts about how Java and OOP will save the world look tame compared to BS contained in this article. I don't think this kind of argumentation is good for Rust or its potential users. God save the poor souls who are forced into Rust for no reason other than their CTO stumbled upon this article and was convinced of the hype.
Title editorialization... The actual title is "5 Reasons Why Rust Is The Future" which is a clickbait article title and if people knew that they wouldn't click it.
Not a really well-written (or well researched) article. One example:
> It’s now used to create web software, embedded computers, and distributed services or the command line.
What does this phrase want to tell us? "Web Software"? Do they mean Firefox? Or web development (which is not the main strength of Rust AFAIK, so it's strange to mention it first)? And it gets even stranger: create embedded computers - just with a programming language? Create [...] the command line? Whaaaaaat?
> It’s now used to create web software, embedded computers, and distributed services or the command line.
What does this phrase want to tell us? "Web Software"? Do they mean Firefox? Or web development (which is not the main strength of Rust AFAIK, so it's strange to mention it first)? And it gets even stranger: create embedded computers - just with a programming language? Create [...] the command line? Whaaaaaat?
"it is believed that it also finds its usage for 3D video games."
There is not a single popular game that shipped any Rust code. Actually I would extend that to "any" game.
There is not a single popular game that shipped any Rust code. Actually I would extend that to "any" game.
I'll stay with perl, it has lasted for 34 years [0], and many "languages for the future" came and went in the meantime, and even with the surviving ones, most of the code won't run on modern versions, and most of the current code wont run on the future versions.
[0] https://news.ycombinator.com/item?id=29602635
[0] https://news.ycombinator.com/item?id=29602635
Thanks, but a content marketing article by a “Marketing Hero at Scalac” is probably not the most trustworthy source on the future of software engineering.
> Rust vs Python: advantages
> Rust is well-designed.
I was just reading Fluent Python 2ed[1] and pondering what a zany grab-bag of features we have in Guido's Folly.
[1] https://www.amazon.com/Fluent-Python-Concise-Effective-Progr...
> Rust is well-designed.
I was just reading Fluent Python 2ed[1] and pondering what a zany grab-bag of features we have in Guido's Folly.
[1] https://www.amazon.com/Fluent-Python-Concise-Effective-Progr...
This will be a much weaker argument after the Go 1.18 release with generics. Should have argued performance.
> Rust vs Go: advantages
> Go lacks expressiveness. Rust has a flexible and expressive system that allows for defining new container types that can hold different types of elements, generics, traits, algebraic data types. Go gives you less control over both resources and memory.
> Rust vs Go: advantages
> Go lacks expressiveness. Rust has a flexible and expressive system that allows for defining new container types that can hold different types of elements, generics, traits, algebraic data types. Go gives you less control over both resources and memory.
And it sounds pretty biased too. Sure, in Go (and other garbage-collected languages) you have less control over resources and memory, but you know what? Sometimes you don't want to worry about resources and memory! And, for most real-world applications, the small performance hit caused by not having this total control is more than acceptable...
If you think generics are going to solve the problem with expressiveness in Go you are sadly mistaken. How do you declare a type that is either type A or type B? Something as basic as that is impossible in Go.
Rust certainly is promising but it will not replace all other languages. Is Rust a better choice than C or C++? Probably. Java, Go, or Python? I don’t think so. Rust has flaws:
1. It is hard to learn. A novice will pick up something like Python much faster
2. It is less productive. You “fight” the borrow checker in Rust and have long compilation times.
1. It is hard to learn. A novice will pick up something like Python much faster
2. It is less productive. You “fight” the borrow checker in Rust and have long compilation times.
Warning: completely one-sided article. Is HN supposed to provide the other side of it?
[deleted]
Wake me up when they have a GUI (not because of the GUI per se but because of the difficulties in how to design such a library given that it has to be ergonomic besides just efficient).
Quite an achievement to write an entire article about why Rust is the future without ever mentioning one of the main advantages of the type system which is data race freedom.
I was going to up-vote because I work with Rust and am invested in it professionally, but I didn't because the title is click-bait and article unsubstantial.
[deleted]
> Rust is simply easier to approach, the learning curve is not very steep
Lol, yeah right.
> One of the biggest issues that are plaguing the developers are memory management issues.
...not an issue in any garbage collected language.
> some areas it may run even three times faster than Scala or Java
Statements like this are almost completely useless. Rust isn't automatically fast, and Java isn't automatically slow.
> it lets you write code that will most likely never go wrong as the compiler is there to check it all
Oh please...
> Rust is a popular programming language for cryptocurrencies and blockchain.
What, no AI?
Rust deserves better promotion than such a fluff piece.