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

Rust – A hard decision pays off

pinecone.io

Post reply on HN
Print view View original

371–380 of 386 posts

Re: Rust – A hard decision pays off

#371

Post by stouset »

mxkopy wrote: post #369
stouset wrote: post #366

Earlier quoted context omitted.

> No, the culty feeling is this paragraph long explanation about how Rust is objectively good So to make sure I have this straight, based on your reply to the sub-thread, your objection is simply that I didn’t repeat the exact reasons why many believe Rust to be an improvement over languages that have come before it? That wasn’t even the damn point of my reply, which was that given the enthusiasm you perceive as cult…

There's enthusiasm, and then there's this > a lot of very experienced engineers encountering Rust, going "holy shit", and trying to preach about it from the rooftops Preaching is like a religious thing. Why are people getting religious over a programming language? People are obviously just making a living off of writing Rust and that's fine. I just find it so hilarious, dumbfounding and sad that people would stoop to…

> Preaching is like a religious thing. Why are people getting religious over a programming language?

My brother in christ it was a turn of phrase meant to be in the spirit of your original complaint.

You seem in need of an axe to grind (not an actual axe, this is another idiom). I’ll leave you to it.

Re: Rust – A hard decision pays off

#372

Post by catach »

benreesman wrote: post #26
bluejekyll wrote: post #18

Earlier quoted context omitted.

> But as someone who likes Rust and wants to like it more: don’t lead with that. The original title appears to be “Inside the Pinecone”, but seeing as they submitted it themselves I’m guessing they wanted the uptick on the Rust. The article itself doesn’t discuss their transition to Rust until the end. So I wouldn’t say they led with it originally, but perhaps didn’t get traction on the original title.

I guess I’m rooting for Rust in the long game sense, which is a different set of imperatives than the hang the hashtag on peripheral stuff sense. I use a lot of great software written in Rust, it’s demonstrably a good vehicle for great software. But too many of its fans are advocates , this can start to seem like an agenda. Don’t take engineering advice from people with an agenda.

Sometimes an agenda is as simple as "I really like this thing, and I think you'd like it too".

I believe this is off-putting primarily due to the mental antibodies people must develop in an advertising-saturated culture. The death of enthusiasm.

Re: Rust – A hard decision pays off

#373

Post by einpoklum »

throwaway2037 wrote: post #300
einpoklum wrote: post #282

Earlier quoted context omitted.

About no. 4: That often translates into noticing C++ has gotten `auto` in C++11 with a later improvement in C++14: auto x { get_something_complicated() }; or foo(int x) -> auto { return get_something_complicated(bar(x)); } so it's less "not-fun" these days.

I feel the same. Java and C# have an equivalent called 'var'. Unless the scope is tiny , I always avoid it. Also, in Java when you create a lambda, it is possible to exclude the parameter types. foo(x) -> get_something_complicated(bar(x)) It is not good for readability in large source bases.

With C++ lambdas, it's similar, but the syntax is a bit uglier:

  [](auto&& x) { return get_something_complicated(bar(x)); }
and you can decide whether you want a value (no &'s), an lvalue reference (&), or a forwarding reference (&&). I think with C++20 you can also use a concept instead of auto for a constrained parameter type.

Re: Rust – A hard decision pays off

#374

Post by lenkite »

benreesman wrote: post #81
throwaway894345 wrote: post #67

Earlier quoted context omitted.

I say this as someone who has had a lot of criticism for Rust: Rust definitely borrows a lot from other languages, but Rust deserves praise precisely because it curates the right features and composes them in the right way. There are way too many languages from the PLT space that add some neat type system innovation, but they fail on syntax or performance or tooling or etc. That's not particularly laudable IMO, but R…

Credit where credit is due: Rust has done a far better job than most of free-riding on Haskell’s type class system and clang’s optimizer, but rust-analyzer is a dumpster fire next to clangd, that’s not an example I’d use.

".. but rust-analyzer is a dumpster fire next to clangd.."

Sorry, but this is patently false and is just straight-up misinformation. rust-analyzer is an extraordinary piece of work with careful, well-thought out idiomatic software design, easy usage and relatively low productive defect count.

Rust, the language, itself might be rather over-hyped here on HN - its most loved status will drop significantly with larger real-world adoption. However, the rust-analyzer project isn't overhyped and is a clean and elegant product of software engineering. I wish I was good enough to design and code language software like this.

Re: Rust – A hard decision pays off

#375

Post by 4m1rk »

> we would discover issues only after deploying (or in production!) due to Python’s run time nature

I love Rust but seems like they just needed to write some test before shipping to prod?

> Built-in test, CI/CD

Does it have anything to do with the language?

Re: Rust – A hard decision pays off

#376

Post by throwaway894345 »

rob74 wrote: post #341
throwaway894345 wrote: post #228

Earlier quoted context omitted.

It probably is Go's propensity to return error values whereas Python would bubble them up. Every action in Docker involves an I/O error at a minimum (since you're talking to the Docker daemon) so this is basically a worst-case scenario for error handling boilerplate. I don't doubt that Python is better for scripting in this case, but if you want to make an application that interfaces with Docker, Go is probably the b…

Still, creating a method that calls several other methods one after another is programming 101, so I refuse to entertain the though that creating a "containers.run" method similar to the one from the Python API is not possible in Go. The error handling is definitely not the culprit, you can check the error after each "subcommand" and return early with this error. The question is just, why didn't they do it?

Fair enough. I didn't look deeply at the API differences.

Re: Rust – A hard decision pays off

#377

Post by nazka »

faitswulff wrote: post #318
nazka wrote: post #253

Earlier quoted context omitted.

I am curious which web framework do you use? Also do you use an ORM like diesel?

You could probably get a pretty good idea from reading the Discord engineering blog.

Yep. I checked his bio only after commenting.

Re: Rust – A hard decision pays off

#378

Post by benreesman »

benreesman wrote: post #100
mustache_kimono wrote: post #90

Earlier quoted context omitted.

Um what? Maybe it's just that I don't understand what clangd provides that's so great, but rust-analyzer, despite a few hiccups I've had with it, seems completely amazing at what it does.

Well we could start with the fact that it crashes process IDs more often than Justin Bieber crashes Maseratis: https://github.com/rust-lang/vscode-rust/issues/890 (it’s always LLVM’s fault, I know). Or move right along to the insane configuration hacks that are mandatory if you want anything upmarket of VSCode (who doesn’t need a little practice with their Emacs Lisp), or the N^2 whatever that happens when you point…

This thread is a bit stale but I try to check once or twice a week to tie off loose ends. I appreciate that probably no one will read this, but, you never know.

One of several issues around engaging with the Rust community at least as personified on HN is that it's very difficult to see any other outcome than being backed into a pretty extreme corner: I started my involvement with this thread saying that I like Rust and want to like it more, but found taking a piece of software that seems interesting on its own merits and headlining the Rust part (whether due to the original post authors or the submitters, makes no difference) contributes to a skepticism-inducing sense that there's an agenda other than "cool software" sitting close to "Rust" in the embedding space.

And, if you care to, you can watch me go from "Rust is cool, great stuff written in it" -> "hey some of these claims are seeming extravagant" -> "ok let's not get carried away, the cited examples are mostly Haskell semantics and clang optimization" -> "alright I'm calling bullshit that all the tooling is superior, that's fucking stupid" give or take. It's a pragmatic cool programming language that people write great software in. That's plenty, that's more than most languages ever achieve, and Rust is far from done achieving things.

`rust-analyzer --version` reports: "rust-analyzer 2022-04-11" on my primary Nix shell. `clangd --version` reports "clangd version 13.0.1" on the same env. I drive both of these things on the command line, in CI, and via `emacs` (on `eglot`) every month at a minimum, every week almost certainly, and usually every day.

I have seven nontrivial elisp `defun` and/or `defadvice` (deep into `rustic-mode`) stanzas for keeping `rust-analyzer` working ok. I have to defeat it's naive `Cargo.toml` search in interesting projects, I have to turn off big blocks of my buffer going RED ALERT RED while a brace remains missing which is statistically most of the time, and most importantly, I have to manually restart it with save excursion trickery so that I can survive a crash without blowing my session. Some of these defects may be as old as earlier this year when I last audited all that.

For `clangd` I have zero such nonsense. Which is completely understandable, it's an older and therefore more mature piece of software. That's not a knock on Rust or `rust-analyzer`.

But I made the fatal mistake of posting the wrong link to the issue tracker, for which my reward was to cause the "Flying Fucking HN Rust Brigade Gangbang Comment/Downvote Battalion" to put the Batman light on.

If you folks are comfortable being the "extremists people are too tired to fuck with", then do you. But I know for absolute certain that I am not the only person doing some level of Rust adoption in spite of this bullshit rather than because of it.

Re: Rust – A hard decision pays off

#379

Post by 0x457 »

Already__Taken wrote: post #304
0x457 wrote: post #261

Earlier quoted context omitted.

Iterator-chain version would be a lot better looking if it was actually was a chain and not everything pushed into a single `filter_map`. "Ifs" are weird looking, one branch is using `entry`(I take it's a `DirEntry`?) and another is using `file_name` I suspect both could use the and look like `Self::is_` ? If you're going to write an iterator chain in an imperative way, then you might as well right it imperatively. A…

Forgive me for asking instead of looking, I'm still getting into rust; why do you map instead of getting the result? path.extension().map(|ext| ext == "bundle").unwrap_or(false) vs (path.extension() == "bundle").unwrap_or(false) or further up .map(|e| e.map(|e| e.path())) vs .map(|e| e.path()) Is the .map keeping any value wrapped in an iterator so you can map again? I thought it was interesting what you wrote looks…

`extension()` gives you an `Option`, remember `Path` might not be a file or file could be without extension.

Why not `((path.extension() == Some("bundle"))`? I don't know, it didn't work, and I didn't want to spend too much time on it.

`read_dir` gives us an iterator over `Result`, so `e` in that map is a `Result` and not a `DirEntry`. It's two different "map" functions - on Option and Result it maps "T", but on Iterator it maps "Item" from that iterator.

Here is an explanation why `read_dir` give you a Result - https://doc.rust-lang.org/std/fs/fn.read_dir.html#errors

Re: Rust – A hard decision pays off

#380

Post by cztomsik »

andrewxdiamond wrote: post #295
s17n wrote: post #177

Earlier quoted context omitted.

The unique safety features of Rus are all about memory safety, which is not something you have to worry about at all in Python. I can only assume that the bug classes you are referring to would have been eliminated by using essentially any language with a type system.

> The unique safety features of Rus are all about memory safety, which is not something you have to worry about at all in Python Rust gets safety with its ownership system. The ownership system brings strong guarantees around who is mutating / reading any given object. Python has uncontrolled ownership. Any function can generally mutate / store any variable you pass in. This can definitely cause bugs if a rouge funct…

wrong, rust is about exclusive ptr access, nothing more. you cannot do ReadOnly in rust.
Post reply on HN