[HN Gopher] Why Not Rust?
___________________________________________________________________
Why Not Rust?
Author : dochtman
Score : 170 points
Date : 2020-09-20 19:27 UTC (3 hours ago)
(HTM) web link (matklad.github.io)
(TXT) w3m dump (matklad.github.io)
| the__alchemist wrote:
| I hope this isn't too much of a tangent given the article's
| subject is details and specifics. I adore Rust for it's unique
| combination of features:
|
| - Can write fast, and systems-level code; something typically
| dominated by C/++
|
| - Makes standalone executables
|
| - Modern, high-level language features
|
| - Best-in-class tooling and docs (As the article points out)
|
| I'm not familiar with another language that can do these
| together. It's easy to pidgeonhole Rust as a "safe" language, but
| I adore it on a holistic level. I've found Rust's consolidated,
| official tooling makes the experience approachable for new
| people.
| nicoburns wrote:
| It's the modern high-level language features that get me.
| Despite Rust technically being a lower-level language, they are
| so well implemented that I often find Rust more enjoyable to
| code something in than other supposedly friendlier languages.
| The killer is the compile times. If Rust had Go-like compile
| times it would be almost perfect.
| ncmncm wrote:
| The expressions "high-level" and "low-level" are almost
| meaningless in this context. Rust, like C++, has a _broad
| range_.
|
| In _any_ big system, almost all of the code will be doing
| high-level-ish things no different than you would do in a
| Python program. At unpredictable points it will need to dip
| into low-level-ish activities, where it might end up spending
| the most runtime. If you were writing Python, you might call
| out to a C or C++ module, then.
|
| It is this broad range that defines a modern systems
| language. It has organizational features that make a big
| system manageable, and features to get full value from
| hardware. People used to try to use C as a systems language,
| with well-known failings.
| est31 wrote:
| You get accustomed to the slow compile times of Rust over
| time. Then you do some Go stuff and get extremely surprised
| by how quick it is, almost as if Go's cheating. But it's just
| rustc being slow :).
| ncmncm wrote:
| You don't achieve success by getting (some) people
| accustomed to your failings. That is a route to failure.
|
| There are many, many routes to failure. Staying off them
| doesn't guarantee success; it's table stakes.
| drran wrote:
| Rust is high-level language. You mean "a language which
| allows low level access to hardware". Right?
| the__alchemist wrote:
| "high level" and "low level" have somewhat fluid meanings,
| and in the case of Rust, aren't ideal for describing the
| language on the whole. Eg: You can do "low level" things
| like read a MCU register using a raw pointer. You can take
| advantage of "high level" abstractions like Result types.
| drran wrote:
| High level language is platform independent. Low level
| stuff can be done from almost any language. I used peek
| and poke in Basic to access hardware registers 30 years
| ago.
| onei wrote:
| > Modern, high-level language features
|
| I think this is something the article overlooked. Sure, Rust
| has the ability to be a system level language, but you don't
| have to use it that way and the breadth of good, albeit
| commonly immature, libraries is testament to this. Rust enums
| and pattern matching are some of my favourite features in any
| language.
|
| Python is often my go to for writing tools, but I mistrust its
| typing and how it behaves when a library throws an exception -
| not forgetting that pylint warns if you try to catch Exception.
| Conversely, Rust error handling feels a bit more verbose, but I
| worry less about what it does in failure scenarios. I either
| handle the error or pass it up the stack and carry on with my
| day.
| [deleted]
| angelbar wrote:
| Because oil...
| forrestthewoods wrote:
| > Rust also lacks an analog for the pimpl idiom, which means that
| changing a crate requires recompiling (and not just relinking)
| all of its reverse dependencies.
|
| Interesting. I did not know this. I would have thought Box<dyn
| Foo> would have achieved PIMPL. Is that not the case?
| joerichey wrote:
| I think you would actually need Box<dyn Foo>. But the bigger
| point is that the current build system can't figure out that a
| rebuild isn't necessary in these cases.
| forrestthewoods wrote:
| > I think you would actually need Box<dyn Foo>
|
| Oops. Good catch. Fixed. :)
|
| Sounds like this is a fixable problem though? That's nice. I
| really appreciate the amount of attention Rust compile times
| is getting. (Especially because relative to C++ they aren't
| actually that bad!)
| ArchOversight wrote:
| The downside to the PIMPL idiom in C++ at least, is that you
| have double indirection.
|
| The outer exposed API is called on `this` which then uses the
| internal `pimpl` pointer to actually call a function.
|
| While it may speed up building, I have found it incredibly
| clunky to use in C++ and prefer to write my code without it,
| choosing instead for longer compilation times.
| forrestthewoods wrote:
| > The downside to the PIMPL idiom in C++ at least, is that
| you have double indirection.
|
| PIMPL is just a tool. There's no argument here that it should
| be used in all or even many cases. The fact that C++ has this
| tool and Rust does not is interesting.
|
| PIMPL indeed has overhead. Both when writing the code and
| when calling the code. If a program crosses the PIMPL
| boundary many times then the calling overhead can be
| meaningful.
|
| However if the API is small and the program spends more time
| "inside" the PIMPL than crossing the boundary the runtime
| overhead is trivial.
|
| A key benefit of PIMPL is that, in some cases, you can have a
| very lightweight header than clearly expresses an API without
| making users include a ton of dependencies they don't
| actually need. I shall not express my opinion on C++ headers.
|
| Historically I have not liked PIMPL. My current project
| benefits from it a great deal. Most projects probably would
| not. Like I said, it's just one of many tools.
| jeffrallen wrote:
| In the section on "Rust is big and you have to learn it" the
| author was too nice to people like me: I'm just not smart enough
| to manage the demands Rust puts on me while also solving my own
| problem.
|
| I feel like this is a really serious problem for Rust: the number
| of people capable of making the right choices among the 10 ways
| to structure a class is too small. This is also why there's too
| much dangerously bad C and C++ in the world.
| dodobirdlord wrote:
| Yea, I think Rust may be hurting currently for conventions or
| "best practices". The benefit of most "best practices" isn't
| usually that the opinions actually have any merit, but rather
| that they are consistent and meld into the background. Has any
| large company that uses Rust published a well-regarded and
| well-adopted detailed style guide in the way that Google
| publishes style guides for the languages they use?
| hobofan wrote:
| You probably won't find much of written out style guides on
| Rust, since with rustfmt and clippy, a strongly community
| endorsed code formatter and linter have been available since
| (almost) day one. With that, you have most of the "best
| practices" in form of a tool already.
| timidger wrote:
| Clippy catches a lot and I can't imagine coding without
| rustfmt.
|
| But there's more to style guides than formatting and Clippy
| lints. Some designs will pass Clippy (or worse, lead to
| Clippy warnings far past the point where a redesign is
| economical) but be inefficient, inflexible, or have a poor
| effect on compile speeds.
|
| One major problem I experienced in my last job (where I
| worked on production rust) was the insane amount of macros
| and proc macros used. This was an originally C++ heavy shop
| so they leaned on it more than, say, a python shop moving
| to rust would.
|
| This led to terrible compilation times and confusing code
| only certain engineers could maintain (I'm guilty here -
| I've since left and I know of one proc macro I wrote that
| will cause headaches to anyone who uses it).
|
| We need an opinionated style guide. The language is so
| complex we probably need multiple, with different trade
| offs.
| hobofan wrote:
| I'm not sure that style guides are the right way to
| tackle such arising problems. That sounds more like
| completely separate problems that are each best explained
| in longer blog posts and learned by the engineers over
| time.
|
| Most of the popular style guides from big companies I
| know from other languages are much more one a trivial
| level where each of the bullet points can be quickly
| explained and generally isn't more complex than a clippy
| lint (which is why I mentioned that).
| est31 wrote:
| A big thing missed here is compatibility. The systems programming
| market is huge but most of it is covered by C/C++ programs, many
| of which being giant codebases with millions of engineer hours
| inside them. You can't just rewrite them in Rust. And Rust will
| always be second in place when it comes to interacting with C/C++
| codebases, C++ will always be better at it, and if it's only the
| explicit safety barrier.
|
| So languages like Rust are relegated to picking up the new
| greenfield codebases and some few codebases where engineers felt
| courageous enough to introduce it.
|
| Overall, the signs are good though. I think it's much easier to
| onboard new engineers to Rust rather than to the company specific
| dialect of C++.
| akiselev wrote:
| I'm hoping that with the advent of projects like autocxx [1],
| the C++ compatibility story will rapidly change. Templates and
| some of C++'s more exotic features will always be an interop
| issue but Rust's ergonomics and type system are addicting.
|
| I've been experimenting with "bidirectional" (for lack of a
| better word) refactoring in autocxx where the bulk of the C++
| implementation stays the same but wrapped in a safe Rust
| interface (using autocxx to generate the underlying interop)
| that is then reexposed by another run of autocxx to the rest of
| the C++ code. New Rust code can use the safe interface while
| old code is refactored to use the now (slightly) safer wrapper
| over the Rust interface. This allows for very intentional,
| piecemeal refactoring across the code base.
|
| Rust's compatibility with other languages like Python and
| Javascript is already, imo, second to none thanks to a few well
| designed libraries and the macro system. The only language that
| comes close is C# with its IronPython integration, except with
| Rust it's a lot easier for library authors to integrate
| runtimes. It took me less than a day to construct a JS/Python
| monstrosity with an absurd call stack (Node => Rust => Python
| => Rust => Node => Rust => Python) when I needed to wrangle
| together a bunch of legacy proprietary libraries in webapp
| form.
|
| Like you said, the signs are good for Rust's interop story in
| general.
|
| [1] https://github.com/google/autocxx
| omn1 wrote:
| You're right about the massive amounts of C/C++ code out there.
| I'd disagree that the integration is harder than with C++,
| though.
|
| Calling Rust from C and vice versa is fairly straightforward
| and there are automatic code generators for doing so. Things
| just get wrapped into an `unsafe` block and that gives you the
| same guarantees you'd have with C++ (none, basically). From
| there you can start to gradually rewrite critical parts in safe
| Rust and profit from the cargo ecosystem along the way. In that
| sense there's even an advantage for Rust over C++ in my book.
| est31 wrote:
| Integrating with C is easier than with C++ but it still needs
| those safe wrappers. With C++ you can use stuff directly, and
| maybe sometimes have to convert between say C and C++
| strings. Integrating with C++ is much harder, especially if
| some C++ features are used. What if you have to inherit a
| class to do something? What if there is a generic function
| that you need to invoke? Even tasks as simple as catching
| exceptions are difficult. Things have improved with dtolnay's
| cxx thankfully.
| ncmncm wrote:
| Calling C++ libraries from Rust is in general impossible. The
| more useful the library is, the less likely it is that Rust
| can call it. As the languages evolve, that will sharpen.
|
| There is no "C/C++" code. Using the expression mainly
| generates confusion, most usually in the person saying it.
| Animats wrote:
| As I've said before, Go has the advantage of mediocrity. It's
| boring as a language, but it does automatically most of the
| things you need for web back-end stuff. It's garbage-collected
| and does subscript checking, so you're covered on memory safety.
| There are stable libraries for most things you need in a web
| server, and those are mostly the same libraries Google is using
| internally, so they're well tested. The green thread/goroutine
| approach means you don't have the problems which come from
| "async" and threads in the same program; there's only one
| concurrent task construct.
|
| There's a lot to be said for that. You can put junior programmers
| on something and they'll probably get it more or less right.
|
| Rust is very clever. The borrow checker was a huge step forward.
| It changed programming. Now, everybody gets ownership semantics.
| Any new language that isn't garbage collected will probably have
| ownership semantics. Before Rust, only theorists discussed
| ownership semantics much. Ownership was implicit in programs, and
| not talked about much.
|
| Tying locking to ownership seems to have worked in Rust. A big
| problem with locking has been that languages didn't address which
| lock covers what data. Java approached that with "synchronized",
| but that seems to have been a flop. (Why?) Ada had the
| "rendezvous", a similar idea. Rust seems to have made forward
| progress in that area.
|
| I used to say that the big problems in C are "How big is it?",
| "Who owns it for deletion purposes?", and "Who locks it?" At
| last, with Rust we see strong solutions to those problems in wide
| use.
|
| Much work has gone into Rust, and it will have much influence on
| the design of later languages. We're finding out what happens
| with that model, what's useful, what's missing, and what's cruft.
|
| In the next round of languages, we'll probably have to deal
| directly with non-shared memory. Totally shared memory in
| multiprocessors is an illusion maintained by elaborate cache
| interlocking and huge inter-cache bandwidth. That has scaling
| limits. Future languages will probably have to track which CPUs
| can access which data. "Thread local" and "immutable" are a
| start.
| kccqzy wrote:
| > You can put junior programmers on something and they'll
| probably get it more or less right.
|
| I see junior programmers screw up Go catastrophically. Thinking
| green threads are magical, they forget the existence of mutexes
| and the resulting code has data races left and right. Languages
| like Haskell combine green threads with carefully controlled
| mutation (be it IORef or STM) to avoid this. Go doesn't, so you
| still need low-level knowledge like how to avoid deadlocks.
|
| As I've said before, Go gives you the veneer of an easy
| language when it's in fact full of traps for those who aren't
| experts.
| Animats wrote:
| Yes. Go's locking is really no better than C/C++. There are
| queues, and there are mutexes. Everybody has those now. Go
| just has a new story for them. The whole "share by
| communicating" thing tends to lead to people just putting
| "tokens" on queues, not the actual data.
|
| But Go does have a run-time race condition checker.
| torgian wrote:
| I learned three new terms today.
|
| Green threads, data races, mutexes.
| bird_monster wrote:
| Most companies, in my experience, want tools that are easy to
| get right in 80% of cases, and in 20% of cases require
| experts. Go has the benefit of most benign work is deadass
| simple to get right. The things you referenced in your post
| are obviously the remaining 20%.
|
| Rust, as an example, is a pretty difficult language to become
| productive in. Sure, once you've invested the time, you're
| equipped to handle a wider array of problems, but most
| organizations don't particularly care about the top. They
| care about becoming relatively productive relatively quickly.
|
| Go's approach to certain problems require expertise, it is
| not a silver bullet. But there are no silver bullets, and the
| examples you gave require expertise in any language. The
| issue is that you've kind of just cherry picked those three
| concepts as proof of complexity, ignoring the boatloads of
| other examples in which Go's simplicity does add value.
| dom96 wrote:
| > In the next round of languages, we'll probably have to deal
| directly with non-shared memory. Totally shared memory in
| multiprocessors is an illusion maintained by elaborate cache
| interlocking and huge inter-cache bandwidth. That has scaling
| limits. Future languages will probably have to track which CPUs
| can access which data. "Thread local" and "immutable" are a
| start.
|
| Interesting prediction. It is precisely the model of threading
| which Nim follows, global variables are thread local and
| sharing them is restricted. I'm not sure if the Nim designer
| thought of it in the terms you've described, but I will
| certainly point this out to him :)
| zozbot234 wrote:
| > It's garbage-collected and does subscript checking, so you're
| covered on memory safety.
|
| Go is only memory safe in sequential code, or concurrent code
| that never accesses shared data from multiple threads. It does
| _not_ protect against data races as Rust does.
| pjmlp wrote:
| I am looking forward that the generics 2020 edition actually
| make it, as Go is becoming anyway harder to avoid on my domain.
|
| I think ultimately the biggest Rust contribution will be for GC
| languages (tracing GC | RC) to also adopt some kind of early
| reclamation, similarly to Swift's ongoing approach, and we will
| reach a good enough situation and that will be it.
| kodkuce wrote:
| Hmm, go sux, i personally love Nim. Rust is bad cuz you need to
| write 10x more but its good for multythreading and only reason
| i gona learn it proper is Bevy :)
| Ericson2314 wrote:
| Great blog post
|
| > Rust also lacks an analog for the pimpl idiom, which means that
| changing a crate requires recompiling (and not just relinking)
| all of its reverse dependencies.
|
| I really hope `extern type` could help with this. _edit_ wrote
| https://github.com/rust-lang/rfcs/pull/2984#issuecomment-695...
| on how I think it could.
| networkimprov wrote:
| Will the compiler performance eventually match C++, or are there
| fundamental limits to it?
| moonchild wrote:
| I'm not sure what your point is there; rust and c++ are both
| famous for having slow compile times.
|
| Languages with good compile times include:
|
| - C[1] (unless you go crazy with the preprocessor)
|
| - Go (unless you go crazy with code generation)
|
| - D (unless you go crazy with templates)
|
| 1. With TCC or similar. Gcc/clang compile times are just ok
| (though better than with c++; and interestingly, though gcc is
| slower for c++, it's faster for c).
| sanxiyn wrote:
| Rust already compiles as fast as C++ if you write in roughly
| equivalent style.
| jhasse wrote:
| In my experience C++ is a lot faster, especially with
| multiple cores.
| pjmlp wrote:
| I can easily beat Rust, thanks to incremental linking and
| binary libraries.
| the_duke wrote:
| > Not All Programming is Systems Programming
|
| Personally I often use Rust for "non systems-programming" tasks,
| even though I really wish a more suitable language existed.
|
| Rust has plenty of downsides, but hits a particular sweet spot
| for me that is hard to find elsewhere:
|
| * Expressive, pretty powerful, ML and Haskell inspired type
| system
|
| * Memory safe. In higher level code you have almost zero
| justification for `unsafe`, unless you really need a C library.
|
| * Immutable by default. Can feel almost functional, depending on
| code style.
|
| * Error handling (it's not perfect by any means, but much better
| than exceptions in my book)
|
| * Very coherent language design. The language has few warts, in
| part thanks to the young age.
|
| * Great package manager and build system.
|
| * Good tooling in general (compiler errors, formatter, linter,
| docs generation, ... )
|
| * Library availability is great for certain domains, decent for
| many.
|
| * Statically compiled. Mostly statically linked. Though I often
| wish there was an additional interpreter/JIT with a REPL.
|
| * Good performance without much effort.
|
| * Good concurrency/parallelism primitives, especially since async
|
| * Increasingly better IDE support, thanks to the author of this
| blog post! (rust-analyzer)
|
| So I often accept the downsides of Rust, even for higher level
| code, because I don't know another language that fits.
|
| My closest alternatives would probably be Go, Haskell or F#. But
| each don't fit the above list one way or another.
| tempsolution wrote:
| > Expressive, pretty powerful, ML and Haskell inspired type
| system
|
| This is not a reason to use rust. It's like saying "I like
| Ferraries, because they drive fast", failing to specify WHY you
| need to drive fast (you usually really don't, unless you are on
| a race track)
|
| > Memory safe. In higher level code you have almost zero
| justification for `unsafe`, except you really need a C library.
|
| Java, C#, etc.
|
| > Immutable by default. Can feel almost functional, depending
| on code style.
|
| Okay, however this isn't a big win in practice. Java has this
| too with @Immutable and mostly that's enough.
|
| > Very coherent language design. The language has few warts, in
| part thanks to the young age.
|
| Yes, Rust looks fine. Let's see how it evolves. Coherent
| language design is however again not a reason to use rust,
| because it fails to mention WHY you need it and WHY it solves a
| business problem better than Java, C# or C++.
|
| > Great package manager and build system.
|
| Yeah, pretty much all modern languages have that, so it's not
| worth to even mention. Rust builds are slow, so there is that.
|
| > Great tooling in general (compiler errors, formatter, linter,
| docs generation, ... )
|
| Really? Ever used Java or C# tooling?
|
| > Library availability is great in certain domains, ok most.
|
| Compared to what? C++? I don't even think there it's true. When
| comparing to Java or C# library availability and quality is a
| joke in Rust.
|
| > Statically compiled (though I often wish there was an
| additional interpreter/repl). Mostly statically linked.
|
| Yeah... What do you need that for? Again no mention of why
| that's even useful.
|
| > Good performance without much effort.
|
| Like in Java, C# and C++ you mean?
|
| > Good concurrency/parallelism primitives, especially since
| async
|
| Async is a paradigm that received a lot of criticism lately. It
| turns out to be cancerous. Fibers will likely replace it and
| Java is getting it soon. Otherwise yeah, concurrency is
| something any modern language should solve and maybe Rust has a
| head-start here. The whole purpose of Rust is focused around
| safe multi-threading. However other languages don't sleep. You
| don't switch your company to Rust just because it does one
| thing better for a couple of years. Other languages will catch
| up soon.
| moonchild wrote:
| Can you describe what's wrong with haskell, ocaml (which,
| incidentally, was a major inspiration for rust), or f#? They
| seem to tick most of the items on your list, though this one I
| don't understand:
|
| > In higher level code you have almost zero justification for
| `unsafe`, except you really need a C library.
|
| If you need a c library, you can build a 'trusted' wrapper
| around it as easily in rust as with any other language.
| the_duke wrote:
| > Haskell
|
| I adore Haskell, but my personal problems with it:
|
| * Records! Lenses are fine, but a huge complexity increase. I
| love the recently accepted record syntax RFC though, this
| will make things a lot nicer.
|
| * I feel like the plethora of (partially incompatible)
| extensions make the language very complicated and messy.
| There is no single Haskell. Each file can be GHC Haskell with
| OverloadedStrings or GADTs or ....
|
| * Library ecosystem: often I didn't find libraries I needed.
| Or they were abandoned, or had no documentation whatsoever,
| or used some fancy dependency I didn't understand. Or all of
| the above...
|
| * Complexity. I can deal with monads, but some parts of the
| ecosystem get much more type-theory heavy than that. Rust is
| close enough to common programming idioms that most of it can
| be understood fairly quickly
|
| * Build system ( Cabal, Stackage, Nix packages, ... ? ),
| tooling (IDE support etc)
|
| > F#
|
| I admittedly haven't tried F# since .net core. I just
| remember it being very Windows-centric and closely tied to
| parts of the C# ecosystem, which brings similar concerns as
| in my sibling comments about Java.
|
| > if you need a c library, you can build a 'trusted' wrapper
| around it as easily in rust as with any other language.
|
| Sure, but if that wrapper does not exist, you have to build
| it yourself. I can say from experience that writing an
| idiomatic, safe Rust wrapper for a C library is far from
| trivial, so you lose the "I don't have to worry about memory
| unsafety" property.
| terhechte wrote:
| Did you try Swift? It is conceptually and syntax wise very
| similar to Rust.
| nicoburns wrote:
| Swift does indeed hit a lot of the same sweet points as Rust
| whilst having automatic memory management and generally more
| user friendly defaults (at the cost of performance). Alas, it
| doesn't have anywhere near the library ecosystem that Rust
| has in most domains, and it's cross-platform support is also
| quite poor.
| ChrisMarshallNY wrote:
| I'm a Swift programmer. I've also used plenty of other
| languages. I don't know enough about Rust to either sing
| its praises, or curse its name.
|
| I'm a bit leery to label Swift as a "systems language," as
| I feel that systems languages should be a wee bit closer to
| the bone (like ObjC); but that also means that I am not a
| fan of using systems languages to write application code. I
| wrote both levels in C and C++ for years, and HATED using
| those languages for app-level code. Swift, to me, is an
| almost ideal application language.
|
| But I don't write system code anymore, and have no desire
| to. I love writing app-level code, and love Swift.
|
| It's been a long time since I've had the pleasure of
| employing a language I actually _like_ using.
| the_duke wrote:
| I did, and I think it's a great language in many ways.
|
| My biggest problem is that, as far as I know, it still is
| very much second/third class citizen on non-Apple platforms.
| With little signs from Apple that this will change. (Happy to
| be corrected here!)
|
| Other (more minor) complaints are the Objective-C baggage and
| the inheritance system - I enjoy the lack of inheritance in
| Rust.
| charrondev wrote:
| My understanding is as soon as you target on a non-Apple
| device, you lose a large chunk of the API (foundation). This
| includes things like file system interaction, date handling,
| sorting/filtering, networking and text processing.
|
| My understanding is there is some effort to provide a version
| that works outside of Apple OSes, but it's incomplete
| https://github.com/apple/swift-corelibs-
| foundation/blob/mast....
|
| If you are looking for static linking stdlib it looks like
| there's still an open bug on Linux.
| https://bugs.swift.org/plugins/servlet/mobile#issue/SR-648
| omginternets wrote:
| What kind of programming do you do? I feel like this is
| important context for understanding your perspective.
| yashap wrote:
| You might like Scala and/or Kotlin. You listed Go, but Go's
| type system is very weak, as is Go's support for immutability,
| two problems that Scala and Kotlin don't share.
| jhardy54 wrote:
| Personally I'm not very excited about making Java a hard
| dependency, _or_ the fact that Scala can 't be bootstrapped
| like most other languages. [0]
|
| [0]: https://bootstrappable.org
| yashap wrote:
| Your 2nd point will stop being true very soon. Scala 3 will
| apparently be coming out sometime this fall
| (https://www.scala-lang.org/blog/2020/09/15/scala-3-the-
| commu...), and the compiler will be the Dotty compiler.
| Dotty is bootstrapped
| (https://dotty.epfl.ch/blog/2019/05/23/15th-dotty-
| milestone-r...).
|
| The first point is true, but IMO not a big deal for most
| applications. Scala native exists, but is very immature.
| Still, if you're writing web services, data processing
| jobs, etc., I don't see much of an issue with depending on
| the JVM. Definitely an issue with things like command line
| tools, or apps with super tight resource requirements, but
| that's not the case for a tonne of software.
| the_duke wrote:
| I conceptually love Scala, but in practice it has a lot of
| downsides.
|
| * Tied to the JVM
|
| * You constantly have to use Java libraries. Which means you
| have to understand the Java ecosystem. Which increases
| complexity a lot, since that ecosystem is very mature but
| also often deeply layered, complex and full of historical
| baggage
|
| * It can be used in so many different ways. Nicer Java on one
| end. Almost Haskell on the other (with cats etc).
|
| * The flexible syntax and multi-model concept leads to very
| variable and non-coherent code styles and libraries
|
| Kotlin is also great, but the type system is less powerful.
| And the same JVM and Java library ecosystem concerns apply. (
| I've jokingly heard "we don't talk about Native" multiple
| times... )
| yashap wrote:
| Scala has been my primary professional language for the
| past 5 years, and I actually don't have to use Java libs
| very often anymore, the pure Scala ecosystem has really
| caught up. When you do have to use them, they're normally
| pretty easy to wrap.
|
| Totally agree with the plethora of ways to use it being an
| issue, though. "Classic Scala" and "let's write Haskel is
| Scala" is a real split in the community, and a significant
| downside. Then you have Akka too, though at least that
| solves different problems (highly stateful AND highly
| concurrent, which is a pretty rare mix).
| lmm wrote:
| > You constantly have to use Java libraries. Which means
| you have to understand the Java ecosystem.
|
| That's not so true in my experience. You have to reach for
| Java libraries in the same cases where you'd have to reach
| for C libraries in other languages. When you're using a
| Java library it's usually to do something specific (because
| using the big Java frameworks makes no sense), so the
| complex parts of the Java ecosystem don't really affect
| you.
| sanderjd wrote:
| At one point in time, I thought Scala would be this, but it
| very much isn't. It feels bulky and lacking orthogonality to
| me, and it's tooling leaves a lot to be desired. (Note: this
| might be true of Rust too once it is as old as Scala.)
|
| Kotlin, though, yep, big fan.
| amelius wrote:
| > Expressive, pretty powerful, ML and Haskell inspired type
| system
|
| It's great that they use this, but it's still difficult to
| program in a purely functional style in Rust the way you would
| in, say, Haskell, because of memory management. Closures can
| create memory dependencies which are too difficult to manage
| with Rust's static tools.
| the_duke wrote:
| True. My biggest complaint there is actually lack of
| guaranteed tail call optimization.
| rudolph9 wrote:
| An interesting development in Haskell is Linear Types. It
| opens the possibility of non-garbage collected Haskell. Still
| a lot of work left but it's based on theory similar to that
| behind the Rust borrower mechanism (if I understand it
| correctly).
|
| https://www.tweag.io/blog/2020-06-19-linear-types-merged/
| zozbot234 wrote:
| A "non-GC Haskell" would also need some way to make strict
| and lazy evaluation equally idiomatic and freely
| interchangeable in the language. Some general approaches
| are known that would clearly help with this issue e.g.
| "polarity" and "focusing", but the actual work of designing
| such a language has not been done.
| ohazi wrote:
| This is definitely true, but you can often get surprisingly
| far by just boxing, cloning, Rc-ing, etc. whenever you hit
| something like this.
| amelius wrote:
| Yes, but doesn't the additional housekeeping negate much of
| the elegance of Haskell?
| jaggirs wrote:
| I feel like it should be trivial to make a 'scripting' variant
| of rust. Just by automatically wrapping values in Box/Rc when
| needed a lot of the cognitive overhead of writing Rust could be
| avoided. Add a repl to that and you have a highly productive
| and performant language, with the added benefit that you can
| always drop down to the real Rust backbone when fine-grained
| control is needed.
| saagarjha wrote:
| One of C++'s biggest draws historically is that it's not just
| used to write systems software. Rust could fill a similar spot.
| [deleted]
| mhh__ wrote:
| I think Andrei Alexandrescu's comment that Rust "skipped leg day"
| is still mostly true (Rust does what it set out to do better than
| anyone else but the metaprogramming in particular isn't very
| attractive)
| nindalf wrote:
| Peronally I feel more comfortable writing metaprograms in Rust
| than any other language. Could you elaborate?
| ncmncm wrote:
| Rust macros have no access to types at all. Types are
| essential for any but the most trivial metaprogramming.
| aazaa wrote:
| > Programmer's time is valuable, and, if you pick Rust, expect to
| spend some of it on learning the ropes.
|
| Of all the arguments, time-to-productivity may be the most
| compelling. Rust will keep most new programmers from being
| productive far longer than any other language. I'd say 3x
| minimum.
|
| What's a little surprising, though, is how many of the
| difficulties beginners have stem from just one concept:
| _ownership_.
|
| Counterintuitively, ownership is quite simple. But what's mind-
| bending about it is that it doesn't exist in any other language a
| beginner is likely to have used. Yet ownership pervades Rust,
| sometimes in very hard to detect ways. And perversely, it's
| possible to write a lot of Rust without ever "seeing" ownership
| thanks to the complier.
|
| Eventually, though, the beginner comes face-to-face with
| ownership without recognizing the trap s/he's fallen into.
| Ownership isn't something you can "discover" by messing around in
| the same way that most language features can be teased apart. The
| term "fighting with the borrow checker" is actually a symptom not
| of a struggle with a feature but a struggle with a basic, non-
| negotiable concept that hasn't been learned.
|
| I can recommend this video for getting over the hump:
|
| https://www.youtube.com/watch?list=PLLqEtX6ql2EyPAZ1M2_C0GgV...
|
| In my experience, Rust productivity shoots up by a lot given a
| basic understanding of ownership.
| lostcolony wrote:
| "But what's mind-bending about it is that it doesn't exist in
| any other language a beginner is likely to have used."
|
| This is true about killer features in any language that is
| above the 'average' on the power spectrum (
| http://www.paulgraham.com/avg.html ). In fact, even beyond
| beginners, I see resumes for people all the time with 20+ years
| who have only used Java/Python/C/C++. If you are evaluating
| languages for power or expressiveness, not just
| tooling/libraries/domain integrations, you're going to have
| longer ramp up time on average, regardless of the seniority of
| the developer, because you're by definition looking for
| features that aren't average (and therefore not mainstream).
| dlubarov wrote:
| Besides the learning difficulty, I'd there are some real
| ergonomic issues related to ownership, such as the difficulty
| of cloning into a closure [1], or nested &mut receiver calls
| being rejected despite being sound [2].
|
| [1] https://github.com/rust-lang/rfcs/issues/2407
|
| [2] https://github.com/rust-lang/rust/issues/6268
| __d wrote:
| Do you know C++ well? Could you compare time to productivity
| for C++ and Rust?
| AllasAskBar wrote:
| Anyone can see that C/C++ is outdated. Peering into the mess of
| those languages is like seeing Java/C# when you are used to a
| modern language like kotlin.
| throwaway78123 wrote:
| Rust in prod has been bittersweet for us. Our main goal was to 1)
| do our job and 2) leverage some of the great promises of Rust.
|
| Deterministic memory management and bare metal performance are
| great and have been realized benefits. The great promises were
| realized.
|
| On the "do your job" front though, the lack of a good STABLE
| library ecosystem has been a real issue and big source of
| frustration. It seems that most library developers in the Rust
| community are hackers writing Rust for fun, and I do not say that
| in a negative way. But the consequence is that things are usually
| not super well maintained, but more critically are targeting Rust
| Nightly (which makes sense as Nightly has all the new cool
| compiler stuff).
|
| Add the scarce professional talent pool, the unavoidable steep
| learning curve, low bus factor risk... It's just hard to justify
| pushing (professionally) more Rust beyond its niche.
|
| With Mozilla pulling out (to some extent), the big focus on Web-
| assembly... it just feels off if all you want to do is build
| boring backends.
|
| The contrast with Golang's "boring as a feature" is quite
| interesting in that regard.
|
| Time will tell if Rust will make it to the major leagues, or will
| be another Haskell.
| tmandry wrote:
| Most libraries don't target nightly anymore. It certainly
| _used_ to be the case that nightly had all the cool features
| everyone wanted, but almost all features that popular crates
| depended on have now been stabilized. Even Rocket (the most
| high-profile holdout I know of) now works on stable as of
| earlier this year.
|
| As for maintenance, as with all library ecosystems it's a mix.
| The most popular crates tend to be the most well-maintained in
| my experience. This is definitely something to consider when
| taking on new dependencies.
| swsieber wrote:
| Many things that used to nightly don't anymore. I think the
| only thing I'm using on nightly is Rocket, and that's set to
| change soon. May I ask what it was?
| rvz wrote:
| Another thing not mentioned is there's still no mature cross-
| platform production ready GUI libraries written in Rust yet. None
| of them come even close to Qt or countering Electron. Just mere
| unmaintained bindings to them. [0]
|
| I guess it is either Electron (HTML/CSS/JS) + 200MB Chromium
| engine or Qt5 (C++) for now.
|
| [0] https://www.areweguiyet.com/
| cxr wrote:
| > I guess it is either Electron [...]
|
| The really crazy thing is that the group that eventually
| birthed Rust had an acceptably performant Electron alternative
| even before Electron existed--and it supported both HTML _and_
| native-ish looking widgets. But they completely underinvested
| in it and eventually killed it--insisting that they knew better
| and that no one really needed or wanted it. Meanwhile, Electron
| is so ridiculously pervasive that it 's regularly brought up in
| conversation where its of very little relevance _just so people
| can complain about how popular it is_. The only thing we hear
| from the former group who strangled their baby, though, is how
| dire the outlook is for them and their influence on the
| computing industry.
| neutronicus wrote:
| "yet"
|
| Most languages never get one, and content themselves with
| piggybacking off of WxWidgets or JavaScript (or whatever).
| raphlinus wrote:
| Indeed. There is certainly no mature GUI framework in Rust
| yet, simply because it is an extremely ambitious undertaking,
| but I believe that Rust is by far one of the most promising
| languages for developing such a thing. I see great vitality
| both in explorations (for example, figuring out the best
| patterns for expressing reactivity) as well as
| infrastructure.
|
| I'll give an example of the latter which I find compelling.
| OpenType shaping (one of the subproblems of text layout) is a
| notoriously difficult problem, and almost nothing can compete
| with HarfBuzz, which is written in C++. Yet there is already
| one pure Rust alternative being used in production, Allsorts
| (used in Prince XML), and another promising one in
| development (rustybuzz, being developed by RazrFalcon, who
| has a track record of shipping ambitious 2D software).
| est31 wrote:
| There are a bunch of tiny single person projects but they are
| young and have tons of missing features and bugs. Ideally,
| you'd have a team building and maintaining a solution but that
| requires either an insane amount of coordination (and there's
| tons of disagreement about which design pattern to use), or
| money.
| mbo wrote:
| > "Rust should have stable ABI" -- I don't think this is a strong
| argument. Monomorphization is pretty fundamentally incompatible
| with dynamic linking and there's C ABI if you really need to.
|
| This is an interesting topic unto itself, described in one of my
| favourite pieces of technical writing of all time:
|
| How Swift Achieved Dynamic Linking Where Rust Couldn't - Alexis
| Beingessner - https://gankra.github.io/blah/swift-abi/
| pron wrote:
| > we don't know how to create a simpler memory safe low-level
| language.
|
| This may well be true, but using a memory-safe language is never,
| ever the goal. The goal is creating correct and secure _programs_
| -- that have as few bugs and security flaws as possible /required
| -- as cheaply as possible. While a memory safe language in the
| style of Rust is one means toward that end, that eliminates an
| important class of bugs at the cost of language complexity, it is
| not the best way toward that goal, at least not that we know, and
| it is certainly not the only one [1]. I.e. the hypothesis that if
| I want to write a program that's as correct as possible/needed as
| cheaply as possible then I should necessarily use the language
| that gives me the most sound guarantees regardless of the cost
| this entails is just some people's guess. It's hard to say if
| it's a good guess or a bad one because it's clear that we're
| talking about specific sweet-spots on a wide spectrum of options
| that could be very context-dependent, but it's still a guess,
| with good arguments both in its favour as well as against.
|
| > In Rust, there are choices to be made, some important enough to
| have dedicated syntax.
|
| Not only that, but those choices are exposed in the type
| signature and are, therefore, viral. Changing some internal
| technical implementation detail can require changes in all
| consumers. This is not a problem with the type system -- on the
| contrary, Rust's type system ensures that all the changes that
| need to be made are made -- but it is a fundamental problem with
| _all_ low level language. They all suffer from _low abstraction_
| , i.e. a certain interface can represent a smaller number of
| implementations than in high-level languages (even if the choice
| is not explicit in the type, like, say, in C, the usage pattern
| is part of the interface). But Rust's choice to expose such
| details in the types has its downsides as well.
|
| > If you use C, you can use formal methods to prove the absence
| of undefined behaviors
|
| C now also has sound static analysis tools [2] that _guarantee_
| no undefined behaviour with a nearly fully automatic proof that
| scales to virtually any code size and requires relatively little
| effort, certainly compared to a rewrite.
|
| [1]: Another low-level language with an emphasis on the same goal
| of correctness, Zig, takes an approach that is radically
| different from Rust's and is so simple it can be fully learned in
| a day or two. Which of the two approaches, if any, is better for
| correctness can only be answered empirically.
|
| [2]: Like https://trust-in-soft.com/, from the makers of Frama-C
| Karupan wrote:
| > Complexity - Programmer's time is valuable, and, if you pick
| Rust, expect to spend some of it on learning the ropes
|
| This has been my experience as well. I've been trying out Rust
| for a week now and as an experienced programmer, the complexity
| of the language is overwhelming. That said, you don't need to
| know all language constructs to get started. In the last week,
| I've been able to build a simple but useful cross-platform GUI
| app after reading only the ownership/lifetime section of the Rust
| book.
|
| But yes, it is not for everyone and it certainly isn't a simple
| language to pick up.
| amelius wrote:
| > All this complexity is there for a reason -- we don't know how
| to create a simpler memory safe low-level language. But not every
| task requires a low-level language to solve it.
|
| And what most people forget is that complexity works _against_
| safety: the less the programmer is distracted by other issues
| (e.g. memory management), the more they can focus on security.
| MaxBarraclough wrote:
| > complexity works against safety.
|
| Not always. Java programs have fewer memory-management issues
| than C programs, and they tend to be less severe.
| ncmncm wrote:
| The evidence does not support this assertion. Certainly C
| programs have a poor record of memory _usage_ errors, but the
| habit of Java programs routinely needing orders of magnitude
| more memory to do similar work is well known.
|
| Memory leaks are as easy under GC as in C.
| whateveracct wrote:
| > Memory leaks are as easy under GC as in C.
|
| This is just untrue. And no, allocating a bunch of short-
| lived objects isn't leaked memory. Neither is the overhead
| of the GC.
| MaxBarraclough wrote:
| > The evidence does not support this assertion.
|
| What are you referring to?
|
| > C programs have a poor record of memory usage errors
|
| Right. The C language allows for all manner of memory-
| related failures that are impossible in a language like
| Java. Use-after-free, double-free, and dereferencing _NULL_
| , are all undefined behaviour in C. In Java, the first two
| are impossible, and attempting to dereference _null_ throws
| an exception. It 's possible to do screwy things with Java
| finalisers, mind.
|
| > the habit of Java programs routinely needing orders of
| magnitude more memory to do similar work is well known
|
| Sure, but that's a matter of efficiency, with no bearing on
| memory safety.
|
| > Memory leaks are as easy under GC as in C.
|
| They're still _possible_ , but I sincerely doubt they
| happen with equal frequency between the two languages. I
| don't know of a good study on this empirical question
| though.
| atoav wrote:
| Not checking things will always be less complex than carrying
| out a metric ton of checks. But if _checks_ means "pass or
| halt" then I don't see how it would impact safety negatively..?
|
| Wouldn't _no checks_ equal less recognized bugs and therefore
| in turn lead to less secure code?
| elteto wrote:
| I think you need to develop this point a bit more: at face
| value it looks (to me) like you are saying:
|
| "The borrow checker is more complex than simple malloc/free
| calls therefore it is less safe."
|
| Which is clearly wrong.
| amelius wrote:
| But you can also compare it to a GC'd language, which from
| this viewpoint _is_ safer.
|
| A GC'd language, however, is usually not preferred for
| systems work. However, _most_ applications don 't fall in
| that category.
| muldvarp wrote:
| I don't think GC'ed languages are actually safer from a
| memory safety viewpoint, they're just easier to use.
| pjmlp wrote:
| Mostly due to cargo cult and politics than anything else.
| gameswithgo wrote:
| Can you elaborate more on what you mean, and how you know it to
| be true? Taking the argument in reverse we might expect
| programming with just nand gates to be the most safe approach.
| Do you mean, all else equal, that it works against safety?
| amelius wrote:
| What I mean is that the less the programmer is distracted by
| other issues (e.g. memory management), the more they can
| focus on security. (I added it to my comment).
| k__ wrote:
| Sure, not everything is system programming, but Rust has some
| higher level features that are even missing in languages like
| JavaScript and Python. Pattern matching is very powerful.
|
| I'm not entirely sure, but have the feeling that Rust's "cons"
| are mostly short term draw backs and the "pros" could be really
| valuable in the long run.
| andrewmcwatters wrote:
| Not many people just come out and say it, but I think Rust is an
| ugly programming language. That's a good enough reason for me.
| cxr wrote:
| I took _a lot_ of heat for that in a recent thread. There 's
| really no convincing Rust's most vocal fans what a mistake it
| was to focus on fixing so few of C++'s problems when they had
| the opportunity to fix the its-grammar-is-dogshit problem (and
| slow compiles times) in the same stroke and then completely
| failed to do so. (Votes were all over the place. At one point
| that comment was up 10-15 points IIRC even with some
| opposition, until the Aucklanders woke up and buried it in
| downvotes. And that was when I was being a lot more polite
| about it than I am now.) C++ programmers seem to have a
| permanently altered sense of what constitutes "tastefulness".
|
| Every time I think of the ugliness of Rust, I'm reminded of the
| comments from Stallman where he acknowledges the elegance of
| Java as an evolution of C's syntax, even though he never
| chooses to use Java for himself, having always stuck to C and
| Lisp instead. Then he goes on to trash C++.
| cuddlecake wrote:
| Could you try to explain why you think rust is an ugly
| programming language?
| jart wrote:
| TIL Rust is working on its own version of ASAN and UBSAN:
| https://github.com/rust-lang/miri How shocking.
| maitredusoi wrote:
| Rust is certainly powerful but not accessible to all dev. After
| 12 years of ruby, nothing push me to learn rust. By most I would
| stick to crystal, which is way morea accessible
| fortran77 wrote:
| Thanks! This convinced me. I'll stick to C for low-level, C++ for
| CUDA stuff, and C# for everything else.
| gameswithgo wrote:
| What if you were working on something where a cve or data leak
| from a buffer overrun could kill the company, or end a life?
| joerichey wrote:
| If you're working on safety-citical software, I think using
| formally verified C code (as discussed in the article) would
| be the best approch.
|
| If a bug could kill someone, you should (to the greatest
| extent possible) have a proof that such bugs are impossible.
| pjmlp wrote:
| How do you ensure an unsafe block on an dependency downloaded
| from cargo out of some pad-left like implementation doesn't
| do exactly that?
|
| Also should be noted that Rust lacks the necessary
| certifications.
| dodobirdlord wrote:
| In a situation where memory unsafety could put people (or
| the future of the company) at risk downloading random
| unaudited dependencies off of crates.io is obviously a no-
| go. Ideally downloading off of crates.io is a no-go during
| building anyway, since cargo can work with all of your
| external dependencies mirrored to a local filesystem or
| your own custom crate registry.
| pjmlp wrote:
| So basically the same approach as required by ISO
| security standards for C, C++, Ada and Java.
| Ensorceled wrote:
| People safely wrote software that could kill people long
| before Rust was invented.
| ausjke wrote:
| https://www.youtube.com/watch?v=iOBXVOAbpdY Rust is not as
| safe as it claimed, not to mention many will use its unsafe
| mode in practice anyways.
| disown wrote:
| The evangelical hype around rust is quite something. Not only
| does rust save companies, it saves lives. Check in next week
| to see if it can stop hair loss.
| fortran77 wrote:
| Steve Kablink _does_ have great hair!
| zelly wrote:
| Ada, Java, C#, Go, Python
| 1tCKV3QfIo wrote:
| Lol, why does it seem that most (if not, all) Rust
| evangelists are ignorant of formal verification.
| pjmlp wrote:
| That was my decision as well after a few forays with Rust in
| GUI programming, I just add Java alongside with .NET due to
| different deployment scenarios.
| nikki93 wrote:
| Just to clarify: do you still have a realm where you would
| use Rust?
| rvz wrote:
| I'm also convinced that there's still no mature cross-platform
| GUI libraries written in Rust, so that's that. All you get is a
| mixture of unmaintained or unstable bindings that may break
| when the library changes its API.
| [deleted]
| ncmncm wrote:
| This is a pretty good summary.
|
| Not to pile on, because Rust is still in a fragile condition, but
| the point that Rust cannot, and never will be able to call,
| typical C++ libraries deserves a boost (no pun intended).
|
| This matters because C++ has more facilities to encapsulate
| powerful semantics into libraries than any other language. You
| can write libraries in C++ that cannot be written in other
| languages, and people do.
|
| This makes it usually impractical to integrate Rust code into an
| existing modern C++ codebase, unless it implements a wholly
| independent subsystem. That matters because effectively all of
| the most demanding systems-level work, today, is conducted in
| C++, not C (old OS kernels and databases excepted).
|
| The longevity problem also deserves attention. The normal,
| expected fate of any new language is to die. It practically takes
| a miracle to survive, and we have no way to predict miracles. So,
| we don't know if there will be anyone to maintain Rust code
| written today.
|
| What will it take to survive? It comes down to numbers. Rust has
| an excellent adoption rate for a language at this stage. To
| survive, it _might_ be enough were the rate to increase by two
| orders of magnitude.
|
| You don't get that just by more and better publicity. It needs
| change. But the changes needed are, by experience, very, very
| unpopular among existing Rust users.
|
| Rust will never displace C++ or C. C++ does things Rust can't. C
| will dwindle only as its user base retires, because C users
| actually like it for its failings: it makes them feel tough (or
| something). Rust is an overwhelmingly better language than Java
| or Go, and the world would be a better place if Rust were to
| displace them.
|
| But neither of those has the specific problems that the borrow
| checker demands be solved. They have other, graver weaknesses.
| So, for Rust to displace them, its advocates will need to change
| their approach to appeal to users of those languages.
|
| That will require at least a different build model that admits an
| order of magnitude faster builds, and a looser use of the borrow
| checker that generates less frustration. It might need
| accommodations to integrate in Go and Java projects, maybe
| including support for a JVM target, virtual call mechanism, and
| import of foreign Go and Java modules.
|
| To get any of that, the project will need to excite people now in
| those environments with the prospect of easing their pain. Rust's
| advantage there is that their pain is great.
| farresito wrote:
| > Rust will never displace C++ or C. C++ does things Rust
| can't.
|
| Could you expand a little bit on that?
| stephc_int13 wrote:
| In the videogames world we - need very good performance - don't
| care about memory safety (not an issue) - also need fast compile
| time
| est31 wrote:
| It has improved a little a while ago with the stable profile
| overrides feature, allowing you to compile dependencies in
| release mode and your own logic in debug mode. Made work on my
| Rust written game much easier. But there's still ways to go.
| Ideally you have an engine and lua/scripting layer anyways.
| silverdrake11 wrote:
| You should care about memory safety in any language. The point
| is to reduce bugs and have more maintainable code, that doesn't
| introduce memory errors when something is changed. Or when
| making something concurrent.
|
| Now of course if you use a garbage collected language, then you
| aren't in control of memory, so it's less of an issue. But if
| you are using C++ for high performance applications such as
| gaming, then you are in control of it and need memory safety.
| muldvarp wrote:
| > In the videogames world we [...] don't care about memory
| safety (not an issue)
|
| Well, that's how you get remote code execution vulnerabilities
| in CS:GO [1]. If you're doing anything at all over the network
| you absolutely need to care about memory safety. This doesn't
| mean that you need to use Rust of course, but security is still
| an issue.
|
| [1] https://hackerone.com/reports/351014
| jay_kyburz wrote:
| Why don't we care about memory safety?
|
| We care about memory safety as much as any program. Engine code
| doesn't need fast compile times, scripts do, but they are
| scripts.
| sanderjd wrote:
| I see this claim a lot, but I don't remember the last time I
| played a game with no network access. If you're capable of
| opening ports to the mad world of the internet, I think memory
| safety is relevant. But I'd love to be educated on why this is
| wrong.
| csomar wrote:
| > Rust is a systems programming language.
|
| While Rust is a systems programming language, it has a very
| advanced Traits system. This makes it, in my opinion, more
| powerful than your average scripting language (Python,
| JavaScript, etc...) I have recently used Rust for something that
| I should have, normally, used JavaScript or Python for. Based on
| my experience, I probably gained in development time because I
| didn't do much debugging. Rust code _just_ works, it 's simply
| amazing.
|
| > Complexity
|
| One way to approach this, is to actually enjoy this complexity
| because there is _real_ theoretical computer science behind it.
| It 's not complexity for its own sake.
|
| > Compile Times
|
| This one is really annoying even with a powerful processor.
|
| > Maturity
|
| I'd argue that since many high profile companies like Facebook,
| Google and Microsoft used Rust to start new projects (like Libra,
| Fuchsia); Rust is stable enough to be used in a production
| capacity. You'll probably benefit more if the project is new and
| thus have less time dealing with C compatibility.
| jhoechtl wrote:
| Too complicated which means when your lead rust dev leaves good
| luck finding another one.
| mhh__ wrote:
| It definitely wouldn't be easy as finding your next web
| developer (or similar) but relatively niche languages (in my
| experience) tend to have some very clever people on their
| forums (or similar) so - especially for Rust which is a
| established language in my mind these days - you shouldn't have
| that much of a problem finding someone technically capable (HR
| notwithstanding)
| dodobirdlord wrote:
| If you run a Rust shop you need to invest in training and
| mentoring. It's probably not the right choice for a butts-in-
| seats feature factory.
| pizza234 wrote:
| If one chooses manual memory managment, the "complicatedness"
| (as you put it) is not a matter of the language, it's a matter
| of programming type.
|
| As other computer engineering concepts (e.g. referential
| integrity in database systems), the lack [of implementation] of
| a feature (e.g. foreign keys) doesn't make a system that needs
| that concept simple - it just shifts it to the application
| level.
| est31 wrote:
| As the article says, it's a chicken and egg problem. Small
| number of jobs, means small number of people who have had those
| jobs in the past and now have those 6 years of experience with
| Rust plus minimum 4 years of leadership experience. Means more
| deciders having the attitude you have instead of "let's go with
| Rust!".
___________________________________________________________________
(page generated 2020-09-20 23:00 UTC)