> By using Rust for both our frontend and backend, we have a unified stack of Rust everywhere, simplifying our hiring.
> I can write web apps in another language than JavaScript
> I can write web apps that are fast
Yeah, this is what's worrying me. If you look at rerun.io website, you will notice that it's built with Next.js, i.e. is using a React framework to build pages that have no interactivity whatsoever. Next.js is used for the blog, despite it being just a collection of simple static html pages. Meanwhile, the user has to download around 200kB of javascript for no reason whatsoever; and the only reward that they get for their trouble is an avalanche of javascript errors in the browser console [0].
We are building the frontend of our _application_ in Rust and rendering it to a canvas using egui.rs. For the web site we are using more "traditional" tech, as you've noticed.
I am not a big fan of the complexity of modern web sites (including our own), which is exactly why I created egui. However, it is targeted at web apps, not web sites.
I'm very curious how well this is working for you in practice, since I've been thinking about what it would look like to share a single Rust UI implementation across a webapp and native apps.
Putting the UI in a canvas elements have some distinct drawbacks (https://github.com/emilk/egui/tree/master/crates/eframe#prob...) but for us it is definitely worth it. Having one unified codebase for our web app and native app, and having it all in Rust, is just amazing.
We're currently working on a 3D renderer based on wgpu (https://github.com/gfx-rs/wgpu) that we will likewise use for both web and desktop.
Rust will never make it to the frontend at scale. There is a reason why JS was invented. People doing frontend dev don't want to bother with slow compile time or 3 strings implementation.
And the fast argument is missleading at best, every modern language are "fast" enough, if Amazon and Google runs Java that mean it's fast enough for 99% of workload.
As I see it, JS was invented as a browser utility, as the name implies "script", i.e same as shell script languages such as BASH, for doing small amounts of interactive stuff.
What JS has morphed into is a Jeckyll & Hyde monstrosity. Frontend devs now routinely dump 200kb+ of junk down the pipe at people's browsers because its somehow "better" to dump the processing/rendering on the user's desktop instead of server side.
And then there's the monstrosity of server-side JS. I think few people can argue that JS was ever supposed to be server-side. Things like Node are basically square-pegging JS into that round hole.
I think you're failing to address the elephant in the room:
The browser is simply the single best application distribution method humanity has ever created. Full stop.
There are literally no other tools that give anywhere close to the same benefits.
So 200kb of scripts might seem "HUGE!" to someone who's thinking about the web as a tool for distributing static information (blog distribution). But in the context of applications 200kb is ridiculously small.
When was the last time you installed an application on Windows/Mac/Android/iOS that was under a single MB?
Yet you install (& run) applications ALL DAMN DAY on the web, without a thought or care.
Things that used to come with 100MB+ installers? Those are web apps now. They serve you 200kb and load in less than a few seconds.
Ex: Outlook used to be a mail client you installed. The installer was several hundred MBs, and it took 10+ minutes to run. Now you point your browser at outlook.com and you get a nearly identical experience.
That spreadsheet app? Just a sheets.google.com away. Loads in seconds - using JS with a tiny payload.
Music player? It's a website now. JS.
See my point?
So is JS a monstrosity? For blogs, sure. For apps? Hell no. It's fucking amazing.
Because your point only works if you make (at least) two prior assumptions which are not always true.
Number one you assume everyone has high-speed broadband and "unlimited" 5G on mobile. This might well be the case in many parts of the Western world. But I can point you to a number of rural areas in the Western world and beyond that, in Africa and Asia where this assumption falls flat.
Number two, given most developers use JS to outsource the processing duties, you assume everyone has a half-decent computer. Many people use cheap laptops with lousy Celeron processors and a minuscule amount of RAM, likely also with an ancient browser that has not been updated for ages. Their experience of a browser-app will likely be very different to the cool-kid developer sitting on his bean-bag in a fancy office coding on a spec'd out beast of a machine.
What is your counter point with these statements? That having everything in canvas negates these potential issues? That having a native application negates them?
In an ideal scenario of application design, these two assumptions apply as well. So I don't think there is any merit in mentioning them as they're not counter points in any way.
But in the context of applications, JavaScript is slow as dog shit.
It takes "seconds" to open my spreadsheet? That is an absolutely deplorable regression.
Personally, I'm fine with 200KB initial downloads, sure that's great and I don't mind repeating them. (But, also don't care about 50MB or even 500MB downloads that I only do once.)
But for the browser to really become the "single best application distribution method humanity has ever created" it needs to be capable of delivering software that executes efficiently or else it is regresssion to barbarism by a thousand cuts. Not just the putrid UX, but we now understand that slow, inefficient code also cooks the planet and destroys various life forms.
I work at a company that uses Google Sheets. So yeah, it does often take seconds to open a document. And I've spent way more time waiting for those sheets to load over the past 5 years than I have waiting for software installers.
And many web apps bog down and lag behind even just typing, because they are doing some (trivial) computation on every keystroke. It doesn't have to be that way, but it often is... because JavaScript.
I'm also bullish on the browser's future as an app-delivery channel — but that is only because I think doing it without JavaScript will become easy, and thus common.
JavaScript is relevant because of the browser, not the other way around.
> it needs to be capable of delivering software that executes efficiently or else it is regresssion to barbarism by a thousand cuts.
WebAssembly executes efficiently, it keeps its overhead within a small multiple of natively compiled binaries which is totally par for the course for any JIT-compiled intermediate code. You can write slow and inefficient code in any language, but Rust makes it a bit easier to do things the efficient way.
Yeah, that's why I remain optimistic about the browser's future. My ranting was mainly about JavaScript itself.
We are already seeing real world web apps using WASM. (What I have seen is indeed mostly Rust, but in theory there are lots of other languages that can already, or will be able to, play in that same sandbox.)
The other fun thing about WASM is that there are already a bunch of ways to run it on the server (including "at the edge"). That makes it really easy to chop apps up into pieces that run in the browser, or run elsewhere.
Your point and explanation are completely disjointed from eachother.
Javascript is not the sole domain of small executables, its not even its primary feature - hell, one of your own examples isn't even very good. Outlook loads nearly 30MB of javascript immediately when you load your inbox, and they update it nearly every other day so you end up downloading hundreds of megabytes just to read your email every single week instead of just once.
> People doing frontend dev don't want to bother with slow compile time
Honestly, with my previous experience as a frontend web, compile time for frontend is starting to become as bad as a standard compiled language. When you start to have a whole framework, many (many!) dependencies (you know, the kind that make just deleting the node_modules directory slow) and webpack with some plugins for CSS, es-lint and all that, the tooling just can't keep up.
It doesn't help that much of the tooling is also done in JS which is fast but not that fast.
It's pretty fast with modern tooling. Try vite or swc if you have the time and inclination. vite builds one of my large $DAYJOB projects in ~45 seconds (which is insane compared to how webpack performed).
If you don't need vite's extensibility, you can go with 'pure' esbuild and slim down transpilation + minification + bundling to only a few seconds.
You also couldn't use JS of that time to build anything remotely like modern SPAs. Unlike some Silicon Valley unicorns, we're using SPAs only where they fit, to replace legacy desktop applications. (It's boring intranet stuff, but they make a lot of sense there.) I was a skeptic initially, but it grew on me.
Yeah, this is really an instance of “tell me that you're not doing front end while not telling me you're not doing front end”. Build time are a really annoying part of modern web jobs…
Typescript and React project build times are easily in the same ballpark as Rust or C++ for similar code base sizes though, yet they are used in the frontend 'at scale' ;)
JS ecosystem front end builds can be complex and incredibly slow these days. It's rare to see a JS app that is just written in JS and shipped as-is without some kind of long "compile" pipeline with translation to support different browsers, minifiers, CSS compilation, and tons of other cruft.
I've definitely seen JS builds be slower than medium to large size Rust builds on the same machine, especially since JS builds often involve large steps that are not parallelized. Rust parallelizes builds pretty well until the very last optimization pass and linker stage.
Go builds are impressively fast, so if that's a big pain point for you I'd look at Go frontend stuff.
Why wouldn't it? Saying that it will never seems very definitive. It's like these famous quotes that "we will never need more than 4kb of memory" or similar. Saying that something will never change is just a lack of imagination of the future.
There are big pushes behind wasm and Rust is leading the way here in a big way. I think you underestimate people and their will not to run javascript. Rust and WASM in particular will make it so that you can bring whatever language you want to the front end.
I believe that while it's very impractical now, wasm will slowly take over and in the future basically no one will use javascript except for basic things and most sites will use wasm for front end logic.
Why? Because it just makes sense for many reasons. You can use whatever language you want both on the server side and in the browser, you can achieve near native speeds and we're already sending big minified javascript blobs anyway so we may as well just send a binary instead. yes it's very hard to make a SPA with Rust today but it is possible and the tooling will become better over time and especially with other languages joining in.
To me it's clear that using javascript on the front end will become slowly irrelevant as more and more devs ship a binary blob. Right now, we need javascript as a glue but I think that will change as well with time.
JS is the best language for web - and generally for high level systems design - and honestly I don't know why people don't want to see it. Good parts of JS are: first class functions and closures and prototypical inheritance. Find decently popular language with those things implemented well, good luck. Rest of JS features are a noise, improvements of developer work ergonomics (all those let/const, modules, async/await and what not etc) and unfortunately pile of bad decisions which cannot be undone because web has to work correctly and do not break constantly.
JavaScript really is a Scheme in disguise with a little bit of Smalltalk. Which really is good. If you don't like junk coming from {}+[] - don't use it, but I consider the lack of errors thrown to be a correct behaviour. Use TS or any other linter to control stuff.
As we can see, Clojure wasn't accepted widely despite the fact it also has first class functions and closures. In my opinion the answer is simple: people want to have syntax for stuff which we agreed is good. Using macros and ((())) is not what people want to do long term.
Because lots of languages have first-class functions, and prototypical inheritance isn't actually that good an idea and most people just use it to implement bad class systems.
> People doing frontend dev don't want to bother with slow compile time or 3 strings implementation.
As someone doing both, my frontend JS/react pipeline has noticeably longer compile times (both to build locally, and for users rendering client-side) than my server-side one.
> There is a reason why JS was invented.
JS isn't here because it's "fast". JS is here because it shipped in browsers, and browsers were popular. JS got fast, after lots of people put a ton of effort into their JS implementations for almost two decades straight to make it so.
> Rust will never make it to the frontend at scale. There is a reason why JS was invented. People doing frontend dev don't want to bother with slow compile time or 3 strings implementation.
> And the fast argument is missleading at best, every modern language are "fast" enough, if Amazon and Google runs Java that mean it's fast enough for 99% of workload.
IMO, it really depends on the workload.
For the stuff that JS is being used for today, you're probably right.
But say someone wanted to implement a CAD program in the browser. I'd say, JS is probably inadequate for that[1]. In that case, performance matters more than for a chat app.
If you look at web development as a spectrum from webpage+ to high performance application, Javascript is a good fit for a large section of that spectrum. But probably not all of it.
---
1. I suppose it depends on the complexity of what you want to display, but "regular" local applications struggle to display extremely complex models today. I'd imagine putting the software in the browser would only introduce additional performance problems.
I have a real-world codebase of considerable complexity in both BE & FE code where I work. Our Rust compile time, across all targets we build (which includes a lot of tooling that's not really "backend", but we compile all the Rust together, so…) is 7m47s. Our FE build time was ~20m (and is part of our CI's critical path).
Obviously not fast enough for Google since they literally invented a new programming language (Go) to address the compile time and runtime limitations of Java.
>> Obviously not fast enough for Google since they literally invented a new programming language (Go) to address the compile time and runtime limitations of Java.
Go was created to overcome complexity issues and compile times of C++ (not Java):
I misspoke (miswrote?). You are correct, it was created to address the issues Google had with C++ and—crucially—other internally supported languages like Java and Python could not adequately fill C++'s role.
If Java could have filled this role in both compile time and memory efficiency, Go in all likelihood would never have been created.
But yes, Go beats Java in compile-time speed as well.
> they literally invented a new programming language (Go) to address the compile time and runtime limitations of Java.
And then ironically they then use a complex and runtime-heavy Java-based CI/CD to manage the compilation of their Go codebase.
Go is great though, best bit is how its so useable for web-stuff out of the box. Unlike Rust where you have to spend half your life either re-inventing the wheel or choosing which of hundreds of crates you want to use to do stuff that should be part of stdlib.
In Rusts defense, I can't think of a situation where you would need `OsString` in a frontend, and I don't think you will need `CString` either since strings are passed into webassembly by address + length (so exactly what Rust expects, no null-terminated nonsense). So you would just use the one default string type (`String` + `&str`).
You shouldn’t ever need to deal with OsString itself on wasm32-unknown-unknown, since that target basically just doesn’t cover functionality that needs it, but the actual situation is genuinely worse than OsString: Rust insists on valid Unicode (as is right and proper), but the web suffers from the affliction of ill-formed UTF-16. If you blindly convert from JavaScript strings to Rust strings, you will encounter data and functionality loss in a few situations, in practice always involving IME (or similar) text entry on Windows. The first bug I filed about this: https://github.com/Pauan/rust-dominator/issues/10, and you can follow further links if you’re interested. IE and Edge used to be largely immune to this, but IE is dead and I suppose Edge will have regressed in this way with the Chromium migration, since the bug filed in Chromium a few years ago <https://bugs.chromium.org/p/chromium/issues/detail?id=949056> has languished. (Firefox too, with <https://bugzilla.mozilla.org/show_bug.cgi?id=1541349>.) In the worst-case scenario, careless use like was the case in rust-dominator will mean that some users typing with particular software in a language that’s outside the Basic Multilingual Plane will not be able to type anything.
What's worrying me is wasm binary size from Rust. People talk about writing web apps in other languages, which is what I wish for, but elephant in the room has few to non existence of discussion.
I've started working in Rust too and I too find it a tremendous breath of fresh air. It's the first time I've been excited about a new programming language in many years.
C++ promised to be a language that was both high performance and very expressive but I always found it very difficult to work at a high level of abstraction in C++. The sharp details always stab through.
Rust code, on the other hand, often doesn't look much more elaborate than code I write in much higher level languages but it's far, far faster and I feel more confident in its correctness.
Too bad most of the Rust jobs right now seem to be in crypto.
> Too bad most of the Rust jobs right now seem to be in crypto.
It is not really surprising that the crypto bros jumped onto the bandwagon, the tech got hyped just around the same time. Just, one of them correctly. :)
It's just a shame that other companies don't seem to follow suit. Except some, who always ask for "Senior Rust Developer" which I'd guess is still a limited supply market. :D
> Except some, who always ask for "Senior Rust Developer" which I'd guess is still a limited supply market.
I've seen a role advertised for 750k/month. It makes sens: those who move fastest get to milk the crypto bubble and make out like bandits. Oh wait, exactly like bandits.
You might try looking at r/rust they have a who's hiring post like HN does. I have only looked at it once or twice but haven't seen a single crypto post.
> C++ promised to be a language that was both high performance and very expressive but I always found it very difficult to work at a high level of abstraction in C++. The sharp details always stab through.
I wonder why, doing Windows programming with OWL in 1993 was quite delightful, or Mac with AppToolbox/PowerPlant,...
Yes there is always C stuff coming throught the cracks, but I see similar aproaches with Rust code making use of unsafe when there are safe alternatives.
>I wonder why, doing Windows programming with OWL in 1993 was quite delightful,
For me, it's because memories are not trustworthy (rose-colored glasses). Also, I had less experience back then. And we as an industry didn't know any better.
I got started in programming in Borland Pascal and Borland C++. Because of nostalgy, I've tried using them for fun again ten years ago and boy is there a reason I stopped using them in the first place. Sheesh.
Example OWL snippets:
for (int index = 0; index < count-1; index++) {
int len = GetStringLen(index);
TAPointer<tchar> buf(new tchar[len+1]);
GetString((tchar*)buf, index);
*outStream << (tchar*)buf << _T('\n');
//delete buf;
}
...
TClipboard cb(*this, false);
if (cb.EmptyClipboard()) {
int len = GetStringLen(index);
HANDLE cbhdl = ::GlobalAlloc(GHND,len+1);
LPTSTR buf = (LPTSTR)::GlobalLock(cbhdl);
GetString(buf, index);
::GlobalUnlock(cbhdl);
...
class tGastValid : public TEdit {
public:
tGastValid(TWindow *Win, short ID) : TEdit(Win, ID) {}
void EvKillFocus(HWND);
DECLARE_RESPONSE_TABLE(tGastValid);
};
DEFINE_RESPONSE_TABLE1(tGastValid, TEdit)
EV_WM_KILLFOCUS,
END_RESPONSE_TABLE;
void tGastValid::EvKillFocus(HWND hWnd) {
GetParentO()->SendMessage(WM_COMMAND, DB_BTGAST, 0);
TEdit::EvKillFocus(hWnd);
}
^-- I liked THAT? What was wrong with me ;)
That said, Borland had really good class libraries. If I had those libraries in a modern language, hey that wouldn't be so bad. But these languages? No, thank you.
Compared with Win16 Petzold style, that looks great, and it also reveals lack of knowledge from OWL features that don't require direct Win16 calls like raw strings instead of TString.
By the way, you should have a dive into how the "modern" development experience with Rust/WinRT compares with C++ Builder in 2022.
> I see similar aproaches with Rust code making use of unsafe when there are safe alternatives.
Really? I review and read a bunch of Rust code on a weekly basis from projects I might use in various contexts. I hardly ever see unsafe used, except in contexts where it is necessary like FFI.
That isn't a trend line, the crates are sorted by percentage of unsafe code.
From your link: To get this plot I ordered all crates by unsafe code % and then plotted it, so each point on the graph is unsafe code % for a single crate.
The link is still some evidence in support of your position, given that it drops off close to the left edge, i.e., a small number of crates have a large amount of unsafe code. But it isn't nearly the smackdown of GP's position you must think it to be for you to be so aggressive toward them.
Yes, you’re correct trend is the wrong term. Was that an aggressive statement? It wasn’t intended to be.
I find the statements around unsafe in Rust to generally be incorrect though, from what I can tell, it’s only ever used in quite narrow cases and not generally across the vast majority of Rust software.
Isn’t that an FFI boundary though? There are a lot of examples of FFI crates where the inner FFI is wrapped by an outer safe crate with a Rust API.
Not having looked at that API specifically, it might be that they think there are perhaps different approaches to implementing the safe interfaces, and those may be best left to specific implementations for UI abstraction frameworks, like Druid.
> doing Windows programming with OWL in 1993 was quite delightful
I never used the C++ version OWL (though i do have Borland C++ 5 around here, perhaps i'll try it for fun at some point), but the Turbo Pascal version of OWL (which i also really used but had a brush with - and some docs) wasn't really that great - more of a helper library for the underlying Windows API, needing to know the underlying API, in practice not very different than MFC (also more of a helper library to make using Win16/Win32 easier than something to let you ignore it).
VCL was by long long far the best API/Framework (and in some ways it still is, though FCL/LCL is better since it is richer and also crossplatform).
FWIW i did a partial recreation of Turbo Pascal OWL in Free Pascal some years ago[0]. It doesn't have much of a practical use though (unless you want to make some small GUI EXE files in Free Pascal) since i think even Borland abandoned the Pascal version of OWL and i doubt many people used it.
When the alternative was raw Win16, it was certainly delightful and felt pretty much an evolution from Turbo Vision.
Naturally VCL was even better, Microsoft is still trying to catch up with C++ Builder and failing spectacularly at it. C++/CX could have been it, but then the ATL/WRL folks at WinDev had to kill it.
> Rust code, on the other hand, often doesn't look much more elaborate than code I write in much higher level languages
I'm curious to see an example. Could you show something written in Rust, or another "much higher level language" that you think would be messier or more difficult to write in C++ ?
OK, that's an interesting language feature, but I can't say it's something that I've often wanted to do in C++. Of course C++ does have std::variant and std::any, although I'm not really a fan. I'd tend to (and have) just use a class that contains the variants and an enum to track which one, then setters and getters.
Of course the Rust features being used by that Event type are runtime polymorphism and type introspection, so another obvious C++ approach would be just to use a pointer to a virtual based class including the type, then:
switch (event->type) {
case EvKeyPressEvent:
{
auto kpe - dynamic_cast<KeyPressEvent*>(event)
...
}
break;
}
This is such a bogus argument. I am working in Crypto and have no trouble getting offers from non crypto companies. My resume also carries other evils such as the surveillance overlord and the evil empire, among others. I always found it easy to waltz into a new job with those names.
I have also hired dozens of people coming from companies which were pinatas of du jour. Neither I nor any of the other people involved (sourcers, recruiters, execs, HR) gave even a minimal amount of shit regarding "resume stench". If a candidate passed our hiring bar, we hired them.
So you think someone who worked at a crypto startup showed a lack of judgement? Do you have a blacklist of companies or sectors (adtech, surveillance tech, data collection, weapons manufacturers, pharma, lottery, porn, ...)? I would love to see that list.
> So you think someone who worked at a crypto startup showed a lack of judgement?
Yes, yes I do. I've had a candidate with 2 crypto rug pull startups under his belt, otherwise brilliant and passionate about tech. He went back in for a hat trick. I do not think he displayed proper judgement, do you?
Depends on the details of the prior two startups and the third one. It may or may not be poor judgement. But to get back to your original post, will you blacklist every single candidate who has had a stint in the Crypto space?
Do you also think that someone who worked on two Google chat apps (which are obviously discontinued) and now working on their third one is showing a lack of judgement?
> But to get back to your original post, will you blacklist every single candidate who has had a stint in the Crypto space?
Not if they recognize the mistake and learn from it.
> Do you also think that someone who worked on two Google chat apps (which are obviously discontinued) and now working on their third one is showing a lack of judgement?
No, it's not fraud and the paycheck checks out. On the other hand, can you imagine? Do you know someone like that?
Yeah, I wouldn't hire someone from a company who caused mass genocide and ran a fake news propaganda machine and then and profited billions from it [0] and is also using Rust as well then. /s
Having FB on your resume can leave a stench indeed. Depends a bit on context though, it's a big place. Going into crypto today, that's a pretty clear lack of judgement.
It's a bubble, 99/100 crypto companies are going to crash and burn, or already have. If you manage to land on the 1/100 that actually does something useful and survives, well, better odds than the lottery I suppose.
> It's a bubble, 99/100 crypto companies are going to crash and burn, or already have.
I'm sure this is the 990th time that I have heard this. The fact is, it isn't going away and it seems even more crypto companies have taken interest in using Rust and that is good.
Even some (crypto) companies are sponsoring the Rust Foundation as silver members. Nothing wrong with that. [0]
VC typically has an investment horizon of 10 years, and the latest crypto surge is only ~2 years old. A lot of the companies from the last (circa 2018) ICO bubble did crash and burn. I don’t think it can be taken as fact that the ones from this round are “here to stay”.
What are crypto companies doing that I should care about? Give me something I could go check out and use that is:
(1) Not speculation, gambling, or some variation thereof.
(2) Useful for something other than crypto itself.
(3) Actually works and can be used today.
(4) Continues to make sense even in a crypto bear market. (In other words: I will still buy milk even if the US dollar is falling because the point is the milk not the dollar. What in crypto is like that?)
That’s cryptocurrency in its original use case: virtual money.
This was all technically possible in 2009. What I was getting at was… what’s new? Billions and billions have been poured into all kinds of app development and R&D in this space and all we have is still what we had when Bitcoin launched.
What are all these people in crypto building? Where is it? Where can I use it?
Imagine if 25 years after the dot com era after hundreds of billions had been spent we still just had e-mail, static html4, and text chat protocols over dialup modem.
Increased social and political acceptance of Bitcoin as virtual money? That is a big deal.
> ...all we have is still what we had when Bitcoin launched.
False. In 2009, a very very small minority took it seriously. Now you have Blackrocks of the world getting in that business and SEC approving a Bitcoin ETF. So after Billions and billions of investment, now Crypto is a "serious business". Which is exactly why people in Afghanistan and Venezuela can rely on Bitcoin. They wouldn't have done so in 2009.
Another use case is digital art. Until NFTs, I am not sure how artists made money with their digital collections. Now, the creators of Bored Apes can fetch ~75 ETH (~100K USD)[1] per Ape, even today after the Crypto market has crashed. That is durable value and Crypto has enabled that avenue for artists. If you think NFTs are scam for laundering black money, burden of proof would be on you to make a case about why that is different from traditional paintings. And if you think traditional art too is nothing more than an avenue for money laundering, then... I'd propose we agree to disagree.
Yet another use case is branding. Just look at the adoption of NFTs[2] among top brands like Nike, D&G, Tiffany, Gucci, NFL, NBA, La Liga or Australian Open. If legit businesses and sports leagues are adopting Crypto for branding purposes, that is a resounding proof about the viability of this particular use case.
Does anyone actually use BAT or just the Brave browser? I would consider paying for a privacy-first browser in regular money, but have no interest in the BAT thing which seems entirely shoehorned in.
According to Eich, something like 20% of their userbase or so. I personally have no interest in it, but don't mind their ad model. The company does sell real money services - perhaps most notably in the "pay for the browser" type category, they offer a paid, ad-free version of Brave Search.
True, but that's the investor's problem, not the employees. They'll end up losing their jobs in the end and move on, but it's not like people in other tech company never lose their job either. The good thing when it eventually happens is that there will be a lot of senior Rust developers that are needed by most company to even start doing things in Rust.
Is their work pointless? Sure. But aren't Googlers' jobs not pointless too? That's the sad state of the 21th century: most people have a bullshit job but they need it to pay their mortgage.
Ability to evade government controls sounds like a great thing in a lot of circumstances. I have compiled a list of specific examples around that topic: https://news.ycombinator.com/item?id=32406095
Why do you think governments are always right? Haven't you learned any history?
Yes and no, both. That really depends on what government and what control.
But anyway, the amount of value you can provide there is severely limited, as you can only at most undo the value your government is destroying. You can't ever get in a better situation than what you would get with a competent liberal-ish government and no cryptomoney.
That means some business can exist there, and a small amount of it can even be morally acceptable. But it is completely different from the internet boom.
> You can't ever get in a better situation than what you would get with a competent liberal-ish government and no cryptomoney.
And what if you have only an incompetent authoritarian government? How would you help fight citizens of those governments? Crypto is a great tool there. Just because there are insufferable crypto-bros peddling shitcoins to make a quick buck doesn't mean entire Crypto field is useless. That'd be like blacklisting the entire data mining field because surveillance tech and adtech exist.
That's my feeling, you might pick the company that becomes the google of crypto, or you might end up in one of the ones you haven't even heard about because they disappeared without a trace.
There are still other options available :) For example, Qdrant vector search engine. It's written in Rust, and it's not about crypto. And currently they are hiring Rust developer. Check job openings in LinkedIn
You'd be surprised. Most legitimate cryptographers I know won't touch this space with a ten-foot pole. That should you to guess who the people actually implementing it are.
Here are a few prominent cryptographers in the 'cryptocurrency' scene with 'deep knowledge':
Matthew Green from John Hopkins University [0]
Zhenfei Zhang of Ethereum, Mina, Algorand blockchains who co-created the NIST post-quantum cryptography standard for digital signatures called Falcon [1]
Nadim Kobeissi creator of cryptocat now created Capsule Social [2]
Silvio Micali, Turing Award Winner for his work on Zero-Knowledge Proofs [3]
So, I'm afraid that there are some credible people like those above who have a significant and documented background in cryptography who are also working in the cryptocurrency industry.
A lot of crypto nerds swarmed to this field because the tech is undeniably fun, and the whole space is rather interesting and is fun to play in. Kinda like it's more fun writing a multiplayer game than a singleplayer game?
I don't think most of these people are into cryptocurrencies specifically.
Very scummy companies. They often try to pull tricks like paying your wage in mostly their own coin which they plan to rug pull before you are able to cash it out.
> I always found it very difficult to work at a high level of abstraction in C++.
That's the opposite of my experience. The ability to abstract is exactly what I miss since working with C#, with much useful stuff removed to please incompetent developers and their managers.
> Rust's enums and exhaustive match statement are just amazing
ADTs + pattern matching are the killer feature set that makes the more popular functional languages so damn pleasant to use, and they're starting to spread to more and more languages. I suspect that, 50 years from now, we'll look back and see them as the key paradigm shift of this era.
This. I have no idea why people underestimate the conceptual power of ADTs. Every time I try to explain this concept they just disregard it as just a convenient wrapper over union...and union isn't THAT common right..?
Turns out that having a much better tagged union opens up so many possibilities. Software deals with states and what's better to represent states than an ADT? Last time I was fixing an issue where a mouse position is initialized to (0.0f,0.0f) and causes it to trigger a mouse event on startup. The fix was to simply turn it into an Option<(f64,f64)> which is so much better than initializing them as (-1.0f,-1.0f) because it forces you to check all the places where you do arithmetic operations on them.
> This. I have no idea why people underestimate the conceptual power of ADTs.
Blub. It's one of those conceptual steps which seems to have no benefit until it actually clicks and you realise how much it opens or does. Being a tremendously good educator is necessary to make people take that step without experience.
> Is an Algebraic Data Type (ADT) in rust an enum or tuple?
It's the combination of both.
Tuples are Product Types. If you treat types as sets of values, then the type (A,B) is the cartesian product of types A and B. For all practical purposes, structs are just syntactic sugar for tuples. Enums are Sum Types. The values of Result<T, E> are fundamentally just all the values of T plus the values of E (with a tag to tell them apart). Put the two things together, and enum Coordinates{TwoD(f32, f32), ThreeD(f32, f32, f32)} is a set of values with cardinality #f32^2 + #f32^3. You can build types corresponding to arbitrary polynomials, hence the name.
"Union type" usually just means the same as "sum type", though it can also be used to mean C-style unions specifically.
(There's also functions as exponential types, with A -> B having cardinality #B^#A, but you're neck deep in type wankery when you start talking about those :o)
Almost every language supports product types in some way, either implicitly or explicitly, and nobody really bothers talking about those in isolation. It's when you add sum types to the mix that people start talking about ADTs, and it's when you add pattern matching that the whole thing comes into its own and you can just express functions as "things with this shape become things with that shape".
Enums are Sum Types, which are a type of ADT[1].
Tuples are a Product Types, which are another type of ADT[2];
Sum Types are so called because when you add one to that, you add just one more possibility (It could be A,B now it can be A,B,C). Product Types, on the other hand, give out possibilities based on their Product, so if you add a new property, you multiply it (A,B can both be two things, so you have 4 possibilities, if you add C that can also be two things, then you now have 8 possibilities).
You are. But benefit depends how your language is utilizing it. Do your function type check your struct input at compile time? Do your condition statement compiled error when you miss addressing a complete set of enum?
Most Java libraries want to keep compatibility with Java 8, or at most Java 11; there will be more uptake of these kinds of features once the baseline becomes Java 17, which will probably still take a long time.
True. But there are more features out there (such as typeclasses) which are also extremely important and need to become mainstream. We are really not quite there yet.
What makes functional languages so damn pleasant to use is the fact that closures are cleaned up automatically by the runtime system once you're done with them.
Could you give some detail? Is it true for functional language that has mutable data structure and reference as well? How does it clean up, are you talking about "closure conversion"?
> There is of course some legitimate worry that the Rust crate ecosystem could devolve into the crazy left-pad world of npm, and it is something to be wary about, but so far the Rust crates keep an overall high quality.
Note that the particular case of left-pad cannot happen with crates.io/cargo, because once published, you cannot unpublish a crate. You can 'yank' it, in which case it will not be resolved by Cargo.toml, but if you put it in Cargo.lock directly (IIUC) it will still work. So we can't have someone pulling a crate and crashing half the ecosystem.
We can however still have lots of other problems that plague all package management systems. Check out `cargo-crev`!!!! It's an awesome idea I'm always plugging to solve the lack of trust in an open library repository. It requires people to participate though.
Good point about the yanking. But yes, there are multiple other problems such as typosquatting and adding malicious code to a patch release. `cargo-crev` and `cargo-vet` are both interesting tools that I'm keeping my eye on.
From my experience in C there are two ways libraries deal with not being able to easily pull in their own dependencies. Some of them include their own reimplementations of lots of things (data structures, logging, error handling, date-times). Others decide to keep it simple and only implement a minimal set of functionality which limits their need for dependencies or reinventing the wheel.
Cargo letting libraries easily have their own dependencies means that many Rust libraries are very rich and fully featured. This has plenty of advantages, but the big dependency tree can be a problem in some circumstances. Crate features can sometimes help but usually not much in my experience.
I’ve seen libraries appearing in Rust which are specifically very simple and minimise dependencies (ureq is an example I like). This gives the developer the choice whether they want libraries which just do a small basic job or whether they are okay with including lots of dependencies in exchange for rich functionality. There’s a risk of segmenting the ecosystem (see also async/tokio) but it seems to be working pretty well to me.
I don't know that I have a better suggestion, but the lack of friction on adding new dependencies makes for really hairy dependency graphs. For example, I really loathed having to write this[1] when all I did was write a gstreamer plugin in Rust. I'm not even confident that I got it all the licensing right, and I surely didn't vet every single library in the graph nor will I vet every library during a future cargo-update.
In languages where adding dependencies is more difficult, I think things tend to be simpler and thus, more verifiable. But it's also simply harder. I don't know which solution I like better.
In theory, if the complexity of libraries stayed the same then pretty much the only advantage of not having recursive dependencies is a simpler license statement, and cargo-license should make that easy to automate.
In terms of checking over the code, cargo dependencies should result in less duplication and so fewer lines of code for the same level of functionality, and having it split into crates doesn’t obviously make it harder to review and Cargo.lock means the dependencies won’t change unexpectedly.
I do agree that there is a question about whether easy access to pulling in dependencies means libraries are more inclined to bloat and unnecessary complexity. But not having cargo dependencies at all would seem like a very big hammer to solve that problem. I’d much prefer to grow an ecosystem of minimal/simple libraries which don’t try to do everything and which limit their dependencies.
Actually writing the license wasn't the bad part, it was that Cargo more-or-less-silently pulled in a couple dozen different projects, which means a couple dozen different projects that a responsible software distributor "should" be vetting.
(I did use some tool like you mention, but my recollection is they were pretty crummy. IIRC they just did a dumb full dependency graph, so included stuff required only for platforms that I wasn't deploying for; also I think the output format was ludicrously verbose so I had to manually trim it down. This was a couple years ago, perhaps the tools have improved since then.)
> Rust's enums and exhaustive match statement are just amazing, and now that I'm using them daily I can barely imagine how I could live without them for so long.
I feel this! I absolutely love rust's fancy enums - i.e. not just a set of constants, but where each variant can be a full fledged type of its own, and how you have to handle every case whenever you're matching on it. It dovetails absolutely wonderfully with non-nullability and errors as values. This is probably the main nice-to-have in a language for me. Unfortunately, I don't really work in a low-level domain so I'm not sure the extra complexity of manually managing memory is worth it to me.
Do any other higher-level languages have rust-style enums with exhaustiveness checking? I only know of Haskell and Ocaml. Actually, I suppose TypeScript has something kind of similar.
I almost said the same thing, but a tuple starting with an atom is basically the dynamically typed version of an enum. :) You can safely think of ADTs as sugar and typing rules for such tuples, though I believe you do need dependent types to come at it from that direction...
If you're considering OCaml, you can also take a look at F# and Scala, both of which are languages that are influenced by the ML family but run on more popular host runtimes (the CLR and JVM respectively) that gives them access to a bigger ecosystem.
You have to understand where enums originally came from. Initially they were simply #defines in the pre-processor to make code easier to read. Instead of having "magic numbers" all over your code you'd have something that kinda made sense.
Then they became part of the C language when they evolved into enums but still remained compatible with int's (you could cast an enum to an int).
In that mindset it never occurred to anyone that an enum could have an "internal" value too.
One thing I can't seem to find a quick answer to from the Rust crowed is how does Rust handle dynamic lifetimes? It seems like it does not; it simply prevents you from referring to objects that have a dynamic lifetime not known at compile time.
You either have to use 'unsafe' or use the 'handles' pattern where you have what amounts to a custom allocator but the compiler does not know that it's an allocator so it can't prevent 'use after free' bugs.
I suppose you can also use Rc, but isn't that essentially a garbage collection scheme, with similar performance characteristics? (AFAICT a reference counting scheme must be able to nullify all references to an object when it's deallocated, so deallocations can become arbitrarily expensive).
- Use a Vec, slotmap, or a similar data-structure and store handles (indexes). This doesn't entirely prevent use-after-free bugs. But it does tend to make them panics rather than silent errors.
- Use unsafe (and ideally create your own higher-level safe abstraction)
In theory, there should also be 4:
- Use a GC library
But I haven't seen a good implementation of this yet.
---
If you're missing something, it's perhaps that most lifetimes aren't dynamic. So you get all the benefits of Rust's ownership in the 80% case. And in the 20% case you don't get any particular benefits, but you still have all the same options available to you as in other languages.
But most of the bugs I often face and seem to struggle with are with dynamic lifetimes (in graphics / simulation / gamedev). So even as a relatively low-level systems dev I don’t really find Rust’s borrow checker that useful.
I think there are cases where borrow checking is difficult for a domain, but without a lot more detail it's hard to say. My understanding is that graphics/gamedev is one of those cases and if you aren't willing to use ECS you may have problems.
You can also check index out of bounds in C++ code, and you actually have more freedom to control it in C++. In Rust bounds checks are required unless you use unsafe, in C++ you can turn it on/off freely depending on your usecase (for example, when you are in debug mode vs. deploying your code).
> AFAICT a reference counting scheme must be able to nullify all references to an object when it's deallocated, so deallocations can become arbitrarily expensive
The idea of reference-counted object is that by the time it's deallocated there _are_ no references left to update. Now you might reasonably be asking about the memory left behind by those old references which contain now-invalid pointers. The use-after-free risks of any single given reference to the object is something the Rust compiler can reason about quite easily. Once you drop one of them (and the refcount decrements) you are guaranteed not to be able to get at that pointer again; not until that memory is reinitialised with something else valid.
Well, there's a concept of a _weak_ reference. I don't know whether it exists in Rust but I can't imaigne a modern reference counting system without support for it.
A weak reference does not prevent the object from being deallocated, but the system guarantees that when the object is deallocated, all weak references to it will be nullified.
This is what makes deallocating objects in a refcounting system potentially arbitrarily expensive.
> A weak reference does not prevent the object from being deallocated, but the system guarantees that when the object is deallocated, all weak references to it will be nullified.
> This is what makes deallocating objects in a refcounting system potentially arbitrarily expensive.
Depends how you implement weakrefs. In Rust, when you upgrade a weakref it checks if there are outstanding strong references, and if there are not the control block is considered invalid and the upgrade fails.
There is no need to touch any of the weakrefs at any point.
And unlike languages like Python, Rust does not have weakref finalizers either.
Deallocation is still arbitrarily expensive in general, as the entire subtree will get deallocated recursively, but that has nothing to do with refcounting.
The way it works is, in order to use it you try to upgrade it to a normal Refcounted pointer. Since it is a weak reference, this upgrade may of course fail and in that case return None (in place of a null pointer). When this upgraded pointer dies (either goes out of scope or is manually downgraded) the refcount will again be updated.
Yes, your options are unsafety, garbage collection (in the broad sense, which includes Rc), and hiding lifetimes from the compiler via "handles" or similar.
Can you even imagine other options, though? If enough information about the lifetimes isn't known at compile time, how can the compiler prove it safe?
It's very rare that a serious problem can be solved without some objects having some sort of a dynamic lifetime that you have to manage.
Rust just prevents you from doing this. So you can say it provides safety, but it also restricts you from solving the vast majority of serious problems that we write programs to solve.
This is very different from static vs dynamic typing.
In a statically typed language, the compiler actually _knows_ what you can and can't do with each object.
Where as Rust's life time management just says "Nope, I have no idea whether what you are doing is safe or not so I'm just going to tell you you can't do it".
If you refer to heap allocations, then you can use Box, Arc, Rc. They are not a "garbage collector" nor do they incur performance hits other than a regular heap allocation.
yes, but that's not a JVM-like slowdown. It's fairly well amortised and _clearly_ not a matter of consideration when writing an app or a library.
If your issue is "atomics are slowing down my app", then I assume you already milked the code to the latest micro second of performances everywhere else. This is likely not the case here and not a general advice I would give to anyone.
Remember, some dev in python where concurrency is inexistent, start-up time is horrendous and performances are abysmal compared to rust. (this is exaggerated: of course you can run stuff in parallel in python)
Which should be incredibly negligible unless you're counting literal millions of objects. Even then, I'm suspecting that refcounting will never be in the top spots of things that slow you down.
What I'm saying is that bumping atomic references inside a hot loop will be detrimental for performance, and since it invalidates a cache line and this can flush caches for lots of cores. It also shuts down ILP.
One really nice thing about Rust's use of Arc is that you don't need to bump atomic references in a hot loop, or much at all usually.
Once you have an Arc<T> you can `as_ref()` to get a &T. So maybe you need an Arc to share something with another thread, so you clone it once. Once you're in that thread though you can go back to just using `&` and never touch the atomic again.
Technically yes, but if you only use it when you need it, it's often not a performance concideration.
And for systems programming, the often overlooked truth is that people care far less about perfect performance than they do about control - ref counting doesn't give up control to a mysterious oracle running in the background which may or may not wreck your performance in hard to predict ways, it just pays a known cost at the time you use it based on how you're using it. (that's not to say performance is irrelevant, but it's not always the top concern, and with control you can always rewrite slow code as needed).
The obvious question is "why can't we have an optional modern garbage collector built into a systems language?", and it's a good question (I remember reading there was one in rust for a while during early development, but it got removed), I think the main reason is that high quality garbage collectors are incredibly complicated, with many trade offs, and a gc that combines well with the rest of a language and various alternative memory tracking solutions is harder than most. The projects that really want one can always implement their own and choose their own tradeoffs, so there's not many use-cases where a generic language-provided one would justify the complexity of implementing it within the language.
> why can't we have an optional modern garbage collector built into a systems language?
It's possible in C#. Some language and runtime features like lambdas insist on using the GC, but with some care they can be avoided. The usability becomes worse without these features, but IMO that's not a dramatic downgrade.
Many pieces of the standard library in modern .NET don't require managed heap. Instead, they operate on stuff like Span<byte> which can be backed by anything: unmanaged heap, native stack, or even the memory mapped to user space by a Linux device driver (I did it with DRM, V4L2 and ALSA devices).
That's an issue when every object is managed. Which is not the case in an unmanaged language, you'd only refcount what you need to refcount.
Furthermore Rust can also safely borrow from a refcounted pointer without the need for refcount traffic, which can be quite the performance gain for atomic refcounts (it's nigh irrelevant for non-thread-safe refcounts as those just do a local increment/decrement).
It's generally true to be fair, reference counting could be used for every garbage collected language (and be much simpler). The only reason they switched to more complex schemes is they're faster on average. Even smart schemes that try to remove unnecessary ref count changes will tend to underperform compared to a (well built) tracing GC. As for a reference, https://en.wikipedia.org/wiki/Tracing_garbage_collection#Per...
The point about predictability is totally valid though (and combined with simplicity is the reason many languages still pick ref counting).
Since 1.62 there have been a native way of doing it with the `total_cmp` method [0] on floating points which can be used to at least sort it quite easily, but cannot really use it in collections like BTreeMap.
As someone who's not the biggest fan of Rust because of its complexity. There is a big reason to use it today. If you need to use something that has safety guarantees where it's possible to achieve acceptable performance in certain classes of programs where languages like golang, nim or crystal have trouble achieving then I just don't see any other options out there certainly not one with as many libraries available as rust.
Maybe I can use a combination like c and lua to get the right trade offs between safety and performance in the necessary parts of my program but I'm not that confident that I can reach either safety or acceptable performance doing that.
Maybe, I could use C and some kind of static analyzer to find all of my memory bugs. Again, I'm
not confident I would succeed there. I might also need a fuzzer to do it.
At this point I'm trading a complicated language for a easy fast language with extra complicated operations that may or may not give me the outcome of memory safety.
Yeah even if I'm a big fan of ML family lang, complexity to solve memory safety is too much to the point Zig is more appealing in way that helps you do it yourself more easily.
IMHO the biggest reason for Rust is that developers NEVER get enough time to write perfect code. All this takes time and management usually doesn't grant you that allowance.
In a perfect world where developers could tinker with the code until it's perfect we wouldn't need Rust. This is not that world.
Not even that. Because if your language isn't expressive enough, you can't make code perfect. Or rather, "perfect" in one language is than worse than "good" in another language.
Imagine big but perfect Assembly codebase against an okay-ish Rust codebase. Which one would you prefer to maintain?
You can choose between 1) your programming language being complex or 2) your codebase being huge, repetitive and boilerplaty. I know what I'll choose any day.
Language features. There are many features and language patterns, paradigms which I need to get used to in order to use libraries and read others code. (Similar to C++) I can't even begin to understand macros.
So far it doesn't seem to be insurmountable but it's definitely not what I'd call simple.
Most benefits of Rust are true, except in some cases it does not allow you to compile an absolutely valid and safe program like here https://github.com/rust-lang/rust/issues/47680 - unfortunately you don't have freedom of code design decisions! I see some possible problems with refactoring, extending logic and functionality, and lots of issues with async code design and readability.
For me, Rust looks like a temporary step before the next language.
You have successfully linked to the only meaningfully loud bug in the borrow checker; declaring that as proof that Rust is a temporary step does not seem like the most cool-headed of evaluations, especially as it will be fixed by a new borrow checker in active development. These assertions are always made, and always alongside information suggesting the speaker has not actually spent very much time using Rust.
Eh, it might be the only meaningful issue with the borrow checker, but the language itself has more issues than just that. I adore rust and have done for years, but I also see it as a stepping stone language and worry about it gaining too much adoption
It is a stepping stone language in the sense that nobody has ever done anything like it before but you could adapt some of its principles to a language where you don't have to care quite so much about the stack. (Things you could not jettison along the way include ownership and explicit lifetime annotations.) But the language has absolutely nothing I'd call an issue. Only things that could be made even better, and coincidentally always are.
I don't understand why everyone seems to ignore Ada? Granted I am completely new to it, but from what I see it is years ahead of Rust in terms of safety (it can prove correctness!! Rust is only heading into that direction).
Yes syntax is verbose, but I dare to believe there must be another blocker than just syntax?
I did some ADA in the past and yes, it is a nice language, but it lacks the modernity and a dynamic community like Rust.
ADA did received some nice update to its specification, but, just like C++, it struggle / cannot really fit the latest innovation in programming language that easily.
And to be fair, it is fine. ADA is very much a "committee" language (its spec are ISO/IEC) instead of a "community" language (all the spec and rfc of Rust are on github and anyone can easily discuss them).
This makes it so that ADA doesn't get the attention, and the rapidity of innovation, that a language like Rust does, but ADA is mostly made for program that will need to be maintained in critical operations for decades with the code being maintainable and compilable far into the future.
> I did some ADA in the past and yes, it is a nice language, but it lacks the modernity and a dynamic community like Rust. ADA did received some nice update to its specification, but, just like C++, it struggle / cannot really fit the latest innovation in programming language that easily.
I'm still learning both Ada and Rust, so please keep that in mind. Nevertheless, I humbly disagree. The more I learn Ada and other "old" languages the more it looks to me like "modern" ones rediscover things that have been present in other languages for years.
The really significant difference I can see for now is that Ada is not focused so strongly on functional programming paradigm and it has no async/await sugar. Rust borrow checker is a strong success of course and was another significant difference, but latest SPARK got borrow checking capabilities too, AFAIK.
While Ada's open-source community is smaller, I find it as energetic and devoted to improving the ecosystem as Rust's. I have no idea about closed-source community, but in the past 4 years ArianeGroup [1], Airbus [2] and Nvidia [3] talked about choosing Ada for their high-integrity applications.
> And to be fair, it is fine. ADA is very much a "committee" language (its spec are ISO/IEC) instead of a "community" language (all the spec and rfc of Rust are on github and anyone can easily discuss them).
You can discuss Ada/SPARK RFCs on Github too. [4] I think I once saw on Ada forum or chat that someone proposing changes to the language was simply invited to talk to people working on the standard, so it doesn't look like the language is developed in isolation or something.
> This makes it so that ADA doesn't get the attention, and the rapidity of innovation, that a language like Rust does, but ADA is mostly made for program that will need to be maintained in critical operations for decades with the code being maintainable and compilable far into the future.
I think that Ada adopted quiet quickly to changing world with Rust as its inspiration: lower entry barrier toolchain, compelling licensing, library distribution, RFCs, etc. And in terms of language features, in many areas it's not only on par, but ahead of competition. So you're less likely to see lots of changes, but they do happen nevertheless. I'm not saying Ada is perfect, of course. There are parts of it that other languages do better. No shame in that.
IMHO, the reason Ada is unknown to many people is a combination of its past, myths surrounding it, and general trend of people to follow trends. ;) But currently I find Ada/SPARK even more compelling option than Rust, even though I like both.
For me it's the borrow checker and lack of shared mutable states stopping me from doing dumb things. Add on things like cargo build manager and crates and it's like a delicious roast dinner smothered in gravy.
I've written in Ada95 back in college and it was great but I'm like a duck in water with Rust.
Oh yeah when I first started coding in Rust and saw its enum type system the first thing that came to my mind was "this is cool but they also need range types like Ada".
I was in college when C++ was taking off, and the hype around C++ wasn't really the language, but rather the OOP paradigm, which C++ enabled on top of C, which was heavily established. C++ took off far faster than Rust has. I don't have exact numbers, but C++ was used almost nowhere in the late 80s, and by 2000, it was the defacto programming language all over the place (especially with video games). Rust's first stable release was 2014, meaning it has been around for 8 years. By the time C++ was around the same age, it was as popular as, well, C++ is now, actually!
Rust is just way better thought out on a deeper level than C++ ever was (or is). It has its issues, and while it may suddenly accelerate adoption in the next several years, I don't actually seeing it gaining many inroads. I hope to be wrong! I think, these days, language kinda doesn't matter as much, as all languages are picking up chunks and pieces of all the various paradigms, like a decorator crab, and that tends to work fine for established code bases.
Yeah? I was excited about C++, when I learned it. Basically all the performance of C, and the standard library included a vector class? And linked lists? And trees? And strings? I don't have to manually manipulate char pointers anymore, and can just say foo + bar to concat strings? Sign me up.
(Does C++ have its warts? Absolutely. But it's a huge productivity boost over C.)
I actually remember that time! C++ rode on a wave of OOP hype. It was all about that, packaged into something people were kind of familiar with. OOP WAS THE FUTURE, MAN!
Good point. I am not aware of how software was developed at the late 80s and early 90s...
But was C++ widely adopted at that time? I remember C++ compilers being a huge pain by the middle 90s. I can't imagine everybody using them earlier. (But then, it wouldn't be the first time everybody just decides to do something I can't imagine.)
I just bootstrapped Rustc 1.58 using only GCC and mrustc sources on an 8 core 16 thread machine with 32 GB memory and lot's of disk space. It took 20 hours.
1. You used an in-progress compiler to build a project and you're drawing conclusions about the language it compiles?
2. The compiler is huge, why does that imply any "bloat" of the language? Compilers do lots of things that aren't "visible" at the language level - optimizations, producing helpful errors, providing code completion/analysis assistance, etc.
3. What does "bloated" even mean?
4. What makes you think that 20 hours is very slow? Have you tried building Clang and llvm together from source? It can take quite a while, but it also depends heavily on how you build it (which build system, flags, etc), which you've not given any information on.
As a developer who mainly writes front end apps with Javascript (but with experience in a lot of other languages), I started to learn Rust for an app I want to build.
The issue is that the app itself will not really be needing maximum performance and I much more concerned about the safety aspects Rust brings. But I guess the safety aspects would be the same with me using Python for example.
Why I want to learn Rust is because it could help me in the front end aspect and I think it's a language that has a bright future.
Am I crazy to spend the time to get effecient in Rust and write my app I want to write in Rust instead of Python? Is there any other benefits of using Rust that I don't see as a beginner? I am afraid that I'll just waste a bunch of time just because I want to learn Rust and think it's cool but ultimately it will slow me down to such an extent that my app never sees the light of day or that it increases general development time.
I saw a YT video about how safe Rust is. I want to give it a try but I do mainly web applications, where I use Spring Boot and front-end frameworks. From what I have read Rust is better for system level or regular applications (not web apps). Can modern web applications be built efficiently with Rust? And by efficiently I mean, is the ecosystem there (libraries and tools).
I imagine the following would be needed..
1) Spring MVC like library for interfacing with HTTP requests.
2) DB ORM or ORM like. DB libraries for any possible DB.
3) centralized logging. e,g, Logback that forwards all logs to ELK.
4) Dependency injection.
5) Versatile configuration system. Similar to Spring configurations.
6) AWS SDK.
7) Commons like libs like Guice or Apache Commons.
We use Actix for HTTP. Works fine. I don't use ORMs, I prefer sqlx, which gives me compile time checking of queries while still just writing plain old sql. I log via the tracing library to stdout, I let other services handle what's done at that point. I don't use DI frameworks, nor do I believe that they are good, I use dependency injection via construction, which works great.
I don't do any fancy configuration. I use `clap` to take in values and ideally I'll never do any config anywhere else in my program.
The AWS SDK from rusoto works well enough. AWS has a beta SDK out for Rust as well, seems good.
I haven't found any need for libraries like Guice, there's metrics, collections, and everything else I've needed in crates.io.
Can you explain why DI needs an entire framework/libary?
When I was taught DI in school, I was given the impression that DI was a $1000 term for a $5 concept in that without DI, you write code like this:
class Foo(object):
def __init__(self):
self.bar = GetBar()
whereas with DI, you write this:
class Foo(object):
def __init__(self, bar):
self.bar = bar
Obviously, I'm grossly misunderstanding what DI is, because if that's really all it was, you wouldn't need a DI framework. I just haven't had to write code using any sort of DI more complicated than that.
What you say is dependency injection, but what people usually mean when they say a "dependency injection framework" is the bits of managing the creation of dependencies and getting them into the class's scope without having to add it as a parameter to every upper scope class's argument list.
Do you know any good references for describing DI frameworks more? Because right now, my cynical take based on your description is that it's a TON of over-engineering and an absurd amount of complexity being added just to avoid a couple extra lines of code.
You can choose your own template engine instead of having to use one that's provided (like in ASP.NET MVC). There are a multitude of template engines available in Rust.
I've heard about Web Assembly/Wasm many times. I thought it was a new kind of JS framework, so I did not pay attention since I am not a JS developer. However, after seeing the egui.rs demo [1], I was impressed! Now, I am interested in knowing more about programming languages that compiles to Wasm. Is it possible to create that sort of UI using other programming languages?
For someone like me that's an experienced programmer but relatively new to Rust, what are some open source Rust projects that could benefit from some help?
Honestly, this kind of breathless adulation is off-putting to me.
> If I'm honest, the main reason is because I love Rust.
That's nice if it works for you, but I'm looking to build and maintain software well and efficiently. I don't want a programming language I can love I want a tool. (BTW, old and tired but true: don't love things that can't love you back.)
One issue with egui and shoving the whole page into a canvas element is accessibility -- having just a canvas element is a screen reader's worst nightmare
I don't imagine its that much worse than a regular GUI program outside of a browser. I assume text can still be selected/copied so screen readers should still be able to access something.
Sorry, yes, that's kind of what I meant. Ultimately, I want to be able to seed an RNG with an alphanumeric string, and in other languages that means using a third-party library or writing one myself.
The `rand` crate in Rust is a de facto standard, but it's not an official standard, so that does technically mean trusting a third-party library. A lot of the Rust ecosystem is structured this way, in part because package management with Cargo is convenient.
They seem pretty universal to me. For example, the tedious error handling in Go that is mentioned is a turn-off to a lot of developers. Safety and speed are both things most languages strive for, and if Rust is not THE fastest or THE safest language, it’s on the efficient frontier of the two.
Exceptions are invisible though? (unless you're using checked exception in Java, which nobody does and neither python nor C++ offer). I've personally found unexpected exceptions being thrown to be one of the main causes of unreliability in production applications I've worked on. Of course you can have a blanket catch statement so it doesn't entirely crash your app, but that doesn't compare to the Rust experience where those errors almost never happen.
> I've personally found unexpected exceptions being thrown to be one of the main causes of unreliability in production applications I've worked on.
Python has a serious problems with this. Not only are exceptions not documented, they are also thrown by normal execution, so you can't just say "something serious happened here, go to the recovery".
Emil has been working in Rust for eight years. Hardly a honeymoon phase.
As for your accusation of lying: I cannot imagine where you’ve pulled that from. Emil’s description of unchecked exceptions as invisible errors insofar as you can’t see where errors might occur from the source code alone is objectively an accurate and reasonable description.
Agreed, checked exceptions surface potential errors to the caller. In that regard Java fares better. However, handling exceptions still require a separate catch clause rather than being part of the normal flow. Furthermore, it is nigh impossible to rely on checked exceptions alone, most Java code may throw RuntimeExceptions such as NullPointerException or ArrayIndexOutOfBoundsException and there is no way to know it by just looking at the calling code.
> However, handling exceptions still require a separate catch clause rather than being part of the normal flow
Only if you want to catch (handle) it. If you don't want to do that, just declare it in your "throws" clause and enjoy writing your code with the (guaranteed) assumption that you are using a valid value.
> Furthermore, it is nigh impossible to rely on checked exceptions alone, most Java code may throw RuntimeExceptions such as NullPointerException or ArrayIndexOutOfBoundsException and there is no way to know it by just looking at the calling code.
That's a bug, not a feature. These errors are often unrecoverable, hence why they are runtime and not checked.
This is personal preference of course, but exceptions are essentially "on error GOTO foo". They never resonated well with me either, since the control flow is muddled once you introduce exceptions.
> "invisible errors"
If you read further on you get the author's justification for this claim:
auto result = foo().bar();
> As a reader, I can't see where potential errors can occur. Even if I look at the function declaration for foo and bar I won't know whether or not they can throw exceptions [...]
Do you disagree with the reasoning reasoning this?
Except for the maybe simplest variable initialization, I always assume that if it exists, it may error. “Won’t error ever” doesn’t exist in the real physical world.
(See also: halting problem.)
The “invisibility” of errors in languages that have first-class exceptions usually means that exceptions are being somehow swallowed without being handled properly. Shit happens, and the program happily chugs along regardless, sowing destruction.
If you get down to reading the code, you can usually see if it is likely to error out or not. At the point where you get down to reading the code, it’s usually quite clear unless intentionally obfuscated.
A better question is, can a machine show you if the code may error and how, given language X? In statically compiled languages, IDEs have been wickedly good at inferring the possible exception types on any line of code for the last decade, even if you don’t annotate them in the signature.
> I can write web apps in another language than JavaScript
> I can write web apps that are fast
Yeah, this is what's worrying me. If you look at rerun.io website, you will notice that it's built with Next.js, i.e. is using a React framework to build pages that have no interactivity whatsoever. Next.js is used for the blog, despite it being just a collection of simple static html pages. Meanwhile, the user has to download around 200kB of javascript for no reason whatsoever; and the only reward that they get for their trouble is an avalanche of javascript errors in the browser console [0].
Is the Rust/wasm future going to look like that?
[0] - https://i.imgur.com/TpYW0Rj.png