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

431–440 of 811 posts

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

#431

Post by nmca »

kaba0 wrote: post #414
rapsey wrote: post #135

Earlier quoted context omitted.

However the constant checking if something is on the stack or heap is a big performance problem for smallvec. It results in terrible cpu branch prediction.

I don't see how is it bad for branch prediction. Like, if you use the same smallvec object in a loop and do not insert any elements to it (so that it doesn't allocate on the heap) the branch will always turn in the same direction making it easy and cheap to predict. And I would think that in most use-cases your smallvec object will either remain in one state, not changing in-between.

+1, I would love to see a trace of smallvec killing performance due to branch prediction.

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

#432

Post by kaba0 »

javajosh wrote: post #55
azemetre wrote: post #43

Earlier quoted context omitted.

In your experience what languages would you say handle async well? Genuinely curious. I’ve only ever done JS professionally for a decade but started branching out into python, rust, and kotlin due to personal projects.

Interestingly, I've become a big fan of node's single-threaded "one big loop" model, which means multitasking is cooperative instead of preemptive. This strikes me as more honest, somehow. It doesn't distract you with abstractions (like threads) that don't make sense in this context. Most production workloads these days will be a docker process assigned to (at best) a single sticky core/thread on a blade somewhere -…

> Plus there is OpenJDK

I'm not sure what you mean here, but if you refer to OracleJDK here then there is basically only OpenJDK for quite some time now -- OracleJDK is just an (optionally) paid support version of the same codebase. Also, most other vendors are pretty much just tiny patched OpenJDKs also, with some niche exceptions.

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

#433

Post by jeroenhd »

eternalban wrote: post #94
jeroenhd wrote: post #53

Earlier quoted context omitted.

Rust isn't hard for the things you try to solve in Rust. The author compares Rust code with Go code. Those two languages serve entirely different purposes, with entirely different mechanisms behind it. Go does what the author does with ease because the runtime fixes all the complicated parts for you. You tell Go what you want and it'll try to solve all the memory management/threading/memory safety issues for you, usu…

> I think the difficulty in Rust lies in that it will enforce correctness. Competing languages are less strict about that, especially when it comes to threading. Enforcing correctness at compile time is not the only way to insure correctness. Some do enjoy solving language puzzles (so choose Rust) and some prefer thinking before coding and prefer solving design puzzles. I personally prefer that latter, as the 'hard'…

If you can solve all your problems by thinking before writing code then you will never see a compiler error, unless you see a compiler bug. If you're solving your problems beforehand by thinking about them but end up solving language puzzles, you clearly haven't thought enough.

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

#434

Post by avidphantasm »

roblabla wrote: post #333
wheelerof4te wrote: post #318

Earlier quoted context omitted.

This comment right here. For most people who program for a living, the hype over Rust means little. They need to use what is in the industry right now. Often, that is a tried and true language that is relatively easy to learn and use. Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast.

> Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast. This is so interesting to me. I'm a Rust programmer by trade (as in - I'm not a hobbyist, I actually write Rust for work). We've found that, while the feature work is a bit slower in Rust than in other languages the company used to use (mostly Python), they tend to requ…

I’m still learning Rust, but the idea of having to use unsafe features to implement something as simple as a linked list seems “wrong” to me. What am I missing?

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

#435

Post by kaba0 »

EugeneOZ wrote: post #416
kaba0 wrote: post #406

Earlier quoted context omitted.

Scala might just be that. It has a very strong type system which is quite similar to Rust's, lifetimes are managed by the JVM's state-of-the art GC, and all in all it is a very expressive language. Think of python-level expressivity, but all statically typed with type inference. It also has a similar stance on the functional-imperative question as Rust has - it prefers functional concepts but lets you write imperativ…

Does it have a borrow checker and mutability control?

It is a GCd language, a borrow checker is very seldom needed outside of that (and frankly, one should just use try-with and similar constructs for other kinds of resources), so why would it need one? As for mutability, it is not enforced on a language level (only shallowly), but the standard library, the language primitives and basically everything makes control over mutability very good. In practice it won't be much different than Rust with the interior mutability pattern.

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

#436

Post by esjeon »

Out-of-topic, but it's funny how some pro-Rust comments actually read like pro-Haskell comments. Haskell has more extensive and thorough typing than Rust, so anything good about `trait` is even better in Haskell. You just have to "unlearn" more to get used to pure functional programming.

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

#437

Post by FpUser »

kaba0 wrote: post #422
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 really don't believe that this high-level low-level language thing is true. Sure, both C++ and Rust are incredibly expressive and cool languages but they want to give control for low-level details, yet make it very easy to ignore these for the most part. But there will sure come a time when you will have to (may not happen at first write, but will definitely happen at refactor, adding a new feature, etc). Managed l…

>"Managed languages make such refactors trivial, while C++ and Rust (even with its very advanced type system) make these harder due to you having to rearchitect the whole program from a memory model perspective. Sure, it can be trivial in many cases, but not always."

This is not the function of the language but the ability of the developer to properly architect their code.

And tools like Visual C++ / CLion have very advanced refactoring features.

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

#438

Post by jeroenhd »

DeathArrow wrote: post #233
jeroenhd wrote: post #53

Earlier quoted context omitted.

Rust isn't hard for the things you try to solve in Rust. The author compares Rust code with Go code. Those two languages serve entirely different purposes, with entirely different mechanisms behind it. Go does what the author does with ease because the runtime fixes all the complicated parts for you. You tell Go what you want and it'll try to solve all the memory management/threading/memory safety issues for you, usu…

>I think comparisons between Rust and Go/C#/Java are what will really trip up a beginner. Rust has a lot of nice features found in higher level languages, but it's decidedly not a higher level language. Rust operates in the space of C and C++, where a small mistake can cause memory corruption no debugger will ever be able to unravel, but where a well placed byte of padding can accelerate a program by as much as 30 pe…

I don't know why you'd possibly want to use Rust for web programming, to be honest. When you add a full stack of databases and entities, Rust barely becomes faster than ASP.NET or Spring Boot. I messed with it for fun, but I don't think I'd pick Rust as a web server language any time soon.

The only reason I can think of is the WASM space, which Rust lends itself very well to, to reuse the same entities and data structures in the front end. Then again, you'll end up writing a terribly bloated web UI and other languages have similar bindings.

I think for new projects where C++ makes sense, Rust probably makes more sense. There are some edge cases (if you expect to be operating on trees in memory, for example, or if you're interfacing with libraries written in other languages) but I think Rust is generally better for such system tools. That assumes that you have in house Rust devs, of course; if you're a C++ shop, you'll have to teach everyone a new language before the switch makes sense.

The C(++) crowd is difficult to teach other languages because they, more than any dev group I've encountered, seem to have a larger amount of vocal people who think their code is perfect, they won't ever produce bugs, and all those compiler errors warning about failing edge cases are unnecessary because they know best.

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

#439

Post by nickduggets »

olalonde wrote: post #281
AndrewGaspar wrote: post #195

Earlier quoted context omitted.

> This is why I think we need a high-level, no-BS version of Rust. F# is probably what you're looking for if you want functional-lite programming with a strong type system, but don't want to deal with the pains caused by static resource management.

It might sound superficial but the simple fact that there is seemingly a hard dependency[0] on Visual Studio (Code) is a major turnoff for me. I am quite attached to my Vim/command line workflow. [0] https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/i...

That link includes documentation for building and running F# projects using only the .net core framework. Seems like the main set of headings is misleading, making it sound like you must install VS or (shudder) VSCode to get F# installed.

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

#440

Post by lenkite »

whazor wrote: post #386
HacklesRaised wrote: post #275

Is rusts most loved status simply Stockholm syndrome? I've really tried with rust, and we simply don't get on. I hear all the arguments about CVEs and wonder if rust will reduce the number of these problems simply by disabling the programmers that create them. I understand the draw, I want to love it, but i think I might not be smart enough.

Rust makes it easier and faster to create certain classes of applications, specifically applications that originally would be written in C and C++. Things that are hard in Rust, are even harder in C and C++. So Rust is liberating and 'rewriting' complicated applications can be satisfying because you can move faster. For me personally I am playing with Wayland and display streaming and it is very satisfactory so far t…

"Things that are hard in Rust, are even harder in C and C++."

Incorrect. This handler-dispatcher problem illustrated in the article is utterly trivial in C++ and many programming languages. No need to struggle and stretch your brain as if you are in the Math olympiad.

I am learning Rust myself and I think Rust fans are spreading misinformation and propaganda by saying Rust makes things easier than other languages. No, Rust makes things VERY difficult - and you need to study and learn the Rust way of doing things - which is significantly different from other programming languages.

We need a BIG design patterns for Rust book - which takes lots of common design problems and shows the idiomatic Rust way of doing it.

But just stating that C++ code for a given design problem is harder than Rust is utterly wrong and demonstrably false. Rust tooling is definitely simpler. Rust coding is definitely not.

Post reply on HN