Rust can be difficult to learn and frustrating, but it's also very exciting • Hacker News Board

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#131

Post by pjmlp » Tue, Oct 23, 2018, 5:54 AM UTC

solidsnack9000 wrote: post #121

bb88 wrote: post #73

Earlier quoted context omitted.

> I'm very bullish on Rust becoming the language of choice in the 2020s for everything from operating systems, web services, desktop applications, and more. It's that good. I don't mean to burst your bubble here. But people need to feel productive quickly with a language, otherwise they'll drop it and move to something else which makes them feel that way. Looking at this thread there are plenty of examples of "I love…

Despite Java's growth, C remains the language of choice for operating systems and C++ for web browsers, desktop applications, games and high performance web services. Rust is really only competing with C/C++, not JavaScript or even Java (or Go).

Some of those reasons are political, not technical.

Like C on embedded vs C++.

On Windows large majority of apps are in .NET with some C++.

On OS X and derived systems it is all about Objective-C and Swift for desktop apps. C++ is mostly used for drivers, LLVM tooling and Metal shaders.

Android is Java with some C++.

ChromeOS is all about JavaScript.

So no, C and C++ have lost the desktop, nowadays they are used for the graphics composition engine, while the remaining APIs are built on top of it with another set of languages.

If Rust is supposed to beat C and C++ on the desktop, it needs to be able to integrate into the IDE tooling alongside the mixed language tooling experience.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#132

Post by haileys » Tue, Oct 23, 2018, 5:56 AM UTC

coder543 wrote: post #94

charliesome wrote: post #77

Earlier quoted context omitted.

> and it's synchronous, so it's really slow. > it's asynchronous (so it's really fast) Whether something is 'synchronous' or 'asynchronous' has absolutely no bearing on performance.

I don't understand the point you're trying to make. In networked stuff, the (a)synchronicity absolutely does make something fast or slow. Suppose you have a synchronous web server with 4 threads, synchronous naturally means that each thread can only handle one request at a time. Each request can take dozens or hundreds of milliseconds to complete, just by being bottlenecked on latency. If it takes 100ms to complete e…

All network I/O is inherently asynchronous of course, so the sync vs async debate is more about whether to use the blocking abstraction the kernel provides versus bringing your own or writing async code directly.

Using async I/O or a userland abstraction like green threads necessarily means you're moving the I/O scheduling work into userland. Sometimes this might be the right call, but it's effectively a bet that your userland scheduler can do a better job than the kernel's own scheduler.

This bet might pay off in highly specialised cases where your userland scheduler is well tuned to your workload, but the majority of userland schedulers (to name a few examples: the Go runtime, node.js's libuv) are also aimed at general purpose workloads and in many cases are far less mature than the kernel's scheduler.

There's been a massive amount of engineering work that's gone into the Linux kernel's various scheduling algorithms over the years. Pathological edge cases resulting in starvation or other performance issues have largely been identified and worked out. The various schedulers are also highly tuneable to the specifics of your workload if you need to do that.

These days OS threads are a totally viable option for building highly concurrent network services on Linux. Spawning hundreds of thousands of threads works fine and is fast enough for most applications. While threads will have 8MB of virtual address space reserved for their stack by default, this is just 'on paper' memory use - no pages are actually allocated until you use them.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#133

Post by pjmlp » Tue, Oct 23, 2018, 6:05 AM UTC

ilovecaching wrote: post #109

xyzzy_plugh wrote: post #100

Earlier quoted context omitted.

> Many people believe that Go rose to popularity because of the authors and the company sponsoring it, not on its technical merits I don't believe this to be the popular opinion. Originally Google's involvement dissuaded me, and indeed the very Googly bits have been the worst (context.Context), but the rest of it is markedly un-google-like. It's much more of a Bell Labs feel, with a focus on tool efficiency and stabi…

> There were a lot of good ideas over the years (especially in Plan 9) and Go is really just a modern, polished revision of those ideas glued together. Plan 9 is an operating system. If you're referring to goroutines, CSP is completely unrelated to any of the work done at Bell Labs. That was Hoare. Go also kept a ton of terrible ideas, like nil, void (interface{}), and default mutability. > Go is a _systems_ language…

People are doing OS research in Go, and Fuchsia core components like the TCP/IP stack are written in it, regardless of what the HN crowd thinks where Go should be used.

https://github.com/mit-pdos/biscuit

https://github.com/ycoroneos/G.E.R.T

Last version of Plan 9 was actually Inferno, which HNers keep forgetting about, which used Limbo for userspace code.

Limbo uses the channel syntax later adopted by Go.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#134

Post by throwaway487548 » Tue, Oct 23, 2018, 6:07 AM UTC

It seems that the main problem with Rust is that it has been grown up not from the CS and PL theory fundamentals, like ML, or Scheme or Erlang or even Go, and it is obviously not a small, clean language everyone loves and appreciates as being beautiful. In other words it is just little better than C++, which is a crap.

If a language could be grown from ML (Ocaml) roots (like Scala) instead of C++, it could be much smaller, cleaner and more pleasant to work with. Rust's only innovation is in the compiler tech, which could be ported and simplified (due to more predictable semantics of a functional language) to any ML-family language.

I cannot overemphasize how beautiful the pattern-matching with local bindings on algebraic data-types is, and what a wonderful thing is Erlang's pattern-matching on receive, and how, say, protobuf is basically product/record-types annotations, which could be done in a ML-family language itself etc.

Rust is under the curse of C++ (a statically typed and standardized dialect of PHP3) if you wish. It is obviously good language compared to C++, but somehow Ruby-ish, compared to ML-family languages.

It is actually a pity that Rust and not ML/Ocaml are considered cool and sexy by modern teenagers (like it used to be with Ruby and with Rails not so long ago). ML is much better starting point than C++. Perhaps, polished to perfection languages (Scheme, Haskell) are less appealing for the crowd being too dry, without ambivalence.

BTW, the next cool language definitely should be something like typed Erlang with Ocaml's syntax ;) - a hybrid into which typed Python or Typescript are growing into.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#135

Post by thethirdone » Tue, Oct 23, 2018, 6:12 AM UTC

ilovecaching wrote: post #69

erwan wrote: post #67

I love Rust, but in all honesty I wouldn't use it vs. Golang or C++17 for something that isn't a critical system (e.g a cryptography lib) and even then I'm not sure I wouldn't use something like OCaml instead. The curve to productivity seem way too steep for the payoff.

Woah, woah, woah. First, Go and C++ are vastly different languages. Apples and oranges. C++ is huge . It takes an incredible amount of effort to become a proficient C++ developer, and even then, C++ offers none of the amazing safety guarantees that Rust's borrow checker enforces. It's old language with sedimentary layers, including C backwards compatibility. Rust is no where near as complex, and Rust does 5x more to…

> but it's performance is closer to Java, which is a few orders of magnitude slower than C++

A few order of magnitude is an exaggeration. A more reasonable expectation is a 5x slowdown [1]. Depending on your task, a few orders of magnitude can be correct for JVM based languages; they can have very poor startup times (compared to c++) [2]. However, in startup time, go is not similar to Java.

[1]:https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [2]:https://github.com/bdrung/startup-time

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#136

Post by rqs » Tue, Oct 23, 2018, 6:13 AM UTC

steveklabnik wrote: post #92

rqs wrote: post #78

Earlier quoted context omitted.

I think the learning curve thing is depends on what's the language that you are compare it with. C++ for example, is a hard language, but the learning curve is ... progressive (rise bit by bit). Rust on the other hand, is like climbing a cliff: You're exposed to everything as soon as you start learning. That's all the Rust things (memory safety model and borrow etc) plus the rest of the knowledge that you need to lea…

Traits for interop are a prime consideration for std, even if we try to keep it small. But we can only add things when they’re ready; that’s part of the stability you desire. Look at the Future trait, as an example. And rust has had the equivalent of io.{Reader, Writer} since 1.0.

I know. But for me personally, the `io::Reader` and `io::Writer` is still not comfortable enough. Mainly because it's return values, `io::Error` to be specific. Because I found that in many of my cases, predefined `io::ErrorKind` is not enough for me, this results my abuse of `io::ErrorKind::Other`.

In Go, `error` is an interface that can later be asserted, so I can return any `error` then deal with them as late as I need.

This gives me ability to write some complex `io.Reader` and `io.Writer`. For example, an `io.Reader` that can Decode data stream, and returns both CodecError and IoError when it encountered any.

In Rust, if I want to write a similar thing, a HPACK decoder that returns both `io::Error` and `HPACK::DecodeError` for example, I need come up with another `Result` type that wraps both errors. This can sometime be tiring and makes the code inflexible (As one simple change to the `Result` may effect the entire call chain up and down).

BUT ... Maybe it's Go's fault, it treats me too well, make me want something that I cannot have for free (performance cost) else where.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#137

Post by fiedzia » Tue, Oct 23, 2018, 6:13 AM UTC

mwcampbell wrote: post #84

Dowwie wrote: post #64

Earlier quoted context omitted.

It's web ready. It's very web ready.

IMO it's not really web ready until there's one web framework that has a clear majority of mindshare, like Rails for Ruby or Django for Python.

What's the point of this requirement? Python doesn't have "the one" either, does it mean its not web ready?

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#138

Post by __bjoernd » Tue, Oct 23, 2018, 6:15 AM UTC

pjmlp wrote: post #131

solidsnack9000 wrote: post #121

Earlier quoted context omitted.

Despite Java's growth, C remains the language of choice for operating systems and C++ for web browsers, desktop applications, games and high performance web services. Rust is really only competing with C/C++, not JavaScript or even Java (or Go).

Some of those reasons are political, not technical. Like C on embedded vs C++. On Windows large majority of apps are in .NET with some C++. On OS X and derived systems it is all about Objective-C and Swift for desktop apps. C++ is mostly used for drivers, LLVM tooling and Metal shaders. Android is Java with some C++. ChromeOS is all about JavaScript. So no, C and C++ have lost the desktop, nowadays they are used for…

C is not used in the embedded space for 'political' reasons but for the fact that in contrast to C++ you have full control over what your program does and don't have to worry about when certain functions get magically called and why the size of your two-int struct is suddenly way larger than the 64 bits you expected it to be.

Sure, this is all a matter of 'using it right', but from my experience many developers in the commercial embedded space are not programmers by trade and this learning those intricacies is a real hurdle for them.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#139

Post by coder543 » Tue, Oct 23, 2018, 6:16 AM UTC

haileys wrote: post #132

coder543 wrote: post #94

Earlier quoted context omitted.

I don't understand the point you're trying to make. In networked stuff, the (a)synchronicity absolutely does make something fast or slow. Suppose you have a synchronous web server with 4 threads, synchronous naturally means that each thread can only handle one request at a time. Each request can take dozens or hundreds of milliseconds to complete, just by being bottlenecked on latency. If it takes 100ms to complete e…

All network I/O is inherently asynchronous of course, so the sync vs async debate is more about whether to use the blocking abstraction the kernel provides versus bringing your own or writing async code directly. Using async I/O or a userland abstraction like green threads necessarily means you're moving the I/O scheduling work into userland. Sometimes this might be the right call, but it's effectively a bet that you…

> These days OS threads are a totally viable option for building highly concurrent network services on Linux. Spawning hundreds of thousands of threads works fine and is fast enough for most applications.

I don't agree. If you're at the point where you need to handle such large numbers of concurrent threads, my own experience and online benchmarks clearly show it is not fast enough. Why are none of the top performers on the TechEmpower benchmark using a thread per connection? The simplest answer is that that can't or they would, since it would be a waste of time to reimplement so much in userland.

More anecdotally, I have been unable to get my Fedora laptop to spawn more than a few tens of thousands of threads before the kernel tells everyone that "resource is temporarily unavailable" to any process that attempts to spawn a new thread or process until the offending process is stopped. I've googled the issue extensively, tweaked countless knobs, and come up empty handed. I'm certain the Linux kernel can spawn more threads than that, but my point still stands that it is nontrivial.

In theory, that's a great perspective you presented. However, the async interfaces into the kernel exist for very real reasons.

I would also challenge you (if you're bored) to write a C, C++, or Rust program that spawns 1 or 2 million threads that do nothing but sleep for a very long time, and write a similar program in Go. See how the two compare in how long it takes to launch all of the tasks, and see how much memory they use. Ideally, you would also use, say, Rust futures + tokio and spawn a million sleeping futures to compare there too, but futures and tokio aren't the most intuitive or well documented things yet, in my opinion.

I've done similar tests in the past, and OS threads are not a lightweight resource.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#140

Post by snrji » Tue, Oct 23, 2018, 6:20 AM UTC

I enjoy coding in Rust, and I think it's a step in the right direction, but I'm still looking for a general purpose programming language which model IO/State effects the same way languages supporting functional programming do with pure functions. Haskell monads are not granular enough. The closer thing I've seen is Purescript, but still is not general purpose enough. Solidity's "pure" annotations are a step in the right direction, but I'm speaking about something much expressive. Also, it should have a Rust/C-like syntax in order to be able to be mainstream, but I'm happy with Haskell-like syntaxes.