[HN Gopher] Rust Foundation: Hello, World
___________________________________________________________________
Rust Foundation: Hello, World
Author : steveklabnik
Score : 641 points
Date : 2021-02-08 17:02 UTC (5 hours ago)
(HTM) web link (foundation.rust-lang.org)
(TXT) w3m dump (foundation.rust-lang.org)
| Lapz wrote:
| Congrats to everyone involved, I started learning rust on a bus 4
| years ago and its amazing to see how far the language has come
| malwrar wrote:
| Awesome news! Rust is easily the best programming experience I've
| had--the language feels incredibly well thought out, common
| tooling like doc generation and dependency management are
| included with the language, and the compiler takes full advantage
| of language features such that my editor's linter is able to
| detect most mistakes I make and the language itself guards me
| from doing anything obviously unsafe. I thought the rewrite-
| everything Rust people were annoying and that turned me off
| initially, but ever since getting involved with the community
| I've found that it's full of lots of very passionate people
| working on a stunning variety of interesting new projects. You
| really feel like you're on the ground floor of the next
| generation of systems programming languages, enough to where I've
| even considered replacing my habitual use of Python with Rust
| considering how easy it is to write.
|
| Seriously, it's worth your time to explore. If you have a spare
| evening and want to be enchanted, highly suggest giving the Rust
| book a gander: https://doc.rust-lang.org/stable/book/
| bcrosby95 wrote:
| > Rust is easily the best programming experience I've had
|
| When you make this statement, what languages are you comparing
| it against?
| malwrar wrote:
| Currently: C, C++, Python, Go, JS, C#, Java, Lua (if that
| counts), Kotlin, Julia, Scala. I've dabbled in a bunch of
| other ones but haven't made anything noteworthy with them.
|
| You may notice a lack of other modern compiled languages like
| Zig, so take that bias in mind :)
| felipemnoa wrote:
| I'm not trolling. I'm genuinely curious. I've always
| thought of languages just as tools and have never been
| fanatic about a particular one. I personally like C and
| Java but have no problem using other languages if they are
| the best for the job.
|
| I'm really curious to know what makes rust so special? Mind
| you that I know nothing about it.
| lights0123 wrote:
| Algebraic data types[0], compile-time thread safety
| guarantees[1], async/await on embedded[2], type inference
| that can work backwards[3], blocks are expressions so you
| can return values from if statements[4], returning from
| while(true) loops[5], and iterators[6] that don't kill
| performance[7].
|
| [0]: https://doc.rust-lang.org/book/ch06-01-defining-an-
| enum.html...
|
| [1]: https://doc.rust-lang.org/book/ch16-04-extensible-
| concurrenc...
|
| [2]: https://lights0123.com/blog/2020/07/25/async-await-
| for-avr-w...
|
| [3]: https://doc.rust-lang.org/book/ch03-02-data-
| types.html#data-...
|
| [4]: https://doc.rust-
| lang.org/book/ch06-02-match.html#the-match-...
|
| [5]: https://doc.rust-lang.org/book/ch03-05-control-
| flow.html#ret...
|
| [6]: https://doc.rust-
| lang.org/book/ch13-02-iterators.html
|
| [7]: https://doc.rust-
| lang.org/book/ch13-04-performance.html
| haskellandchill wrote:
| It's booming. I'm considering making Rust or Haskell a
| requirement for my current remote job search. And given that I
| have no strong salary requirements it's actually going to work,
| could not have done this 4 years ago.
| manishsharan wrote:
| serious question : would you recommend Rust for CRUDdy type of
| web applications -- stuff where mostly you are firing off
| prepared statememts at a SQL db and then applying business
| logic to result set. This is what most J2EE apps do currently.
| mamcx wrote:
| I have a app that have been ported from old python -> f# ->
| rust (e-commerce like) and the transition was great (https://
| www.reddit.com/r/rust/comments/hh9tz6/does_rust_have...).
|
| You need to pay attention in how align the whole software
| stack. Pairing Rust with tailwinds and htmx or Hotwire
| simplify so much stuff is like cheating.
|
| For regular CRUD flows having enums/traits/iterators make
| domain modeling very good and found is more productive to me
| than F#/Python at the domain layer.
|
| I do my own micro SQL-orm layer (I have the need to talk to
| +6 RDBMS and be dynamic at runtime), and most db libraries in
| the rust ecosystem are mature enough now.
|
| I find recently the whole auth is not as mature as you find
| with Django (aka: Not need to code part of it, you can
| certainly do it manually), but anyway is now better to
| offload to key cloak or similar.
| Smaug123 wrote:
| Could you comment a bit more on how Rust let you model the
| domain better than F# did?
| mamcx wrote:
| The thing with F# is that (idiomatic) models/functions
| rely on type inference, and eventually is hard to see
| what is the flow without look at the IDE. Rust making
| type annotations explicit with minimal inference is much
| clearer.
|
| Also, the fact I can do mutation + imperative code
| locally yet give a functional feel make some hacks around
| this on F# unnecessary.
|
| But probably the biggest thing is that Rust make
| idiomatic things like conversions with
| From/Into/AsRef/etc instead of rely in your own
| conventions, making code more readable in the long run.
|
| Other source of simplification is serde. A lot of my
| stuff is transfer/(re)encoding of data and have a "de
| facto" idiom for this help a lot.
|
| One thing that F# make far easier and I miss much is the
| sequences (https://docs.microsoft.com/en-
| us/dotnet/fsharp/language-refe...). Making iterators is
| boilerplate and wish Rust have generators in stable.
|
| I found a decent library for this in
| https://lib.rs/crates/genawaiter but is not the same as
| have it in-build.
| Smaug123 wrote:
| Admittedly I work for a very opinionated team - we even
| have our own style guidelines
| (https://github.com/G-Research/fsharp-formatting-
| conventions) which are often in direct contradiction to
| Microsoft's, and my team strongly skews towards writing
| explicit type annotations on all function signatures. I
| can certainly see how there would be a problem if one
| defaulted to omitting type annotations.
| ragnese wrote:
| I currently do it and have no regrets, but I don't require a
| lot of fancy stuff that you might find the Java ecosystem.
|
| If you don't have any need for concurrent sharing of data and
| never really miss having destructors in a managed language,
| then I'd guess that Rust wouldn't be a great fit for a CRUDy
| backend.
|
| Scala and Kotlin are great choices there. They have good type
| systems (everyone loves Rust's enum types, which are just
| ADTs and exist in many other languages as well), they have
| garbage collection- so no borrow checker headaches, and they
| have the massive Java ecosystem if and when you need it.
|
| On the other hand, all programming languages are greater than
| the sum of their parts. Rust is more than just a checklist of
| "borrow checker, fancy enums, no exceptions, move semantics,
| etc, etc". You might just love the language even if it's not
| "objectively" better for your use case than something else.
| That's where I am. I spent years doing C++ and I instantly
| fell in love with Rust. It's not perfect, but it's usually my
| first choice when doing almost any project. I only ask myself
| "Is Rust such a bad fit for this task that I'm significantly
| hindering myself?" and/or "Is FooLang so PERFECT for this
| task that not using it is stupid?".
| akritrime wrote:
| hmm, no. While compile-time type check[0] for SQL queries
| changes your whole experience of how you do SQL, at the end
| of the day creating an webapp in rust is not as easy or
| mature as any of the other languages more suited for the
| task. If you want to learn, then its fine. But if you are
| newish to rust and want to do your next CRUD app at work in
| rust, I don't think its going to a good experience.
|
| [0]: https://github.com/launchbadge/sqlx
| JeremyNT wrote:
| I'm mostly a rails developer and really want to get into
| Rust. I went through the tutorial and did some practice on
| Excersism. I'm not a rust expert but I enjoyed working with
| it and learning about it.
|
| With that disclaimer: as of now, what rust lacks is a
| comprehensive framework for web development.
|
| I'm sure your story in the J2EE world is similar to rails:
| you have libraries that you can use to abstract away a lot of
| repetitive things such as authentication. You probably also
| have a framework-aware test suite that integrates with
| something like Selenium. You may have abstractions around
| javascript build systems like Rails' webpacker that allow you
| to easily integrate SPAs directly into your app using the
| same overall tooling. There's so much code you don't have to
| write, and you probably don't think much about it, and you
| probably just take it for granted.
|
| This is not the story with Rust. There are some frameworks
| such as Rocket you can reach for, but when I evaluated the
| situation ~6 months ago I realized I couldn't justify using
| Rust for this yet. From a web development perspective, there
| was just too much busy work you'd need to do.
|
| I don't think this is an inherent limitation of the language,
| by the way. I think Rust is a lot of fun to work with and I
| wouldn't hesitate to use it once a more robust library
| ecosystem is developed for this use case. I'm always keeping
| an eye open for places where it would fit what I do, like a
| small performance-sensitive microservice for example. The
| type system is powerful, it's great (as a Ruby developer who
| last worked with C++ a _long_ time ago) to work with a
| compiled language again. The type system, Rust linter, and
| compiler together catch many classes of trivial errors that
| you need to test against in Ruby.
|
| I hope it'll get there one day!
| torgard wrote:
| actix-web seems really interesting, just from some cursory
| reading.
|
| Also, from a performance standpoint, it seems to be
| _really_ good: https://www.techempower.com/benchmarks/
|
| This example in particular piqued my interest: https://gith
| ub.com/actix/examples/blob/master/async_pg/src/m...
|
| I have no experience in Rust whatsoever, but I feel
| inspired to try it out.
| hobofan wrote:
| Reddit thread about this question from yesterday: https://www
| .reddit.com/r/rust/comments/leki5o/advantages_of_...
| tempest_ wrote:
| I mean you could certainly do it in Rust. I am not sure I
| would recommend it though. The dev time for rust will
| naturally be slower because the developer will have to take
| more into consideration.
|
| Additionally while the community is growing rapidly you wont
| find the same depth of ecosystem that you have with Java.
| Client libraries will be half baked and still be a work in
| progress a lot of the time.
|
| If the business stuff is not performance or time sensitive it
| would probably be better to use something like
| Java/Go/Python, maybe elixir, that will have good turn around
| time with reasonable performance.
|
| A good litmus test for the moment is probably "Would I write
| this in C++ five years ago?" if yes Rust might be a good
| option today with a few caveats, like GUI or GPU programming
| still being in their relative infancy in Rust.
| redis_mlc wrote:
| No, because rust is extremely picky about types and casts,
| which makes for a large learning curve for no real advantage
| in text processing.
|
| Expect to be much less productive until you get your own toy
| programs working.
| bluejekyll wrote:
| You're in a Rust thread, I think the general response is
| going to be, "Yes!"
|
| And I personally, say yes. But that comes with some caveats.
| You will be entering an ecosystem that doesn't have all the
| libraries that folks coming from the rich history of Java
| has, so you will most likely be signing up for some extra
| work.
|
| But, this is also a great opportunity, because it means that
| you could be responsible for building a missing library or
| feature.
| jariel wrote:
| "But, this is also a great opportunity, because it means
| that you could be responsible for building a missing
| library or feature. "
|
| Ok, so this is an 'opportunity' for some, but a 'big cost'
| for others.
|
| So remember there are very few Rust devs out there, it is a
| little bit hard, and though a good chunk of devs might jump
| at the chance to learn, others, not so much.
|
| It would be a really hard thing to rationally do a 'crud
| app in Rust' at this moment in time due to all the above
| reasons. There's a lot of added risk for really no
| benefits.
|
| _If_ you have a core team that has the skills, ability and
| is willing to commit to it, then maybe. But we have to
| think beyond that, when you need another 100 devs ... and
| people maintaining it ... one can see how other things
| factor into the equation.
|
| If there is some specific reason and the conditions are
| right, and if that reasoning is not warped by our own
| natural tendencies to 'want to use Rust' then there might
| be an opportunity ... but generally not.
|
| As team members get more excited about 'the problem they
| are solving' and less 'the tools they use' - you might see
| an inclination towards other tools, for the most part, at
| least today, for CRUD-ish kinds of things.
| steveklabnik wrote:
| We are doing some web backend stuff in Rust at Oxide, my
| colleagues gave a talk on it:
| https://www.youtube.com/watch?v=EmSjZbSzA3A
|
| The TL;DR is it may or may not make sense for you.
| Engineering! We are finding it valuable, but you may have
| different needs than we do. Ecosystem maturity is variable.
| Animats wrote:
| That's what Go is for. I've said this before. Go has all
| those well-exercised packages for doing web applications.
|
| Rust is for harder problems. The ones you'd otherwise have to
| do in C++. I'm working on a client for a virtual world in
| Rust, and it is far easier in Rust than it would be in C++.
| Full 3D, GPU usage, networking, lots of state, a constantly
| changing big world through which you can move, compute bound,
| multiple threads. All my code is in safe Rust, and I've never
| had to use a debugger.
|
| Write your embedded software in Rust. Write your networking
| software in Rust. Write databases in Rust. Write browsers in
| Rust. Write complex games in Rust. For ordinary server side
| web jobs, it's overkill.
| bsaul wrote:
| Go is clearly not for crud web apps. For that you have all
| the rails clone that'll autogenerate pretty much
| everything, and has a predetermined path for every
| situation. Or the enterprisy version, with a decent orm, if
| you want type-safety.
|
| Go is for system-level programming that mainly consists of
| plumbing api endpoints together. i would recommend it for
| building middlewares in a server environment
| tmountain wrote:
| Can't speak to Rust, but this is a sweet spot for Golang for
| sure.
| cultofmetatron wrote:
| don't get me wrong, I love rust and find it a great language
| for doing systems level stuff but it would be my last choice
| for a crudy type web application. Those are intrinsically IO
| bound. Sure, you might find a noticeable improvement if
| you're using something really slow like rails without any
| caching but there are plenty of garbage collected rapid
| development languages that will be fast enough that the
| visible performance difference will be dwarfed by the IO
| bottleneck.
|
| There are already several languages that server that niche
| better. I myself use phoenix/elixir which is batteries
| included. I have a nice toolbox of production ready
| libraries. I can prototype/build endpoints much faster than I
| would in rust and the sub 200ms req/res times (including the
| database call) is plenty fast enough.
|
| That said, there are a few things I'd consider rust for.
|
| 1.cpu intensive jobs - elixir and any language with c interop
| have rust interop and I'd be happy to delegate those jobs to
| a service written in rust.
|
| 2. optimized large data structures, discord did something
| akin to this for their chat system
|
| 3. serverless functions - having no runtime or garbage
| collector makes for a gloriously fast cold boot if you're
| into that sort of thing.
|
| In short, While you CAN user rust for web development, I
| dont' think its appropriate for most web development related
| use cases if you're trying to develop software for a client.
| IF its for fun, Then by all means, go nuts! :)
| zozbot234 wrote:
| > Those are intrinsically IO bound.
|
| Rust has a great async story compared to other languages,
| which benefits IO-bound workloads even more so than CPU-
| busy ones.
| andrewflnr wrote:
| Not compared to Elixir. It's hard to beat lightweight
| processes for concurrency. I've used Rust, but I'm doing
| my webapp in Elixir.
| coder543 wrote:
| I disagree.
|
| Saying that it is "great" is really overselling it at
| this point, unless the languages you're comparing to are
| mainly C or C++. I would also toss Ruby in that category
| for now, but they seem to be working on making async
| better with Ruby 3+.
|
| When compared to Python, JavaScript, or C#... Rust's
| language support for async isn't really that impressive
| to most developers, although the implementation has some
| technical characteristics that are nice for people who
| care about the low level details. The ecosystem is pretty
| lacking, even though it is much better than it was a few
| years ago.
|
| Compared to the aforementioned languages (including
| Rust), Go and BEAM-based languages are just on another
| level.
|
| I'm sure both Rust's language ergonomics and the
| ecosystem will improve over time, but Rust's goals also
| make it unlikely to ever be compatible with _my_
| definition of a great async system... which is the model
| Go and Erlang use where the developer can 't tell that
| every single sequential process _isn 't_ running in a
| separate OS thread -- and, by extension, every function
| is automatically async with no distinction that I have to
| worry about.
|
| In Go, I can spin up as many goroutines as I need, and I
| don't have to worry about any single goroutine blocking
| an executor like I have to worry about in Rust.
|
| Yes, some async runtimes in Rust have worked on clever
| things like monitoring the executor threads and spawning
| a new executor to steal a blocked executor's work
| queue... maybe some day that will be a battle tested
| solution. Like most of the Rust async story, there are
| rough edges that could benefit from some more time.
|
| (I have worked professionally with both Rust and Go for
| several years, and I think they're both great languages
| with different trade offs... I'm not trying to bash Rust
| here.)
| nahuel0x wrote:
| You are right, but this project (or a similar one) who
| uses WASM based rust nano processes has the potential to
| leave Go and Erlang in the dust:
| https://github.com/lunatic-solutions/lunatic
| coder543 wrote:
| That project does look really fun!
|
| I can't tell if that is pulling V8 in as the WASM
| interpreter or not. Obviously, I would prefer that they
| leave others in the dust _without_ having to pull in a
| huge C++ codebase, but it still sounds promising either
| way!
| nahuel0x wrote:
| There is no V8 here, you don't need a JS VM to run WASM.
| It uses wasmer, a Rust based WASM VM:
| https://github.com/wasmerio/wasmer
| coder543 wrote:
| Awesome! I had heard of wasmer before, but I didn't
| realize its performance was that good yet. I'll
| definitely be paying closer attention to this space now.
|
| Although, on closer inspection it seems like wasmer is
| using LLVM as a backend to get that good performance,
| which tempers my enthusiasm a little bit. I see that
| wasmer also supports the Cranelift backend, but the
| promised performance blog post[1] doesn't seem to have
| been published yet, so I don't know _how much_ of a
| difference that makes in the real world.
|
| A ~13x difference in JIT compile time (LLVM vs Cranelift)
| is huge, and waiting on LLVM itself to compile can also
| be... exciting. LLVM does good work for AOT compilation,
| but I don't know how I feel about the trade-offs of using
| it as a JIT. If a massive C++ code base is going to be
| pulled in anyways, I would almost rather them pull in V8
| than LLVM... but that's just my opinion, since V8 seems
| to be very well optimized for the JIT use case.
|
| But, I'm glad there is the choice to use Cranelift (and
| presumably exclude LLVM from the final binary) if that
| fits a particular use case, and I'm excited to see that
| follow-up blog post whenever the wasmer team has time to
| publish it.
|
| [1]: https://medium.com/wasmer/wasmer-1-0-3f86ca18c043
| cultofmetatron wrote:
| when its ready, I'll be happy to try it. That said, the
| BEAM codebase is around 30 years old and indestructibly
| stable while being pretty damn fast. Its going to be
| awhile before anything with teh same goals catches up.
| bestinterest wrote:
| Also one of the reasons I'm looking forward to Java's
| Project Loom. It seems Go/Elixir/Java have went for the
| `virtual threading` path to simplify the dev experience
| greatly.
| idubrov wrote:
| I have some extensive (self-assesment :) ) experience
| building this kind of application, and my answer would be
| "no, but maybe" (I was one of the first engineers & architect
| on our zero to ~500k codebase).
|
| Some of the arbitrary, random things I've learned:
|
| 1. Given how nice and powerful language is, Rust works
| relatively well with less experienced engineers. Potentially.
| You can build very nice APIs which are straightforward to
| use.
|
| If you can stay in this territory, everything is great.
|
| However, there are some hard walls in Rust which are really
| difficult to jump over. And once you hit them, you really
| need somebody who understands Rust really really well and is
| capable of working around those issues.
|
| 2. It was quite hard to find the right balance between
| engineering time, compilation/linking time, safety, ease of
| use, performance, etc. Might be my personal biases, but I had
| to make some questionable decisions to keep compilation times
| / turnaround times at bay (like, unsound plugin system,
| custom serialization framework or test framework using
| nightly Rust features).
|
| 3. The type system is really, really nice. This alone
| compensates for a lot of things.
|
| 4. Ecosystem? Simply amazing. High quality libraries,
| documentation and everything.
|
| 5. Ecosystem again? Lots of things are still missing.
|
| 6. Performance? I'm 90% trolling here, but my experience was
| that Rust is not "blazing fast" by default. Not for
| "enterprise" software. You have to do some legwork sometimes.
| I've built some simple tool to do certain transformation
| between JSON and XML, and out of gate it was ~2x slower than
| Java equivalent (yes, with release build). Turned out,
| strings are not that cheap to clone if all you have is a
| bunch of strings. I did make it like 5x times faster than
| Java in the end, but it did require some weird tricks (like
| forcing hash map to look for a "derived" key than I give it).
|
| There were some other cases where performance was reduced by
| simple things (like, having "heavy" Result vs having error
| variant boxed).
|
| I think, this is "easily" counteracted by adopted practices
| and libraries (optimized error types, for instance), some
| standard patterns (like don't be afraid of Arc, they are
| better than to move huge data chunks around), maybe, good
| profilers as well.
|
| This is probably also my biases talking here, frankly, I
| don't think it mattered at all (performance was killed by
| database, as is very common with enterprise systems). Also,
| in the end, it was fast (outside of database woes).
|
| 7. Overall, I find Rust very exciting language to work with,
| which was a big driver (but that doesn't necessarily scale --
| you'll have to have some answer prepared when less
| experienced engineers will ask you "but why can't I do like I
| did in Typescript in those trivial 500 lines of code").
|
| Would I do it again? Probably, but with understanding that
| whoever pays for it, might be paying for my "fun" on top of
| the product they are getting. Which is not necessarily a bad
| thing -- "fun" is also a factor in attraction and retention
| of engineers.
|
| I'm also not going to lean into the "dark side". Like, if all
| you care is to get some half-broken whatever out as quick as
| possible, Rust might not be the right choice. It makes you
| think about "right or wrong" a lot, imo.
| wtetzner wrote:
| > Turned out, strings are not that cheap to clone if all
| you have is a bunch of strings.
|
| Yeah, if you're doing a lot of cloning, you'll probably run
| into performance issues at some point. A common way to
| solve that problem is usually to use references instead of
| cloning.
|
| Of course, writing your code that way takes more
| work/thought/planning.
| idubrov wrote:
| >A common way to solve that problem is usually to use
| references instead of cloning.
|
| Right. I think, we ended up with having everything from
| the list:
|
| 1. String 2. &str 3. Cow<str> 4. Arc<str>, for interned
| strings (thin Arc would be even better & there is
| probably a crate for this) 5. Something like
| owning_ref::ArcRef<Owner, str> 6. One-off tricks where
| you actually need to construct a new string, but don't
| want to really construct it (for example, for hash
| lookup).
|
| #5 I think is undervalued, actually; it's amazing for
| "enterprise" kind of stuff where you have large trees of
| data you need to pass around & you don't want to use
| straight borrowing (like &'a Whatever) because lifetimes
| are too infectious. And you don't want to use Arc at
| every corner (like, say, Java would do, not quite, but in
| semantics).
|
| My problem, though, was to explain all the nuances given
| that they usually have nothing to do with the "business"
| part of the problem somebody was solving.
| Arnavion wrote:
| Or, to get the computational equivalent of what Java is
| doing (immutable, interned strings), use a Rust string
| interning library like what servo uses [1], or just
| `Arc<str>`
|
| [1]: https://docs.rs/string_cache/
| snake_case wrote:
| I just launched a jigsaw puzzle website last week that has a
| backend API written in Rust and uses the postgres crate [1].
|
| Since this is a side project for me, there wasn't much risk
| if it ended up being a bad decision. Multiple times
| throughout the project I got frustrated with the DX of
| existing http frameworks I tried and ended up building my own
| [2] on top of hyper. However, after launching my site and
| seeing how it performs in production, I could not be happier
| with the result! I had a bit of Rust experience before the
| project but learned a lot more through building this.
|
| For you and others, I think it really depends on the
| situation. Building a Rust CRUD app will likely take longer
| than the other languages you're used to as the ecosystem is
| under heavy development, especially with async/await. So if
| you or your team are in a rush, I'll just echo that you
| should build with the tools you already know. If you have
| time and budget to experiment like I did, it might be
| worthwhile and I can promise it will be fun :)
|
| [1]: https://github.com/sfackler/rust-postgres
|
| [2]:
| https://twitter.com/jakedeichert/status/1205230350160539650
| heavyset_go wrote:
| The ecosystems that support creating CRUD apps are more
| mature in other languages.
| raphlinus wrote:
| I'm really happy to see this happen. I'm also really thrilled to
| see Lars Bergstrom on the board, and am excited about taking Rust
| farther both at Google and across the industry. Rust is evolving
| from being centered at Mozilla to being a true community and
| collaboration between many different groups, including big
| companies, so I think a well-supported foundation is key. I'm
| very hopeful for the future.
| sho_hn wrote:
| > The decision making power within the Rust project is uniquely
| delegated and distributed; with the core team holding little more
| privilege than other more specialized teams. [...] And the
| potential of such a system has bore fruit: It is not a mistake
| that such a promising technology has emerged from such a
| progressive conception of collaboration.
|
| These are values and thoughts describing an approach that the KDE
| community (and its foundation; hello from another board!) holds
| equally dearly and has inscribed in its Manifesto
| (https://manifesto.kde.org/, cf. Common Ownership).
|
| While maybe not unique, I'm excited to see another organization
| adopt this idea set (a support body not interfering with
| technical agenda, low barriers to participation, not entrenching
| maintainers, working succession mechanisms, etc.) as a core
| message. We've seen it work very well to sustain a productive
| community for 25 years and I think this bodes well for Rust!
| steveklabnik wrote:
| Hey folks! Normally, I am all over these threads answering
| questions, but I am not on the foundation board and did none of
| the real work to get this going! The foundation members are
| unlikely to comment on Hacker News, so if you have big questions
| you want answered, contacting them via the address on the site is
| the right way.
|
| Personally, I am very excited that this is happening, and really
| looking forward to the future here.
| jdright wrote:
| I would like to raise awareness to a tiny detail:
|
| > February 9th, at 4pm CT.
|
| When using local time zones we should strive to always also add
| the equivalent GMT time to a global audience - even if this
| audience will not participate in the meeting, it is good to
| have an idea of when that is actually happening without needing
| to go through a timezone converter.
| ChrisSD wrote:
| https://github.com/rust-lang/foundation.rust-lang.org/issues
| steveklabnik wrote:
| As I said, not involved, so you should submit this feedback
| to them. I can try to pass it along, but there's no reason to
| have me as a middleman.
| chc wrote:
| I don't think I understand. Those are both just time zones,
| right? So knowing what time it happens elsewhere requires a
| conversion no matter what time zone you gave originally,
| doesn't it?
| jbarberu wrote:
| I think the point is that more people would be able to
| figure out what the local time is if it was listed as 4pm
| CT (22:00 GMT/UTC), since more would know what their local
| time is compared to GMT vs compared to CT.
| ynfnehf wrote:
| I find it very funny that four people independently wrote
| almost the exact same response to your question.
| cristoperb wrote:
| I think the idea is that many people know the offset of
| their timezone from GMT/UTC, so they wouldn't have to look
| it up, but nobody can be expected to know their offset from
| any arbitrary other timezone.
| lilyball wrote:
| Offsets from GMT/UTC are annoying when you have to deal
| with DST though, as it can be confusing to remember which
| offset applies at any given point in time.
| riffraff wrote:
| I think the point is you know how far your timezone is from
| GMT, but you don't necessarily know what "CT" means.
| toyg wrote:
| I think the point is that most people will know the offset
| of their own timezone from GMT/UTC. If you specify time in
| another timezone, they now need to know _two_ offsets -
| theirs AND yours. Chances are they won 't know yours and
| they have to look it up.
| da_big_ghey wrote:
| This is a very "HN bubble" perspective. No, most people
| do not know their time zone's offset from GMT and go
| through a timezone converter. When they have to set a
| timezone, they click a spot on a map or look up, "What
| timezone is Pittsburgh?" For most, it's faster to search
| "12:00 GMT to EST" or whatever than it is to remember it
| and do the arithmetic.
| pas wrote:
| Rust Foundation seems pretty much targeted at HN-bubble-
| like groups, that do indeed have some familiarity with
| GMT/UTC.
| viraptor wrote:
| Also CT is lucky to be unique. CST / BST / IST are a bit
| more of a guesswork for international groups.
| kras143 wrote:
| Assuming most people do not know is also a "bubble"
| perspective. We don't know what "most" people know about
| their time zones. Most countries in Asia have only one
| timezone.
|
| source: https://www.timetemperature.com/asia/asia_time_zo
| nes.shtml
|
| It is easier for them to relate to GMT in my opinion.
| coldtea wrote:
| > _This is a very "HN bubble" perspective. No, most
| people do not know their time zone's offset from GMT_
|
| Well, almost everybody who's done server work knows their
| timezone offset from UTC, though, which is basically GMT.
| toyg wrote:
| It might be different elsewhere, but most people in
| Europe really do know their GMT offset.
| dpritchett wrote:
| Most people in the US know their offsets from the other
| three US time zones as well.
| Floegipoky wrote:
| I usually try to avoid getting into TZ pedantry, but since
| you brought it up, UTC is preferred and is not
| interchangeable with GMT.
| rvz wrote:
| There you have it. Right decision & direction here. We'll see how
| this goes for the Rust programming language.
| lacker wrote:
| It's a little concerning to see Huawei involved so closely in
| Rust, given the concerns about them silently including spyware in
| their products to give access to the Chinese government. I don't
| think I'm being a total conspiracy theorist; for example the UK,
| US and Sweden all ban Huawei equipment from their countries'
| mobile phone networks. Hopefully since this code is all open
| source there is sufficient scrutiny to avoid any shenanigans.
| theaeolist wrote:
| As far as "concerns" go these are not even allegations, these
| are rumors and slanders. There has never been even one shred of
| evidence that Huawei have done that.
| remexre wrote:
| And, Rust already has a way of avoiding trusting-trust attacks
| via mrustc.
| crazypython wrote:
| The board's vote seems to be heavily biased in favor of large
| corporations, with half the seats for them, 2 for the community,
| and 3 for "project areas." Contrast this with the governance of
| GCC, which has all of them as community members or project areas.
| thesuperbigfrog wrote:
| It makes sense that large corporations would be interested in
| Rust given its current capabilities and future potential.
|
| Amazon, Huawei, Google, Microsoft, and Mozilla all have a
| vested interest in Rust succeeding since they are all deeply
| invested in high performance software, the majority of which is
| written in C and C++.
|
| The undefined behavior semantics in C and C++ trade safe
| handling of undefined behavior for high performance. The result
| is high performance code that is difficult for developers to
| reason about and vulnerable from a security standpoint.
|
| https://blog.regehr.org/archives/213 gives great insights into
| how undefined behavior in C and C++ can cause problems.
|
| Rust is becoming an excellent replacement and hopefully will
| continue to succeed to enter all the niches that C and C++
| currently occupy.
| pjmlp wrote:
| GCC is one compiler project among others, ironically for your
| example most funding comes from corporations as well, with Red-
| Hat being a major contributor.
| pdpi wrote:
| I can't find much in the way of Rust credentials for the rest
| of the members but, looking at their profiles, Nell (MS's
| representative) used to manage crates.io while at Mozilla, and
| Lars (Google) used to manage the Servo team. While they are
| technically representing corporate interests, they're also
| heavily invested in the community.
| emiliocobos wrote:
| Bobby (the Mozilla rep) was also heavily involved with Servo
| and Rust-in-Firefox, see e.g.
| https://bholley.net/blog/2017/stylo.html
| pornel wrote:
| That doesn't mean much long term. If they disagree with the
| corporations they represent, they will be replaced.
| hobofan wrote:
| > Contrast this with the governance of GCC
|
| The equivalent of that would be the Rust teams[0] as far as I
| can tell, which will still be the governing body of all
| development, and won't be replaced by the Rust foundation.
|
| [0]: https://www.rust-lang.org/governance
| ChrisSD wrote:
| The goal of the foundation is to work as a bridge between the
| Rust teams and the corporate world (e.g. sponsorship,
| licensing, etc). As the blog post notes, the actual development
| of the language is fully open and is comprised of RFCs and the
| like which allow anyone to contribute. It's the core team who
| oversee this process, not the foundation.
|
| In short the foundation works for Rust, not the other way
| around.
| [deleted]
| yannoninator wrote:
| Doesn't look like you can donate to Rust as an individual.
|
| Too bad.
| steveklabnik wrote:
| This is true right this moment, yes. That may change in the
| future.
| [deleted]
| Vinnl wrote:
| Related: https://blog.mozilla.org/blog/2021/02/08/mozilla-
| welcomes-th...
| isaacimagine wrote:
| Yes!
| nynx wrote:
| May this be the beginning of a long, interesting, and productive
| future.
| lvass wrote:
| Are there plans for waiving the relevant trademarks? I know many
| people are fine with them, but seeing how the FSF directory lists
| it as an "anti-feature" is a bit disheartening.
| rattray wrote:
| I love the FSF, but frankly as a user, I'm glad that not just
| anybody can claim to be Rust. Especially so now that the
| trademark is controlled by a dedicated nonprofit.
| lvass wrote:
| But how could anyone reasonably claim they are Rust,
| particularly given the large reach of it's online services,
| like docs, crates.io and rustup? Those trademarks are very
| unlikely to produce anything except another round of debian's
| icy rebrands.
| ChrisSD wrote:
| Rust is already in Debian's repository. The trademarks
| haven't been an issue at all.
| lvass wrote:
| It seems no one had to rebrand Rust yet, but can you
| guarantee this will always be the case? Firefox was fine
| in debian until 2006.
| nojito wrote:
| Mozilla Foundation != Mozilla Corporation.
|
| Which is why there was an issue with branding.
| mattl wrote:
| The issue with Firefox was that Mozilla didn't want
| Debian's modified version of Firefox to be called
| Firefox.
|
| https://en.wikipedia.org/wiki/Mozilla_software_rebranded_
| by_...
| forgetfulness wrote:
| Well it'll be amusing to see the playful knockoff names
| that Debian will come up with when rebranding Rust.
|
| Will they go with the metal chemistry theme, go back to
| the original plant pathology one?
|
| https://www.reddit.com/r/rust/comments/27jvdt/internet_ar
| cha...
| ChrisSD wrote:
| But why? Python has been going for decades without issue.
| https://www.python.org/psf/trademarks/
| [deleted]
| blacktulip wrote:
| Genuine question: what is Huawei's role in Rust Lang? It is in
| the founding member companies list.
| hobofan wrote:
| "Huawei uses Rust to develop a real-time OS for IoT devices,
| and in the StratoVirt project, a high-performance
| virtualization platform. According to engineers at Huawei, the
| company organizes routine Rust training and evaluation
| activities to encourage its large number of C/C++ developers to
| write safer code."
|
| https://www.infoq.com/news/2021/01/rust-china-conf/
|
| -----------
|
| I think they've been a big user of Rust in China for some time
| now, though I'm not aware of any big technical contributions to
| the language (or the core ecosystem) by them. In a similar
| vein, I find it a bit surprising that Facebook (or whatever
| they rebranded Libra to) is not part of the foundation. I think
| they are the only company that was interviewed when Rust's
| usage/usability experience in big companies was evaluated, that
| is not part of the foundation.
| metreo wrote:
| I think I saw something about reports that FB has hired a
| number of individuals to work full-time on the Rust lang, so
| there are probably lots of companies contributing to Rust in
| ways that don't get them features on the website.
| hobofan wrote:
| Yes I'm aware, which is exactly why I find it surprising
| that they aren't involved in the foundation even though the
| other tech giants that have made investments in Rust of
| similar size are.
| akritrime wrote:
| Disregarding all allegations, Huawei is one of the bigger tech
| companies and is one that has its finger in every pie,
| especially across domains where rust is advertised as a better
| alternative to incumbent C/C++. I can see why they are on the
| board.
| oytis wrote:
| Peixin Hou seems to be a director on Linux foundation too.
| Probably responsible for corporate lobbyism in OSS in general.
| Erlangen wrote:
| Well, hw is the top contributor to linux kernel in 5.10.
| https://lwn.net/Articles/839772/. I remember it was discussed
| in HN before.
| oytis wrote:
| It's pretty reasonable for a hardware vendor building on
| top of Linux to upstream their changes.
| uh_uh wrote:
| This is great news, but I have to point it out. Some of the
| social media handles on the Board of Directors page are
| hilariously unreadable: https://foundation.rust-lang.org/board/
|
| (Click the pictures to reveal them)
| valarauko wrote:
| What's with the crabs? Is it an inside joke I'm not getting?
| brabel wrote:
| I think it started with the name given to Rust programmers:
| Rustaceans.
|
| It is close to crustaceans so I think the puns just got out
| of hand from there :D
| kwierso wrote:
| "crustacean" > crab
|
| "rust-acean"
| yannoninator wrote:
| Just as crazypython said, it seems that the power has shifted
| from Mozilla and the community to big corporations on the future
| of Rust.
|
| This is worrying to me in that engineers are naively selling
| their souls to big corporations just to work on Rust.
|
| I'm glad for the formation of the foundation, even though I hear
| that even Facebook (although not on the board yet) are looking
| for engineers to work on the Rust compiler.
|
| Yikes.
| iso8859-1 wrote:
| No language has ever been ruined by large corporations.
| Languages are too far removed from society to be affected by
| this.
| pjmlp wrote:
| Big corporations are also driving ISO and ECMA languages, so do
| you feel like selling your soul to work with C?
| yannoninator wrote:
| Yes, you and I are more likely not to have say in this, I
| prefer the community to have a say not corporations.
| pjmlp wrote:
| Anyone is free to submit a paper to ISO and ECMA, provided
| they are willing to champion it.
| jiayounokim wrote:
| Code is code. Big corporations or small corporation, if the
| language benefits from it, its all good.
|
| React is from FB, they have engineering talent as such Amazon,
| Google, Microsoft, Mozilla.
| yudlejoza wrote:
| As a C developer, after getting sick and tired of hearing about
| Rust everywhere, I decided to do a bit of assessment in terms of
| code-size complexity.
|
| I heard of ripgrep, an amazing twenty-first century revolution
| that beats grep in the dust.
|
| I have never seen grep source code. I told myself, if I download
| ripgrep-on-Rust and grep-on-C and find out that ripgrep is doing
| all it's doing in one-tenth the size of grep source code, or even
| half the code size, I'd be quite impressed, and be willing to
| take Rust seriously.
|
| Well guess what, I downloaded the two sources. Grep source code
| is about 4k LoC. ripgrep? about 24k.
|
| WTF.
|
| I thought maybe I was mistaken. I went into the ripgrep source
| directory and started going through the individual subdirectories
| under 'crates'.
|
| - printer: 4664
|
| - core: 4561
|
| - searcher: 4360
|
| - ignore: 4321
|
| If your printing code, and your searching code individually is
| the size of the whole machinery of grep, I feel sorry for you. If
| this is the state of the rewrite-everything gang, I can't take
| those guys and their language seriously. I just can't.
|
| edit: to those who're saying ripgrep is more than grep. First, I
| know. Second, wouldn't it be great if someone could rewrite
| ripgrep in C? Now I'm really curious to find out the code-size
| complexity of all the ripgrep features backported to grep.
| nneonneo wrote:
| As a Rust developer (not really), after getting sick and tired
| of hearing about C everywhere, I decided to do a bit of
| assessment in terms of code-size complexity.
|
| I heard of Linux, an amazing operating system kernel that beats
| Redox in the dust.
|
| I have never seen Redox source code. I told myself, if I
| download Linux-on-C and Redox-on-Rust and find out that Linux
| is doing all it's doing in one-tenth the size of Redox source
| code, or even half the code size, I'd be quite impressed, and
| be willing to take C seriously.
|
| Well guess what, I downloaded the two sources. Redox kernel
| source code is about 24k LoC. Linux? about 27M.
|
| WTF.
|
| ----
|
| In all seriousness, LoC comparisons are absolutely the worst
| way to compare languages, especially across projects that are
| completely different in scope and design.
|
| (This was a joking reply in the style of OP's now-flagged
| comment, which was comparing LoC between ripgrep and grep.)
| krylon wrote:
| IIUC, minimum code size was not the top priority of the creator
| of ripgrep.
|
| And Rust's claim to fame is not that it allows you to get the
| job done with less code. Its claim is that it allows you to get
| the job done, but with far fewer memory access issues, without
| sacrificing runtime efficiency.
| Ar-Curunir wrote:
| You know you can just ignore the Rust talk? And maybe measuring
| things by how many LoC they require is not the best metric.
| kevincox wrote:
| You are acting as if these are the same thing. ripgrep has more
| features than grep and that is going to take more code. At the
| very least you can drop the printer and ignore crates. You are
| still looking at twice the code but ripgrep is doing parallel
| searching so it is obviously going to be more. How much more is
| hard to say without trying to rewrite one or the other to make
| this an apples-to-apples comparison.
|
| And even if it results in 1-2x amount of code that is not the
| end-all metric. How quickly was this code written and how easy
| is it to maintain? How many bugs does it have?
|
| I mean rust is basically a superset of C (other than having to
| write "unsafe" everywhere if you use a c-style), so it is hard
| to dismiss this as wasted noise because if it was wasted
| wouldn't people have written it like C line-for-line?
| protoman3000 wrote:
| The amount of damage stupid and overconfident people can cause
| with sharp tools like C is a too high to bear risk. That's why
| we instead use Java or (God forbid) JavaScript, but at the
| expense of speed.
|
| Rust tries to gain back this lost speed without making it too
| easy for idiots to destroy everything. Such code can of course
| look larger and more convoluted than over decades on every
| corner optimized C code, but at least we're as fast as C and
| much safer from ignorant people.
| codr7 wrote:
| Making tools for "idiots" didn't really work out so far,
| that's how we got Cobol and Java.
|
| From my experience, empathy works better as a design
| strategy.
| protoman3000 wrote:
| What's the issue with Java? It empowers teams consisting of
| many heterogeneous people to get work done easier and
| limits the scope to logical errors only.
| nindalf wrote:
| For the record, that word has never been used to describe
| Rust's goals by those who work on it. The slogan of the
| language is "empowering everyone to build reliable and
| efficient software."
|
| And for what it's worth, I think the people working on Rust
| are empathetic and it shows in their work. For example, he
| error messages given by the compiler try to hand hold you
| gently when you're learning the language.
| protoman3000 wrote:
| For the record, how else do you call obtuse persons who
| proudly claim to be C programmers while using LOCs in a
| troll comment? :)
| adamch wrote:
| ripgrep's src/ contain both library code and unit tests. The
| grep source code appears to use different tests/ and src/
| directories.
|
| ripgre's source code files appear to be between 1/3 and 1/2
| unit tests, in the few samples I checked. For example,
| https://github.com/BurntSushi/ripgrep/blob/master/crates/sea...
| ragnese wrote:
| > edit: to those who're saying ripgrep is more than grep.
| First, I know. Second, wouldn't it be great if someone could
| rewrite ripgrep in C? Now I'm really curious to find out the
| code-size complexity of all the ripgrep features backported to
| grep.
|
| I'd be shocked if a C version measured fewer LoC without
| resorting to some real dark art pointer magic.
| adamch wrote:
| Perhaps the developers had a success metric other than LOC.
| isbadawi wrote:
| ripgrep isn't a 1:1 rewrite of grep. It's a different program.
| teraflop wrote:
| Maybe the fact that ripgrep contains more lines of code is
| related to the fact that it has more features, and not just
| about the language it's written in?
| https://beyondgrep.com/feature-comparison/
|
| Also, it's kind of pointless to compare lines of code given
| that both projects get large amounts of their functionality
| from dependencies. For instance, the GNU grep repository
| doesn't actually contain any regex-matching code; that's all in
| gnulib.
|
| EDIT: If you already knew that ripgrep had more features, and
| yet your immediate reaction was that you "can't take those guys
| and their language seriously", then your comment is straight-up
| trolling. Please don't do that here.
| jrimbault wrote:
| The "proper" comparison (that would still be horribly
| misguided) would be against the "core" crate in ripgrep. And
| that's only 5kloc, a lot of it from the "app.rs" (3kloc) and
| "args.rs" (1.2kloc) which is almost only declarative usage
| strings.
|
| The "actual" code of ripgrep is accross its multiple support
| crates, which the community largely benefits from having
| since those are general enough to be almost foundational to
| any software.
|
| imo, op is trolling, the old fashioned way
| yudlejoza wrote:
| I'm trolling because there is no doubt in the mind of Rust
| fanboys that if ripgrep was a feature-for-feature replica
| of grep, in some parallel hypothetical universe, it would
| for sure have less code-size complexity.
|
| Got it.
| saagarjha wrote:
| Hacker News is not a place for you to troll.
| nojito wrote:
| ripgrep does more than vanilla grep.
|
| How is looking at LoC meaningful?
| hojjat12000 wrote:
| > I heard of ripgrep, an amazing twenty-first century
| revolution that beats grep in the dust.
|
| So, when you heard that, you thought "LOC"? Not safety, not
| speed, not features, not FFI, but LOC? why?
| Ar-Curunir wrote:
| Maybe because that's the only metric that C is better at (I
| jest)
| ATsch wrote:
| I'm sure every project having it's own buffer, list,
| config, logging, hashmap and endianness implementation
| helps a lot with that :)
| fireeyed wrote:
| Huawei ?
| brabel wrote:
| Microsoft?? Google?? Don't they already have their own
| languages?!
| mirekrusin wrote:
| Maybe they need to rewrite them in rust?
| ChrisSD wrote:
| Announcements also from Mozilla, Amazon and Microsoft:
|
| https://blog.mozilla.org/blog/2021/02/08/mozilla-welcomes-th...
|
| https://aws.amazon.com/blogs/opensource/congratulations-rust...
|
| https://cloudblogs.microsoft.com/opensource/2021/02/08/micro...
| raphlinus wrote:
| And Google:
|
| https://opensource.googleblog.com/2021/02/google-joins-rust-...
| TheGuyWhoCodes wrote:
| I find it puzzling that aws uses rust so much yet don't have an
| official rust aws sdk
| anonyfox wrote:
| I'd love to see Apple joining. They already have the hand on
| LLVM and support things indirectly, but...
|
| There is no reason that serious things written in Rust can't
| coexist with app-y stuff in swift.
|
| Seriously, I think we all would benefit enormously from some
| consolidation, especially on such a great foundation like Rust.
| Think investments like: compiler-optimizations like V8,
| portability like C, enterprise grade tooling like Java,
| productive libraries like Ruby, datascience libs like python,
| ... it would be great to have all of this in one coherent
| package.
|
| Why? Instead of glueing together brittle and fragile things
| where the moving parts break within weeks, reinventing the
| wheel, we could finally focus on the actual things to build.
| Bonuspoints for Rust: every other techstack can leverage/profit
| directly, like when binding C stuff.
|
| Everyone still can innovate like the past decades, languages
| and libs will be re-explored and reinvented and so on, but,
| really, a solid baseline would be a dream
| pjmlp wrote:
| We don't need monocultures.
| mjw1007 wrote:
| I found parts of that announcement very difficult to follow.
|
| Can anyone tell me what the following means?
|
| << For too long, open source as both an industry and a community
| has done a poor audit of its expenses. Notably, ignoring the
| price of what I'd controversially argue is the core value
| proposition of open source software: the freedom to collaborate.
| >>
| Rusky wrote:
| I read it as a reference to the problem of maintainer burnout
| in the face of unbounded input from users and collaborators.
| This is something the Rust project has been dealing with and
| thinking about for a while.
| muricula wrote:
| Here's my take: Collaborating in the open and communicating the
| results of discussions and the rationales for decisions to the
| wider community who wasn't present for the discussions has a
| high time cost. It seems the core rust team has put a lot of
| effort into making decisions in the open, which increases
| freedom to collaborate.
| picardo wrote:
| Just a throwaway line, written, no doubt, in a fit of high-
| mindedness.
| mkl95 wrote:
| Great news for Rust, congrats
| nadllik wrote:
| Same, congrats.
| rexdexpl wrote:
| Well - no surprise for me here. Speaking as someone that worked
| in FAANGs - people love to burn money unproductively there and
| RUST is just perfect for that. Reinventing the wheel and solving
| already solved problems but "different". It's a language for
| theoretical "perfectionists" and Code Review keyboard fighters
| that will burrow themselves in it for years and probably never
| contribute to company's IP in any meaningful way.
|
| It's great that those big-tech money furnaces finally "embraced"
| it.
| gabereiser wrote:
| You love to see it. Huge congratulations to everyone involved, to
| the rust maintainers, community, and admins.
| [deleted]
| mssundaram wrote:
| A win for Rust for sure, but it also seems like a loss for
| Mozilla.
| mhh__ wrote:
| Honestly steering a programming language is basically just work
| and writing rather than anything particularly strategic.
| AnimalMuppet wrote:
| Depends. Do you want the language to go somewhere in
| particular, or just wander around accumulating features? If
| you want it to go somewhere, steering it there becomes
| strategic. In particular, it's strategic for the survival and
| ongoing health of the language.
| ChrisSD wrote:
| In what way?
| staticassertion wrote:
| Mozilla was sort of de-facto the steward of the language up
| until recently. They stupidly fired the teams behind their
| most promising R&D project and lost any semblance of control
| over it.
| ChrisSD wrote:
| No, Rust has been independent since Rust 1.0. Mozilla only
| provided free legal advice (+trademarks, etc) and employed
| some team members but they didn't have control.
| staticassertion wrote:
| I wasn't implying that Mozilla had explicit control over
| the project, but to say that it just "employed some team
| members" really undersells things. They employed critical
| team members, including as I recall the majority of the
| core team. They were also leveraging the project for R&D,
| allowing for fast feedback loops between core members and
| Servo developers.
|
| Rust always, thankfully, made sure to be independent of
| Mozilla, but it would be silly to think that they had no
| influence over the project and that by firing major
| contributors they've lost that.
| hobofan wrote:
| Not hard control, but I think they had a pretty big
| impact on where Rust headed (not in direction, but
| prioritization), even in the 1.x days, though more in
| core ecosystem than in the language itself. E.g. I doubt
| Rust would be in it's dominant position regarding WASM,
| if it weren't for Mozilla.
| ChrisSD wrote:
| That was only because they had engineers working on it.
| The foundation changes nothing in that regard. If Mozilla
| were to hire engineers to work on bringing Rust to a new
| platform then it would have the same effect now.
|
| I don't want to downplay Mozilla's many contributions to
| Rust in any way but I also acknowledge they worked hard
| to ensure Rust operated independently of any
| organisation, including themselves.
| Ericson2314 wrote:
| This is a very good "partial exit" for Mozilla, actually. The
| original plan might be to do something like this to split the
| cost, while oxidized Firefox still reaps more benefits than the
| competition playing catch-up.
|
| Rust can't/shouldn't be directly monitized, so it makes sense
| to have something like this. Mozilla can still hire as many
| people as they want, but they never attempted to make it a
| company-managed project.
| hobofan wrote:
| > Rust can't/shouldn't be directly monitized
|
| I agree that the main implementation should not, but I could
| see something like a verified Rust compiler (maybe something
| like the "Sealed Rust" proposal) being commercialized.
|
| [0]: https://ferrous-systems.com/blog/sealed-rust-the-pitch
| FreeFull wrote:
| Mozilla has brought this on themselves. I just hope that
| Firefox itself will be able to stay on a productive path,
| somehow.
| [deleted]
| pdevr wrote:
| As someone who wants to use Rust for real world applications,
| what are some good use cases for Rust? Web development is not its
| strong suite, apparently.
|
| Or, better still, what have you personally built using Rust?
| Mordak wrote:
| I feel like rust has some good sweet spots right now. I care
| about these but maybe not everyone else does.
|
| - Parsing untrusted inputs. nom[1] is a joy to use, and lets
| you kind of effortlessly and fearlessly process random input
| from wherever and turn it into useful data structures. If your
| data is very regular or in a standard format, then serde[3] is
| very hard to beat if it just boils down to 'derive(Deserialize,
| Serialize)' on your Rust struct.
|
| - Bulk data processing. rayon[2] makes pegging your machine
| easy if you have a lot of work do to, and the Rust semantics
| around thread safety, data ownership, and explicit copying make
| it kind of trivial to reason about how your data gets from
| input to output and tuning it to be crazy fast.
|
| - Generic systems language. Maybe this one is personal, but I
| find it's more productive to write generic cli applications and
| whatnot in Rust over C, ruby, or python. There are some nice
| libs to make part of this pleasant (structopt[4]) but this
| really boils down to reliability. Because Rust makes it obvious
| where things can fail so I can deal with it I have way higher
| 'just works' outcomes in Rust than other languages. I might
| spend slightly more time making it compile, but I spend
| basically zero time debugging runtime failures and this is kind
| of indescribably amazing.
|
| [1] https://docs.rs/nom/6.1.0/nom/index.html
|
| [2] https://docs.rs/rayon/1.5.0/rayon/
|
| [3] https://serde.rs/
|
| [4] https://docs.rs/structopt/0.3.21/structopt/
| brabel wrote:
| I've used Rust to write a couple of personal projects: a
| compiler for a language I've designed (it's really good for
| that because of its great ADT and pattern matching support) and
| a small CLI which I wanted to be very fast. Rust is great for
| that. The `structopt`[0] crate makes writing CLIs almost as
| easy as on a high level language.
|
| The other project is a web app and I use Rust to compile to
| WASM. Because I had to use several web APIs (DOM, WebCrypto) I
| used the JS interop heavily, and that's still very painful to
| use if you use the low-level interop (js-sys and web-sys)...
| however, I am aware of several efforts in this area, like
| Yew[1], which should make things better.
|
| The language is very hard to learn, but once you get past a
| certain threshold (depending on what you know already, that may
| take weeks to several months) it's really nice to use (though
| certain things are still hard to write because managing
| lifetimes can be very tricky).
|
| [0] https://crates.io/crates/structopt
|
| [1] https://yew.rs/
| Dowwie wrote:
| It's a good thing I didn't get that memo, nor anyone to tell me
| that backend web development wasn't its strong suit, because I
| built an entire platform of services with it and an EDA. As I
| worked on my projects, I wound up crossing streams with
| developers who had moved from Node, Python, Java, Ruby, PHP,
| and Go.
| snake_case wrote:
| I mentioned elsewhere in this thread that I built a jigsaw
| puzzle website [1] with a Rust API backend and I launched it
| last week. It definitely took longer than if I had used Node,
| but I enjoy working with Rust much more.
|
| Apart from that website, I have also open sourced a Rust CLI
| task runner [2] which uses markdown files as a command
| definition format. This is probably the most important tool
| I've ever written, as I have used it every single day since.
|
| [1]: https://puzzlepanda.com
|
| [2]: https://github.com/jakedeichert/mask
| andrewkdinh wrote:
| Some off the top of my head are Alacritty (terminal emulator),
| exa (ls alternative), bat (cat alternative), and dog (dig
| alternative). Discord is rewriting a lot of their services from
| Go to Rust [0]. I personally built a CLI text editor in Rust
| [1] (very early development).
|
| [0] https://blog.discord.com/why-discord-is-switching-from-go-
| to...
|
| [1] https://github.com/andrewkdinh/via
| da_big_ghey wrote:
| Small erratum: Your first link describes re-writing a back-
| end service from go to rust; the first-party Discord client
| is Electron.
| mhh__ wrote:
| As a D foundation employee, good luck have fun
___________________________________________________________________
(page generated 2021-02-08 23:00 UTC)