Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust Is Hard, Or: The Misery of Mainstream Programming

hirrolot.github.io

Post reply on HN
Print view View original

101–110 of 811 posts

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#101

Post by rfiat »

0des wrote: post #23
adeon wrote: post #10

I wish there was a Rust-like programming language that was just a little bit higher level than Rust. I like Rust's wide ecosystem with high quality packages, the nice type system, traits, the idea that my code generally runs pretty fast even if I'm being lazy about writing good code, and my code usually working correctly if it compiles. I care about speed and correctness but Rust makes me also care about ownership an…

Go and Hare are rust-adjacent with just a touch of crayon involved. I highly recommend both especially Go since you mention rust with GC

It's interesting that you find Go to be Rust-adjacent. Setting aside the USPs of each language (goroutines and borrow checker respectively) and just speaking about the general experience of writing code, I find Go painful for all the reasons that I find Rust pleasant.

The best summary I can give of Rust is that it was designed by people who learned from the mistakes of the programming languages that came before it.

The best summary I can give of Go is to quote Rob Pike's response [0] to a request for syntax highlighting in the Go playground:

> Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods (http://en.wikipedia.org/wiki/Cuisenaire_rods). I grew up and today I use monochromatic numerals.

[0] https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3B...

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#102

Post by tialaramex »

megous wrote: post #79
nyanpasu64 wrote: post #52

Earlier quoted context omitted.

Rust marks cross-thread shared memory as immutable in the general case, and allows you to define your own shared mutability constructs out of primitives like mutexes, atomics, and UnsafeCell. As a result you don't get rope to hang yourself with by default , but atomic orderings are more than enough rope to devise incorrect synchronizations ( especially with more than 2 threads or memory locations). To quote an earlie…

Re: fearless concurrency... Would Rust prevent you in general from writing code that could deadlock, btw? Thread1: takes lock A, ..., tries to take lock B Thread2: takes lock B, ..., tries to take lock A Looks like you should be able to pass Mutex and Mutex to both threads otherwise what's the point of mutex if there's no way to share data protected by it, so it doesn't look like it prevents you from hitting this sce…

No, Rust doesn't prevent deadlocks, a deadlock is safe (it isn't what you wanted, but it's safe). There are well-known strategies to avoid deadlock (in any language)

In the trivial example you gave, one strategy just insists we take locks in alphabetical order. Thread 2 can't take lock A, because it already has lock B and that's not the correct order.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#103

Post by beltsazar »

nullcipher wrote: post #7

Unpopular opinion: I find rust code unreadable. And I consider myself a polyglot. I am sure all those symbols have a special meaning but it's like perl to me. Just throw some random special characters and they all mean something.

My only gripe of Rust's syntax is the lifetime annotation, but I can't suggest any better alternative, either.

> And I consider myself a polyglot.

Then you should realize that Rust borrows some of its syntax from other languages:

- Function's parameter and return types are borrowed from Python's type annotations.

- Turbofish syntax is from C++.

- Closure syntax follows Ruby's.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#104

Post by syntheweave »

adeon wrote: post #10

I wish there was a Rust-like programming language that was just a little bit higher level than Rust. I like Rust's wide ecosystem with high quality packages, the nice type system, traits, the idea that my code generally runs pretty fast even if I'm being lazy about writing good code, and my code usually working correctly if it compiles. I care about speed and correctness but Rust makes me also care about ownership an…

In addition to the Ocaml recommendations I suggest Haxe, which is basically "Ocaml concepts transposed into a compiler targeting various GC runtimes". (Compiler is also written in Ocaml - it's not kidding around) Easy to pick up if you already know JS syntax, and basically covers the "best-of" of static inferred type systems, but you can easily break out of it if you need dynamic or low-level behavior.

Downside is that it's not convenient if you just want one standard library and runtime because it targets all of them. You have to justify the trade-offs involved in that, but it's a good secret weapon.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#106

Post by FpUser »

cmrdporcupine wrote: post #91
FpUser wrote: post #86

Earlier quoted context omitted.

>"I don't understand why so many people lately seem to want to use Rust for web domain stuff." >"Rust is the new C++. Let's just stick with that." I write "web domain stuff" in C++ and it is incredibly easy (well for me at least). In C++ I could always use my own styles / paradigms / patterns etc. etc. Not forced to any particular way. And modern C++ is incredibly safe if one wishes. So if it is bad idea to write "we…

I wrote plenty of vaguely web stuff in C++ at Google. A lot of services at Google are C++. But it's kind of, not how the rest of the industry expects things. And most of that stuff there is now moving to Go.

>"not how the rest of the industry expects things"

I run my own company, prefer to count money and Have no shortage of work - so could not care less about what "the rest of the industry thinks".

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#107

Post by Klonoar »

cmrdporcupine wrote: post #66
Animats wrote: post #21

Earlier quoted context omitted.

> If you can avoid async I would recommend doing so. The problem is that the entire ecosystem has completely shifted to async. There are almost no active / popular libraries related to network IO that haven't switched over. Yes. I've been complaining about async contamination for some time. I'm writing heavily threaded code, with threads running at different priorities, and libraries which want async get in the way.…

I agree, I don't understand why so many people lately seem to want to use Rust for web domain stuff. I don't like Go, I hated the year I had to work in it @ Google. But frankly, it's better suited for 'server' type stuff, unless you're talking about a very specific type of server that has super intense latency guarantees. And now that Go has generics, I'd probably hate it less. Go is the new Java. Rust is the new C++…

I do it first and foremost because I dislike the error checking story in Go, and writing Rust for web stuff doesn't really feel too dissimilar to hacking on web frameworks of years past. In fact, I'd argue that web domain stuff is where Rust is relatively mature.

But this all said, there's definitely a point to be made here - Go works fine for so many use-cases, people should use it if they like it or it fits the story better. The idea of "one true language" has never worked out.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#108

Post by crabbygrabby »

jerf wrote: post #87
crabbygrabby wrote: post #76

Earlier quoted context omitted.

Why? Because it's stupid fast, fast means serving an order of magnitude or more clients before requiring scale up. Scale up means $. No stop the world GC time situations, etc. That's basically it. To be fair, I usually prefer to use go as well, lately though rust is more appealing.

Rust does not in general have an order of magnitude advantage over Go. 2 or 3 would be closer, and that's with some nontrivial attention paid to optimization, not "you write Rust and it's automatically always faster". Super high-end stuff can outclass Go by that much, like if you're seriously using DPDK or something, and in those cases I strongly recommend Rust over Go. There some other noches like that. But in gener…

It really depends. I agree it's not always an entire order of magnitude didn't mean to paint that picture for passerbys who don't know better. Not trying to touch the "this lang vs that lang performance" conversation with a ten foot pole...

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#109

Post by pclmulqdq »

jerf wrote: post #87
crabbygrabby wrote: post #76

Earlier quoted context omitted.

Why? Because it's stupid fast, fast means serving an order of magnitude or more clients before requiring scale up. Scale up means $. No stop the world GC time situations, etc. That's basically it. To be fair, I usually prefer to use go as well, lately though rust is more appealing.

Rust does not in general have an order of magnitude advantage over Go. 2 or 3 would be closer, and that's with some nontrivial attention paid to optimization, not "you write Rust and it's automatically always faster". Super high-end stuff can outclass Go by that much, like if you're seriously using DPDK or something, and in those cases I strongly recommend Rust over Go. There some other noches like that. But in gener…

I would not suggest using DPDK with Rust, unless you want to write a lot of stuff for yourself and wrangle with some tricky `unsafe` code. Sticking to C or C++ will make your life a lot easier.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#110

Post by mikebenfield »

999900000999 wrote: post #62

The syntax is just hard. I tell new programmers to start with either Python or JavaScript. The pay is the same or better, and it's much easier. I've been programing for almost a decade, I still can't understand lower level languages like Rust and C++. Why, if you can design a new language, not make something with the simplicity of Python ? If your going to compile the binary anyway, have the complier figure out the t…

Python can be simple, to the degree it is simple, because it makes so many of your decisions for you.

In Rust the design space is very large. For instance, if your new type is going to refer to some data, should it own the data, should the data be on the heap (in a box), should it carry a safe reference (if so, mutable or not?), should the data be reference counted, or possibly atomic reference counted, or maybe for some reason you need to keep an unsafe raw pointer to the data?

In Python this is simple because the decision is already made for you: your new type keeps (essentially) a reference counted ref to the data it needs. That’s it. That’s all you can do.

That’s great if that decision is always adequate for your application. If you need extra flexibility you’ve got a problem.

Post reply on HN