Should one learn Rust, lets say after 3-4 years, i.e by mid 2020s, once it becomes more mainstream? The syntax of Rust is a mix of OCaml/C++ and I feel some of the concepts are very esoteric for a normal enterprise Java/C#/JS/Python developer, so it takes a lot of cognitive overload to master it. So is it worth learning now or later?
Personally, I'd say it's worth it now. I've been dabbling in Rust for a few years and while I still don't get to use it at $DAYJOB it's been a huge benefit to me. Those "esoteric" concepts have bled into other languages and my usage of them, making me a better programmer overall. Read a chapter of "The Book" once a month or so over the next 3 years and I wager you'll find yourself in a better place than had you waited 3 years to start.
After doing a couple of projects with it, I have found that learning Rust is an exercise in futility. I wish I had never heard of Rust. What will happen is you'll immediately recognize it as the greatest language ever invented and you'll want everyone else to know about it. You will try to convey what it is about Rust that makes all other languages obsolete, but they will look at you like you're a crazy person. You will be ostracized and considered a lunatic. You will lose all your friends. They will say you are part of a cult now and you will eat your lunch at a separate table. You have seen nirvana and will never be satisfied again with doing your old Python or JavaScript job. After doing a few projects in Rust, yet unable to convince your non-programmer managers why they should convert to it, doing your old job no longer brings the joy it once did. You will stop shaving and grow a long beard. Because using non-Rust languages is basically the same as living in the past. The world has lost all its color. The future is Rust, and yet the business world is too conservative, or too afraid, or too incurious to make the leap. This is how I feel about learning Rust right now.
I can relate, i learned React in tandem with ReasonML. The first job working with TypeScript felt like watching paint dry. Awesome languages can spoil you.
> I feel some of the concepts are very esoteric for a normal enterprise Java/C#/JS/Python developer
This notion is common among those who are first considering Rust, but also quite overblown in practice. The only thing that reasonably qualifies as "esoteric" in Rust is borrow checking and lifetimes, and these can be mitigated by using very simple idioms/patterns like cloning objects via .clone() or using copy-on-write via Cow<>.
You can then code with much the same convenience as e.g. Python, Java or C#, but it's also very clear where some potential gains in performance have been left off the table for the sake of rapid development.
Disagree - a low level language can’t really mask itself as high level, the abstraction will always leak. Don’t get me wrong, Rust is a really great language and it is a very welcome addition to the for a long time seemingly stagnant low level world, but you won’t be able to refactor logic-related parts “without a thought” on memory layout, even ownership, etc —- something trivially done in high level languages. C++ tried the same thing, without luck.
So for a typical CRUD app, just use one of the litany of high level language frameworks and be done with it.
For many, learning the low-level aspects of programming is the attraction of learning Rust. They want to be exposed to these concepts. What Rust does well is creating a golden pathway with guard rails through which one can learn these concepts without exposing oneself to the pitfalls of memory safety issues, thread safety issues and undefined behaviour.
Ah I see. My personal take is that while Rust introduces some inconveniences not present in those languages, those languages also have plenty of inconveniences that are not present in Rust. From my perspective, enums and traits are so much better than classes as abstractions that most of the productivity lost is already made back.
Rust is a very well designed language no doubt, but I think maintenance is where high level languages have an upper hand in some domains.
Also, there are plenty of high level languages with traits, eg Haskell, but if you prefer one where it is easier to express things optionally with an imperative/OOP mindset, Scala.
> but you won’t be able to refactor logic-related parts “without a thought” on memory layout, even ownership, etc
This is sort of true, in that I might take reference where I used to take a value, or vice versa, but it's pretty trivial. It's extremely rare for borrow checking or memory layout to slow me down at all when refactoring.
Actually, once you get used to Rust, what you “loose” on one side of the productivity (ownership/lifetime/dispatch) you gain on the other side with the ergonomics (enum, matches, expression, …). So our experience, is that at the end, you still a net positive on the productivity side plus the other benefits.
We started to rewrite some of our smaller js/TS utilities, ~3k LOC, and surprisingly Rust was 10% to 20% smaller. Not that it a relevant metric, but still, we were expecting the opposite.
The missing part compared to other languages is specialization, but other patterns can be used. Still, would be nice if they add a good sound specialization construct (min_specialization seems to come short so far)
The biggest challenge is to train a full team on Rust.
It varies widely based on the type of app. Most simple apps using standard lib or a few basic crates/packages/gems/etc can indeed be switched over without too much fuss. But if you're using any large frameworks with a ton of dynamic features that dictate the structure of your application, such as Rails or Django, then it's hopeless, it'll need a complete rewrite with major architectural changes.
I actually find Rust easier to refactor Rust code than my other $DAYJOB languages, thanks to its strict type system, its informative function signatures, and its syntax. These are ingredients that make Rust programming "fearless".
> the concepts are very esoteric for a normal enterprise Java/C#/JS/Python developer
I on this space and found Rust to be a great boost in my ability to ship code with FAR lower debugging (post-deployment) and hosting cost (can pay for half for more than 4x the amount of load, and not even doing a lot for improve things).
Rust is already "mainstream-ish" and the amount of libraries and stuff is becoming better and better. So, I don't see any point on "wait".
Sure, it will be challenging! But the benefits are too nice to pass of, I think.
As somebody who's worked mostly in very high level "loosey goosey" languages (Ruby, JS) for several years, I had a lot of fun learning Rust. I've still only used it for trivial things but it's an eye opener.
When I was in college, they taught C++ as the programming language (dating myself here...). I walked away with enough negative feelings about it that I thought I just hated strongly typed programming languages that lacked garbage collection, and I thought I hated compilers that spewed errors all the time, and so I gravitated towards things like Python and Ruby.
Rust has proven that I was wrong about myself. I really enjoy working with it - rust has many of the same features but dramatically modernized, and it solves so many ergonomic nightmares that I remember from C++.
With rust I find that entire classes of mistakes I can make with Ruby are straight up impossible because the compiler won't let you get away with it.
If you were scarred by C++, give it a shot, and it may erase some of those old battle scars.
Rust is great as a hobby language, as it tickles some previously unutilized brain patterns.
I don't think it's a great replacement for Java/C#. Unless your problem is GC pauses, either language will let you be more productive even when you master the borrow checker simply because their ecosystems are much richer.
I can imagine AAA game engines slowly migrating from C++ to Rust, but enterprise applications are already fast enough in 99.9% of the cases.
Enterprise applications are already fast enough, but memory footprint can still be a real pain. Monitoring and deploying the JVM isn't easy, and I think there is absolutely room in the future for lower footprint deployments in the enterprise space. Golang has already seem some limited adoption, but has a limited type system that doesn't easily allow expressing complex business logic. Rust has the possibility to really shine here, even if it doesn't eat the enterprise world.
The Rust "ecosystem" can seamlessly expand to include any language with a C ABI and FFI. Solutions are also being developed to ease interop with managed platforms like Java/C#.
Contrast this with something like Go, where even interoperability with C does not come out-of-the-box and requires compromising the most desirable features in the language itself.
Can be, yes. Seamless, no. In the best case where the api uses very old fashioned c without many pointers it's an extra afternoon at least. (I've written high level bindings for a few small libraries for hobby projects)
There's no "language to rule them all". Java already tried and almost ruled the world, but reality is that with options languages take here and there to whats important to them, they will never expand to a certain level.
Languages compete in their axes, which for me there are mainly 4 big ones:
I've never seen a language ruling in two axes at the same time (as in you can use it for the same goals), let alone in all four, or at least three.
The a' axis are very hardcore languages with insane amount of control, but they will never be as productive as the b' and c' axis.
Meanwhile the b' axis is the most popular one, as they allow you to create big and complex application while being productive. Their runtime are not far away from the languages on the a' axis.
The c' axis is most productive and easy to pick up, with languages that feels more natural, but they dont have the performance of the a' and b' axis and also its hard to compose big applications on them unlike the a' and b' axis.
Maybe a successor of languages like Rust and Swift might be the on to do this, but i cant hardly see Rust in that position because programming in it have more or less the kind of productivity that C++ gives you.
I relax much more when i can write something in Swift instead of C++ or Rust for instance, and i would mostly choose it given the perfect match to the problem i'm solving.
I think we are going for a more polyglot world, not less, and i mostly use C++, Swift and Python when i can, where you can replace C++ for Rust, Swift for C# and Python with JavaScript according to your personal tastes.
But using something from one axis trying to reach for the goals better served in another axis is mostly a "when all you have is a hammer.." kind of paradox.
I think you are way overthinking my comment. I just added a note that for regular, user-space applications there really is no longer a reason to use low-level languages even if latency is important.
Of course embedded will always exist, as well as specialized programs requiring utmost control over the machine.
I don't see any such note and it's 8 days later. May be you should check your comment again? Also, while games aren't exactly regular applications performance-wise, I think they fall more under that than embedded or utmost control and while a 1ms delay won't be the end of the world, it'll likely hurt.
Whether you should learn it or not I can't answer, but I want to mention that I personally don't feel anything in Rust is very esoteric. Python's metaclasses or JavaScript's prototype object model feel more unusual to me than anything I encountered in Rust. If you have never written in an unmanaged language like C++ though I could see that a lot of Rust feels foreign.
C++ developers deal with lifetimes all the time (grep for "outlive" in a large codebase, for example). It just isn't baked into the language.
The notion of the "lifetime" is fundamental to systems programming, particularly when dealing with concurrency. It's quite natural to folks who are used to dealing with use-after-free/use-after-move and iterator invalidation bugs, imo.
I would say definitely yes. While Rust asks the developer to worry about things they don't in other "memory managed" languages, its ergonomic and expressiveness add to the productivity. Once you get used to Rust, it becomes a net positive from a productivity side; at least this has been our experience, and you get a much more efficient and robust codebase.
However, here are the following caveats:
- If you have a client or employer project to do now, and you are not yet familiar with Rust, do it with your language of expertise. Rust has to be learned before starting a new real project with it.
- The real challenge is the cost to train an entire team on it.
- Obviously, universal languages do not exist, so if you do AI, especially modeling, use Python (for now), web stuff use JS/TS, mobile stuff, Kotlin | Swift | Dart/Flutter. You can do some Rust on mobile and even web with WASM, but those are very niche use cases.
I learned rust just before 1.0. Probably one of my best decisions as an engineer. I now run a company where we're using it as the primary language for our services.
Many people report that learning rust made them a better C++ programmer (because the kind of habits rust enforces are things which good C++ programmers do to avoid memory problems). I would expect this would work with C as well to some degree. In that sense it may be worth learning even if you never really use it professionally.
I've enjoyed learning Rust and there is is a lot I like about it, I've just been doing leetcode problems with it though and not working on large projects. In my view, the biggest advantages and steps forward with Rust the language are:
1. Memory management
2. Typing
I think your listed languages all have Garbage Collection? It will probably take quite a bit of mental effort to get comfortable with memory management in Rust but it is a valuable topic if you want to understand performance and language runtimes.
I've started learning it in March when the pandemic hit and I lost my job, so I had free time. I just started by making a side project, a static site generator of course. Now at my current job I was able to use Rust for an IoT data acquisition project, and feel like I'm more productive than I am with C++, which I have 20 years of experience with.
The other day the partner company which is using the output of my software admitted to me that they are chasing some weird heap corruption error in QtCore.dll, and therefore cannot hit a deadline.. I was relieved that this is a thing of the past for me now.
When I run into a memory error now, it's somewhere in the unsafe code blocks I have in the wrapper around the shitty C libraries by other partner companies, that didn't document the conditions of their API properly.
You can spend the time on it since you will make it up by not having to worry about your awful C++ dependency/build system which is the language targeted by rust to replace (/complement) ;)
If you consider GitHub to be a reasonable metric of industry practice in general, then judging by these charts [https://madnight.github.io/githut/#/pull_requests/2021/1], I would say that going mainstream in a couple years is not very likely at all. Tiobe [https://www.tiobe.com/tiobe-index/] paints a similar picture. The number of Rust-specific jobs advertisements also don't seem to suggest a coming wave that employers are trying to get ahead of[https://www.dice.com/jobs?q=rust&countryCode=US&radius=30&ra...]. I'm not aware of any real success stories with the language, either, unlike Go and the CNCF ecosystem that's the latest fashion right now. There are rewrites of GNU coreutils (ripgrep, bat), a couple components in already commercially successful software (Dropbox, Discord), a couple side-projects within large companies (fuschia OS, FirecrackerVM) and I guess terminal emulators are a big focus. You could say the same of Haskell, which is very cool, but is not going to be an industry standard in the foreseeable future.
One way to think about it is that the big wave of new languages like Go, Rust, Elixir and Kotlin all sprang up around 2010. At that time, C99, C++03, Java 6 or C#2 were probably what you would have been using (honorable mentions to Python 2.7, PHP 5, and Ruby 1.8). The new languages were perceived solutions to the limitations of the mainstream languages; however, today, very many of the new features and the old points of frustration have already been addressed within these same 'boring' mainstream languages. Java 16, C# 8, and C++20 are vastly improved and have (or will soon have [check out Loom for Java!]) almost all the conveniences the new-wave offered without having to throw old programs in the bin and reimplement entire ecosystems. C++ and Rust are also so similar in terms of semantics and memory model, that I really don't see the value proposition of walking away from huge, mature projects like Qt for academically interesting type algebra. There have been some ambitious fresh-takes on things like ECS-based game engines in Rust, but I'm not aware of impending migration to these tools.
Agreed. But it can also mean not actually achieving at all what you set out to do. I don't know if that is the case for Loom specifically, but that seems to be what was implied by the parent comment.
I could never figure out Githut2.0. Githut1.0 had a much nicer interface and although Rust looked bad on first impression, just moving it left a set period of time (or vice versa moving Go right a set period) showed that Rust actually grew at a very similar rate as Go... until Rust started accelerating by around 2018. I suspect something similar may be the case on Githut2.0 but just too hard to tell. Linear graphs comparing exponential growths can be very deceiving.
In my experience TIOBE is very noisy and bad at predicting long-term trends for languages outside the top-ten or so. And it seems even worse recently due to Covid. Heck Julia recently jumped into the top-20 for a single motnh earlier this year before falling back to the mid 30's. And that isn't even all that uncommon for TIOBE. I think I see a trend of Rust slowly climbing, but it is hard to tell through the noise.
PYPL says Rust has respectable growth and that its growth is remarkably consistent (i.e. it is growing at a near constant expeonential rate until 2018, then slowing down a bit in 2018 and then continuing at a very constant and this time faster exponential growth rate.
Redmonk calls Rust the tortoise language (from the hare and the tortoise story). It's growth is never impressive, but its steadiness in growing is very impressive.
You actually do mention some success stories. Also, Amazon is using Rust for a lot more than Firecracker. A lot of their critical infra is in Rust. Also, rustls is pretty big, IMO. Finally an actually secure implementation of SSH. ;-) (And fast to boot.) The Ferrocene project project is fully open source, paid for in full by donations despite the considerable expense because some of the (very big) high integrity industry really want to use Rust The Linux kernel is seriously considering including Rust and Linus said something like Rust in the kernel is inevitable. The Linux kernel team (and Linus specifically) are notorious for their previously adamant hostility towards any language other than C in the kernel. They are starting carefully with just drivers but that's already way more than for example C++ ever managed. On the CNCF, we have TiKV and Linkerd2 in Rust. These aren't small or unimportant projects although, no, they don't quite match k8s.
Over all. Rust is trying to replace C/C++. That is a very tall order. No previous language have ever come close to where Rust currently is already in that task. But it is not going to happen over night. It is a huuuuuuge task that will take a lot of time and a lot of resources and a lot of mindshifts.
Regarding improvements in the other languages. Sure, but C++20_0000_000 will not come close to some of the advantages Rust already had by 1.0 unless they are willing to break backward compatibility to the point where you can just as well rewrite in Rust. All those languages are fundamentally broken or limited in ways that cannot be fixed or worked around. Rust also have historical baggage already. But it starts from a much better starting point with a lot of lessons learned.
How have unsafety been addressed in C/C++? C++20 is exactly as unsafe as C. It has much better what I call "safeness", but that's like saying by going from 1 to 10 I made progress towards infinity. It reduces some classes of errors, if you know what you are doing and apply considerable discipline. It doesn't eliminate any errors. C++20 is sill based on the C abstract machine, which is to say a DEC11. It is still very hard to do some optimizations that are easy or even trivial in Rust and some that would've been trivial if LLVM didn't miscompile perfectly correct code. C++20 still doesn't have a borrow checker and will never have one remotely as capable as Rust's. C++/Java/C#/Python/... are still OOP with inheritance which is fundamentally at odds with really capable composition which is fundamentally superior in expressive power and fits a lot of domains a lot better. Yes. Those languages can close the gap. They can never catch up. Can they get close enough to reduce the value proposition of the newer languages to the point where the newer languages (or some others even newer than these) won't take and hold a considerable fraction of their market share? I doubt that. But taking the market share of the incumbents will take very long. The network effect is brutal. But sometimes a disruptive technology is too good to stop it from -- eventually -- overcoming that effect. Of course, again exponential growth means what starts slow can quite suddenly explode. Also, when sufficient barriers are overcome or a language gets the rigth killer app it can again explode. May be for Rust that'll be high integrity or the Linux kernel. Consider that Redleaf is already vastly superior (better security, better performance, more features, more portable) and vastly cheaper to develop and verify than sel4 for one impressive achievement. Of course, until we can actually compile Redleaf on a certified rust compiler (probably by next year), Redleaf will remain an academic curiosity. But once we can? I'm no high integrity developer, but it seems the sky's the limit.
Yikes! That was a lot of words! Sorry, but I'm too tired to edit.
Don't unless it's to advance a particular career development or personal project goal. I left Go because it became a yuppie slum of trend-seekers riding a wave and leeching rather than contributing: blog hype and too many dumb support requests/questions. Making powerful languages too easy to get started without any understanding results in burdensome, low-signal distractions of maintainers and contributors.
This appears like it may happen with Rust but I hope it doesn't. It's a good thing it won't ever happen with Haskell, which is my warm safety-blanket should any particular language community implode.
You didn't have to wait for this release. `std::array::IntoIter::new()` was stabilized earlier already. This release just adds places where you don't have to write that explicitly any more.
> Identifiers can now contain non-ascii characters. All valid identifier characters in Unicode as defined in UAX #31 can now be used. That includes characters from many different scripts and languages, but does not include emoji.
Don't despair fellow emoji devs, our time will come soon enough.
In the English speaking world, I have a hard time justifying untypeable identifiers. Maybe, and this is a fat maybe, Greek symbols could make the odd write-once math or scientific code easier to read. It would be bonkers to use any non-ascii codepoints in a public API.
Which do you prefer: P, Petit, Petite, 小小小, 3小, XXS, 2XS?
English is chalk full of non-English words. And lots of symbols are useful. Sometimes it's worth it to learn the symbol. And often not much harder than learning the English abbreviation.
enum ⏻ { ⭘, ⏽, ⏾ }
Again, "typeable" is ambiguous but obviously an important consideration.
None of this is to argue against your point. Just musing.
Are you distinguishing Chinese or Japanese on visual appearance? Or by some other method?
I think 小中大 have an advantage over SML because SML have no meaning by themselves. 小中大 have the exact meaning we need. Granted, 中 kinda ruins that argument. Size::中 is very clear, but perhaps not more so than Size::M.
I'm actually curious. Which do you like better in code? P, SSS, XXS, 小小小, 3S, 3小, whole words, something else?
I can't read Japanese. I just know they use characters slightly differently, so I
can't be sure they wouldn't write that.
The majority of people in the world can read and type 'S' easily, not so for '小'.
It seems you're basically arguing for pictograms. Like coding in Wingdings with a character map or something.
I would prefer to use a number scale, but if I had to choose from those options I would use whatever is most conventional in whatever area I'm in, which would probably be XXS.
Even if english speaking, it is still ambiguous. For example in my keyboard the micro sign (µ; not to be confused with the Greek small letter mu) is easy to type (AltGr + M). I bet this is the same for the majority of HN users. The US keyboard doesn’t use third level shift (usually AltGr) so most people that use US keyboard exclusively are unaware of this. Whenever I see people using the Latin small letter U (u) instead of the micro sign, all I think about is how restrictive the US keyboard actually is, and how much of a shame it is that the culture which predominantly uses this restrictive keyboard design came to be the dominant when designing computer interfaces.
Unicode has both MICRO SIGN (U+00B5) and GREEK SMALL LETTER MU (U+03BC). The former is the one on (most) people's keyboard, and it shouldn't be used to type actual Greek.
Some font-families might want these letters to look different for some reason. Even if they look the same perhaps the boldfaced or italics should behave differently, perhaps the spacing should be different etc.
I’m not a font designer but I can imagine that the micro sign often appears around Latin letters whereas the Greek letter mu doesn’t, so that font designers might space them differently for that reason.
For fun I compared 10µm (upper; using the micro sign) with 10μm (lower; using the greek letter mu) in the comic sans font face. https://imgur.com/qwnnAqD
> Why would they deliberately put duplicates in unicode though?
IIRC, to enable adoption. Many of the codepoints were adopted from other encoding systems, and it was often useful to support 2-way conversions without loss while Unicode was being adopted.
What's a "duplicate" is also sometimes in the eye of the beholder.
There's lots of non-english codebases out there, supporting symbols for their languages is a big deal.
In a way, it's in part a job for the dev tools. Autocomplete engines should be able to complete these symbols from an ascii-only hint. 'a' should offer "α" as one of the completion options, and 'bla' should offer "BLÅHAJ".
But then others won't feel dirty when they use the method. The goal is to make people feel bad when they add more usages of it and make it harder to remove. This is the case when it's easier and faster than the proper way. When there is crunch time it's hard to push your lead to reject the PR so it's soft pressure and it's apparent at the call site whereas a TODO in the method definition is not.
There is a famous story of a codebase that used `sleep` calls for this purpose. Start by sleeping 1 ms every time that the undesired function is called. Next release, up it to 10 ms, then 100 ms, and so on.
Reminds me of Haskell's tendency to prepend "unsafe" (or, in one case where that was insufficiently dire, "accursedUnutterable"), although the use case is a little different.
I assume making the name of the function they want to eventually get rid of more annoying to type is part of the reason to do this rather than just tracking ones needing replacement.
It's really not hard at all to make them typeable, it just requires some minor setup (use an IME). Still doesn't necessarily mean it's a good idea, but it's not a total blocker.
Scientific computing is actually a use-case I see this working well in; IMO, it's perfectly fine to have terse code that exactly matches up to equations in a longer paper that justifies correctness, etc. (as long as the paper is easy to find from the code!)
It helps here to have good shortcuts (i.e. \tex like commands) for all the symbols. Otherwise writing them is a PITA and nobody will do it (e.g. Go supports full unicode identifiers, when was the last time you saw one in the wild?)
This is the one thing I used to love about Maple back in college. You can compute directly with mathematical symbols, draw matrices and rational numbers the same way you would on paper, and the language runtime understands it. Too bad it's a $5000 license or whatever.
maybe we can have some keyboard plugin/"mode" that merges letters to form symbols in special way?
Korean windows have a "special-emoji" keyboard that can be invoked by: 1. type a charactor 2. press 'hanja' key 3. (wild special character selection menu appears)
Most Linux environments already have this, it's called "compose key". You may need to enable it in your desktop environment's settings, but then after pressing the key you can press !? to type ‽, 12 to type ½, <= to type ≤, n~ to type ñ, <3 to type ♥, etc. Here's GTK's list: https://help.ubuntu.com/community/GtkComposeTable
It would be nice if this were built into Windows, but in lieu of that, I have been using WinCompose[0] for several years for typing diacritics (as part of my learning French). For example:
* ALT e' = é
* ALT u " = ü
* ALT n ~ = ñ
It's not limited to diacritics; you can type ligatures (ALT ae = æ), extended characters (ALT [/] = ), I assume the majority of UTF (ALT #G = 𝄞) and so on. And yes, even emoji (ALT ALT alembic = )
edit: apparently, HN won't show the checkbox (U+2611) or alembic[1].
> It would be nice if this were built into Windows, but in lieu of that
Something that's basically equivalent is builtin. Just switch your keyboard from EN-US to EN-INTL, and now several accent characters become dead keys, so ' e = é, etc.
For Windows, the ENG-INTL keyboard layout is pretty good for simple accented characters, covering latin-based European languages [1].
Windows+. also allows you to just type to search for emojis, so e.g. typing WINDOWS+. sad ENTER gives you a sad emoji. Sadly this doesn't work for symbols, even though the Windows+. menu has a good coverage of symbols.
I guess you can always switch your keyboard to Korean input.
Julia does this in a pretty simple way, you type \lamdba then press tab and it becomes λ, emojis and many other things work like this, so typing them is very wasy.
Animated GIF meme identifier devs of the world unite! We will overthrow this repressive violence against our kind. Baby dance will be the next "Hello, world!"
I just recompiled rustc on my Linux From Scratch desktop. I guess I should have timed it, but it sure felt a lot faster. Finished when I wasn't even paying attention.
Went from 9 failed tests on 1.52.1 to 13 on 1.53.0.
I'm not expecting Firefox to compile, but that's entirely on Mozilla.
I love the non-ascii character support although for me as an English speaker I wouldn't use it, but I'm sure there many Asian teams that would appreciate these changes
Sweet, cmp::min_by_key and cmp::max_by_key have finally been stabilized. Was sorely missing this little convenience in Rust, as it helps express a particular idea more clearly and succinctly.
Also the improvement to compile times on macOS due to the change in how debug info is stored is a nice productivity boost.
I'm a little OT (sorry), but I am wondering if is there a way to learn Rust while keeping up with the changes made from last edition (Rust 2018, which is 1.31)?
Not specifically, changes since then have landed in all editions. We did have a doc that described the full set of changes, but people didn't like it, so it got removed.
This notion is common among those who are first considering Rust, but also quite overblown in practice. The only thing that reasonably qualifies as "esoteric" in Rust is borrow checking and lifetimes, and these can be mitigated by using very simple idioms/patterns like cloning objects via .clone() or using copy-on-write via Cow<>.
You can then code with much the same convenience as e.g. Python, Java or C#, but it's also very clear where some potential gains in performance have been left off the table for the sake of rapid development.
So for a typical CRUD app, just use one of the litany of high level language frameworks and be done with it.
Also, there are plenty of high level languages with traits, eg Haskell, but if you prefer one where it is easier to express things optionally with an imperative/OOP mindset, Scala.
This is sort of true, in that I might take reference where I used to take a value, or vice versa, but it's pretty trivial. It's extremely rare for borrow checking or memory layout to slow me down at all when refactoring.
We started to rewrite some of our smaller js/TS utilities, ~3k LOC, and surprisingly Rust was 10% to 20% smaller. Not that it a relevant metric, but still, we were expecting the opposite.
The missing part compared to other languages is specialization, but other patterns can be used. Still, would be nice if they add a good sound specialization construct (min_specialization seems to come short so far)
The biggest challenge is to train a full team on Rust.
I on this space and found Rust to be a great boost in my ability to ship code with FAR lower debugging (post-deployment) and hosting cost (can pay for half for more than 4x the amount of load, and not even doing a lot for improve things).
Rust is already "mainstream-ish" and the amount of libraries and stuff is becoming better and better. So, I don't see any point on "wait".
Sure, it will be challenging! But the benefits are too nice to pass of, I think.
When I was in college, they taught C++ as the programming language (dating myself here...). I walked away with enough negative feelings about it that I thought I just hated strongly typed programming languages that lacked garbage collection, and I thought I hated compilers that spewed errors all the time, and so I gravitated towards things like Python and Ruby.
Rust has proven that I was wrong about myself. I really enjoy working with it - rust has many of the same features but dramatically modernized, and it solves so many ergonomic nightmares that I remember from C++.
With rust I find that entire classes of mistakes I can make with Ruby are straight up impossible because the compiler won't let you get away with it.
If you were scarred by C++, give it a shot, and it may erase some of those old battle scars.
I don't think it's a great replacement for Java/C#. Unless your problem is GC pauses, either language will let you be more productive even when you master the borrow checker simply because their ecosystems are much richer.
I can imagine AAA game engines slowly migrating from C++ to Rust, but enterprise applications are already fast enough in 99.9% of the cases.
The Rust "ecosystem" can seamlessly expand to include any language with a C ABI and FFI. Solutions are also being developed to ease interop with managed platforms like Java/C#.
Contrast this with something like Go, where even interoperability with C does not come out-of-the-box and requires compromising the most desirable features in the language itself.
Languages compete in their axes, which for me there are mainly 4 big ones:
a) System/Performance/Control: C, C++, Rust, Zig
b) Application: Java, C#, Swift, Go, Kotlin, Nim
c) Script/Casual: Python, Ruby, Lua, Javascript
d) Domain specific: OCAML, Scheme, Haskell, Matlab
I've never seen a language ruling in two axes at the same time (as in you can use it for the same goals), let alone in all four, or at least three.
The a' axis are very hardcore languages with insane amount of control, but they will never be as productive as the b' and c' axis.
Meanwhile the b' axis is the most popular one, as they allow you to create big and complex application while being productive. Their runtime are not far away from the languages on the a' axis.
The c' axis is most productive and easy to pick up, with languages that feels more natural, but they dont have the performance of the a' and b' axis and also its hard to compose big applications on them unlike the a' and b' axis.
Maybe a successor of languages like Rust and Swift might be the on to do this, but i cant hardly see Rust in that position because programming in it have more or less the kind of productivity that C++ gives you.
I relax much more when i can write something in Swift instead of C++ or Rust for instance, and i would mostly choose it given the perfect match to the problem i'm solving.
I think we are going for a more polyglot world, not less, and i mostly use C++, Swift and Python when i can, where you can replace C++ for Rust, Swift for C# and Python with JavaScript according to your personal tastes.
But using something from one axis trying to reach for the goals better served in another axis is mostly a "when all you have is a hammer.." kind of paradox.
I work in telecoms on the layer just above the FPGAs/DSP: even a 1ms 'pause' would be totally unacceptable here..
Of course embedded will always exist, as well as specialized programs requiring utmost control over the machine.
The notion of the "lifetime" is fundamental to systems programming, particularly when dealing with concurrency. It's quite natural to folks who are used to dealing with use-after-free/use-after-move and iterator invalidation bugs, imo.
However, here are the following caveats: - If you have a client or employer project to do now, and you are not yet familiar with Rust, do it with your language of expertise. Rust has to be learned before starting a new real project with it. - The real challenge is the cost to train an entire team on it. - Obviously, universal languages do not exist, so if you do AI, especially modeling, use Python (for now), web stuff use JS/TS, mobile stuff, Kotlin | Swift | Dart/Flutter. You can do some Rust on mobile and even web with WASM, but those are very niche use cases.
1. Memory management
2. Typing
I think your listed languages all have Garbage Collection? It will probably take quite a bit of mental effort to get comfortable with memory management in Rust but it is a valuable topic if you want to understand performance and language runtimes.
The other day the partner company which is using the output of my software admitted to me that they are chasing some weird heap corruption error in QtCore.dll, and therefore cannot hit a deadline.. I was relieved that this is a thing of the past for me now.
When I run into a memory error now, it's somewhere in the unsafe code blocks I have in the wrapper around the shitty C libraries by other partner companies, that didn't document the conditions of their API properly.
One way to think about it is that the big wave of new languages like Go, Rust, Elixir and Kotlin all sprang up around 2010. At that time, C99, C++03, Java 6 or C#2 were probably what you would have been using (honorable mentions to Python 2.7, PHP 5, and Ruby 1.8). The new languages were perceived solutions to the limitations of the mainstream languages; however, today, very many of the new features and the old points of frustration have already been addressed within these same 'boring' mainstream languages. Java 16, C# 8, and C++20 are vastly improved and have (or will soon have [check out Loom for Java!]) almost all the conveniences the new-wave offered without having to throw old programs in the bin and reimplement entire ecosystems. C++ and Rust are also so similar in terms of semantics and memory model, that I really don't see the value proposition of walking away from huge, mature projects like Qt for academically interesting type algebra. There have been some ambitious fresh-takes on things like ECS-based game engines in Rust, but I'm not aware of impending migration to these tools.
In my experience TIOBE is very noisy and bad at predicting long-term trends for languages outside the top-ten or so. And it seems even worse recently due to Covid. Heck Julia recently jumped into the top-20 for a single motnh earlier this year before falling back to the mid 30's. And that isn't even all that uncommon for TIOBE. I think I see a trend of Rust slowly climbing, but it is hard to tell through the noise.
PYPL says Rust has respectable growth and that its growth is remarkably consistent (i.e. it is growing at a near constant expeonential rate until 2018, then slowing down a bit in 2018 and then continuing at a very constant and this time faster exponential growth rate.
Redmonk calls Rust the tortoise language (from the hare and the tortoise story). It's growth is never impressive, but its steadiness in growing is very impressive.
You actually do mention some success stories. Also, Amazon is using Rust for a lot more than Firecracker. A lot of their critical infra is in Rust. Also, rustls is pretty big, IMO. Finally an actually secure implementation of SSH. ;-) (And fast to boot.) The Ferrocene project project is fully open source, paid for in full by donations despite the considerable expense because some of the (very big) high integrity industry really want to use Rust The Linux kernel is seriously considering including Rust and Linus said something like Rust in the kernel is inevitable. The Linux kernel team (and Linus specifically) are notorious for their previously adamant hostility towards any language other than C in the kernel. They are starting carefully with just drivers but that's already way more than for example C++ ever managed. On the CNCF, we have TiKV and Linkerd2 in Rust. These aren't small or unimportant projects although, no, they don't quite match k8s.
Over all. Rust is trying to replace C/C++. That is a very tall order. No previous language have ever come close to where Rust currently is already in that task. But it is not going to happen over night. It is a huuuuuuge task that will take a lot of time and a lot of resources and a lot of mindshifts.
Regarding improvements in the other languages. Sure, but C++20_0000_000 will not come close to some of the advantages Rust already had by 1.0 unless they are willing to break backward compatibility to the point where you can just as well rewrite in Rust. All those languages are fundamentally broken or limited in ways that cannot be fixed or worked around. Rust also have historical baggage already. But it starts from a much better starting point with a lot of lessons learned.
How have unsafety been addressed in C/C++? C++20 is exactly as unsafe as C. It has much better what I call "safeness", but that's like saying by going from 1 to 10 I made progress towards infinity. It reduces some classes of errors, if you know what you are doing and apply considerable discipline. It doesn't eliminate any errors. C++20 is sill based on the C abstract machine, which is to say a DEC11. It is still very hard to do some optimizations that are easy or even trivial in Rust and some that would've been trivial if LLVM didn't miscompile perfectly correct code. C++20 still doesn't have a borrow checker and will never have one remotely as capable as Rust's. C++/Java/C#/Python/... are still OOP with inheritance which is fundamentally at odds with really capable composition which is fundamentally superior in expressive power and fits a lot of domains a lot better. Yes. Those languages can close the gap. They can never catch up. Can they get close enough to reduce the value proposition of the newer languages to the point where the newer languages (or some others even newer than these) won't take and hold a considerable fraction of their market share? I doubt that. But taking the market share of the incumbents will take very long. The network effect is brutal. But sometimes a disruptive technology is too good to stop it from -- eventually -- overcoming that effect. Of course, again exponential growth means what starts slow can quite suddenly explode. Also, when sufficient barriers are overcome or a language gets the rigth killer app it can again explode. May be for Rust that'll be high integrity or the Linux kernel. Consider that Redleaf is already vastly superior (better security, better performance, more features, more portable) and vastly cheaper to develop and verify than sel4 for one impressive achievement. Of course, until we can actually compile Redleaf on a certified rust compiler (probably by next year), Redleaf will remain an academic curiosity. But once we can? I'm no high integrity developer, but it seems the sky's the limit.
Yikes! That was a lot of words! Sorry, but I'm too tired to edit.
This appears like it may happen with Rust but I hope it doesn't. It's a good thing it won't ever happen with Haskell, which is my warm safety-blanket should any particular language community implode.
Don't despair fellow emoji devs, our time will come soon enough.
"English speaking world"
"untypeable"
"public API"
Even then you exempt Greek symbols. I suppose you might be willing to accept ¢ or €. Of course, "untypeable" is very ambiguous.
Still, not all code is "public API" and not all code is intended for the English speaking world. So I think it's great to support non-ASCII symbols.
よろしく
enum Size { P, XS, S, M, L, XL, XXL }
enum Size { Petit, Extra_Small, Small, Medium, Large, Extra_Large, Extra_Extra_Large }
enum Size { 小小小, 小小, 小, 中, 大, 大大, 大大大 }
Which do you prefer: P, Petit, Petite, 小小小, 3小, XXS, 2XS?
English is chalk full of non-English words. And lots of symbols are useful. Sometimes it's worth it to learn the symbol. And often not much harder than learning the English abbreviation.
enum ⏻ { ⭘, ⏽, ⏾ }
Again, "typeable" is ambiguous but obviously an important consideration.
None of this is to argue against your point. Just musing.
You could write SSS, SS, LL and LLL in English too.
By the way, it's 'chock-full' not 'chalk-full'.
Are you distinguishing Chinese or Japanese on visual appearance? Or by some other method?
I think 小中大 have an advantage over SML because SML have no meaning by themselves. 小中大 have the exact meaning we need. Granted, 中 kinda ruins that argument. Size::中 is very clear, but perhaps not more so than Size::M.
I'm actually curious. Which do you like better in code? P, SSS, XXS, 小小小, 3S, 3小, whole words, something else?
The majority of people in the world can read and type 'S' easily, not so for '小'.
It seems you're basically arguing for pictograms. Like coding in Wingdings with a character map or something.
I would prefer to use a number scale, but if I had to choose from those options I would use whatever is most conventional in whatever area I'm in, which would probably be XXS.
The greek letter mu IS the micro sign, where do you think it comes from?
MICRO SIGN (U+00B5)[1] vs. GREEK SMALL LETTER MU (U+03BC)[2]
1: https://www.fileformat.info/info/unicode/char/00b5/index.htm
2: https://www.fileformat.info/info/unicode/char/03bc/index.htm
I’m not a font designer but I can imagine that the micro sign often appears around Latin letters whereas the Greek letter mu doesn’t, so that font designers might space them differently for that reason.
For fun I compared 10µm (upper; using the micro sign) with 10μm (lower; using the greek letter mu) in the comic sans font face. https://imgur.com/qwnnAqD
IIRC, to enable adoption. Many of the codepoints were adopted from other encoding systems, and it was often useful to support 2-way conversions without loss while Unicode was being adopted.
What's a "duplicate" is also sometimes in the eye of the beholder.
In a way, it's in part a job for the dev tools. Autocomplete engines should be able to complete these symbols from an ascii-only hint. 'a' should offer "α" as one of the completion options, and 'bla' should offer "BLÅHAJ".
Being harder to type is part of the point.
I guess you have a point. It's clearly a "let's meet in the back alley" API.
The Julia community has been trying really hard to convince people that this is a good idea and I'm still not on board with it.
Back when someone used them to add pseudo-generics https://old.reddit.com/r/rust/comments/5penft/parallelizing_...
Korean windows have a "special-emoji" keyboard that can be invoked by: 1. type a charactor 2. press 'hanja' key 3. (wild special character selection menu appears)
example: § (from 'ㅁ') / ㈜ (from 'ㅁ') / ㎖ (from 'ㄹ')
* ALT e' = é
* ALT u " = ü
* ALT n ~ = ñ
It's not limited to diacritics; you can type ligatures (ALT ae = æ), extended characters (ALT [/] = ), I assume the majority of UTF (ALT #G = 𝄞) and so on. And yes, even emoji (ALT ALT alembic = )
edit: apparently, HN won't show the checkbox (U+2611) or alembic[1].
[0] http://wincompose.info/
[1] https://emojipedia.org/alembic/
Something that's basically equivalent is builtin. Just switch your keyboard from EN-US to EN-INTL, and now several accent characters become dead keys, so ' e = é, etc.
Windows+. also allows you to just type to search for emojis, so e.g. typing WINDOWS+. sad ENTER gives you a sad emoji. Sadly this doesn't work for symbols, even though the Windows+. menu has a good coverage of symbols.
I guess you can always switch your keyboard to Korean input.
1: https://community.windows.com/en-us/stories/keyboard-shortcu...
Went from 9 failed tests on 1.52.1 to 13 on 1.53.0.
I'm not expecting Firefox to compile, but that's entirely on Mozilla.
Also the improvement to compile times on macOS due to the change in how debug info is stored is a nice productivity boost.