They’re too busy high-fiving and laughing like jackasses over their revenge porn fantasies coming true to notice.
For now at least.
There’s a lot more Cleetuses than Elons though. And Cleetus is the one who’s going to suffer.
729 karma · joined July 29, 2018
For now at least.
There’s a lot more Cleetuses than Elons though. And Cleetus is the one who’s going to suffer.
He repeatedly implies that these are fees that other countries will shoulder to “bring them into compliance.”
The truth is (as I’m sure you all know) these are fees that we pay to the federal government separately when we import goods from these countries. Other countries don’t pay a dime.
On top of that, supply chains don’t (or can’t) change at the drop of a hat. Large scale onshoring takes time and investment.
So the reality for the average American is that the crippling inflation we’ve endured for the last 3 years is not going away, and we’re going to pay an extra 25% on top of it for the vast majority of our imported goods (which is basically everything nowadays).
The thing I can’t figure out is if he really doesn’t know how tariffs work, or if he’s just a liar. Either way it doesn’t make him look good.
And from any reasonable analysis I’ve seen, I just don’t understand how this is going to bring anything back home. It’s just going to raise prices and cause more suffering for those who can least afford it.
But I think most people understand that it’s not actually about accomplishing any goal in particular or about solving any problem, it’s just a bro flex.
Awesome. Your guy can flex. Congratulations. All your shit just went up 25%, so now you’re paying too. Elections have consequences, as they like to say.
I'm not above being put in my place and being shown the light.
(And when I said OP, I did mean the parent poster)
You should also understand that the "you" in my comment you quoted is the colloquial you and not necessarily the parent poster.
So lay it on me.
Meanwhile, their entire training corpus was the result of scraping the intellectual property and copyrighted materials of THE ENTIRE PUBLIC INTERNET.
Woe is them to be sure.
If I have 500 functions, I don't want to extrapolate out the overhead of passing a state object around to all of them. That's a waste of effort, and frankly makes me think you want to code using an FP paradigm even in imperative languages.
Module-level and thread-level "globals" are fine. You gain nothing (other than some smug ivory tower sense of superiority) by making your functions pure and passing around a global state object to every single method invocation.
I haven't really seen the diamond problem referenced lately as an objection to inheritance, but I honestly never understood what the big deal was. In the event of a collision, the compiler can ask for further disambiguation, which does in fact boil down to an issue of syntax, not one of a soundness or correctness violation.
As I stated in my original post, the implementations of interfaces/composition that I have used (primarily C# and Rust) are stateless, so you must always re-implement. And honestly, if Rust were to say, allow the specification of struct members in trait definitions, one could argue that their structs are really sealed/final classes, just using different keywords.
I am genuinely curious, because I do believe that people have a valid point that composition does tend to lead to less object spaghetti than inheritance, even if I can't quite pinpoint why from a purely theoretical standpoint (my belief is that they're "holding it wrong").
You cannot eliminate complexity (although you can minimize it, to be clear). But for most things, you can shuffle the semantics around, you can paper over them in a new way, but at the end of the day, someone has to pay the piper.
In my experience, complexity eliminated from one spot will invariably bubble up somewhere else in an unexpected way.
It seems to me that a new generation of developers are simply rejecting oo-paradigms because they are oo, without an in-depth analysis.
I agree with the general consensus that oo inheritance hierarchies of the past became too deep and were overwhelming, but subtyping has a place.
Because interfaces are stateless, you generally cannot completely implement required interface functionality without wiring them up to each individual object, resulting in a lot of boilerplate code repetition.
This is exacerbated in GUI programming, for example, where subtyping makes a lot of sense (and doesn't devolve into Animal -> Rabbit nonsense).
With subtyping, you can take an object that is 95% of another object and just override where necessary.
I also don't believe composition provides the same level of encapsulation that can be achieved through traditional class-based oo. There seems to be this prevailing view that oo is all about inheritance, when the truth is that oo was really about encapsulation and isolation. You only expose what you need to, and objects (whether they be classes or structs or whatever) can be built and tested without fear of code collisions or meddling from the outside view.
I will concede that interfaces can and do provide a level of encapsulation, but in practice, it's just clunky.
Just look at some Rust objects and the sheer number of traits that they must be aware of and implement by hand. It's piecemeal when it could be one and done.
And please understand, I'm not talking about "...in the beginning there was a GObject, and that GObject bequeathed to...and..."
Thank goodness MS got over their allergy to open source licenses, as they seem to prefer MIT nowadays for their releases.
My apologies for misremembering the details and being snarky. Humble pie eaten and enjoyed. :)
So, as I stated, you would use the interface keyword.
public interface IFromString<T>
{
static abstract T FromString(string value);
}
public struct MyHasFromString : IFromString<MyHasFromString>
{
public string Text = "";
public MyHasFromString(string value)
{
Text = value;
}
public static MyHasFromString FromString(string value)
=> return new MyHasFromString(value);
public override string ToString() => Text;
}That being said, check out Avalonia: https://avaloniaui.net/ and https://github.com/AvaloniaUI/Avalonia
Cross-platform, open source, MVVM & reactive.
A breath of fresh air.
You just define the required methods and that's the interface.
I don't think my code was pretty and I know it wasn't idiomatic. But I have some experience in writing concurrent code, so I have an understanding of the reasoning behind Rust's borrowing semantics, why lifetimes are important, and the difference between boxed values, rc, arc, and I additionally understand the semantics of semaphores, mutexes, spinlocks, and critical sections.
(As an aside, I don't know if I'm an N+1 programmer. My code works, long term, requires very little maintenance, and generally stays out the way. Just the way I like it.)
But- I see these recurring themes in posts from Rustaceans along the lines of "the compiler tells you what's wrong" and "if it compiles, it's correct!"
These kinds of statements worry me. Not necessarily because I think their code is going to blow something up, but because I think a sizeable portion of the community does not really understand the guarantees Rust provides, and under what contexts they are valid. I mean, sure, you might not have a data race, but you sure as hell can code yourself into race condition or a deadlock, and from what I understand from HNers, these situations are not all that uncommon in Rust crates. I'm also led to believe that the panic handling situation in some crates isn't ideal.
You shouldn't just haphazardly Arc<Mutex<T>> all the things just because that gives you the Send + Sync that you think you're looking for (or the compiler is looking for). You should understand what the hell you're doing, be able to tell if those things are necessary, and understand the ramifications of using those abstractions.
I think there's a lot of good going on in the Rust ecosystem, and I wish I had more work in that area, but there's a lot of blind advocacy there that assumes the Rust approach is the best, but the language does have serious ergonomic limitations in certain low level scenarios. My whole career I've had to focus on scope and objects that outlive their scope, but now every other word I seem to hear from the Rust community is "Lifetimes" and "Ownership", like these concepts were completely unfamiliar to developers before and now the Rust Way(tm) is not only THE WAY, but THE ONLY RIGHT WAY.
I don't want to go too far off the rails, because I find the ecosystem intriguing, and I see tremendous value there. Whether those approaches stand the test of time isn't a given (although let's face it, they probably will because they are sound and they are gaining developer mindshare, which is the most important factor).
I just worry about ergonomics. Coding is not supposed to be easy, so please don't misunderstand- but coding, especially for those that do it day in and day out for decades, should not be a chore. There are definitely some QOL improvements that could be realized in the near term, although I'm not sure what those would look like.
I have to admit that I haven't done much with the interweb side. Truth be told, the few times I've used Asp.Net, I used KeyCloak as the authentication provider, and that's Java-based, lol.
That being said (and damn you for making me link to ms docs yet another time today), there is a built in provider, but my recollection is it did not support OAuth2 or JWT: https://learn.microsoft.com/en-us/aspnet/core/security/?view...
It may not suit your needs, but maybe that high-level doc can help you drill down quickly and not waste too much time on it.
I will say that I do always find it amazing how large sites can be sucessfully operated without too much fuss on the platform. Stack Overflow was notorious for being a very high traffic site that ran on a small cluster of machines and was all done in Asp.Net (might have been the old Windows framework, however).
I would like to add that I've been working with Entity Framework (EFCore) for the past year, and I've found it to provide velocity on that front. Never was a big ORM fan, but I can definitely see the use cases now.
As a big C# proponent, my gut tells me the JVM probably has the edge here, but it's not a clean sweep. The CLR has areas where it excels. I would also freely admit that the Java ecosystem is far larger and more mature. The NuGet ecosystem is no slouch, however.
But if I were a gambling man, I would bet that AOT compilation will become much more widespread in the .NET ecosystem while Oracle will ensure that you have to pay the piper for GraalVM to do anything interesting. Call it a hunch.
Some of the niceties over the last several versions include immutable record types, stack allocated structs (ref structs), lambdas (and a host of enhancements thereof since), async/await (of course), generic math ops, platform intrinsics, pattern matching, AOT, nullable types, robust generics, reflection, dynamic types, etc. The big thing I expect next is algebraic data types.
The language has really grown by leaps and bounds, but it doesn't ever feel overwhelming, and it has really kept its verbosity to a minimum without turning into a soup of hieroglyphics.
That being said, I have found the Android/iOS solutions to be underwhelming. I understand the iOS side a bit, but I thought Android would be better. That's not to say you can't make great applications using C# on these platforms, just that it requires more effort.
I'm also not a huge fan of ASP.Net. I've never really cared for it, and I think that stems from a project I had early in my career duct-taping together another developer's classic ASP applicat^HHH monstrosity and mucking about with IIS and FoxPro (!!). I know it's not classic ASP, but once bitten, lol. I will say that it is modern and performant, but very rigid. I'd defer to others' opinions here because I have mostly avoided it.
But in general, the tooling is great, and I don't encounter much that ties you to a Windows box anymore. I know there are some differences in platform support, but most of the rough edges were handled in the early days of .NET Core 2 & 3. Now that we're way past that (the "traditional" .NET merged with .NET Core in a combined version 5 release). Now that it's on version 9, the language features and low-level hits keep coming. I can, today, write code that is 99% of what you can get from C++ (and in some edge cases can exceed it), compiled to native code, that will run on Windows & Linux (x64 & arm64), BSD & MacOS without too much trouble.
And as a fellow HNer pointed out the other day on an unrelated thread, the native interop is painless. You can load .dll, .so, .dylib files with ease. No frankenstein FFI (ala Go or Java).
The language is safe. GC can be avoided (or controlled), and it offers raw pointers, manual memory manipulation with spans, and more low-level features through the unsafe subset of functions.
I know people like to say this started as a rip-off of Java, and there is some truth to that, but I have too much respect for Anders to believe he set out to rip off Java part and parcel. There was a method to his madness, and from my perspective, C# has always been a step ahead in programmer ergonomics (but definitely not performance). Maybe that's due to the sheer intertia of the Java ecosystem, or to Sun and then Oracle being more conservative, I don't know. Hell, it probably had more to do with Microsoft's reputation.
I value programmer ergonomics and tooling, almost above all else, and I am a happy camper. You can write C# from several different angles as you see fit, and in most cases it checks all the boxes for a large subset of projects.
Too general, too much trivia without explaining the underlying concepts. Questionable recommendations (without covering potential pitfalls).
I have to say that the discourse here is refreshing. I got a headache reading the 190+ comments on the /r/prog post of this article. They are a lively bunch though.
But honestly, in all my years, Visual Studio has been (by far) the best non-commercial (or should I say built-in?) debugger that I've used, and that includes gdb.
I am not a huge c++ on Windows guy though, so YMMV.
Here are a few guides that you may find helpful (and I am also going to include the beginner one, but please do not take that as an indictment of your skill level, I am including only for completeness).
These are all for VS2022:
C++ Debugging Tutorial: https://learn.microsoft.com/en-us/visualstudio/debugger/gett...
C++ Breakpoint Debugging: https://learn.microsoft.com/en-us/visualstudio/debugger/usin...
Breakpoint/Watch Expressions (pay attention to the debugger intrinsics): https://learn.microsoft.com/en-us/visualstudio/debugger/expr...
High Level Debugger Tour: https://learn.microsoft.com/en-us/visualstudio/debugger/debu...
VS2022 Debugging TOC: https://learn.microsoft.com/en-us/visualstudio/debugger/?vie...
My apologies if you've already found these references and they don't do you any good, but your issues just don't sound like the types of issues I've ever experienced with the debugger, and sometimes MS' documentation is just disorganized and incomplete.
But I keep at it, and I do keep learning. I am striving for better literacy (i.e. being able to read papers).
The advice I've been given, and it is helping, is to be persistent and to actually do the work. Only through doing will you start to see everything take shape. You will start to notice the way problem sets are laid out and build up your foundation.
It's like the Karate Kid. Wax on, wax off. Paint the fence. You can't just read the material and hope to keep your understanding. You have to burn it into your memory through practice.
The ecosystem has been MIT since 2016, and the last few releases have been solidifying the AOT proposition.
It just has so many features that allow it to compete with C/C++ on the low level, but it also provides exceptional high level niceties (which admittedly can be slow, some LINQ for example).
I know it's not fashionable, especially in a Linux-centric world, but I have used it extensively for many years (on essentially every platform), and it's lightweight (in most instances) and has the features and tooling to make development less stressful.
Every time I use Java, it just feels overwhelming and slow.
There are times I want a scratch file to stick around without saving it to disk (I know it's still saved to disk somewhere, but that's not the point).
The answer is to close the file you don't want to stick around.