151–160 of 175 posts
"Note that nonbinary crates still obey the orphan rules." I find it slightly humorous that this sentence contains three words which would be understood completely differently by the majority of the English-speaking population.
Earlier quoted context omitted.
> Other than duck-typed languages (and I count Go as basically that), which languages actually provide this feature? There are only like 3 significant languages with trait-based generics, and both the other ones have some way of providing orphan instances (Haskell by requiring a flag, Scala by not having a coherence requirement at all and relying on you getting it right, which turns out to work out pretty well in pra…
Sure, the `chrono` library in Rust had essentially the same problem. Scala is interesting. How do they resolve conflicts?
If there are multiple possible instances you get a compilation error and have to specify one explicitly (which is always an option). So you do have the problem of upgrading a dependency and getting a compilation error for something that was previously fine, but it's not a big deal in practice - what I generally do is go back to the previous version and explicitly pass the instance that I was using, which is just an IDE key-combo, and then the upgrade will succeed. (After all, it's always possible to get a conflict because a library you use added a new method and the name conflicted with another library you were using - the way I see it this is essentially the same thing, just with the name being anonymous and the type being the part that matters)
You also theoretically have the much bigger problem of using two different hashing/sorting/etc. implementations with the same datastructure, which would be disastrous (although not an immediate memory corruption issue the way it could be in Rust). But in practice it's just not something I see happening, it would take a very contrived set of circumstances to encounter it.
From that link:
> We made these changes as part of our continuing effort to make Go a great language for building production systems. We studied many third-party web frameworks, extracted what we felt were the most used features, and integrated them into net/http. Then we validated our choices and improved our design by collaborating with the community in a GitHub discussion and a proposal issue. Adding these features to the standard library means one fewer dependency for many projects. But third-party web frameworks remain a fine choice for current users or programs with advanced routing needs.
I used Rust for ~14 months and released one profitable SaaS product built entirely in Rust (actix-web, sqlx, askama). I won't be using Rust moving forward. I do like the language but it's complicated (hard to hold in your head). I feel useless without the LSP and I don't like how taxing the compiler and LSP are on my system. It feels really wasteful to burn CPU and spin up fans every time I save a file. I find it har…
Earlier quoted context omitted.
I still use Eclipse CDT and its static analysis is running in real time, as you type code, which is killer. Combined with Valgrind integration, I don't see myself moving on anytime soon.
Is Eclipse CDT still good these days? Wow did not hear of it for a while. I thought C++ support was not maintained anymore. I use CLion mostly but I never stop coming back to Emacs+LSP. And yes, the analysis is quite competitive tbh. People often talk about this weird thing or the other in C++ but the experience is quite better than what the ISO standard strictly has to offer.
Eclipse is one of the rare software suites which didn't get slower as the tech evolves. Yes, it's probably heavier when compared to 20 years ago, but it starts pretty quickly and works snappily. I'm a happy camper.
If only the Go tools didn't get discontinued, but alas. KATE/BBEdit + Gopls is a pretty nifty combo on Linux/macOS.
It was always an agenda masquerading as a solution.
Earlier quoted context omitted.
bit_cast and reinterpret_cast do different things: one works at the value level, the second preserves address identity (and it is problematic from an aliasing point of view). Not sure what any of this has to do with initialization though. FWIW, the direct translation of your rust code is: constexpr char y = 2; constexpr bool x = std::bit_cast (y); It fails on clang for y=2 and works for y=1, exactly like rust; GCC pr…
Firstly, that's not a direct translation because you're making two variables and I made none at all. Rust's const is an actual constant, it's not an immutable variable. We have both, but they're different. The analogous Rust for your bit cast example would make two immutable variables that we promise have constant values, maybe: static y: u8 = 2; static x: bool = unsafe { core::mem::transmute(y) }; Of course this als…
I could have written it as x = bit_cast(char{2}), but does it really make a difference?
I don't know enough rust to know what's the difference between its const and c++ constexpr. It might not be a meaningful difference in C++.
> So this is an impedance mismatch, you've got Roman numerals and you can't see why metric units are a good idea, and I've got the positional notation and so it's obvious to me. I am not going to be able to explain why this is a good idea in your notation, the brilliance vanishes during translation.
There are plenty of rust users on HN that are capable of kind, constructive, and technically interesting conversations. Unfortunately there are a small few that will destroy any goodwill the rest of the community works hard to generate.
I’m not convinced that the problem is actually a problem. Suppose someone writes a type PairOfNumbers with a couple fields. The author did not define a serialization. You use it in another type and want it to serialize it as: { "a": 1, "b": 2 } I use it and want to serialize it as: [ 1, 2 ] What we’re doing is fine. You should get your serialization and I should get mine. But if either of us declares, process-wide, t…