[HN Gopher] Why Rust?
___________________________________________________________________
Why Rust?
Author : emilern
Score : 215 points
Date : 2022-10-18 09:12 UTC (13 hours ago)
(HTM) web link (www.rerun.io)
(TXT) w3m dump (www.rerun.io)
| clemens3 wrote:
| 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.
|
| If you think Rust is bloated, I agree.
| insanitybit wrote:
| It's hard to even respond to this lol
|
| 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.
| richdodd wrote:
| > 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.
| kajaktum wrote:
| What is the alternative to not having a crate ecosystem?
| Everyone roll their own smallvec implementations? How is that
| any better?
| xigoi wrote:
| You can decrease the attack surface by having a good standard
| library, so packages don't have hundreds of microdependencies
| like `rand`.
| cillian64 wrote:
| 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.
| coldpie wrote:
| 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.
|
| [1] ~75 lines of library authorship copyrights https://gith
| ub.com/ValveSoftware/Proton/blob/proton_7.0/dist...
| pie_flavor wrote:
| Note that the cargo-about tool can be used to
| autogenerate the license declaration.
| cillian64 wrote:
| 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.
| dureuill wrote:
| in case you don't know and it would be useful to you,
| there's tooling out there to generate license files from
| the Cargo.toml.
|
| cargo lichking is an example, and I _think_ cargo deny
| has similar functionality?
| emilern wrote:
| Hi, author here
|
| 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.
| cageface wrote:
| 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.
| rvz wrote:
| > Too bad most of the Rust jobs right now seem to be in crypto.
|
| What is the problem with that?
| jakobnissen wrote:
| I imagine if you're not a cryptographer, you don't have a
| chance getting those jobs.
| nicoburns wrote:
| Sadly crypto in this context refers to cryptocurrencies,
| not cryptography.
| stouset wrote:
| 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.
| bornfreddy wrote:
| Sorry to be explaining the joke, but I think GP
| (deliberately) misunderstood what was meant by the term
| "crypto".
| vanviegen wrote:
| I don't think there are that many people with deep
| knowledge of crypto working in the 'crypto' scene.
| rvz wrote:
| 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.
|
| [0] https://blog.cryptographyengineering.com/
|
| [1] https://falcon-sign.info/
|
| [2] https://nadim.computer/
|
| [3] http://people.csail.mit.edu/silvio/
| spoiler wrote:
| 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.
| coffeeblack wrote:
| Probably better if you are not a cryptographer. Because
| you have fewer inclination to write "your own
| cryptographic algo".
| Alyka wrote:
| 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
| sirwhinesalot wrote:
| 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.
| indy wrote:
| Sounds a lot like Silicon Valley circa. 1999
| marcosdumay wrote:
| Except that cryptomoney isn't adding insane amounts of
| value in any niche, outside of extortion and evading
| government controls.
| indy wrote:
| Evading government controls sounds like a valuable
| attribute.
| achenet wrote:
| oh hi there, would you like to hire a few super expensive
| accountants to optimize taxes like the other big
| corporations?
|
| (in case it isn't obvious, yes, I fully agree that
| evading government control/taxation is a _hugely_
| lucrative market).
| marcosdumay wrote:
| 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.
| RestlessMind wrote:
| > 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.
| marcosdumay wrote:
| > And what if you have only an incompetent authoritarian
| government?
|
| Then cryptomoney can give you a limited, non-zero amount
| of value. Still less than fixing the government, but it
| is easier to deploy.
|
| Even then, comparing it with the internet boom is
| bullshit.
| RestlessMind wrote:
| 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?
| sirwhinesalot wrote:
| 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.
| RestlessMind wrote:
| rvz wrote:
| > 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]
|
| [0] https://foundation.rust-lang.org/members
| paulgb wrote:
| 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".
| gdprrrr wrote:
| Well, considering that 90% of _all_ startups fail, that
| number isn 't unrealistic
| api wrote:
| 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?)
| RestlessMind wrote:
| https://news.ycombinator.com/item?id=32406095
|
| I prepared that post since the question you posed comes
| up every week here, if not more frequently.
| api wrote:
| 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.
| littlestymaar wrote:
| 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.
| rwaksmunski wrote:
| Potential criminal liability and resume stench. Would you
| hire ex scammer/ponzi to maintain your backend? I wouldn't.
| RestlessMind wrote:
| > resume stench
|
| 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 stop spreading this FUD.
| rwaksmunski wrote:
| I hire candidates based on skill, core values and
| judgment. I completely accept that others might use
| different criteria.
| RestlessMind wrote:
| 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.
| rwaksmunski wrote:
| > 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?
| RestlessMind wrote:
| 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?
| rwaksmunski wrote:
| > 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?
| rvz wrote:
| 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
|
| [0] https://www.globalwitness.org/en/campaigns/digital-
| threats/r...
| black_puppydog wrote:
| 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.
| Gigachad wrote:
| 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.
| pjmlp wrote:
| > 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.
| bluejekyll wrote:
| > 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.
|
| I am pretty sure that your comment is provably false, if
| someone wanted to run a report on crates.io. Oh, looks like
| someone did, and it trends to 0: https://www.reddit.com/r/rus
| t/comments/g0wu9b/percentage_of_...
| torstenvl wrote:
| 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.
| bluejekyll wrote:
| 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.
| pjmlp wrote:
| Have a look at Rust/WinRT where the Microsoft team is the
| opinion others should provide the safer wrappers on top.
| cageface wrote:
| Yeah everything was perfect back in my day and there's
| nothing new under the sun. You kids get off my lawn.
|
| I've been coding C/C++ since 1995. I'll take Rust any day,
| thanks.
| pjmlp wrote:
| Are we GUI, CUDA and SYSCL yet?
|
| Don't forget that to contribute to Rust backends on their
| present forms, some C++ is required.
| dannymi wrote:
| >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.
| pjmlp wrote:
| 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.
| badsectoracula wrote:
| > 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.
|
| [0] http://runtimeterror.com/tech/fowl/
| pjmlp wrote:
| 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.
| stonemetal12 wrote:
| 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.
| api wrote:
| ZeroTier is doing all its new stuff in Rust and rewriting our
| core network virtualization engine in Rust, and not crypto. We
| are hiring.
| tasn wrote:
| > Too bad most of the Rust jobs right now seem to be in crypto.
|
| We are hiring for Rust engineers. Not crypto. :)
|
| https://www.svix.com/careers/
| HarHarVeryFunny wrote:
| > 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++ ?
| emilern wrote:
| The enum example in the article
| HarHarVeryFunny wrote:
| 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.
|
| event.SetKeyPress(ch);
|
| event.SetMouseButtonPress(pos, but); etc
|
| ...
|
| switch (event.type) {
|
| case EvKeyPress: ch = event.GetKeyPress();
| pif wrote:
| > 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.
| black_puppydog wrote:
| > 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
| ncmncm wrote:
| allisdust wrote:
| It was due to its ability to be compiled to wasm which most
| chains use to execute contracts.
| manholio wrote:
| > 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.
| alexb_ wrote:
| I think you misread - they are talking about the non-crypto
| companies here.
| jmull wrote:
| 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.)
| timeon wrote:
| But I love good food.
| jmull wrote:
| I have to admit, food is a good exception to the rule.
| amelius wrote:
| This must be how people felt about C++ in the beginning ...
| gilbetron wrote:
| 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.
| Keyframe wrote:
| 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!
| marcosdumay wrote:
| C++ was C with a better interface for GUI widgets and generic
| templates.
|
| There was a lot of hype about OOP too, but I am not sure it
| was ever adopted because of it.
| Keyframe wrote:
| _C++ was C with a better interface for GUI widgets and
| generic templates._
|
| That came a lot later in its life, like mid to late 90's.
| marcosdumay wrote:
| 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.)
| nosequel wrote:
| No one thought C++ was safe in the beginning. It was very clear
| with all of the undefined behavior that we were not getting any
| safety.
| deathanatos wrote:
| 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.)
| losvedir wrote:
| > 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.
| UltraViolence wrote:
| 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.
| Existenceblinks wrote:
| Basically ML family languages have them. When you read Rust is
| ML style, almost 100% sure it's going to have Algebraic Data
| Types.
| mamp wrote:
| F#, Swift
| pdpi wrote:
| Scala, Kotlin, Haxe, Swift, and several others. The search term
| you want is "Algebraic Data Types"
|
| Erlang has the superpowered version of this - _binary_ pattern
| matching, that lets you pattern match on a bitstream directly.
| andrewflnr wrote:
| Binary pattern matching is very cool, but I wouldn't call it
| a version of ADT matching.
| hota_mazi wrote:
| Erlang doesn't have enums.
| andrewflnr wrote:
| 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...
| rad_gruchalski wrote:
| Erlang also has exhaustive pattern matching. To the extent of
| having to declare catch all arity for functions.
| vips7L wrote:
| Don't forget Java :)
| valenterry wrote:
| It's not there yet, is it?
| vips7L wrote:
| Pattern matching and exhaustive switch expressions are in
| preview.
| masklinn wrote:
| > Erlang has the superpowered version of this - binary
| pattern matching, that lets you pattern match on a bitstream
| directly.
|
| Erlang has a super-powered version of the pattern matching
| bit, but not of what GP actually likes about it:
|
| > you have to handle every case whenever you're matching on
| it
|
| because Erlang is dynamically typed. So partial patterns are
| acceptable, and not entirely uncommon.
| zaphar wrote:
| You can use partial patterns in Rust too. I think perhaps
| you meant partial matches?
| [deleted]
| masklinn wrote:
| Yeah.
|
| Also faillible patterns outside of conditional contexts.
| It acts as an assertion which is nice, but the assertion
| is implicit which is less nice.
| d3nj4l wrote:
| 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.
| throwway989 wrote:
| pdpi wrote:
| > 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.
| qaq wrote:
| ADTs is last missing piece that would make me fully content
| with Go :)
| [deleted]
| kajaktum wrote:
| I agree, I love that Go is simple but it is simply
| too...simple. It makes it hard to represent a much harder
| state transformations.
| achenet wrote:
| aren't interfaces technically an abstract data type?
|
| EDIT: ah, it's algebraic data types, my bad, apologies.
| xigoi wrote:
| Interfaces are not closed, which is considered a big
| advantage of sum types (though it can also be a
| disadvantage).
| pjmlp wrote:
| Pity that it took people 50 years to discover them.
| naasking wrote:
| > we'll look back and see them as the key paradigm shift of
| this era.
|
| You mean the key paradigm shift of the 1970s when they were
| invented. Only took 50 years for it to go semi-mainstream.
| pdpi wrote:
| Going mainstream _is_ the paradigm shift.
|
| OOP was invented in the 60s/70s, but the paradigm shift came
| in the 80s/90s.
| amelius wrote:
| 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.
| Existenceblinks wrote:
| 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"?
| kajaktum wrote:
| 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.
| masklinn wrote:
| > 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.
| the__alchemist wrote:
| I'll bite - I just googled this, and am having a struggle
| understanding.
|
| Is an Algebraic Data Type (ADT) in rust an enum or tuple? I
| make heavy use of enums (along with structs) as my program
| foundations. Am I using ADTs?
|
| The third type the query shows are unions, which I'm not
| familiar with.
| zanellato19 wrote:
| 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).
|
| This is a good explanation:
| https://jrsinclair.com/articles/2019/algebraic-data-types-
| wh...
|
| [1]https://en.wikipedia.org/wiki/Tagged_union
|
| [2]https://en.wikipedia.org/wiki/Product_type
| Existenceblinks wrote:
| I found https://guide.elm-
| lang.org/appendix/types_as_sets.html is friendly describing
| the what and why.
| belmont_sup wrote:
| They're enums that can hold additional data types.
|
| But they're additionally great because the compiler does
| exhaustive pattern matching.
| pdpi wrote:
| > 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".
| the__alchemist wrote:
| That's an outstanding explanation!
| xigoi wrote:
| Union types and sum types are different things. Given a
| type A:
|
| A + A [?] A
|
| A [?] A = A
| Existenceblinks wrote:
| 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?
| pooya72 wrote:
| Yeah, it's interesting to see them become a part of Java with
| records, sealed types, and pattern matching. However, I haven't
| seen much uptake yet.
| cesarb wrote:
| 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.
| jmfldn wrote:
| As a Scala dev I agree.
| valenterry wrote:
| 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.
| commitpizza wrote:
| UltraViolence wrote:
| bobajeff wrote:
| 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.
| valenterry wrote:
| 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.
| j-krieger wrote:
| What are the major points concerning complexity you have
| encountered?
| bobajeff wrote:
| 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.
| UltraViolence wrote:
| 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.
| Existenceblinks wrote:
| 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.
| bobajeff wrote:
| Oh, I forgot about Zig. I haven't had a chance to really
| check it out yet.
|
| As far as memory safety do you think it would be a good idea
| to write something like say a http server or client in Zig?
| stefanka wrote:
| Thanks for the article? You are not still hiring per chance..?
| emilern wrote:
| No, not right now!
| stefanka wrote:
| Maybe later then :)
| 1equalsequals1 wrote:
| Are you propagating errors with the question marks here?
| stefanka wrote:
| Good one!
|
| is_hiring()?.apply()?.code_rust()?
|
| Error handling is really nice in rust
|
| Edit: Just realized that the first question mark in my
| original question was a mistake
| ncmncm wrote:
| quuuu wrote:
| 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
| Gigachad wrote:
| 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.
| dgan wrote:
| 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?
| Veliladon wrote:
| 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.
| 0rzech wrote:
| > _For me it 's the borrow checker and lack of shared mutable
| states stopping me from doing dumb things._
|
| AFAIK, the newest SPARK got borrow checking capability. Also,
| Ada has excellent design by contract capabilities [1] and
| constrained subtypes [2].
|
| > _Add on things like cargo build manager and crates and it
| 's like a delicious roast dinner smothered in gravy._
|
| Ada has now Alire [3] for that.
|
| > _I 've written in Ada95 back in college and it was great
| but I'm like a duck in water with Rust._
|
| Ada is nearing the 2022 standard now. It changed a lot since
| 95.
|
| PS. I have nothing against you liking Rust. Just wanted to
| clarify few things.
|
| [1] https://learn.adacore.com/courses/intro-to-
| ada/chapters/cont...
|
| [2] https://learn.adacore.com/courses/intro-to-
| ada/chapters/stro...
|
| [3] https://alire.ada.dev/
| maeln wrote:
| 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.
| 0rzech wrote:
| > _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.
|
| [1]
| https://www.facebook.com/ArianeGroup/posts/2872955946126067
|
| [2] https://www.manufacturing.net/aerospace/news/21175187/air
| bus...
|
| [3] https://blogs.nvidia.com/blog/2019/02/05/adacore-secure-
| auto...
|
| [4] https://github.com/AdaCore/ada-spark-rfcs
| jmartrican wrote:
| 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.
|
| stuff like that.
| Sohcahtoa82 wrote:
| > 4) Dependency injection.
|
| 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.
| UltraViolence wrote:
| Rocket is another nice Rust web framework.
|
| 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.
| insanitybit wrote:
| 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.
| jmartrican wrote:
| Thanks for your reply. Can you disclose what web application
| this is you work on?
| insanitybit wrote:
| https://graplsecurity.com/
|
| That's my company. The blog is hosted elsewhere. Our
| frontend is hosted via a rust service, which talks to other
| rust services via grpc.
| trinovantes wrote:
| I wish C++ has a universal dependency manager like crates. It
| feels like every external library I want to use requires their
| own exotic setup.
| UltraViolence wrote:
| Yes, but C/C++ is straightforward also. You simply need the
| source and link it or get a library object file (.lib or .so)
| and the header files.
|
| IDE's like Visual Studio hide this behind tons of settings and
| dialogs but in the end it's simple if you know the above.
| dureuill wrote:
| This simplicity translates to afternoons of work lost to
| CMake.
|
| cargo just works, and isn't really complex in design. just
| less anticated.
| djha-skin wrote:
| > We've had fast languages like C and C++, and then we've had
| safe languages like Lisp, Java, and Python. The safe languages
| were all slower.
|
| Them's fightin' words. SBCL (Lisp) totally screams with speed as
| far as I've been able to tell.
| stonemetal12 wrote:
| https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
|
| Its runtimes are all like 5X C's. Not sure I would say
| "screams", it looks like it keeps up with Java though.
| bovermyer wrote:
| How does Rust do at random number generation? Is there (for
| example) a crate for seeding random number generators?
| mynameisash wrote:
| I'm not sure if I understand your wording: "a crate for seeding
| random number generators"? Do you mean, "is there a RNG that
| you can seed in Rust"?
|
| There's a `rand` crate[0] which I believe was written by folks
| in the Rust project, though it's not part of std. You can seed
| the RNG[1].
|
| [0] https://crates.io/crates/rand, https://github.com/rust-
| random/rand
|
| [1]
| https://docs.rs/rand/latest/rand/rngs/struct.StdRng.html#met...
| bovermyer wrote:
| 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.
| oconnor663 wrote:
| 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.
| WesolyKubeczek wrote:
| TL;DR -- because the author loves it, followed by what can be
| described as multiple paragraphs of personal preferences.
| paulgb wrote:
| 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.
| WesolyKubeczek wrote:
| Well, I've been tempted to stop reading past "because I love
| it". Another honeymoon phase. I stopped reading after the
| author called Python's, Java's, and C++'s way of handling
| exceptions "invisible errors". I get it, you have your
| darling language, but could you please not be _lying_ in
| order to make your darling look good?
| jakobnissen wrote:
| In which way is that incorrect? How can you, when reading
| Python code, know whether it may error?
|
| Or is your point that Rust code can panic too, without it
| being clear from reading the code?
| WesolyKubeczek wrote:
| 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.
| marcosdumay wrote:
| > See also: halting problem.
|
| The one that can be solved for the overwhelming majority
| of code people write on real life?
| chrismorgan wrote:
| 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.
| hota_mazi wrote:
| Except Emil is talking about "Java exceptions", not "Java
| runtime exceptions".
|
| Because Java's checked exceptions have the exact same
| good qualities that Rust's question mark operator offers.
| jrpelkonen wrote:
| 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.
| nicoburns wrote:
| 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.
| marcosdumay wrote:
| > 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".
| fellerts wrote:
| 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?
| k__ wrote:
| Retrospectively you might be right.
|
| The majority of software is slow and not safe to use and the
| majority of people do it anyway.
| WesolyKubeczek wrote:
| The majority of things in general is not safe to use, and yet
| somehow we do it anyway, and thrive.
| hsn915 wrote:
| > Safety and speed
|
| 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).
|
| Am I missing something?
| thombles wrote:
| > 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.
| hsn915 wrote:
| 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.
| masklinn wrote:
| > Well, there's a concept of a _weak_ reference. I don't
| know whether it exists in Rust
|
| It does:
|
| - https://doc.rust-lang.org/std/rc/struct.Weak.html
|
| - https://doc.rust-lang.org/std/sync/struct.Weak.html
|
| > 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.
| frisia wrote:
| There are weak references in Rust. https://doc.rust-
| lang.org/std/rc/struct.Weak.html
|
| 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.
| nicoburns wrote:
| I think you've covered all the major options:
|
| - Use Rc (or Arc if you need to be thread-safe)
|
| - 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.
| cyber_kinetist wrote:
| 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.
| nicoburns wrote:
| I guess the benefit of Rust in this case is that you will
| get an index out of bounds error rather than Undefined
| Behaviour.
| insanitybit wrote:
| 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.
| creata wrote:
| 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?
| Fiahil wrote:
| > dynamic lifetimes
|
| What do you mean ?
|
| 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.
| eptcyka wrote:
| Atomic reference counting does incur a slowdown.
| j-krieger wrote:
| 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.
| eptcyka wrote:
| 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.
| insanitybit wrote:
| 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.
| Fiahil wrote:
| 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)
| moonchild wrote:
| Reference counting is much slower than 'garbage collection'.
| scratcheee wrote:
| 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.
| Const-me wrote:
| > 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).
| [deleted]
| anonymous_sorry wrote:
| Reference for "much" slower? Surely depends on usage?
|
| The cost is also more predictable/amortised than classic
| garbage collection.
| scratcheee wrote:
| 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/Tra
| cing_garbage_collection#Per...
|
| The point about predictability is totally valid though
| (and combined with simplicity is the reason many
| languages still pick ref counting).
| marcosdumay wrote:
| It's not generally true. It's true for the case when the
| runtime keeps track of every little memory segment.
| masklinn wrote:
| 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).
| cageface wrote:
| 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?
| insanitybit wrote:
| Check out 'This Week In Rust', which has some calls to action
| from various projects.
| artogahr wrote:
| Also me. Albeit probably not as experienced as OP, I still
| would like to help.
| bjarneh wrote:
| > A lot of people who are new to Rust struggle with the borrow
| checker
|
| Guilty as charged
| azangru wrote:
| > 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].
|
| Is the Rust/wasm future going to look like that?
|
| [0] - https://i.imgur.com/TpYW0Rj.png
| Existenceblinks wrote:
| 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.
| Thaxll wrote:
| 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.
| masklinn wrote:
| > There is a reason why JS was invented. People doing
| frontend dev don't want to bother with slow compile time
|
| You have never actually looked at the history of javascript
| have you? Or at the current "best practices"?
| maxsilver wrote:
| > 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.
|
| (See https://blog.mozilla.org/javascript/2012/12/04/arewefast
| yet-... from _ten years ago_ as just one of many, many
| examples)
| api wrote:
| 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.
| insanitybit wrote:
| Our TS frontend compile times are worse than our Rust compile
| times.
| flohofwoe wrote:
| 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' ;)
| hsn915 wrote:
| Yes but you can use esbuild to make it fast. My projects
| take less than a second.
| deathanatos wrote:
| 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).
| ttfkam wrote:
| 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.
| traceroute66 wrote:
| > 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.
| fuckstick wrote:
| Of all the criticisms I've heard hurled at Java, compile
| time isn't one of them. Have you actually used any of these
| things you comment on?
| vips7L wrote:
| Javac isn't even an optimizing compiler. There's few
| things faster than it.
| thesuperbigfrog wrote:
| >> 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):
|
| https://commandcenter.blogspot.com/2012/06/less-is-
| exponenti...
|
| https://go.dev/talks/2015/gophercon-goevolution.slide#4
| traceroute66 wrote:
| > There is a reason why JS was invented.
|
| I disagree.
|
| 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.
| horsawlarway wrote:
| 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.
| traceroute66 wrote:
| > See my point?
|
| No.
|
| 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.
| lnenad wrote:
| 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.
| masklinn wrote:
| > So is JS a monstrosity? For blogs, sure. For apps? Hell
| no. It's fucking amazing.
|
| That web application delivery is "fucking amazing"
| doesn't mean javascript is. Javascript very much is not.
|
| What javascript is, is the only complete option until
| wasm is way more fleshed out than it currently is.
|
| > Things that used to come with 100MB+ installers? Those
| are web apps now. They serve you 200kb
|
| With an entire browser and server farm to do that.
|
| > and load in less than a few seconds.
|
| Instead of instantaneously.
|
| > That spreadsheet app? Just a sheets.google.com away.
| Loads in seconds - using JS with a tiny payload.
|
| 10% the functionality, 20% the performance, at twice the
| heft. Amazing.
|
| > Music player? It's a website now. JS.
|
| Your music library? Doesn't exist now.
| veidr wrote:
| For blogs, sure, JavaScript is "fast enough".
|
| 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.
| devmor wrote:
| 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.
| EamonnMR wrote:
| Of course it's better to do processing client side. You pay
| for server side compute, you don't pay for client side
| compute.
| nordsieck wrote:
| > 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.
| bartq wrote:
| 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.
| blep_ wrote:
| 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.
| maeln wrote:
| > 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.
| littlestymaar wrote:
| 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...
| 5e92cb50239222b wrote:
| 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.
|
| https://vitejs.dev
|
| https://github.com/swc-project/swc
|
| https://github.com/evanw/esbuild
| toyg wrote:
| _> There is a reason why JS was invented. People doing
| frontend dev don 't want to bother with slow compile time_
|
| Lol. That's not why JS was invented, at all.
|
| JS was invented to provide basic interactivity to static html
| pages. By accidents of history it snowballed in the current
| monstrosity.
| Thiez wrote:
| 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`).
| chrismorgan wrote:
| 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/deta
| il?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_.
| commitpizza wrote:
| 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.
| Traubenfuchs wrote:
| > an avalanche of javascript errors in the browser console
|
| Dear god. And then you can't even visually tell if you are at
| the main, "Team" or "Blog" page from the menu bar.
|
| This says one thing very clearly: "This website was not made
| with love." -which says NOTHING about the product they are
| offering.
| emilern wrote:
| Hi, author here!
|
| 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.
| chanks wrote:
| 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.
| emilern wrote:
| So far so good!
|
| 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.
| bern4444 wrote:
| Doesn't dart/flutter do this? Render everything to a canvas.
|
| It is difficult to believe this will be the future of the
| web.
|
| I don't think websites should take this approach. Seems like
| a bad idea
| panzi wrote:
| How does egui interact with screen readers and other
| accessibility APIs?
| emilern wrote:
| So-so. There is an experimental screen reader you can
| enable in the "Backend" panel of egui.rs.
|
| There is ongoing work to integrate AccessKit
| (https://github.com/AccessKit/accesskit) which will improve
| things significantly.
| mwcampbell wrote:
| Anyone who's interested in the AccessKit integration can
| play with my work-in-progress branch:
| https://github.com/mwcampbell/egui/tree/accesskit
|
| It's currently Windows-only, and I'm working on the big
| missing feature, which is text editing support.
| UltraViolence wrote:
| They may be static pages, but usually you need a CMS to manage
| those static pages and their content.
|
| So it containing Javascript to fetch the content isn't all that
| far fetched.
| erk__ wrote:
| > Floating point behavior
|
| 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.
|
| [0]: https://doc.rust-
| lang.org/std/primitive.f64.html#method.tota...
| spoiler wrote:
| > but cannot really use it in collections like BTreeMap
|
| Given the nature of floats, is this really a problem?
|
| Worst case scenario the floats can be represented differently,
| if one really needs to use them as keys.
| erk__ wrote:
| Yeah it was mostly to give a example of where a wrapped type
| would be better than `total_cmp`. E.g. something that needs
| the value to implement Ord.
| listenlight wrote:
| Does Rust have a webapp framework like Rails?
| rwaksmunski wrote:
| https://www.arewewebyet.org/
| foobarfoox4 wrote:
| This is cool. Are there similar websites for other languages?
| achenet wrote:
| er, there's another one for Rust and game dev
|
| https://arewegameyet.rs/
| sadn1ck wrote:
| and another for rust gui frameworks
| https://www.areweguiyet.com/
| cyber1 wrote:
| 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.
| pie_flavor wrote:
| 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.
| 3836293648 wrote:
| 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
| labrador wrote:
| In "Oral History of Bjarne Stroustrup" Bjarne describes his goal
| for C++, which was abstractions with zero runtime cost :
| https://www.youtube.com/watch?v=ZO0PXYMVGSU
|
| I understand Rust is fast, but how does it do with complex
| abstractions?
___________________________________________________________________
(page generated 2022-10-18 23:02 UTC)