[deleted]
Rust – A hard decision pays off
361–370 of 386 posts
Re: Rust – A hard decision pays off
#362Earlier quoted context omitted.
Source? I thought .NET GC was tuned for high throughput. Their performance is, impressive, to say the least. https://www.techempower.com/benchmarks/#section=data-r21
It has terrible latency characteristics
IIRC it also doesn’t do much/any escape analysis, so ~everything ends up on the heap as an individual allocation (except for values), putting even more pressure on GC.
Re: Rust – A hard decision pays off
#363Earlier quoted context omitted.
> I can't explain it, but I find the language infuriating. It somehow manages to be less expressive, more verbose and more straight up boring than all the other options. I don't hate it like you, I just find it amazingly backwards, and I think I can explain why: The community has the same persistence as certain teachers when it comes to locking things down and making things harder than necessary for no good reason, a…
Yeah, honestly I would respect them more if they never added generics. Still wouldn't use it. I haven't tried go-with-generics but I can't imagine it can be a good addition so late in the game.
Was absolutely a brilliant addition to Java.
I haven't used Go for years but it was sorely lacking last time.
Are you sure you aren't suffering from the Stockholm Syndrome?
Re: Rust – A hard decision pays off
#364Earlier quoted context omitted.
That doesn't look too bad on a quick glance, but the possibility to say that "this content goes in that template" still seems to be missing. Look at this page: https://quarkus.io/guides/qute-reference and read about “Template inheritance” in 3.5.6 to see what I mean.
In this example, I'm passing an object with a single value into the header template, but it could have as many values in it as needed: https://go.dev/play/p/kC8pm4Z4WrH Go doesn't really do template inheritance in the way I think you're meaning. Go prefers composition over inheritance, and that carries over to the templating system. Go templates let you pass a parameter to the template you're calling, which I believe…
> people often start mixing complex logic into the templates, including database calls
Sometimes you can solve social problems with technical interventions, but at this point, someone needs to sit down and talk :-)
> Go encourages you to compute your data ahead of time, then pass it into the template
Same elsewhere including modern PHP and Java.
The thing that is missing in Go is a natural way to group together what goes around the content.
Sure, stringing together the templates (yes, I know the other template can act on input provided by the calling template, but they are still stringed together) feels weird when what one really wants is to fill in slots in a design, which is my thought process.
Re: Rust – A hard decision pays off
#365Earlier quoted context omitted.
While the big one for rust borrowing system is memory bugs it als make it extremely specific what can be mutated. And there can only be a single mutator at any time. Unless you explicitly write something to work for multiple mutators. This makes many logic bugs much more obvious even though you could still make them. And of course you don't have nullability which is another big one.
Due to the pain that concurrency is in Python, the codebases I've seen mostly shared data only via external processes (queues, databases). I was very surprised to read the article. I think in the code I have in mind the borrow checker would only add overhead. The most frequent errors I see in the Python webapp code are: 1. logic errors, especially around concurrent DB transactions, 2. type errors (missing values, imp…
Well the article is about writing a database, which is definitely going to need concurrency and communication via shared memory to deliver the performance that it needs to (which is why the original implementation was mostly C++ and the new one is Rust). But yeah, I think in general if you're running into issues with mutability in Python, you're either using Python for something it should not be used for, or you're just programming in a really weird way.
Re: Rust – A hard decision pays off
#366Earlier quoted context omitted.
IMO that "culty feeling" you're getting is the end result of a lot of very experienced engineers encountering Rust, going "holy shit", and trying to preach about it from the rooftops because it feels so much better than the things that have come before it. I find this particularly compelling because Rust generally does not market itself towards novice developers. At least until very recently, I've seen Rust communiti…
No, the culty feeling is this paragraph long explanation about how Rust is objectively good, paired with the downvotes I got from saying I feel like Rust is culty. Pretty sure most experienced devs will say "use whatever works, there's some art out there written in erlang/JS/C++" Case in point I think the most valid critique is that Rust is new and lacks a developed ecosystem. As an ML person myself it's not even use…
> 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 cultish behavior, here’s my take on the underlying reason.
Something tells me you’d have been even less happy had I launched into a lengthy breakdown of all the comparative advantages. It’s a no-win situation you’ve constructed. Congratulations, I guess?
> Pretty sure most experienced devs will say "use whatever works, there's some art out there written in erlang/JS/C++"
There’s art in Ruby and I love the language but it’s a terrible choice for long-term projects that grow to large team sizes. A language doesn’t have to completely replace all others to warrant enthusiasm. It doesn’t have to be better along every possible axis to warrant enthusiasm.
> Case in point I think the most valid critique is that Rust is new and lacks a developed ecosystem.
Ah yes, the favorite criticism of bitter and cynical engineers, right up to the moment they switch to “it’s old and crufty and the industry has moved on”. Oddly, none of these critiques ever seem to apply to the languages of one’s own choosing…
> As an ML person myself it's not even useful for me to learn Rust unless I want to roll alot of my own stuff.
Nobody anywhere is arguing any language is the best choice for all use-cases. Nobody anywhere is arguing for ML people to rewrite-it-in-rust. These are straw men of your own making.
> Also, fucking lmao, get over yourself, Rust isn't that hard to learn
More straw men! I literally never said this. Only that the community has made few if any attempts to promote it to complete novices, thus skewing the experience level of those who you do see promoting it (compared to popular languages that do promote themselves to novices).
I don’t think Rust is hard to learn, but I do think Rust’s ownership model is hard to truly appreciate if you haven’t spent at least some time in the trenches of languages with manually-managed memory.
Re: Rust – A hard decision pays off
#367Earlier quoted context omitted.
Agreed 100%. Go doesn't have a standard library problem, it has a userland language problem. * No sum types / algebraic data types in 2022. * No exhaustive pattern matching in 2022 * No move semantics / Uses GC * No borrow checker * Still suffers from nil problem / No type-safe nil / No type-safe Optionals in 2022 -- (I can show you all the nil panics in kubernetes logs if you like) Current go users are already sold…
And yet Go has delivered very useful software used by millions of people.
So has C, and most other popular languages. Doesn't mean they don't have issues, often dangerous issues.
Re: Rust – A hard decision pays off
#368;lkj
Re: Rust – A hard decision pays off
#369Earlier quoted context omitted.
No, the culty feeling is this paragraph long explanation about how Rust is objectively good, paired with the downvotes I got from saying I feel like Rust is culty. Pretty sure most experienced devs will say "use whatever works, there's some art out there written in erlang/JS/C++" Case in point I think the most valid critique is that Rust is new and lacks a developed ecosystem. As an ML person myself it's not even use…
> 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 such levels of dick-suckery over a programming language. Like, you all know it's going to replaced by Malbolge in 15 years, right?
Re: Rust – A hard decision pays off
#370Earlier quoted context omitted.
> 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. Rust has a very expressive type system[0], which you won't otherwise find before hitting the more functional and research-y side of things. Modelling data in terms of enums (sum types), move types (affine types), etc... makes it a lot more reliable and a lot less faillible as…
Other than Rust the only other "pragmatic" language I can think of that has as much of a robust type system is Typescript. As you say anything else you'd have a hard time convincing the rest of your team to use.
I now introduce you to Haskell. Welcome to the dark side.