Earlier quoted context omitted.
Elixir?
Not for system-level programming.
Well they want something GCd so it won’t be for systems programming anyways
Rust Is Hard, Or: The Misery of Mainstream Programming
491–500 of 811 posts
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#492Is 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.
I actually feel this way about C++ to some extent. I love that C++ has zero overhead abstractions. I hate that to use them requires programming in the most obtuse and indirect meta language. If you ever read, I think it was Modern C++? Where they point out the huge "trick" in C++ was someone figuring out you could make a compile time branch by declaring arrays of size 0 or some such nonsense. They then wrapped that f…
An application developer spending hours refining a method/class/function to it's most optimized form is usually not worth the time. It's only going to be used in the application so the ROI is much lower.
The author of a library with wide usage spending hours refining a method/class/function to it's most optimzied form may actually be worth the time because that effort is amortized over hundreds or even thousands of applications. The ROI is much higher in that case.
Determining when it's correct to make that tradeoff is an important part of the job. Boost probably makes the correct tradeoff. But your average C++ application dev might need to make a completely different one.
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#493Earlier quoted context omitted.
I think that's consistent with my line of thinking - if in 2015 some people tried it and decided that it's not for them, they drop off from the sample and % loved goes up in following years. Not claiming that this explains the entire increase in the percentage (I have no way of knowing) but I don't think this data contradicts my reasoning either.
How is it different than in case of every other language? Also, why not another newer language tops the list?
Rust is really hard. So while people that don’t like Javascript still continue to use it, but people that don’t like Rust are likely to drop it like a brick.
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#494Earlier quoted context omitted.
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. T…
If your primary criticism of golang is that its creator doesn't like syntax highlighting, then it must be doing pretty good.
As the sibling commentor said, syntax highlighting is only one example meant to illustrate Go's sometimes unnecessarily frustrating design. In case it wasn't clear, the example wasn't that Rob Pike doesn't like syntax highlighting. The example was that Go's playground doesn't have syntax highlighting (even as an option) for a reason as arbitrary as "because I said so".
That is why I find Rust and Go to be dissimilar. Rust is a language full of good ideas, almost all of which didn't originate in Rust. Go feels like it was designed with a very specific brief - "we want C but with GC and easy concurrency" - but whose designers otherwise had an NIH syndrome-like aversion to good ideas and common sense.
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#495Rust does not have to be this hard. Most of the pain here come from the unholy trifactor: combining async, lifetimes and dynamic dispatch with trait object closures; which is indeed very awkward in practice. Async support is incredibly half-baked. It was released as an MVP, but that MVP has not improved notably in almost three years. There are lots of ideas, some progress on the fundamental language features required…
> Async support is incredibly half-baked. It was released as an MVP, but that MVP has not improved notably in almost three years. As the primary mover of the MVP (who stopped working on Rust shortly after it was launched), I'm really sad to see this. I certainly didn't imagine that 3 years later, none of the next steps past the MVP would have even made it into nightly. I don't want to speculate as to why this is. I a…
> As the primary mover of the MVP (who stopped working on Rust shortly after it was launched)
At the risk of rehashing something that has already been discussed to death, did you stop working on Rust because of the difficulty of launching that MVP? I imagine that all of the arguments involved, particularly about things that are prone to bike-shedding like the await syntax, could be exhausting.
Any idea where we should send money to get things moving again? Lack of money is always the biggest problem in open source, right?
FWIW, I only started seriously using Rust in the past year. I quietly watched and waited while the async/await MVP was being developed. I didn't participate in any discussions. On the one hand, that means I didn't exacerbate any exhausting arguments. On the other hand, I wasn't actively supportive either.
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#496Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#497Is 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.
No, it's a selection effect. The stackoverflow most loved metric is people_who_want_to_keep_using_the_language / people_who_have_used_it_in_the_past_year Since Rust is so early in its adoption and there are few jobs, many of the responders are hobbyists who are into Rust, like it and want to keep using; not necessarily people who use it for work. And since you only take into account the people who have used it in the…
Its so hard for me to think someone actually thinks this.
Rust really is a great programming language that solves a lot of other problems other languages don't. It does so by introducing a pretty clever paradigm.
The rust community is the least toxic programming community I've ever seen. Leaps and bounds away from go lang, python, and light years away from c, etc.
Like use your head, is vba therefore the language which everyone tried and loved and had to move on from? You're trolling yourself lol. Rust is great but yes you have to learn it and yes that is tricky at first. Join a rust chatroom or discussion board and give it a whack.
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#498Another data point: After writing / (re)writing 20K+ lines of code as a CLI side project in Rust (without touching async), I think I can say it's the best language for me after 20+ years of experience in other languages. I like the compiler, and I learn a lot from clippy. The "hard" part about Rust is you have to "unlearn" some of the basic mechanisms like scope and ownership that you bring from other languages. It d…
I have found that as I gain experience with rust, I spend less and less time “upfront to compile and fix all warnings”. I think rust requires a different design philosophy. It just takes time to adopt it into your mind.
That's true for me as well, but I learned these after many failures. Now, I start by writing enums and structs for the problem, then iterate the design with functions and if it's really needed add these functions as impl of a certain struct/enum. This is the inverse of "Object-Oriented" design where one has to start from interfaces and manipulate data to satisfy the interfaces.
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#499While the article is an absolutely excellent analysis of Rust from the low, PL-level ergonomics point of view, it seems to largely miss (or, intentionally, skip) the bird's eye point of view of complexity inherent to software development. I was recently tasked with developing a fragment of a mobile app written in Objective-C++ (an awesome PL powerhorse, BTW) that mixed multi-threaded (multiple dynamic UI layers, mult…
I liked your thoughts but disagree with the conclusion.
It seems that serverless is cost prohibitive in many scenarios, and requires lots of optimization to be cost effective. So isn't it more of a fault of serverless than a strength of rust?
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#500Another data point: After writing / (re)writing 20K+ lines of code as a CLI side project in Rust (without touching async), I think I can say it's the best language for me after 20+ years of experience in other languages. I like the compiler, and I learn a lot from clippy. The "hard" part about Rust is you have to "unlearn" some of the basic mechanisms like scope and ownership that you bring from other languages. It d…
To be honest that doesn't seem too convincing for a new language. It actually reminds me of the early dogmatism of Java which today is often seen as too restrictive.
Rust makes an argument about safety but only for a select few types of errors and the cost seem rather high.