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
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.
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)
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 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.
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.
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…)
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.
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."
> 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.
> 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.
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?
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.
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.
> 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!
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.
>"[]... 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."
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.
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.
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.
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.
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.
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.
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.
"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."
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.
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. :)
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/
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/
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?".
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! :)
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
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!
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.
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.
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.
"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.
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.
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.
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.
> 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.
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.
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
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.
> 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.
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.
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 :)
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.
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.
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.
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.
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.
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.
> 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.
>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.
> 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.
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.
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)
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>`
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 :)
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.
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].
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.
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.
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?
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.
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. »
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.
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.
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.
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.
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.
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.
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.
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?
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.
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).
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'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.
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).
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.
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.
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.
Yes, and the point is that this post assumes their audience to be US-only with this. When dealing with a global audience, try to use GMT/UTC reference, a lot of people will appreciate it.
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.
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.
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.
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.
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.
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.
> How is including Huawei as a founding member of the Rust Foundation in any way justifiable from a moral perspective?
Probably in the same way that it is justifiable to support the DoD of the USA to use Rust on their drones that kill civilians all over the world. (the micro-controller of one of the turbines used in these drones runs 100% Rust).
US military technology that uses Rust is also deployed in Israel to genocide palestinians, and at this point Rust is involved somewhere in every civilian life the US directly or indirectly contributes to taking away.
So if this is where you want to put the bar, then none of the tech companies that are now major Rust foundation members would pass it.
I mean, Microsoft hosts the NSA cloud that's used to spy on citizens all around the world, and rattle them out to get them killed when it suits the CIA. Facebook was used by Cambridge Analytica to rig Brexit in the UK, and the list goes on and on and on.
It seems the point of my [now censored] comment was misunderstood.
It's not about the fact that the Rust language itself is used to do bad things. It's about what the organizations that comprise the Rust foundation represent.
Yeah, I'll grant you the others are indeed guilty of terrible things. Personally I abhore parts of virtually every company there in some way or another.
Here's the thing: not every member company is completely beholden to an authoritarian government. Only one is.
> Here's the thing: not every member company is completely beholden to an authoritarian government. Only one is.
If you think this is an objectively a bad thing, you should probably compare the per capita excess mortality of China vs the US for 2020...
---
The Rust community is very diverse and include people from all around the world, including a huge number of Chinese developers.
Not giving China a voice means that "negotiation" is not an option that China can choose when there is a dispute, forcing them to pick some other option instead.
If you really believe that China is super dangerous, forcing them out of the negotiation table is probably the single worst decision you can actually make.
I really hope you are not in favor of expelling China and all other countries you disagree with from the United Nations and similar policies, because that's how World War 3 starts...
>If you think this is an objectively a bad thing, you should probably compare the per capita excess mortality of China vs the US for 2020...
Authoritarian regimes are much better equipped than free societies to handle pandemics. That doesn't somehow excuse nor justify crimes against humanity at terrifying scale.
>The Rust community is very diverse and include people from all around the world, including a huge number of Chinese developers.
Including Chinese developers is great. Including a large tech company that has no choice but to act as an arm of its authoritarian government isn't. These are two very different things.
>Not giving China a voice means that "negotiation" is not an option that China can choose when there is a dispute, forcing them to pick some other option instead.
Generally speaking when large-scale atrocities occur, the concern isn't with giving the entity committing said atrocities a voice so much as it is things like international condemnation and exclusion until the abhorrent behavior ceases. Negotiating with and giving voice to authoritarian regimes simply enables them to act in bad faith. History is littered with examples of this. Atrocities become bargaining chips, and that is grotesque.
Don't most of those points apply to all of the companies involved? Not defending Huawei here, but basically every tech giant has a bad track record regarding these topics.
In general it's a very traditional tech worker dilemma: Do I want to get a good salary working on interesting problems that is mostly of interests of big tech companies that make their money via arguably shady means, or do I want to earn an average salary working on boring problems and be 100% sure I have a clean conscience.
I'm guessing the approach is to have a quasi-parasitic relationship with the sponsors: You personally stay as little involved with the "bad parts" of the company and try to push the "good parts" forward while also pushing the open source tech forward (hopefully for the good of all humanity). That's how I have seen the relationship between Rust and Github (= Microsoft) play out so far too: Rust is very deeply relying on Github for pretty much everything while a good chunk of the individual team members critizize their involvement with ICE at every opportunity.
Every company has some dirty bits but the nature and scale of those bits matter.
For example, what ICE does and what China is doing in Xinjiang may be superficially similar but there are also huge differences. For example, ICE incarcerates people who voluntarily enter the United States, while in Xinjiang the CCP incarcerates the native population. Also at any given time the CCP is detaining probably > 10x the number of ICE detainees.
So no, those points do not apply equally to all the companies involved.
Maybe the fact that ripgrep contains more lines of code is related to the fact that it has more features, and not just about the language it's written in? https://beyondgrep.com/feature-comparison/
Also, it's kind of pointless to compare lines of code given that both projects get large amounts of their functionality from dependencies. For instance, the GNU grep repository doesn't actually contain any regex-matching code; that's all in gnulib.
EDIT: If you already knew that ripgrep had more features, and yet your immediate reaction was that you "can't take those guys and their language seriously", then your comment is straight-up trolling. Please don't do that here.
The "proper" comparison (that would still be horribly misguided) would be against the "core" crate in ripgrep. And that's only 5kloc, a lot of it from the "app.rs" (3kloc) and "args.rs" (1.2kloc) which is almost only declarative usage strings.
The "actual" code of ripgrep is accross its multiple support crates, which the community largely benefits from having since those are general enough to be almost foundational to any software.
No, you're trolling because you're being disingenuous and unnecessarily inflammatory. Your LOC counting, in particular, gratuitously misses the mark for a number of reasons.
Firstly, as others have pointed out, the features in GNU grep and ripgrep are radically different. GNU grep, for example, doesn't have anything that the `ignore` crate provides. So on this point alone, a simple LOC comparison falls flat. For example, does more lines of code imply that code complexity is higher? Not necessarily. Try reading and understanding the code itself. Obviously I'm biased, but I think folks would have an easier time with ripgrep than with GNU grep.
Secondly, ripgrep does a lot more than GNU grep does in order to make more searches faster. This ranges from parallelism, to differing search strategies (mmap vs standard read calls) to pattern analysis for better literal optimizations and more involved SIMD algorithms and better performance in the face of Unicode. (In addition to supporting a lot more of Unicode than GNU grep does.) Making programs run faster often leads to greater code complexity. Such a phenomenon, ironically, is easy to observe when comparing GNU tools with other coreutils implementations from BSD or busybox.
Thirdly, the way in which you counted lines is weirdly arbitrary. For example, GNU grep uses a lot of code from gnulib, including but not limited to, an entire regex engine. (It used to be part of GNU grep proper, so if you had done this analysis a few years ago, your LOC count would be at least double than what you came up with. Which supports my previous point: GNU grep's special lazy DFA internal regex engine only exists for performance reasons.)
Fourthly, I made a decision to make a lot of ripgrep's internals generic over both the regex engine and the printer. This was to make it possible for others to use those libraries, but also to make it easier to support plugging other regex engines into ripgrep. The official ripgrep distribution, for example, comes with both Rust's regex engine and PCRE2. But it goes beyond that. Someone even maintains a fork of ripgrep[1] that uses Hyperscan[2] to make it faster in some cases. The fact that this is even plausible to do is only because much of ripgrep's core is, in fact, generic. Making things generic tends to require more code and more complexity. I made this trade off intentionally.
Fifthly, your LOC counts include a ton of tests for ripgrep, where as your GNU grep LOC count presumably does not. For example, about half the LOC in the `printer` crate are tests. And that's just at a library level. Does GNU grep even have library level tests at all? A cursory glance suggests it does not.
Sixthly, in the course of developing ripgrep, I made a conscious decision to contribute back to the Rust library ecosystem. As a result, several of ripgrep's libraries are now used in Cargo and rustc itself, among many other tools. GNU grep has no such goal beyond the GNU project and their gnulib itself. Writing more tightly coupled application level code would make the code much tighter. (Which you can observe for yourself by looking at the evolution of ripgrep. It started off with a lot more tightly coupled application level code.)
There are probably more reasons why your comparison falls flat, but this is what I could come up with quickly before going to bed. In particular, the choice of programming language is but one factor in overall code complexity. Design goals and other such things arguably have even more of an impact. Thus, your analysis is shallow, and the lack of self-awareness of this fact combined with your inflammatory marks and seeming certainty of your position are why you are a troll.
It took me about ten minutes to write that. Sometimes trolls need to be called out. And sometimes, lame myths espoused by trolls need to be deconstructed.
I've been on discussion forums since my childhood years. I'm well aware of my opportunity costs, thank you very much. :-)
As a Rust developer (not really), after getting sick and tired of hearing about C everywhere, I decided to do a bit of assessment in terms of code-size complexity.
I heard of Linux, an amazing operating system kernel that beats Redox in the dust.
I have never seen Redox source code. I told myself, if I download Linux-on-C and Redox-on-Rust and find out that Linux is doing all it's doing in one-tenth the size of Redox source code, or even half the code size, I'd be quite impressed, and be willing to take C seriously.
Well guess what, I downloaded the two sources. Redox kernel source code is about 24k LoC. Linux? about 27M.
WTF.
----
In all seriousness, LoC comparisons are absolutely the worst way to compare languages, especially across projects that are completely different in scope and design.
(This was a joking reply in the style of OP's now-flagged comment, which was comparing LoC between ripgrep and grep.)
IIUC, minimum code size was not the top priority of the creator of ripgrep.
And Rust's claim to fame is not that it allows you to get the job done with less code. Its claim is that it allows you to get the job done, but with far fewer memory access issues, without sacrificing runtime efficiency.
You are acting as if these are the same thing. ripgrep has more features than grep and that is going to take more code. At the very least you can drop the printer and ignore crates. You are still looking at twice the code but ripgrep is doing parallel searching so it is obviously going to be more. How much more is hard to say without trying to rewrite one or the other to make this an apples-to-apples comparison.
And even if it results in 1-2x amount of code that is not the end-all metric. How quickly was this code written and how easy is it to maintain? How many bugs does it have?
I mean rust is basically a superset of C (other than having to write "unsafe" everywhere if you use a c-style), so it is hard to dismiss this as wasted noise because if it was wasted wouldn't people have written it like C line-for-line?
The amount of damage stupid and overconfident people can cause with sharp tools like C is a too high to bear risk. That’s why we instead use Java or (God forbid) JavaScript, but at the expense of speed.
Rust tries to gain back this lost speed without making it too easy for idiots to destroy everything. Such code can of course look larger and more convoluted than over decades on every corner optimized C code, but at least we’re as fast as C and much safer from ignorant people.
For the record, that word has never been used to describe Rust's goals by those who work on it. The slogan of the language is "empowering everyone to build reliable and efficient software."
And for what it's worth, I think the people working on Rust are empathetic and it shows in their work. For example, he error messages given by the compiler try to hand hold you gently when you're learning the language.
What's the issue with Java? It empowers teams consisting of many heterogeneous people to get work done easier and limits the scope to logical errors only.
> edit: to those who're saying ripgrep is more than grep. First, I know. Second, wouldn't it be great if someone could rewrite ripgrep in C? Now I'm really curious to find out the code-size complexity of all the ripgrep features backported to grep.
I'd be shocked if a C version measured fewer LoC without resorting to some real dark art pointer magic.
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.
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.
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.
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.
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.
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.
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.
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.
Please look at this thread again because you brought up ISO and ECMA to derail the thread and it turns out you have to pay to have a say in it, after you said that:
> There is no payment to be a member in ISO.
So why bring this up in the first place? and now you're sprinkling clarifications afterwards. When are you going to admit that what you said is incorrect?
> ...We are discussing about Rust here, C and C++ WG members don't pay for membership.
Incorrect, we are talking about the Rust foundation. Which covers more than just the language.
Again, what difference does this make in you having a say as a community member? Seems like you need to join a big company to have a say, because that's all I see.
> Again, please provide a famous programming language thriving on the market that fits your beloved world view.
So R does not count as a famous thriving programming language that is driven by the community (not corporations) and allows donations? You're more likely to have a say on R than on C, C++ and now Rust.
To be clear: the Rust foundation does not control any technical decision making in the Rust project. Anyone willing to open an RFC on GitHub has the opportunity to influence the development of Rust, and that has not changed.
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.
> "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.
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.
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...