Rust Foundation: Hello, World(foundation.rust-lang.org)
foundation.rust-lang.org
Rust Foundation: Hello, World
https://foundation.rust-lang.org/posts/2021-02-08-hello-world/
281 comments
I‘d love to see Apple joining. They already have the hand on LLVM and support things indirectly, but...
There is no reason that serious things written in Rust can‘t coexist with app-y stuff in swift.
Seriously, I think we all would benefit enormously from some consolidation, especially on such a great foundation like Rust. Think investments like: compiler-optimizations like V8, portability like C, enterprise grade tooling like Java, productive libraries like Ruby, datascience libs like python, ... it would be great to have all of this in one coherent package.
Why? Instead of glueing together brittle and fragile things where the moving parts break within weeks, reinventing the wheel, we could finally focus on the actual things to build. Bonuspoints for Rust: every other techstack can leverage/profit directly, like when binding C stuff.
Everyone still can innovate like the past decades, languages and libs will be re-explored and reinvented and so on, but, really, a solid baseline would be a dream
There is no reason that serious things written in Rust can‘t coexist with app-y stuff in swift.
Seriously, I think we all would benefit enormously from some consolidation, especially on such a great foundation like Rust. Think investments like: compiler-optimizations like V8, portability like C, enterprise grade tooling like Java, productive libraries like Ruby, datascience libs like python, ... it would be great to have all of this in one coherent package.
Why? Instead of glueing together brittle and fragile things where the moving parts break within weeks, reinventing the wheel, we could finally focus on the actual things to build. Bonuspoints for Rust: every other techstack can leverage/profit directly, like when binding C stuff.
Everyone still can innovate like the past decades, languages and libs will be re-explored and reinvented and so on, but, really, a solid baseline would be a dream
Pretty much everything you listed is stuff Apple is already doing with Swift, and although Rust is awesome for lower level stuff, and stretches up quite well, Swift really does cover more of the stack of abstraction.
That said, I’d say Apple having Swift is part of the reason everyone else is getting involved with Rust.
Rust is credible competition for Swift where nothing else is.
That said, I’d say Apple having Swift is part of the reason everyone else is getting involved with Rust.
Rust is credible competition for Swift where nothing else is.
I have not used Swift much but the use cases overlap more with C# than Rust IMO.
[deleted]
Hi, as someone interested in typography I am interested in how and why you wrote a ‘ (U+2018 LEFT SINGLE QUOTATION MARK) instead of a ' (U+0027 APOSTROPHE) or a ` (U+0060 GRAVE ACCENT)? Is it used by a language on your system? is it in your keyboard? Or maybe a conscious typographical statement of proper style? I wonder :)
Personally I have had my dose of fighting with using multiple languages with incompatible keyboards layouts, I would like to hear your story (even if it has nothing to do with keyboard layouts)
Personally I have had my dose of fighting with using multiple languages with incompatible keyboards layouts, I would like to hear your story (even if it has nothing to do with keyboard layouts)
I find a compose key (see Wikipedia) quite helpful for diacritics, em dashes, &c.—once you get the hang of it, it’s really quite fast and intuitive. One can even add new combinations.
I recently left the linux world and with it the compose key... the most similar (native) thing windows offers are dead keys which I find deeply abhorring.
I settled on switching keyboard layouts with Windows+space.
I was more curious about the why than the how in a sense.
I settled on switching keyboard layouts with Windows+space.
I was more curious about the why than the how in a sense.
I use Windows, and haven't used Linux for years. It's probably just a matter of time before I go back, and when I do I know I'll love the compose key.
However, the workaround I use on Windows is Alt key combinations: I memorized the dozen or so patterns [1] I use the most. For example, `Alt + 0160` for non-breaking space, `Alt + 0150` for en dash, `Alt + 26` (and a few more) for arrows and `Alt + 0133` for ellipsis. It must seem crazy when you're used to the compose key.
I haven't heard of dead keys as a workaround. How does it compare? (Wow, this is getting very far from the original topic…)
[1] An important key to memorizing them is to see them as patterns on the numpad, rather than a sequence of digits.
However, the workaround I use on Windows is Alt key combinations: I memorized the dozen or so patterns [1] I use the most. For example, `Alt + 0160` for non-breaking space, `Alt + 0150` for en dash, `Alt + 26` (and a few more) for arrows and `Alt + 0133` for ellipsis. It must seem crazy when you're used to the compose key.
I haven't heard of dead keys as a workaround. How does it compare? (Wow, this is getting very far from the original topic…)
[1] An important key to memorizing them is to see them as patterns on the numpad, rather than a sequence of digits.
dead keys are an hack that implement a feature of old typewriters. On a computer it simply disables the keys for accents and combine the accent with the next letter, the catch is that if you want to write the accent character (',`,^," etc.) you have to press the key twice, as the first press does nothing.
We don't need monocultures.
Then Swift should be replaced by something more mainstream. Adding Rust would be less monoculture than what we have now.
Apple is using Rust somehow internally, they were advertising for network software developers with Rust experience a while back.
Why make the Rust Foundation be its own corporate entity, instead of a project within another major non-profit like the Software Freedom Conservancy?
(For those not familiar, SFC is the home of Git, Godot Engine, Homebrew, Inkscape, QEMU, and Wine.)
My worry would be that this is happening because Amazon, Google, and Microsoft want control over the foundation. (They are writing the checks, so no surprise they'd want to control how that money gets invested…)
(For those not familiar, SFC is the home of Git, Godot Engine, Homebrew, Inkscape, QEMU, and Wine.)
My worry would be that this is happening because Amazon, Google, and Microsoft want control over the foundation. (They are writing the checks, so no surprise they'd want to control how that money gets invested…)
I actually feel almost the opposite. Umbrellas are a good thing, but if you have the resources to go your own way, that makes more sense. So if your vision is that in five years nobody cares about Rust, these corporations have lost interest, the few dozen people still working on it need somebody to do paperwork and finances, then yeah, an umbrella is great. If your vision is that in five years Rust is ubiquitous and we are arguing about someone having too much control over the foundation an umbrella is exactly not what you want.
An example of a project I think would be less healthy under an umbrella would be LibreOffice. An example of a project I think would be more healthy under an umbrella would be the Haiku Operating System.
You largely cannot fight those big cheques, if you say "We don't want any corporate influence, go away", you lose, Amazon, Google and Microsoft do go away and build I dunno, "Titanium", a language eerily similar to Rust and with lots of manpower and money behind it.
You can put some structures in place to reduce the worst influences of money, you obviously don't want a situation where one day everybody senior at the Rust Foundation wouldn't know an IEEE float from a UTF-16 code unit and the language is allowed to decay and fail while executives fill their pockets from the dwindling coffers. But there are practical limits, at some point you must trust in the basic goodness of your fellow humans.
Our industry hasn't really been around long enough for the worst rot to set in, but there's a Vox story (I think?) years back about the problem of zombie foundations, with a set mission that ceased to make sense in the modern world. There's plenty of money but the intended charitable purpose no longer makes sense. A free primary school for the "disadvantaged" children in a long-since gentrified inner city region where the average child today is a millionaire is the sort of problem that arises.
An example of a project I think would be less healthy under an umbrella would be LibreOffice. An example of a project I think would be more healthy under an umbrella would be the Haiku Operating System.
You largely cannot fight those big cheques, if you say "We don't want any corporate influence, go away", you lose, Amazon, Google and Microsoft do go away and build I dunno, "Titanium", a language eerily similar to Rust and with lots of manpower and money behind it.
You can put some structures in place to reduce the worst influences of money, you obviously don't want a situation where one day everybody senior at the Rust Foundation wouldn't know an IEEE float from a UTF-16 code unit and the language is allowed to decay and fail while executives fill their pockets from the dwindling coffers. But there are practical limits, at some point you must trust in the basic goodness of your fellow humans.
Our industry hasn't really been around long enough for the worst rot to set in, but there's a Vox story (I think?) years back about the problem of zombie foundations, with a set mission that ceased to make sense in the modern world. There's plenty of money but the intended charitable purpose no longer makes sense. A free primary school for the "disadvantaged" children in a long-since gentrified inner city region where the average child today is a millionaire is the sort of problem that arises.
Titania, to follow the oxide metaphor. Which is honestly a pretty darn decent name.
They have an unhelpfully generic answer to that in their FAQ: "After spending a significant amount of time researching potential umbrella organizations, we decided that our best option was to incorporate an independent entity. Rust is a technology and community that is value driven and we simply didn’t find an organization that we felt was aligned with our community goals. This does mean more work for us, especially upfront, but we think the tradeoff is worth it."
https://github.com/rust-lang/foundation-faq-2020/blob/main/F...
As they are registering as a 501(c)6, I would assume that tax reasons would have impacting their decision not to join the SFC.
https://github.com/rust-lang/foundation-faq-2020/blob/main/F...
As they are registering as a 501(c)6, I would assume that tax reasons would have impacting their decision not to join the SFC.
> My worry would be that this is happening because Amazon, Google, and Microsoft want control over the foundation. (They are writing the checks, so no surprise they'd want to control how that money gets invested…)
I find this attitude surprising. They are paying for development, why they shouldn't have authority to dictate the priorities? If it was SFC, some other interests would be dictating the priorities anyway.
I find this attitude surprising. They are paying for development, why they shouldn't have authority to dictate the priorities? If it was SFC, some other interests would be dictating the priorities anyway.
> They are paying for development, why they shouldn't have authority to dictate the priorities?
If you are sponsoring a foundation and can dictate the direction you aren't a sponsor but an employer and owner. Then the foundation is just a way to make good looking PR or get tax-cuts.
If you are sponsoring a foundation and can dictate the direction you aren't a sponsor but an employer and owner. Then the foundation is just a way to make good looking PR or get tax-cuts.
Companies shouldn't be able to control other people's projects just because they pay developers to work on it. The project's vision can't be corrupted to serve any one company's interests. I'd even say this should also hold true for every company's own products.
Realistically, it all comes down to leverage and power. Who needs the other the most?
Realistically, it all comes down to leverage and power. Who needs the other the most?
As I mentioned below, the way to get good answers here is to contact them directly; nobody from the foundation is in this thread.
I find it puzzling that aws uses rust so much yet don't have an official rust aws sdk
That metric doesn't really matter for that purpose. If AWS gets enough customer requests to warrant building a rust SDK, they'll do it. It doesn't have much to do with internal rust adoption at AWS.
I don't think any of these companies use Rust much. You may find teams here and there using it but the vast majority of the Rust type stuff is written in C++ or Java.
It depends on what you mean by "much." If you mean "as a volume of LOC of total software development," absolutely. But if you mean "not being used for anything big" or "not being used for anything important," that is very much wrong.
In what concerns Microsoft, I am yet to see anything besides Win32 and WinRT bindings generation.
UWP/WinUI foundations are in C++ and .NET.
Azure Sphere, despite all the security selling marketing uses C based SDK.
Windows kernel seemed to be in the right direction adopting more C++ and less C, specially with the userspace drivers COM SDK, but they just reverted to more C support on the latest versions.
So in what concerns Microsoft, I look forward to their Rust's adoption, although currently its adoption is yet to be reflected on the Windows development ecosystem.
UWP/WinUI foundations are in C++ and .NET.
Azure Sphere, despite all the security selling marketing uses C based SDK.
Windows kernel seemed to be in the right direction adopting more C++ and less C, specially with the userspace drivers COM SDK, but they just reverted to more C support on the latest versions.
So in what concerns Microsoft, I look forward to their Rust's adoption, although currently its adoption is yet to be reflected on the Windows development ecosystem.
Firecracker is written in rust and is from Amazon.
Firecracker being a modified fork of Google’s crosvm project.
While not official, there is at least one or two Amazonians working on https://github.com/rusoto/rusoto which is a pretty great Rust AWS SDK.
Just wanted to point out in case you didn't see it, that rusuto currently needs a fulltime maintainer! They're in maintenance mode currently, no one is spending much time on it since the primary maintainer stepped back.
An AWS tech lead mentioned that they were working on an official Rust SDK a while back
> The decision making power within the Rust project is uniquely delegated and distributed; with the core team holding little more privilege than other more specialized teams. [...] And the potential of such a system has bore fruit: It is not a mistake that such a promising technology has emerged from such a progressive conception of collaboration.
These are values and thoughts describing an approach that the KDE community (and its foundation; hello from another board!) holds equally dearly and has inscribed in its Manifesto (https://manifesto.kde.org/, cf. Common Ownership).
While maybe not unique, I'm excited to see another organization adopt this idea set (a support body not interfering with technical agenda, low barriers to participation, not entrenching maintainers, working succession mechanisms, etc.) as a core message. We've seen it work very well to sustain a productive community for 25 years and I think this bodes well for Rust!
These are values and thoughts describing an approach that the KDE community (and its foundation; hello from another board!) holds equally dearly and has inscribed in its Manifesto (https://manifesto.kde.org/, cf. Common Ownership).
While maybe not unique, I'm excited to see another organization adopt this idea set (a support body not interfering with technical agenda, low barriers to participation, not entrenching maintainers, working succession mechanisms, etc.) as a core message. We've seen it work very well to sustain a productive community for 25 years and I think this bodes well for Rust!
[deleted]
I'm really happy to see this happen. I'm also really thrilled to see Lars Bergstrom on the board, and am excited about taking Rust farther both at Google and across the industry. Rust is evolving from being centered at Mozilla to being a true community and collaboration between many different groups, including big companies, so I think a well-supported foundation is key. I'm very hopeful for the future.
Interesting.
>"[]... Director of Engineering at Google, working on Android Platform Programming Languages. Previously, I was a Senior Director of Engineering at Mozilla, working on Virtual and Augmented Reality."
https://www.lars.com/
>"[]... Director of Engineering at Google, working on Android Platform Programming Languages. Previously, I was a Senior Director of Engineering at Mozilla, working on Virtual and Augmented Reality."
https://www.lars.com/
The board's vote seems to be heavily biased in favor of large corporations, with half the seats for them, 2 for the community, and 3 for "project areas." Contrast this with the governance of GCC, which has all of them as community members or project areas.
The goal of the foundation is to work as a bridge between the Rust teams and the corporate world (e.g. sponsorship, licensing, etc). As the blog post notes, the actual development of the language is fully open and is comprised of RFCs and the like which allow anyone to contribute. It's the core team who oversee this process, not the foundation.
In short the foundation works for Rust, not the other way around.
In short the foundation works for Rust, not the other way around.
The foundation works for its board members. We can hope that the board members will work for Rust, but the structure of the board does nothing to check their power and influence.
On the other hand, I do recognize that the board members are the ones bringing the funding to the table; maybe this was the best way to maximize their contributions. If the board's interests align well with the Rust community's interests, then this could turn out fine, at least at first.
On the other hand, I do recognize that the board members are the ones bringing the funding to the table; maybe this was the best way to maximize their contributions. If the board's interests align well with the Rust community's interests, then this could turn out fine, at least at first.
Rust as a language is great already as it is, it doesn’t need more features to be much better than C++ (compilation speed may be an exception...). So I guess my take is that corporate adoption is the most important thing to happen with it at this stage.
Nobody expects the board of directors to influence the technical work being done. The skepticism is about decisions that have political consequences.
This [1] was from the keynote of the latest RustConf. While there's surely plenty of good the Rust project will manage to do regardless of these decisions, I can't help but think there's a small disconnect between "owning" the political role of Rust, and then surrendering half the board to the usual suspects.
[1] https://youtu.be/IwPRu5FhfIQ?t=1659
This [1] was from the keynote of the latest RustConf. While there's surely plenty of good the Rust project will manage to do regardless of these decisions, I can't help but think there's a small disconnect between "owning" the political role of Rust, and then surrendering half the board to the usual suspects.
[1] https://youtu.be/IwPRu5FhfIQ?t=1659
I can't find much in the way of Rust credentials for the rest of the members but, looking at their profiles, Nell (MS's representative) used to manage crates.io while at Mozilla, and Lars (Google) used to manage the Servo team. While they are technically representing corporate interests, they're also heavily invested in the community.
That doesn't mean much long term. If they disagree with the corporations they represent, they will be replaced.
Bobby (the Mozilla rep) was also heavily involved with Servo and Rust-in-Firefox, see e.g. https://bholley.net/blog/2017/stylo.html
> Contrast this with the governance of GCC
The equivalent of that would be the Rust teams[0] as far as I can tell, which will still be the governing body of all development, and won't be replaced by the Rust foundation.
[0]: https://www.rust-lang.org/governance
The equivalent of that would be the Rust teams[0] as far as I can tell, which will still be the governing body of all development, and won't be replaced by the Rust foundation.
[0]: https://www.rust-lang.org/governance
It makes sense that large corporations would be interested in Rust given its current capabilities and future potential.
Amazon, Huawei, Google, Microsoft, and Mozilla all have a vested interest in Rust succeeding since they are all deeply invested in high performance software, the majority of which is written in C and C++.
The undefined behavior semantics in C and C++ trade safe handling of undefined behavior for high performance. The result is high performance code that is difficult for developers to reason about and vulnerable from a security standpoint.
https://blog.regehr.org/archives/213 gives great insights into how undefined behavior in C and C++ can cause problems.
Rust is becoming an excellent replacement and hopefully will continue to succeed to enter all the niches that C and C++ currently occupy.
Amazon, Huawei, Google, Microsoft, and Mozilla all have a vested interest in Rust succeeding since they are all deeply invested in high performance software, the majority of which is written in C and C++.
The undefined behavior semantics in C and C++ trade safe handling of undefined behavior for high performance. The result is high performance code that is difficult for developers to reason about and vulnerable from a security standpoint.
https://blog.regehr.org/archives/213 gives great insights into how undefined behavior in C and C++ can cause problems.
Rust is becoming an excellent replacement and hopefully will continue to succeed to enter all the niches that C and C++ currently occupy.
GCC is one compiler project among others, ironically for your example most funding comes from corporations as well, with Red-Hat being a major contributor.
If you can get MS, Google and Amazon to all agree on an approach, odds are it's probably the right approach.
It's a business association, like the Linux Foundation. It's very much for the corporate members, like the Linux Foundation.
[deleted]
Doesn't look like you can donate to Rust as an individual.
Too bad.
Too bad.
This is true right this moment, yes. That may change in the future.
This is a business association, for the benefit of member businesses. It's a non-profit, but not a charity.
Genuine question: what is Huawei's role in Rust Lang? It is in the founding member companies list.
"Huawei uses Rust to develop a real-time OS for IoT devices, and in the StratoVirt project, a high-performance virtualization platform. According to engineers at Huawei, the company organizes routine Rust training and evaluation activities to encourage its large number of C/C++ developers to write safer code."
https://www.infoq.com/news/2021/01/rust-china-conf/
-----------
I think they've been a big user of Rust in China for some time now, though I'm not aware of any big technical contributions to the language (or the core ecosystem) by them. In a similar vein, I find it a bit surprising that Facebook (or whatever they rebranded Libra to) is not part of the foundation. I think they are the only company that was interviewed when Rust's usage/usability experience in big companies was evaluated, that is not part of the foundation.
https://www.infoq.com/news/2021/01/rust-china-conf/
-----------
I think they've been a big user of Rust in China for some time now, though I'm not aware of any big technical contributions to the language (or the core ecosystem) by them. In a similar vein, I find it a bit surprising that Facebook (or whatever they rebranded Libra to) is not part of the foundation. I think they are the only company that was interviewed when Rust's usage/usability experience in big companies was evaluated, that is not part of the foundation.
I think I saw something about reports that FB has hired a number of individuals to work full-time on the Rust lang, so there are probably lots of companies contributing to Rust in ways that don't get them features on the website.
Yes I'm aware, which is exactly why I find it surprising that they aren't involved in the foundation even though the other tech giants that have made investments in Rust of similar size are.
Disregarding all allegations, Huawei is one of the bigger tech companies and is one that has its finger in every pie, especially across domains where rust is advertised as a better alternative to incumbent C/C++. I can see why they are on the board.
Peixin Hou seems to be a director on Linux foundation too. Probably responsible for corporate lobbyism in OSS in general.
Well, hw is the top contributor to linux kernel in 5.10. https://lwn.net/Articles/839772/. I remember it was discussed in HN before.
It's pretty reasonable for a hardware vendor building on top of Linux to upstream their changes.
The decision to partially "let go" of Rustlang as an asset on some level makes Mozilla something like the anti-Google. If Mozilla make this a habit, they'll come closer to achieving their mission, and the spirit of FOSS. It's a worthy goal, using your power to spin off great pieces of software into independent organizations. I mean, even old "Micro$oft" now knows that open source is more of an asset to them than a competitor. Good to be coding in a time like this. :)
That's a funny way to spin "fired all the people that were working on it".
FWIW Google did this ("letting go" of an asset) with Kubernetes / the CNCF.
I work on this at Google, but Google no longer owns this since 2015.
I work on this at Google, but Google no longer owns this since 2015.
This is great news, but I have to point it out. Some of the social media handles on the Board of Directors page are hilariously unreadable: https://foundation.rust-lang.org/board/
(Click the pictures to reveal them)
(Click the pictures to reveal them)
It works on hover for me. The orange text is hard to read against that background, though.
>(Click the pictures to reveal them)
Not working for me (iOS/safari). That's a bit weird.
Not working for me (iOS/safari). That's a bit weird.
Works fine in Firefox and Chrome in both Android and Windows. Looks like a Safari bug.
What's with the crabs? Is it an inside joke I'm not getting?
Awesome news! Rust is easily the best programming experience I've had--the language feels incredibly well thought out, common tooling like doc generation and dependency management are included with the language, and the compiler takes full advantage of language features such that my editor's linter is able to detect most mistakes I make and the language itself guards me from doing anything obviously unsafe. I thought the rewrite-everything Rust people were annoying and that turned me off initially, but ever since getting involved with the community I've found that it's full of lots of very passionate people working on a stunning variety of interesting new projects. You really feel like you're on the ground floor of the next generation of systems programming languages, enough to where I've even considered replacing my habitual use of Python with Rust considering how easy it is to write.
Seriously, it's worth your time to explore. If you have a spare evening and want to be enchanted, highly suggest giving the Rust book a gander: https://doc.rust-lang.org/stable/book/
Seriously, it's worth your time to explore. If you have a spare evening and want to be enchanted, highly suggest giving the Rust book a gander: https://doc.rust-lang.org/stable/book/
serious question : would you recommend Rust for CRUDdy type of web applications -- stuff where mostly you are firing off prepared statememts at a SQL db and then applying business logic to result set. This is what most J2EE apps do currently.
I currently do it and have no regrets, but I don't require a lot of fancy stuff that you might find the Java ecosystem.
If you don't have any need for concurrent sharing of data and never really miss having destructors in a managed language, then I'd guess that Rust wouldn't be a great fit for a CRUDy backend.
Scala and Kotlin are great choices there. They have good type systems (everyone loves Rust's enum types, which are just ADTs and exist in many other languages as well), they have garbage collection- so no borrow checker headaches, and they have the massive Java ecosystem if and when you need it.
On the other hand, all programming languages are greater than the sum of their parts. Rust is more than just a checklist of "borrow checker, fancy enums, no exceptions, move semantics, etc, etc". You might just love the language even if it's not "objectively" better for your use case than something else. That's where I am. I spent years doing C++ and I instantly fell in love with Rust. It's not perfect, but it's usually my first choice when doing almost any project. I only ask myself "Is Rust such a bad fit for this task that I'm significantly hindering myself?" and/or "Is FooLang so PERFECT for this task that not using it is stupid?".
If you don't have any need for concurrent sharing of data and never really miss having destructors in a managed language, then I'd guess that Rust wouldn't be a great fit for a CRUDy backend.
Scala and Kotlin are great choices there. They have good type systems (everyone loves Rust's enum types, which are just ADTs and exist in many other languages as well), they have garbage collection- so no borrow checker headaches, and they have the massive Java ecosystem if and when you need it.
On the other hand, all programming languages are greater than the sum of their parts. Rust is more than just a checklist of "borrow checker, fancy enums, no exceptions, move semantics, etc, etc". You might just love the language even if it's not "objectively" better for your use case than something else. That's where I am. I spent years doing C++ and I instantly fell in love with Rust. It's not perfect, but it's usually my first choice when doing almost any project. I only ask myself "Is Rust such a bad fit for this task that I'm significantly hindering myself?" and/or "Is FooLang so PERFECT for this task that not using it is stupid?".
don't get me wrong, I love rust and find it a great language for doing systems level stuff but it would be my last choice for a crudy type web application. Those are intrinsically IO bound. Sure, you might find a noticeable improvement if you're using something really slow like rails without any caching but there are plenty of garbage collected rapid development languages that will be fast enough that the visible performance difference will be dwarfed by the IO bottleneck.
There are already several languages that server that niche better. I myself use phoenix/elixir which is batteries included. I have a nice toolbox of production ready libraries. I can prototype/build endpoints much faster than I would in rust and the sub 200ms req/res times (including the database call) is plenty fast enough.
That said, there are a few things I'd consider rust for.
1.cpu intensive jobs - elixir and any language with c interop have rust interop and I'd be happy to delegate those jobs to a service written in rust.
2. optimized large data structures, discord did something akin to this for their chat system
3. serverless functions - having no runtime or garbage collector makes for a gloriously fast cold boot if you're into that sort of thing.
In short, While you CAN user rust for web development, I dont' think its appropriate for most web development related use cases if you're trying to develop software for a client. IF its for fun, Then by all means, go nuts! :)
There are already several languages that server that niche better. I myself use phoenix/elixir which is batteries included. I have a nice toolbox of production ready libraries. I can prototype/build endpoints much faster than I would in rust and the sub 200ms req/res times (including the database call) is plenty fast enough.
That said, there are a few things I'd consider rust for.
1.cpu intensive jobs - elixir and any language with c interop have rust interop and I'd be happy to delegate those jobs to a service written in rust.
2. optimized large data structures, discord did something akin to this for their chat system
3. serverless functions - having no runtime or garbage collector makes for a gloriously fast cold boot if you're into that sort of thing.
In short, While you CAN user rust for web development, I dont' think its appropriate for most web development related use cases if you're trying to develop software for a client. IF its for fun, Then by all means, go nuts! :)
> Those are intrinsically IO bound.
Rust has a great async story compared to other languages, which benefits IO-bound workloads even more so than CPU-busy ones.
Rust has a great async story compared to other languages, which benefits IO-bound workloads even more so than CPU-busy ones.
I disagree.
Saying that it is "great" is really overselling it at this point, unless the languages you're comparing to are mainly C or C++. I would also toss Ruby in that category for now, but they seem to be working on making async better with Ruby 3+.
When compared to Python, JavaScript, or C#... Rust's language support for async isn't really that impressive to most developers, although the implementation has some technical characteristics that are nice for people who care about the low level details. The ecosystem is pretty lacking, even though it is much better than it was a few years ago.
Compared to the aforementioned languages (including Rust), Go and BEAM-based languages are just on another level.
I'm sure both Rust's language ergonomics and the ecosystem will improve over time, but Rust's goals also make it unlikely to ever be compatible with my definition of a great async system... which is the model Go and Erlang use where the developer can't tell that every single sequential process isn't running in a separate OS thread -- and, by extension, every function is automatically async with no distinction that I have to worry about.
In Go, I can spin up as many goroutines as I need, and I don't have to worry about any single goroutine blocking an executor like I have to worry about in Rust.
Yes, some async runtimes in Rust have worked on clever things like monitoring the executor threads and spawning a new executor to steal a blocked executor's work queue... maybe some day that will be a battle tested solution. Like most of the Rust async story, there are rough edges that could benefit from some more time.
(I have worked professionally with both Rust and Go for several years, and I think they're both great languages with different trade offs... I'm not trying to bash Rust here.)
Saying that it is "great" is really overselling it at this point, unless the languages you're comparing to are mainly C or C++. I would also toss Ruby in that category for now, but they seem to be working on making async better with Ruby 3+.
When compared to Python, JavaScript, or C#... Rust's language support for async isn't really that impressive to most developers, although the implementation has some technical characteristics that are nice for people who care about the low level details. The ecosystem is pretty lacking, even though it is much better than it was a few years ago.
Compared to the aforementioned languages (including Rust), Go and BEAM-based languages are just on another level.
I'm sure both Rust's language ergonomics and the ecosystem will improve over time, but Rust's goals also make it unlikely to ever be compatible with my definition of a great async system... which is the model Go and Erlang use where the developer can't tell that every single sequential process isn't running in a separate OS thread -- and, by extension, every function is automatically async with no distinction that I have to worry about.
In Go, I can spin up as many goroutines as I need, and I don't have to worry about any single goroutine blocking an executor like I have to worry about in Rust.
Yes, some async runtimes in Rust have worked on clever things like monitoring the executor threads and spawning a new executor to steal a blocked executor's work queue... maybe some day that will be a battle tested solution. Like most of the Rust async story, there are rough edges that could benefit from some more time.
(I have worked professionally with both Rust and Go for several years, and I think they're both great languages with different trade offs... I'm not trying to bash Rust here.)
You are right, but this project (or a similar one) who uses WASM based rust nano processes has the potential to leave Go and Erlang in the dust: https://github.com/lunatic-solutions/lunatic
That project does look really fun!
I can't tell if that is pulling V8 in as the WASM interpreter or not. Obviously, I would prefer that they leave others in the dust without having to pull in a huge C++ codebase, but it still sounds promising either way!
I can't tell if that is pulling V8 in as the WASM interpreter or not. Obviously, I would prefer that they leave others in the dust without having to pull in a huge C++ codebase, but it still sounds promising either way!
There is no V8 here, you don't need a JS VM to run WASM. It uses wasmer, a Rust based WASM VM: https://github.com/wasmerio/wasmer
Awesome! I had heard of wasmer before, but I didn't realize its performance was that good yet. I'll definitely be paying closer attention to this space now.
Although, on closer inspection it seems like wasmer is using LLVM as a backend to get that good performance, which tempers my enthusiasm a little bit. I see that wasmer also supports the Cranelift backend, but the promised performance blog post[1] doesn't seem to have been published yet, so I don't know how much of a difference that makes in the real world.
A ~13x difference in JIT compile time (LLVM vs Cranelift) is huge, and waiting on LLVM itself to compile can also be... exciting. LLVM does good work for AOT compilation, but I don't know how I feel about the trade-offs of using it as a JIT. If a massive C++ code base is going to be pulled in anyways, I would almost rather them pull in V8 than LLVM... but that's just my opinion, since V8 seems to be very well optimized for the JIT use case.
But, I'm glad there is the choice to use Cranelift (and presumably exclude LLVM from the final binary) if that fits a particular use case, and I'm excited to see that follow-up blog post whenever the wasmer team has time to publish it.
[1]: https://medium.com/wasmer/wasmer-1-0-3f86ca18c043
Although, on closer inspection it seems like wasmer is using LLVM as a backend to get that good performance, which tempers my enthusiasm a little bit. I see that wasmer also supports the Cranelift backend, but the promised performance blog post[1] doesn't seem to have been published yet, so I don't know how much of a difference that makes in the real world.
A ~13x difference in JIT compile time (LLVM vs Cranelift) is huge, and waiting on LLVM itself to compile can also be... exciting. LLVM does good work for AOT compilation, but I don't know how I feel about the trade-offs of using it as a JIT. If a massive C++ code base is going to be pulled in anyways, I would almost rather them pull in V8 than LLVM... but that's just my opinion, since V8 seems to be very well optimized for the JIT use case.
But, I'm glad there is the choice to use Cranelift (and presumably exclude LLVM from the final binary) if that fits a particular use case, and I'm excited to see that follow-up blog post whenever the wasmer team has time to publish it.
[1]: https://medium.com/wasmer/wasmer-1-0-3f86ca18c043
Syrus here, from Wasmer.
Thanks for the kind words!
There are some nice opportunities to bring LLVM compilation times closer to the optimal ones in multithreaded environments. We are currently working towards that and hope to get something tangible in next releases... stay tuned!
Thanks for the kind words!
There are some nice opportunities to bring LLVM compilation times closer to the optimal ones in multithreaded environments. We are currently working towards that and hope to get something tangible in next releases... stay tuned!
when its ready, I'll be happy to try it. That said, the BEAM codebase is around 30 years old and indestructibly stable while being pretty damn fast. Its going to be awhile before anything with teh same goals catches up.
Also one of the reasons I'm looking forward to Java's Project Loom. It seems Go/Elixir/Java have went for the `virtual threading` path to simplify the dev experience greatly.
Not compared to Elixir. It's hard to beat lightweight processes for concurrency. I've used Rust, but I'm doing my webapp in Elixir.
You're in a Rust thread, I think the general response is going to be, "Yes!"
And I personally, say yes. But that comes with some caveats. You will be entering an ecosystem that doesn't have all the libraries that folks coming from the rich history of Java has, so you will most likely be signing up for some extra work.
But, this is also a great opportunity, because it means that you could be responsible for building a missing library or feature.
And I personally, say yes. But that comes with some caveats. You will be entering an ecosystem that doesn't have all the libraries that folks coming from the rich history of Java has, so you will most likely be signing up for some extra work.
But, this is also a great opportunity, because it means that you could be responsible for building a missing library or feature.
"But, this is also a great opportunity, because it means that you could be responsible for building a missing library or feature. "
Ok, so this is an 'opportunity' for some, but a 'big cost' for others.
So remember there are very few Rust devs out there, it is a little bit hard, and though a good chunk of devs might jump at the chance to learn, others, not so much.
It would be a really hard thing to rationally do a 'crud app in Rust' at this moment in time due to all the above reasons. There's a lot of added risk for really no benefits.
If you have a core team that has the skills, ability and is willing to commit to it, then maybe. But we have to think beyond that, when you need another 100 devs ... and people maintaining it ... one can see how other things factor into the equation.
If there is some specific reason and the conditions are right, and if that reasoning is not warped by our own natural tendencies to 'want to use Rust' then there might be an opportunity ... but generally not.
As team members get more excited about 'the problem they are solving' and less 'the tools they use' - you might see an inclination towards other tools, for the most part, at least today, for CRUD-ish kinds of things.
Ok, so this is an 'opportunity' for some, but a 'big cost' for others.
So remember there are very few Rust devs out there, it is a little bit hard, and though a good chunk of devs might jump at the chance to learn, others, not so much.
It would be a really hard thing to rationally do a 'crud app in Rust' at this moment in time due to all the above reasons. There's a lot of added risk for really no benefits.
If you have a core team that has the skills, ability and is willing to commit to it, then maybe. But we have to think beyond that, when you need another 100 devs ... and people maintaining it ... one can see how other things factor into the equation.
If there is some specific reason and the conditions are right, and if that reasoning is not warped by our own natural tendencies to 'want to use Rust' then there might be an opportunity ... but generally not.
As team members get more excited about 'the problem they are solving' and less 'the tools they use' - you might see an inclination towards other tools, for the most part, at least today, for CRUD-ish kinds of things.
Everything you stated, is literally the reason I said there are caveats, I find it interesting you decided to expand on that, but quoted the second part, pretty much out of context.
Nothing you said is wrong per se, but it’s also not entirely accurate. First, there are very good db connection libraries available to Rust users, with good connection pooling options. Second there are good ORMs if that’s something you enjoy using. Third there are excellent application server options in Rocket and Actix available.
Your comment implies these don’t exist. It’s more the edge cases, and the things outside the DB that will be issues. And even there, you’d need to get into specific areas that would cause issues due to lack of available implementations.
In terms of developers out there that want to work with a language, there’s no better response to that than it’s “the most loved language”, and that may translate to many people adopting and expanding its use.
Nothing you said is wrong per se, but it’s also not entirely accurate. First, there are very good db connection libraries available to Rust users, with good connection pooling options. Second there are good ORMs if that’s something you enjoy using. Third there are excellent application server options in Rocket and Actix available.
Your comment implies these don’t exist. It’s more the edge cases, and the things outside the DB that will be issues. And even there, you’d need to get into specific areas that would cause issues due to lack of available implementations.
In terms of developers out there that want to work with a language, there’s no better response to that than it’s “the most loved language”, and that may translate to many people adopting and expanding its use.
Rust for CRUD is not a 'Yes with Caveats' - it's a 'No' in all but some very specific cases, and even then it's a 'maybe'.
It's outclassed by other stacks in almost every way for this purpose, and provides no material advantage most of these scenarios. Null safety never was a problem in CRUD apps, and, though performance usually is, it never boils down to 'speed of execution'. And of course, the long list of disadvantages, the most obvious of which is inflexible and slow development, especially in scenarios that require adaptation.
I can't think of a scenario wherein it would make sense for a CRUD app. Some associated micro-services, sure, but not for the core of the app.
It's outclassed by other stacks in almost every way for this purpose, and provides no material advantage most of these scenarios. Null safety never was a problem in CRUD apps, and, though performance usually is, it never boils down to 'speed of execution'. And of course, the long list of disadvantages, the most obvious of which is inflexible and slow development, especially in scenarios that require adaptation.
I can't think of a scenario wherein it would make sense for a CRUD app. Some associated micro-services, sure, but not for the core of the app.
That is a very narrow perspective on the usefulness of languages and glosses over all the other reasons why someone would want to use Rust. You do it because you like the language, with the caveat that you may have extra dev work to fill in gaps.
As a Rust dev coming from Java, I will tell you nulls and proper error handling in Java are still major runtime issues, a cause for many rollbacks and emergency fixes.
There is even the promise now with wasm and other tools to use Rust from the bottom to the top of the stack without any compromises (in terms of performance, memory usage, or type safety).
Rust might not be the language for you and that’s fine, but your opinion is not shared by everyone.
As a Rust dev coming from Java, I will tell you nulls and proper error handling in Java are still major runtime issues, a cause for many rollbacks and emergency fixes.
There is even the promise now with wasm and other tools to use Rust from the bottom to the top of the stack without any compromises (in terms of performance, memory usage, or type safety).
Rust might not be the language for you and that’s fine, but your opinion is not shared by everyone.
> And of course, the long list of disadvantages, the most obvious of which is inflexible and slow development
This claim requires some data to back it up. I know at least a few people (including myself) who are more productive in Rust than in other mainstream languages typically used for CRUDs like Java, C#, Python, Ruby or PHP.
This claim requires some data to back it up. I know at least a few people (including myself) who are more productive in Rust than in other mainstream languages typically used for CRUDs like Java, C#, Python, Ruby or PHP.
That's what Go is for. I've said this before. Go has all those well-exercised packages for doing web applications.
Rust is for harder problems. The ones you'd otherwise have to do in C++. I'm working on a client for a virtual world in Rust, and it is far easier in Rust than it would be in C++. Full 3D, GPU usage, networking, lots of state, a constantly changing big world through which you can move, compute bound, multiple threads. All my code is in safe Rust, and I've never had to use a debugger.
Write your embedded software in Rust. Write your networking software in Rust. Write databases in Rust. Write browsers in Rust. Write complex games in Rust. For ordinary server side web jobs, it's overkill.
Rust is for harder problems. The ones you'd otherwise have to do in C++. I'm working on a client for a virtual world in Rust, and it is far easier in Rust than it would be in C++. Full 3D, GPU usage, networking, lots of state, a constantly changing big world through which you can move, compute bound, multiple threads. All my code is in safe Rust, and I've never had to use a debugger.
Write your embedded software in Rust. Write your networking software in Rust. Write databases in Rust. Write browsers in Rust. Write complex games in Rust. For ordinary server side web jobs, it's overkill.
Go is clearly not for crud web apps. For that you have all the rails clone that’ll autogenerate pretty much everything, and has a predetermined path for every situation. Or the enterprisy version, with a decent orm, if you want type-safety.
Go is for system-level programming that mainly consists of plumbing api endpoints together. i would recommend it for building middlewares in a server environment
Go is for system-level programming that mainly consists of plumbing api endpoints together. i would recommend it for building middlewares in a server environment
Looking for a virtual world in Rust, is yours on github?
I'm working on a little crud project. It uses rust all the way down, with actix-web as the http framework and sled as an embedded key value store. The idea is to replace the complexity and expense of using many nodes with one node that's extremely fast.
It's been a slow side project for the last month learning the ecosystem and figuring out how to properly deal with types etc.
But now I have a page that uses an opaque cookie stored in the database to identify the logged in user and return proof of success in a rendered template. My goal was to keep server latency for that request below a millisecond, and it ended up being about 100 microseconds on my laptop, so 10 times faster than I was hoping for. I'm just not sure how I could have achieved that with, for example, Django.
So I guess what I'm saying is that it's slow and challenging for me, at least in the beginning. But it's getting faster and easier over time. And in the end, I'm creating something with performance and reliability that would be hard to achieve in another way.
It's been a slow side project for the last month learning the ecosystem and figuring out how to properly deal with types etc.
But now I have a page that uses an opaque cookie stored in the database to identify the logged in user and return proof of success in a rendered template. My goal was to keep server latency for that request below a millisecond, and it ended up being about 100 microseconds on my laptop, so 10 times faster than I was hoping for. I'm just not sure how I could have achieved that with, for example, Django.
So I guess what I'm saying is that it's slow and challenging for me, at least in the beginning. But it's getting faster and easier over time. And in the end, I'm creating something with performance and reliability that would be hard to achieve in another way.
> I'm just not sure how I could have achieved that with, for example, Django.
Impossible.
Also look at startup time, disk size for installation...
But the real benefit is when you want to hack/refactor your code months or years later (or someone else working on the code): languages with strong type systems can help prevent sooo many error in those cases. Compare that to Python where many errors are only discovered runtime.
Impossible.
Also look at startup time, disk size for installation...
But the real benefit is when you want to hack/refactor your code months or years later (or someone else working on the code): languages with strong type systems can help prevent sooo many error in those cases. Compare that to Python where many errors are only discovered runtime.
I'm mostly a rails developer and really want to get into Rust. I went through the tutorial and did some practice on Excersism. I'm not a rust expert but I enjoyed working with it and learning about it.
With that disclaimer: as of now, what rust lacks is a comprehensive framework for web development.
I'm sure your story in the J2EE world is similar to rails: you have libraries that you can use to abstract away a lot of repetitive things such as authentication. You probably also have a framework-aware test suite that integrates with something like Selenium. You may have abstractions around javascript build systems like Rails' webpacker that allow you to easily integrate SPAs directly into your app using the same overall tooling. There's so much code you don't have to write, and you probably don't think much about it, and you probably just take it for granted.
This is not the story with Rust. There are some frameworks such as Rocket you can reach for, but when I evaluated the situation ~6 months ago I realized I couldn't justify using Rust for this yet. From a web development perspective, there was just too much busy work you'd need to do.
I don't think this is an inherent limitation of the language, by the way. I think Rust is a lot of fun to work with and I wouldn't hesitate to use it once a more robust library ecosystem is developed for this use case. I'm always keeping an eye open for places where it would fit what I do, like a small performance-sensitive microservice for example. The type system is powerful, it's great (as a Ruby developer who last worked with C++ a long time ago) to work with a compiled language again. The type system, Rust linter, and compiler together catch many classes of trivial errors that you need to test against in Ruby.
I hope it'll get there one day!
With that disclaimer: as of now, what rust lacks is a comprehensive framework for web development.
I'm sure your story in the J2EE world is similar to rails: you have libraries that you can use to abstract away a lot of repetitive things such as authentication. You probably also have a framework-aware test suite that integrates with something like Selenium. You may have abstractions around javascript build systems like Rails' webpacker that allow you to easily integrate SPAs directly into your app using the same overall tooling. There's so much code you don't have to write, and you probably don't think much about it, and you probably just take it for granted.
This is not the story with Rust. There are some frameworks such as Rocket you can reach for, but when I evaluated the situation ~6 months ago I realized I couldn't justify using Rust for this yet. From a web development perspective, there was just too much busy work you'd need to do.
I don't think this is an inherent limitation of the language, by the way. I think Rust is a lot of fun to work with and I wouldn't hesitate to use it once a more robust library ecosystem is developed for this use case. I'm always keeping an eye open for places where it would fit what I do, like a small performance-sensitive microservice for example. The type system is powerful, it's great (as a Ruby developer who last worked with C++ a long time ago) to work with a compiled language again. The type system, Rust linter, and compiler together catch many classes of trivial errors that you need to test against in Ruby.
I hope it'll get there one day!
actix-web seems really interesting, just from some cursory reading.
Also, from a performance standpoint, it seems to be _really_ good: https://www.techempower.com/benchmarks/
This example in particular piqued my interest: https://github.com/actix/examples/blob/master/async_pg/src/m...
I have no experience in Rust whatsoever, but I feel inspired to try it out.
Also, from a performance standpoint, it seems to be _really_ good: https://www.techempower.com/benchmarks/
This example in particular piqued my interest: https://github.com/actix/examples/blob/master/async_pg/src/m...
I have no experience in Rust whatsoever, but I feel inspired to try it out.
We are doing some web backend stuff in Rust at Oxide, my colleagues gave a talk on it: https://www.youtube.com/watch?v=EmSjZbSzA3A
The TL;DR is it may or may not make sense for you. Engineering! We are finding it valuable, but you may have different needs than we do. Ecosystem maturity is variable.
The TL;DR is it may or may not make sense for you. Engineering! We are finding it valuable, but you may have different needs than we do. Ecosystem maturity is variable.
I just launched a jigsaw puzzle website last week that has a backend API written in Rust and uses the postgres crate [1].
Since this is a side project for me, there wasn't much risk if it ended up being a bad decision. Multiple times throughout the project I got frustrated with the DX of existing http frameworks I tried and ended up building my own [2] on top of hyper. However, after launching my site and seeing how it performs in production, I could not be happier with the result! I had a bit of Rust experience before the project but learned a lot more through building this.
For you and others, I think it really depends on the situation. Building a Rust CRUD app will likely take longer than the other languages you're used to as the ecosystem is under heavy development, especially with async/await. So if you or your team are in a rush, I'll just echo that you should build with the tools you already know. If you have time and budget to experiment like I did, it might be worthwhile and I can promise it will be fun :)
[1]: https://github.com/sfackler/rust-postgres
[2]: https://twitter.com/jakedeichert/status/1205230350160539650
Since this is a side project for me, there wasn't much risk if it ended up being a bad decision. Multiple times throughout the project I got frustrated with the DX of existing http frameworks I tried and ended up building my own [2] on top of hyper. However, after launching my site and seeing how it performs in production, I could not be happier with the result! I had a bit of Rust experience before the project but learned a lot more through building this.
For you and others, I think it really depends on the situation. Building a Rust CRUD app will likely take longer than the other languages you're used to as the ecosystem is under heavy development, especially with async/await. So if you or your team are in a rush, I'll just echo that you should build with the tools you already know. If you have time and budget to experiment like I did, it might be worthwhile and I can promise it will be fun :)
[1]: https://github.com/sfackler/rust-postgres
[2]: https://twitter.com/jakedeichert/status/1205230350160539650
I have a app that have been ported from old python -> f# -> rust (e-commerce like) and the transition was great (https://www.reddit.com/r/rust/comments/hh9tz6/does_rust_have...).
You need to pay attention in how align the whole software stack. Pairing Rust with tailwinds and htmx or Hotwire simplify so much stuff is like cheating.
For regular CRUD flows having enums/traits/iterators make domain modeling very good and found is more productive to me than F#/Python at the domain layer.
I do my own micro SQL-orm layer (I have the need to talk to +6 RDBMS and be dynamic at runtime), and most db libraries in the rust ecosystem are mature enough now.
I find recently the whole auth is not as mature as you find with Django (aka: Not need to code part of it, you can certainly do it manually), but anyway is now better to offload to key cloak or similar.
You need to pay attention in how align the whole software stack. Pairing Rust with tailwinds and htmx or Hotwire simplify so much stuff is like cheating.
For regular CRUD flows having enums/traits/iterators make domain modeling very good and found is more productive to me than F#/Python at the domain layer.
I do my own micro SQL-orm layer (I have the need to talk to +6 RDBMS and be dynamic at runtime), and most db libraries in the rust ecosystem are mature enough now.
I find recently the whole auth is not as mature as you find with Django (aka: Not need to code part of it, you can certainly do it manually), but anyway is now better to offload to key cloak or similar.
Could you comment a bit more on how Rust let you model the domain better than F# did?
The thing with F# is that (idiomatic) models/functions rely on type inference, and eventually is hard to see what is the flow without look at the IDE. Rust making type annotations explicit with minimal inference is much clearer.
Also, the fact I can do mutation + imperative code locally yet give a functional feel make some hacks around this on F# unnecessary.
But probably the biggest thing is that Rust make idiomatic things like conversions with From/Into/AsRef/etc instead of rely in your own conventions, making code more readable in the long run.
Other source of simplification is serde. A lot of my stuff is transfer/(re)encoding of data and have a "de facto" idiom for this help a lot.
One thing that F# make far easier and I miss much is the sequences (https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...). Making iterators is boilerplate and wish Rust have generators in stable.
I found a decent library for this in https://lib.rs/crates/genawaiter but is not the same as have it in-build.
Also, the fact I can do mutation + imperative code locally yet give a functional feel make some hacks around this on F# unnecessary.
But probably the biggest thing is that Rust make idiomatic things like conversions with From/Into/AsRef/etc instead of rely in your own conventions, making code more readable in the long run.
Other source of simplification is serde. A lot of my stuff is transfer/(re)encoding of data and have a "de facto" idiom for this help a lot.
One thing that F# make far easier and I miss much is the sequences (https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...). Making iterators is boilerplate and wish Rust have generators in stable.
I found a decent library for this in https://lib.rs/crates/genawaiter but is not the same as have it in-build.
Admittedly I work for a very opinionated team - we even have our own style guidelines (https://github.com/G-Research/fsharp-formatting-conventions) which are often in direct contradiction to Microsoft's, and my team strongly skews towards writing explicit type annotations on all function signatures. I can certainly see how there would be a problem if one defaulted to omitting type annotations.
Can you share a bit about how you’ve integrated Hotwire with Rust? I recently wondered how well they’d pair.
I use htmx, just pointing Hotwire will be similar.
With this kind of library, your rust code is the same as processing regular html forms, is only the HTML that need to be annotated.
MAYBE you could optimize partial rendering detecting just the portion to change:
https://htmx.org/docs/#requests
But I not bother with that.
With this kind of library, your rust code is the same as processing regular html forms, is only the HTML that need to be annotated.
MAYBE you could optimize partial rendering detecting just the portion to change:
https://htmx.org/docs/#requests
But I not bother with that.
I mean you could certainly do it in Rust. I am not sure I would recommend it though. The dev time for rust will naturally be slower because the developer will have to take more into consideration.
Additionally while the community is growing rapidly you wont find the same depth of ecosystem that you have with Java. Client libraries will be half baked and still be a work in progress a lot of the time.
If the business stuff is not performance or time sensitive it would probably be better to use something like Java/Go/Python, maybe elixir, that will have good turn around time with reasonable performance.
A good litmus test for the moment is probably "Would I write this in C++ five years ago?" if yes Rust might be a good option today with a few caveats, like GUI or GPU programming still being in their relative infancy in Rust.
Additionally while the community is growing rapidly you wont find the same depth of ecosystem that you have with Java. Client libraries will be half baked and still be a work in progress a lot of the time.
If the business stuff is not performance or time sensitive it would probably be better to use something like Java/Go/Python, maybe elixir, that will have good turn around time with reasonable performance.
A good litmus test for the moment is probably "Would I write this in C++ five years ago?" if yes Rust might be a good option today with a few caveats, like GUI or GPU programming still being in their relative infancy in Rust.
hmm, no. While compile-time type check[0] for SQL queries changes your whole experience of how you do SQL, at the end of the day creating an webapp in rust is not as easy or mature as any of the other languages more suited for the task. If you want to learn, then its fine. But if you are newish to rust and want to do your next CRUD app at work in rust, I don't think its going to a good experience.
[0]: https://github.com/launchbadge/sqlx
[0]: https://github.com/launchbadge/sqlx
Reddit thread about this question from yesterday: https://www.reddit.com/r/rust/comments/leki5o/advantages_of_...
The ecosystems that support creating CRUD apps are more mature in other languages.
I have some extensive (self-assesment :) ) experience building this kind of application, and my answer would be "no, but maybe" (I was one of the first engineers & architect on our zero to ~500k codebase).
Some of the arbitrary, random things I've learned:
1. Given how nice and powerful language is, Rust works relatively well with less experienced engineers. Potentially. You can build very nice APIs which are straightforward to use.
If you can stay in this territory, everything is great.
However, there are some hard walls in Rust which are really difficult to jump over. And once you hit them, you really need somebody who understands Rust really really well and is capable of working around those issues.
2. It was quite hard to find the right balance between engineering time, compilation/linking time, safety, ease of use, performance, etc. Might be my personal biases, but I had to make some questionable decisions to keep compilation times / turnaround times at bay (like, unsound plugin system, custom serialization framework or test framework using nightly Rust features).
3. The type system is really, really nice. This alone compensates for a lot of things.
4. Ecosystem? Simply amazing. High quality libraries, documentation and everything.
5. Ecosystem again? Lots of things are still missing.
6. Performance? I'm 90% trolling here, but my experience was that Rust is not "blazing fast" by default. Not for "enterprise" software. You have to do some legwork sometimes. I've built some simple tool to do certain transformation between JSON and XML, and out of gate it was ~2x slower than Java equivalent (yes, with release build). Turned out, strings are not that cheap to clone if all you have is a bunch of strings. I did make it like 5x times faster than Java in the end, but it did require some weird tricks (like forcing hash map to look for a "derived" key than I give it).
There were some other cases where performance was reduced by simple things (like, having "heavy" Result vs having error variant boxed).
I think, this is "easily" counteracted by adopted practices and libraries (optimized error types, for instance), some standard patterns (like don't be afraid of Arc, they are better than to move huge data chunks around), maybe, good profilers as well.
This is probably also my biases talking here, frankly, I don't think it mattered at all (performance was killed by database, as is very common with enterprise systems). Also, in the end, it was fast (outside of database woes).
7. Overall, I find Rust very exciting language to work with, which was a big driver (but that doesn't necessarily scale -- you'll have to have some answer prepared when less experienced engineers will ask you "but why can't I do like I did in Typescript in those trivial 500 lines of code").
Would I do it again? Probably, but with understanding that whoever pays for it, might be paying for my "fun" on top of the product they are getting. Which is not necessarily a bad thing -- "fun" is also a factor in attraction and retention of engineers.
I'm also not going to lean into the "dark side". Like, if all you care is to get some half-broken whatever out as quick as possible, Rust might not be the right choice. It makes you think about "right or wrong" a lot, imo.
Some of the arbitrary, random things I've learned:
1. Given how nice and powerful language is, Rust works relatively well with less experienced engineers. Potentially. You can build very nice APIs which are straightforward to use.
If you can stay in this territory, everything is great.
However, there are some hard walls in Rust which are really difficult to jump over. And once you hit them, you really need somebody who understands Rust really really well and is capable of working around those issues.
2. It was quite hard to find the right balance between engineering time, compilation/linking time, safety, ease of use, performance, etc. Might be my personal biases, but I had to make some questionable decisions to keep compilation times / turnaround times at bay (like, unsound plugin system, custom serialization framework or test framework using nightly Rust features).
3. The type system is really, really nice. This alone compensates for a lot of things.
4. Ecosystem? Simply amazing. High quality libraries, documentation and everything.
5. Ecosystem again? Lots of things are still missing.
6. Performance? I'm 90% trolling here, but my experience was that Rust is not "blazing fast" by default. Not for "enterprise" software. You have to do some legwork sometimes. I've built some simple tool to do certain transformation between JSON and XML, and out of gate it was ~2x slower than Java equivalent (yes, with release build). Turned out, strings are not that cheap to clone if all you have is a bunch of strings. I did make it like 5x times faster than Java in the end, but it did require some weird tricks (like forcing hash map to look for a "derived" key than I give it).
There were some other cases where performance was reduced by simple things (like, having "heavy" Result vs having error variant boxed).
I think, this is "easily" counteracted by adopted practices and libraries (optimized error types, for instance), some standard patterns (like don't be afraid of Arc, they are better than to move huge data chunks around), maybe, good profilers as well.
This is probably also my biases talking here, frankly, I don't think it mattered at all (performance was killed by database, as is very common with enterprise systems). Also, in the end, it was fast (outside of database woes).
7. Overall, I find Rust very exciting language to work with, which was a big driver (but that doesn't necessarily scale -- you'll have to have some answer prepared when less experienced engineers will ask you "but why can't I do like I did in Typescript in those trivial 500 lines of code").
Would I do it again? Probably, but with understanding that whoever pays for it, might be paying for my "fun" on top of the product they are getting. Which is not necessarily a bad thing -- "fun" is also a factor in attraction and retention of engineers.
I'm also not going to lean into the "dark side". Like, if all you care is to get some half-broken whatever out as quick as possible, Rust might not be the right choice. It makes you think about "right or wrong" a lot, imo.
> Turned out, strings are not that cheap to clone if all you have is a bunch of strings.
Yeah, if you're doing a lot of cloning, you'll probably run into performance issues at some point. A common way to solve that problem is usually to use references instead of cloning.
Of course, writing your code that way takes more work/thought/planning.
Yeah, if you're doing a lot of cloning, you'll probably run into performance issues at some point. A common way to solve that problem is usually to use references instead of cloning.
Of course, writing your code that way takes more work/thought/planning.
>A common way to solve that problem is usually to use references instead of cloning.
Right. I think, we ended up with having everything from the list:
1. String 2. &str 3. Cow<str> 4. Arc<str>, for interned strings (thin Arc would be even better & there is probably a crate for this) 5. Something like owning_ref::ArcRef<Owner, str> 6. One-off tricks where you actually need to construct a new string, but don't want to really construct it (for example, for hash lookup).
#5 I think is undervalued, actually; it's amazing for "enterprise" kind of stuff where you have large trees of data you need to pass around & you don't want to use straight borrowing (like &'a Whatever) because lifetimes are too infectious. And you don't want to use Arc at every corner (like, say, Java would do, not quite, but in semantics).
My problem, though, was to explain all the nuances given that they usually have nothing to do with the "business" part of the problem somebody was solving.
Right. I think, we ended up with having everything from the list:
1. String 2. &str 3. Cow<str> 4. Arc<str>, for interned strings (thin Arc would be even better & there is probably a crate for this) 5. Something like owning_ref::ArcRef<Owner, str> 6. One-off tricks where you actually need to construct a new string, but don't want to really construct it (for example, for hash lookup).
#5 I think is undervalued, actually; it's amazing for "enterprise" kind of stuff where you have large trees of data you need to pass around & you don't want to use straight borrowing (like &'a Whatever) because lifetimes are too infectious. And you don't want to use Arc at every corner (like, say, Java would do, not quite, but in semantics).
My problem, though, was to explain all the nuances given that they usually have nothing to do with the "business" part of the problem somebody was solving.
> My problem, though, was to explain all the nuances given that they usually have nothing to do with the "business" part of the problem somebody was solving.
Yeah, I completely agree. A GC provides a lot of benefits in terms of clarifying the intention of business logic.
Unless, of course, performance/memory usage is an important part of your business logic, in which case Rust is exactly what you want.
Yeah, I completely agree. A GC provides a lot of benefits in terms of clarifying the intention of business logic.
Unless, of course, performance/memory usage is an important part of your business logic, in which case Rust is exactly what you want.
Maybe I'm weird, but I find the explicit ownership, mutability and lifetime information encoded in Rust definitions very helpful at understanding a new code-base. Something that otherwise needs to be documented in comments / external documentation in Java, but most often it is missing, and then recovering such information from the code is similarly hard to recovering the types in a dynamic language.
Lack of GC in makes it harder to write but easier to read.
Lack of GC in makes it harder to write but easier to read.
It gives you a lot more information, but a lot of that information is more about lower-level mechanics than "business logic". I think it really depends on what you're writing and what's important to it.
It can be actually tied pretty well to business logic. You can explicitly model some business rules, e.g. a subscription cannot exceed the lifetime of the user account, etc. Similar to how you can use static type system to prohibit invalid states. Here Rust gives more tools of this kind, than other languages.
Another one I really love is ability to destroy objects on final operation. E.g you close something and it can't be used any more. Most other languages can protect using such closed object only with runtime exceptions.
Some languages like Java don't even make a distinction between "object A is composed of B and C" vs "uses B and C" (in both cases they'd be references)
Another one I really love is ability to destroy objects on final operation. E.g you close something and it can't be used any more. Most other languages can protect using such closed object only with runtime exceptions.
Some languages like Java don't even make a distinction between "object A is composed of B and C" vs "uses B and C" (in both cases they'd be references)
Or, to get the computational equivalent of what Java is doing (immutable, interned strings), use a Rust string interning library like what servo uses [1], or just `Arc<str>`
[1]: https://docs.rs/string_cache/
[1]: https://docs.rs/string_cache/
I love Node for those types of situations... that said, it's sometimes useful to optimize certain portions of applications depending on the need.
Can't speak to Rust, but this is a sweet spot for Golang for sure.
> Rust is easily the best programming experience I've had
When you make this statement, what languages are you comparing it against?
When you make this statement, what languages are you comparing it against?
Currently: C, C++, Python, Go, JS, C#, Java, Lua (if that counts), Kotlin, Julia, Scala. I've dabbled in a bunch of other ones but haven't made anything noteworthy with them.
You may notice a lack of other modern compiled languages like Zig, so take that bias in mind :)
You may notice a lack of other modern compiled languages like Zig, so take that bias in mind :)
I'm not trolling. I'm genuinely curious. I've always thought of languages just as tools and have never been fanatic about a particular one. I personally like C and Java but have no problem using other languages if they are the best for the job.
I'm really curious to know what makes rust so special? Mind you that I know nothing about it.
I'm really curious to know what makes rust so special? Mind you that I know nothing about it.
Algebraic data types[0], compile-time thread safety guarantees[1], async/await on embedded[2], type inference that can work backwards[3], blocks are expressions so you can return values from if statements[4], returning from while(true) loops[5], and iterators[6] that don't kill performance[7].
[0]: https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html...
[1]: https://doc.rust-lang.org/book/ch16-04-extensible-concurrenc...
[2]: https://lights0123.com/blog/2020/07/25/async-await-for-avr-w...
[3]: https://doc.rust-lang.org/book/ch03-02-data-types.html#data-...
[4]: https://doc.rust-lang.org/book/ch06-02-match.html#the-match-...
[5]: https://doc.rust-lang.org/book/ch03-05-control-flow.html#ret...
[6]: https://doc.rust-lang.org/book/ch13-02-iterators.html
[7]: https://doc.rust-lang.org/book/ch13-04-performance.html
[0]: https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html...
[1]: https://doc.rust-lang.org/book/ch16-04-extensible-concurrenc...
[2]: https://lights0123.com/blog/2020/07/25/async-await-for-avr-w...
[3]: https://doc.rust-lang.org/book/ch03-02-data-types.html#data-...
[4]: https://doc.rust-lang.org/book/ch06-02-match.html#the-match-...
[5]: https://doc.rust-lang.org/book/ch03-05-control-flow.html#ret...
[6]: https://doc.rust-lang.org/book/ch13-02-iterators.html
[7]: https://doc.rust-lang.org/book/ch13-04-performance.html
Hmm, have you ever finished any real world scale product in it? All those things you mentioned are mostly toys that mostly inexperienced programmers are only excited with.
RUST lacks in real world scalability and applicability, it's still toy language even after years of development.
RUST lacks in real world scalability and applicability, it's still toy language even after years of development.
I worked on two Rust projects over 500k LOC, one 800k LOC and one that's now at 1.5 million LOC.
Number one feature versus Kotlin, C++, C#, C, Haskell, Python, Ruby, etc. is how easy it is to refactor large-scale Rust code bases safely.
Refactoring a large C++ code-base is almost impossible to do correctly without introducing lots of bugs, undefined behavior, security vulnerabilities, etc.
We did a major refactor (completely parallelized an ~700k LOC application) in a relatively short span of time (6 months) in Rust without issues.
We are also not the only ones that did this. Mozilla tried to parallelize Firefox using C++, and this failed so hard, that they actually chose to develop Rust far enough first, to be able to do that in Rust instead, and all that work actually landed on Firefox a couple of years ago already. I wouldn't consider Firefox a "toy" project.
Number one feature versus Kotlin, C++, C#, C, Haskell, Python, Ruby, etc. is how easy it is to refactor large-scale Rust code bases safely.
Refactoring a large C++ code-base is almost impossible to do correctly without introducing lots of bugs, undefined behavior, security vulnerabilities, etc.
We did a major refactor (completely parallelized an ~700k LOC application) in a relatively short span of time (6 months) in Rust without issues.
We are also not the only ones that did this. Mozilla tried to parallelize Firefox using C++, and this failed so hard, that they actually chose to develop Rust far enough first, to be able to do that in Rust instead, and all that work actually landed on Firefox a couple of years ago already. I wouldn't consider Firefox a "toy" project.
The foundation member companies are some of the largest technology companies in the world, and are using Rust at scale.
I think there are quite a lot of real world scale projects written in Rust... At least for me as an embedded developer, Rust is really superior to C/C++. Although the ecosystem is not that mature and lacks vendor support, it is easier to read/write in Rust and expect the code to work.
Do you have any features that you think experienced programmers are excited with? Or features that are required to provide real world scalability and applicability?
Do you have any features that you think experienced programmers are excited with? Or features that are required to provide real world scalability and applicability?
Critical parts of AWS's Nitro are written in Rust, which powers all of their new high-performance computing—is that a "toy"? What about Dropbox's sync algorithm? You know, the one that runs on every computer with Dropbox installed that is their core business logic, powering file storage for more than 0.5B users? Firefox's Stylo and other parts? They still have hundreds of millions of users.
I learned VB, Java, python, "C++", C, JS, go, rust, "Real" C++, in roughly that order. The first c++ is basically writing c with classes. Enough to write Arduino stuff. The latter is learning modern ish c++14. Smart pointers, copy and move constructors, lots of boost, move semantics (I still don't grok &&). Also, interfacing with c++98 and C drivers. On top of that, Cmake for building complex c++ projects.
I thought rust had a steep learning curve and borrow mechanics were hard. Boy howdy, "Real" c++ makes rust look like a cake walk. C++ has basically all the borrow mechanics of rust, it's just verbose, tedious , idiosyncratic, and bolted on. Plus umpteen other ways to pass data around.
The package and build system just works.
IMHO The "only" real advantages c++ has over rust are momentum, availability, and the ability to natively use C can code. The mind share, library ecosystem, and ubiquity are unmatched. However I see a point where wrapping FFI becomes easy enough that this last advantage becomes a draw. The second is fixed by more compiler support.
Compared to Java, rust is less verbose, faster, less memory, and better abstractions, though I haven't touched Java in 5 years.
The rust experience is so much better than C++ that I see it continuously eating into mind share. I think the joy comes from the relief of frustration of working with automatic foot guns for years.
I thought rust had a steep learning curve and borrow mechanics were hard. Boy howdy, "Real" c++ makes rust look like a cake walk. C++ has basically all the borrow mechanics of rust, it's just verbose, tedious , idiosyncratic, and bolted on. Plus umpteen other ways to pass data around.
The package and build system just works.
IMHO The "only" real advantages c++ has over rust are momentum, availability, and the ability to natively use C can code. The mind share, library ecosystem, and ubiquity are unmatched. However I see a point where wrapping FFI becomes easy enough that this last advantage becomes a draw. The second is fixed by more compiler support.
Compared to Java, rust is less verbose, faster, less memory, and better abstractions, though I haven't touched Java in 5 years.
The rust experience is so much better than C++ that I see it continuously eating into mind share. I think the joy comes from the relief of frustration of working with automatic foot guns for years.
[deleted]
If you've never seriously used an ML-family language then you don't know what you're missing. Lots of popular languages are in a very narrow slice of the language space; you talk about "other languages" but you only mention C and Java which are very similar languages to each other in many respects.
It’s booming. I’m considering making Rust or Haskell a requirement for my current remote job search. And given that I have no strong salary requirements it’s actually going to work, could not have done this 4 years ago.
I found parts of that announcement very difficult to follow.
Can anyone tell me what the following means?
« For too long, open source as both an industry and a community has done a poor audit of its expenses. Notably, ignoring the price of what I’d controversially argue is the core value proposition of open source software: the freedom to collaborate. »
Can anyone tell me what the following means?
« For too long, open source as both an industry and a community has done a poor audit of its expenses. Notably, ignoring the price of what I’d controversially argue is the core value proposition of open source software: the freedom to collaborate. »
Here's my take: Collaborating in the open and communicating the results of discussions and the rationales for decisions to the wider community who wasn't present for the discussions has a high time cost. It seems the core rust team has put a lot of effort into making decisions in the open, which increases freedom to collaborate.
I read it as a reference to the problem of maintainer burnout in the face of unbounded input from users and collaborators. This is something the Rust project has been dealing with and thinking about for a while.
Just a throwaway line, written, no doubt, in a fit of high-mindedness.
A win for Rust for sure, but it also seems like a loss for Mozilla.
This is a very good "partial exit" for Mozilla, actually. The original plan might be to do something like this to split the cost, while oxidized Firefox still reaps more benefits than the competition playing catch-up.
Rust can't/shouldn't be directly monitized, so it makes sense to have something like this. Mozilla can still hire as many people as they want, but they never attempted to make it a company-managed project.
Rust can't/shouldn't be directly monitized, so it makes sense to have something like this. Mozilla can still hire as many people as they want, but they never attempted to make it a company-managed project.
> Rust can't/shouldn't be directly monitized
I agree that the main implementation should not, but I could see something like a verified Rust compiler (maybe something like the "Sealed Rust" proposal) being commercialized.
[0]: https://ferrous-systems.com/blog/sealed-rust-the-pitch
I agree that the main implementation should not, but I could see something like a verified Rust compiler (maybe something like the "Sealed Rust" proposal) being commercialized.
[0]: https://ferrous-systems.com/blog/sealed-rust-the-pitch
I think this is a massive win for Mozilla, which may end up having a longer and larger impact on the world than Firefox.
Having "control" over Rust didn't ever seem like Mozilla's goal (nor in its interests), so the trajectory of the language since 1.0, its healthy and energetic community, and the founding members of the independent Rust Foundation is a huge achievement.
Thanks to Mozilla for incubating a long shot project.
Having "control" over Rust didn't ever seem like Mozilla's goal (nor in its interests), so the trajectory of the language since 1.0, its healthy and energetic community, and the founding members of the independent Rust Foundation is a huge achievement.
Thanks to Mozilla for incubating a long shot project.
Honestly steering a programming language is basically just work and writing rather than anything particularly strategic.
Depends. Do you want the language to go somewhere in particular, or just wander around accumulating features? If you want it to go somewhere, steering it there becomes strategic. In particular, it's strategic for the survival and ongoing health of the language.
In what way?
Mozilla was sort of de-facto the steward of the language up until recently. They stupidly fired the teams behind their most promising R&D project and lost any semblance of control over it.
No, Rust has been independent since Rust 1.0. Mozilla only provided free legal advice (+trademarks, etc) and employed some team members but they didn't have control.
I wasn't implying that Mozilla had explicit control over the project, but to say that it just "employed some team members" really undersells things. They employed critical team members, including as I recall the majority of the core team. They were also leveraging the project for R&D, allowing for fast feedback loops between core members and Servo developers.
Rust always, thankfully, made sure to be independent of Mozilla, but it would be silly to think that they had no influence over the project and that by firing major contributors they've lost that.
Rust always, thankfully, made sure to be independent of Mozilla, but it would be silly to think that they had no influence over the project and that by firing major contributors they've lost that.
Not hard control, but I think they had a pretty big impact on where Rust headed (not in direction, but prioritization), even in the 1.x days, though more in core ecosystem than in the language itself. E.g. I doubt Rust would be in it's dominant position regarding WASM, if it weren't for Mozilla.
That was only because they had engineers working on it. The foundation changes nothing in that regard. If Mozilla were to hire engineers to work on bringing Rust to a new platform then it would have the same effect now.
I don't want to downplay Mozilla's many contributions to Rust in any way but I also acknowledge they worked hard to ensure Rust operated independently of any organisation, including themselves.
I don't want to downplay Mozilla's many contributions to Rust in any way but I also acknowledge they worked hard to ensure Rust operated independently of any organisation, including themselves.
Yes, I think that the only chance Mozilla has to ever conquer Chrome and its clones is to finish the Firefox code conversion to Rust.
Mozilla has brought this on themselves. I just hope that Firefox itself will be able to stay on a productive path, somehow.
[deleted]
As a D foundation employee, good luck have fun
There you have it. Right decision & direction here. We'll see how this goes for the Rust programming language.
As someone who wants to use Rust for real world applications, what are some good use cases for Rust?
Web development is not its strong suite, apparently.
Or, better still, what have you personally built using Rust?
Or, better still, what have you personally built using Rust?
I feel like rust has some good sweet spots right now. I care about these but maybe not everyone else does.
- Parsing untrusted inputs. nom[1] is a joy to use, and lets you kind of effortlessly and fearlessly process random input from wherever and turn it into useful data structures. If your data is very regular or in a standard format, then serde[3] is very hard to beat if it just boils down to 'derive(Deserialize, Serialize)' on your Rust struct.
- Bulk data processing. rayon[2] makes pegging your machine easy if you have a lot of work do to, and the Rust semantics around thread safety, data ownership, and explicit copying make it kind of trivial to reason about how your data gets from input to output and tuning it to be crazy fast.
- Generic systems language. Maybe this one is personal, but I find it's more productive to write generic cli applications and whatnot in Rust over C, ruby, or python. There are some nice libs to make part of this pleasant (structopt[4]) but this really boils down to reliability. Because Rust makes it obvious where things can fail so I can deal with it I have way higher 'just works' outcomes in Rust than other languages. I might spend slightly more time making it compile, but I spend basically zero time debugging runtime failures and this is kind of indescribably amazing.
[1] https://docs.rs/nom/6.1.0/nom/index.html
[2] https://docs.rs/rayon/1.5.0/rayon/
[3] https://serde.rs/
[4] https://docs.rs/structopt/0.3.21/structopt/
- Parsing untrusted inputs. nom[1] is a joy to use, and lets you kind of effortlessly and fearlessly process random input from wherever and turn it into useful data structures. If your data is very regular or in a standard format, then serde[3] is very hard to beat if it just boils down to 'derive(Deserialize, Serialize)' on your Rust struct.
- Bulk data processing. rayon[2] makes pegging your machine easy if you have a lot of work do to, and the Rust semantics around thread safety, data ownership, and explicit copying make it kind of trivial to reason about how your data gets from input to output and tuning it to be crazy fast.
- Generic systems language. Maybe this one is personal, but I find it's more productive to write generic cli applications and whatnot in Rust over C, ruby, or python. There are some nice libs to make part of this pleasant (structopt[4]) but this really boils down to reliability. Because Rust makes it obvious where things can fail so I can deal with it I have way higher 'just works' outcomes in Rust than other languages. I might spend slightly more time making it compile, but I spend basically zero time debugging runtime failures and this is kind of indescribably amazing.
[1] https://docs.rs/nom/6.1.0/nom/index.html
[2] https://docs.rs/rayon/1.5.0/rayon/
[3] https://serde.rs/
[4] https://docs.rs/structopt/0.3.21/structopt/
I've used Rust to write a couple of personal projects: a compiler for a language I've designed (it's really good for that because of its great ADT and pattern matching support) and a small CLI which I wanted to be very fast. Rust is great for that. The `structopt`[0] crate makes writing CLIs almost as easy as on a high level language.
The other project is a web app and I use Rust to compile to WASM. Because I had to use several web APIs (DOM, WebCrypto) I used the JS interop heavily, and that's still very painful to use if you use the low-level interop (js-sys and web-sys)... however, I am aware of several efforts in this area, like Yew[1], which should make things better.
The language is very hard to learn, but once you get past a certain threshold (depending on what you know already, that may take weeks to several months) it's really nice to use (though certain things are still hard to write because managing lifetimes can be very tricky).
[0] https://crates.io/crates/structopt
[1] https://yew.rs/
The other project is a web app and I use Rust to compile to WASM. Because I had to use several web APIs (DOM, WebCrypto) I used the JS interop heavily, and that's still very painful to use if you use the low-level interop (js-sys and web-sys)... however, I am aware of several efforts in this area, like Yew[1], which should make things better.
The language is very hard to learn, but once you get past a certain threshold (depending on what you know already, that may take weeks to several months) it's really nice to use (though certain things are still hard to write because managing lifetimes can be very tricky).
[0] https://crates.io/crates/structopt
[1] https://yew.rs/
I built a tool that generates personal code coverage reports from general test code coverage and repo inputs. IE what is the code coverage on lines I wrote this sprint and lines I wrote ever.
It stores blame coverage data in an sqlite db and generates static html reports for easy deployment. It handles TS/JS (lcov) coverage natively (I have to parse the files with SWC to figure out what lines are parseable). It has to dish out to a small jar to extract jacoco coverage.
It takes about an hour to do the initial data population and can generate an report and update test infor in 5-10 minutes for a roughly 600K loc codebase. Sadly it's closed source at work.
I'd been kicking around the idea in my head for a bit, and when I got the go-ahead from my boss I was able to bring it to completion fast enough to surprise my boss.
It stores blame coverage data in an sqlite db and generates static html reports for easy deployment. It handles TS/JS (lcov) coverage natively (I have to parse the files with SWC to figure out what lines are parseable). It has to dish out to a small jar to extract jacoco coverage.
It takes about an hour to do the initial data population and can generate an report and update test infor in 5-10 minutes for a roughly 600K loc codebase. Sadly it's closed source at work.
I'd been kicking around the idea in my head for a bit, and when I got the go-ahead from my boss I was able to bring it to completion fast enough to surprise my boss.
It's a good thing I didn't get that memo, nor anyone to tell me that backend web development wasn't its strong suit, because I built an entire platform of services with it and an EDA. As I worked on my projects, I wound up crossing streams with developers who had moved from Node, Python, Java, Ruby, PHP, and Go.
I mentioned elsewhere in this thread that I built a jigsaw puzzle website [1] with a Rust API backend and I launched it last week. It definitely took longer than if I had used Node, but I enjoy working with Rust much more.
Apart from that website, I have also open sourced a Rust CLI task runner [2] which uses markdown files as a command definition format. This is probably the most important tool I've ever written, as I have used it every single day since.
[1]: https://puzzlepanda.com
[2]: https://github.com/jakedeichert/mask
Apart from that website, I have also open sourced a Rust CLI task runner [2] which uses markdown files as a command definition format. This is probably the most important tool I've ever written, as I have used it every single day since.
[1]: https://puzzlepanda.com
[2]: https://github.com/jakedeichert/mask
Some off the top of my head are Alacritty (terminal emulator), exa (ls alternative), bat (cat alternative), and dog (dig alternative). Discord is rewriting a lot of their services from Go to Rust [0]. I personally built a CLI text editor in Rust [1] (very early development).
[0] https://blog.discord.com/why-discord-is-switching-from-go-to...
[1] https://github.com/andrewkdinh/via
[0] https://blog.discord.com/why-discord-is-switching-from-go-to...
[1] https://github.com/andrewkdinh/via
Small erratum: Your first link describes re-writing a back-end service from go to rust; the first-party Discord client is Electron.
As an author of the idea I'm happy to see it implemented :) Now I only wait to read the instructions how I can donate money to this foundation.
May this be the beginning of a long, interesting, and productive future.
[deleted]
Congrats to everyone involved, I started learning rust on a bus 4 years ago and its amazing to see how far the language has come
You love to see it. Huge congratulations to everyone involved, to the rust maintainers, community, and admins.
Yes!
Hey folks! Normally, I am all over these threads answering questions, but I am not on the foundation board and did none of the real work to get this going! The foundation members are unlikely to comment on Hacker News, so if you have big questions you want answered, contacting them via the address on the site is the right way.
Personally, I am very excited that this is happening, and really looking forward to the future here.
Personally, I am very excited that this is happening, and really looking forward to the future here.
I would like to raise awareness to a tiny detail:
> February 9th, at 4pm CT.
When using local time zones we should strive to always also add the equivalent GMT time to a global audience - even if this audience will not participate in the meeting, it is good to have an idea of when that is actually happening without needing to go through a timezone converter.
> February 9th, at 4pm CT.
When using local time zones we should strive to always also add the equivalent GMT time to a global audience - even if this audience will not participate in the meeting, it is good to have an idea of when that is actually happening without needing to go through a timezone converter.
As I said, not involved, so you should submit this feedback to them. I can try to pass it along, but there's no reason to have me as a middleman.
I don't think I understand. Those are both just time zones, right? So knowing what time it happens elsewhere requires a conversion no matter what time zone you gave originally, doesn't it?
I think the point is that most people will know the offset of their own timezone from GMT/UTC. If you specify time in another timezone, they now need to know two offsets - theirs AND yours. Chances are they won't know yours and they have to look it up.
This is a very "HN bubble" perspective. No, most people do not know their time zone's offset from GMT and go through a timezone converter. When they have to set a timezone, they click a spot on a map or look up, "What timezone is Pittsburgh?" For most, it's faster to search "12:00 GMT to EST" or whatever than it is to remember it and do the arithmetic.
It might be different elsewhere, but most people in Europe really do know their GMT offset.
Most people in the US know their offsets from the other three US time zones as well.
Assuming most people do not know is also a "bubble" perspective. We don't know what "most" people know about their time zones. Most countries in Asia have only one timezone.
source: https://www.timetemperature.com/asia/asia_time_zones.shtml
It is easier for them to relate to GMT in my opinion.
source: https://www.timetemperature.com/asia/asia_time_zones.shtml
It is easier for them to relate to GMT in my opinion.
Most people outside of north America knows their offset to the GMT timezone. GMT is a standard reference point, I barely know anyone that does not know about this. Even my old parents know it. I think the HN bubble is exactly the opposite, thinking only about north american timezones.
Rust Foundation seems pretty much targeted at HN-bubble-like groups, that do indeed have some familiarity with GMT/UTC.
Also CT is lucky to be unique. CST / BST / IST are a bit more of a guesswork for international groups.
I have no idea which one is CT. Nor does this seem important. Why should we care when this meeting takes place? Is this going to be live streamed? No? Then what's the point of mentioning it? This whole post seems completely devoid of real information. (Other than foundation 0.0.1 is released.)
Where are the bylaws? What are the responsibilities and rights of each role? Interim? Between what and what? ...
Sometimes Rust preaches inclusivity harder than it practices it.
/rant
Where are the bylaws? What are the responsibilities and rights of each role? Interim? Between what and what? ...
Sometimes Rust preaches inclusivity harder than it practices it.
/rant
>This is a very "HN bubble" perspective. No, most people do not know their time zone's offset from GMT
Well, almost everybody who's done server work knows their timezone offset from UTC, though, which is basically GMT.
Well, almost everybody who's done server work knows their timezone offset from UTC, though, which is basically GMT.
I find it very funny that four people independently wrote almost the exact same response to your question.
I think the idea is that many people know the offset of their timezone from GMT/UTC, so they wouldn't have to look it up, but nobody can be expected to know their offset from any arbitrary other timezone.
Offsets from GMT/UTC are annoying when you have to deal with DST though, as it can be confusing to remember which offset applies at any given point in time.
This, of course, applies to any timezone, as the starts and ends of DSTs (if they exist) are different in different countries.
I think the point is you know how far your timezone is from GMT, but you don't necessarily know what "CT" means.
I think the point is that more people would be able to figure out what the local time is if it was listed as 4pm CT (22:00 GMT/UTC), since more would know what their local time is compared to GMT vs compared to CT.
I usually try to avoid getting into TZ pedantry, but since you brought it up, UTC is preferred and is not interchangeable with GMT.
I see your point, but no, I actually meant GMT as it is an actual timezone AND a non-technical person (may) actually know about it.
Nice downvoting for an honest feedback.
Huawei ?
What is the question? Huawei is a great tech company no matter if there's any truth in the accusations levelled upon them by the US. They are are pretty big user of Rust and are even co-organizer of Rust Events, like Rust China Conf. I see it as a good thing that it isn't the usual FAANG being behind it.
Microsoft?? Google?? Don't they already have their own languages?!
Rust, Go, C#, and TypeScript doesn’t overlap all that much.
Maybe they need to rewrite them in rust?
rl3(2)
yudlejoza(12)
Are there plans for waiving the relevant trademarks? I know many people are fine with them, but seeing how the FSF directory lists it as an "anti-feature" is a bit disheartening.
I love the FSF, but frankly as a user, I'm glad that not just anybody can claim to be Rust. Especially so now that the trademark is controlled by a dedicated nonprofit.
But how could anyone reasonably claim they are Rust, particularly given the large reach of it's online services, like docs, crates.io and rustup? Those trademarks are very unlikely to produce anything except another round of debian's icy rebrands.
Rust is already in Debian's repository. The trademarks haven't been an issue at all.
It seems no one had to rebrand Rust yet, but can you guarantee this will always be the case? Firefox was fine in debian until 2006.
But why? Python has been going for decades without issue. https://www.python.org/psf/trademarks/
No, Python is dead because the maintainers decided to create a new, defective, language with a intentionally-misleading name, and then threatened trademark lawsuits against anyone who kept maintaining the original. That sort of thing is (I assume) why lvass was asking about trademark waivers in the first place.
The most used programming language is dead? Please stop the FUD. Python is doing great. Calling it a new language is insane. There's way less difference than in early Cpp versus late Cpp.
The issue with Firefox was that Mozilla didn't want Debian's modified version of Firefox to be called Firefox.
https://en.wikipedia.org/wiki/Mozilla_software_rebranded_by_...
https://en.wikipedia.org/wiki/Mozilla_software_rebranded_by_...
Well it'll be amusing to see the playful knockoff names that Debian will come up with when rebranding Rust.
Will they go with the metal chemistry theme, go back to the original plant pathology one?
https://www.reddit.com/r/rust/comments/27jvdt/internet_archa...
Will they go with the metal chemistry theme, go back to the original plant pathology one?
https://www.reddit.com/r/rust/comments/27jvdt/internet_archa...
Mozilla Foundation != Mozilla Corporation.
Which is why there was an issue with branding.
Which is why there was an issue with branding.
No, there was an issue with branding because Debian was diverging too much from mainline Firefox, and not keeping up to date with security patches. Not some corporate malintent.
The way that was resolved was with Firefox LTS.
The way that was resolved was with Firefox LTS.
[deleted]
[deleted]
Just as crazypython said, it seems that the power has shifted from Mozilla and the community to big corporations on the future of Rust.
This is worrying to me in that engineers are naively selling their souls to big corporations just to work on Rust.
I'm glad for the formation of the foundation, even though I hear that even Facebook (although not on the board yet) are looking for engineers to work on the Rust compiler.
Yikes.
This is worrying to me in that engineers are naively selling their souls to big corporations just to work on Rust.
I'm glad for the formation of the foundation, even though I hear that even Facebook (although not on the board yet) are looking for engineers to work on the Rust compiler.
Yikes.
Big corporations are also driving ISO and ECMA languages, so do you feel like selling your soul to work with C?
Yes, you and I are more likely not to have say in this, I prefer the community to have a say not corporations.
Anyone is free to submit a paper to ISO and ECMA, provided they are willing to champion it.
Yeah, this point is moot, still no say unless you pay to be a member, looks very high to me even to get a vote.
My point is that it's all corporations and not the community, eventually the foundation will serve the interests of corporations one way or another.
My point is that it's all corporations and not the community, eventually the foundation will serve the interests of corporations one way or another.
There is no payment to be a member in ISO.
As for the corporations, that is life, name one successful programming language without corporation backing.
As for the corporations, that is life, name one successful programming language without corporation backing.
> There is no payment to be a member in ISO.
The ISO member bodies don't charge any fees to be a member then?
> As for the corporations, that is life, name one successful programming language without corporation backing.
That isn't even the point, the issue is with these companies being on the board of directors, it seems you've resigned yourself to allow big tech companies to take control over Rust.
You can have companies and individuals donate to a project without placing them on the board, and it seems that with Rust you can't even donate.
The ISO member bodies don't charge any fees to be a member then?
> As for the corporations, that is life, name one successful programming language without corporation backing.
That isn't even the point, the issue is with these companies being on the board of directors, it seems you've resigned yourself to allow big tech companies to take control over Rust.
You can have companies and individuals donate to a project without placing them on the board, and it seems that with Rust you can't even donate.
Depends on the ISO work group, in what concerns C and C++, they don't charge for it, but it is up to you to cover for your travel expenses and vacation days to defend your papers. This is where corporation (or employeer) sponsorship comes into play.
That is pretty much the point, given that there are no successfull programing languages in existence without companies financial support for their core team.
That is pretty much the point, given that there are no successfull programing languages in existence without companies financial support for their core team.
> Depends on the ISO work group...
So they do charge for membership fees then, thanks for confirming, remember you said:
> There is no payment to be a member in ISO.
Your other point is irrelevant, I am not even arguing that case and you haven't even provided your definition for "successfull programing languages".
So they do charge for membership fees then, thanks for confirming, remember you said:
> There is no payment to be a member in ISO.
Your other point is irrelevant, I am not even arguing that case and you haven't even provided your definition for "successfull programing languages".
Don't twist my words, I explicitly stated that is not the case for C and C++.
Your point is the one that is irrelevant, because your are yet to point out a successful programming language on the market according to your world vision.
Here are some examples to inspire yourself.
Ada, C, C++, Java, Python, Perl, JavaScript, F#, C#, VB.NET, Kotlin, Swift, Objective-C, Delphi, Typescript, Scala, Haskell, OCaml, Ruby, Erlang, Elixir.
Your point is the one that is irrelevant, because your are yet to point out a successful programming language on the market according to your world vision.
Here are some examples to inspire yourself.
Ada, C, C++, Java, Python, Perl, JavaScript, F#, C#, VB.NET, Kotlin, Swift, Objective-C, Delphi, Typescript, Scala, Haskell, OCaml, Ruby, Erlang, Elixir.
So in general for ISO you do have to pay for fees, saying "not the case for C and C++" does not mean they don't do it at all, please don't move goal posts.
> Your point is the one that is irrelevant, because your are yet to point out a successful programming language on the market according to your world vision.
Is it? I still don't see your point, It seems you've just listed a bunch of languages when I am talking about big tech companies that are joining the board of directors of a foundation that you cannot even support as an individual, let alone have any say on.
> Your point is the one that is irrelevant, because your are yet to point out a successful programming language on the market according to your world vision.
Is it? I still don't see your point, It seems you've just listed a bunch of languages when I am talking about big tech companies that are joining the board of directors of a foundation that you cannot even support as an individual, let alone have any say on.
I am not moving goal posts, we are discussing about Rust here, C and C++ WG members don't pay for membership, the languages Rust is trying to replace, but apparently it doesn't fit into your world view.
Again, please provide a famous programming language thriving on the market that fits your beloved world view.
If you don't have any to share, windmills are over there.
Again, please provide a famous programming language thriving on the market that fits your beloved world view.
If you don't have any to share, windmills are over there.
That doesn't mean everyone is equally heard. I seem to remember some debacle with an Open Document standard some years back...
Code is code. Big corporations or small corporation, if the language benefits from it, its all good.
React is from FB, they have engineering talent as such Amazon, Google, Microsoft, Mozilla.
React is from FB, they have engineering talent as such Amazon, Google, Microsoft, Mozilla.
No language has ever been ruined by large corporations. Languages are too far removed from society to be affected by this.
> No language has ever been ruined by large corporations.
Oracle ruined Java.
Oracle ruined Java.
How? Pron seems to be ok with the direction: https://news.ycombinator.com/item?id=19827063
It's a little concerning to see Huawei involved so closely in Rust, given the concerns about them silently including spyware in their products to give access to the Chinese government. I don't think I'm being a total conspiracy theorist; for example the UK, US and Sweden all ban Huawei equipment from their countries' mobile phone networks. Hopefully since this code is all open source there is sufficient scrutiny to avoid any shenanigans.
As far as "concerns" go these are not even allegations, these are rumors and slanders. There has never been even one shred of evidence that Huawei have done that.
The issue not whether Huawei have done that, the issue is whether they will if asked.
https://www.cnbc.com/2019/03/05/huawei-would-have-to-give-da...
> "any organization or citizen shall support, assist and cooperate with the state intelligence work in accordance with the law”
> “when the state security organ investigates and understands the situation of espionage and collects relevant evidence, the relevant organizations and individuals shall provide it truthfully and may not refuse.”
Furthermore, the CCP has a long track record of detaining anyone they want for whatever reason they choose. The idea that Huawei's executives could resist such an order is ludicrous.
However, it seems likely that in the case of Rust, Huawei's ability to anything nefarious would be negligible.
https://www.cnbc.com/2019/03/05/huawei-would-have-to-give-da...
> "any organization or citizen shall support, assist and cooperate with the state intelligence work in accordance with the law”
> “when the state security organ investigates and understands the situation of espionage and collects relevant evidence, the relevant organizations and individuals shall provide it truthfully and may not refuse.”
Furthermore, the CCP has a long track record of detaining anyone they want for whatever reason they choose. The idea that Huawei's executives could resist such an order is ludicrous.
However, it seems likely that in the case of Rust, Huawei's ability to anything nefarious would be negligible.
And, Rust already has a way of avoiding trusting-trust attacks via mrustc.
Well - no surprise for me here. Speaking as someone that worked in FAANGs - people love to burn money unproductively there and RUST is just perfect for that. Reinventing the wheel and solving already solved problems but "different". It's a language for theoretical "perfectionists" and Code Review keyboard fighters that will burrow themselves in it for years and probably never contribute to company's IP in any meaningful way.
It's great that those big-tech money furnaces finally "embraced" it.
It's great that those big-tech money furnaces finally "embraced" it.
https://blog.mozilla.org/blog/2021/02/08/mozilla-welcomes-th...
https://aws.amazon.com/blogs/opensource/congratulations-rust...
https://cloudblogs.microsoft.com/opensource/2021/02/08/micro...