Another thought is the fact that no advanced civilisation has ever made it to earth is proof that any intelligent species is destined to destroy itself before it can evolve far enough to travel the stars.
Both outcomes are pretty bleak
311 karma · joined January 4, 2016
Another thought is the fact that no advanced civilisation has ever made it to earth is proof that any intelligent species is destined to destroy itself before it can evolve far enough to travel the stars.
Both outcomes are pretty bleak
Sometimes overhyped tech is just over hyped tech.
Conversely, you used to look at a line of OS code and knew how that translated to registers within a processor. Now i barely know which kubernetes cluster the code is currently deployed in
Great take. It feels like the path of least resistance peppered with obscene amounts of resume driven development.
Complexity in all the wrong places.
> On the other hand, you can easily have a programming career in .net alone. Its not going away the next 30 years.
Not to mention if a service offers an official client or SDK, C# is almost always on that list. That is awesome.
Pretty much answered their own question in sentence one.
In my opinion OP is delusional. I worked in .net for 13 years and was stoked to leave. The layers of indirection, obtuse abstraction and over application of design patterns in “idiomatic c#” is preposterous.
> He made sure that he boarded before the the passenger who had the boarding pass information that he stole; when the other passenger tried to board, the system suggested that this passenger had already boarded, though the gate agent assumed it was a glitch, so allowed that person to board
Modern day software engineers need to eat a huge slice of humble pie.
The trick is to make sure when you promise 5 9s to your customer that you build in the same bullshit clauses so you dont get left holding the bag.
Its gross
The original example was more “wrap a simple type in an object so it’s always validated when set” which looks beautiful when you don’t have the needed getters in the example nor show all the Get call sites opposed to the 1 or 2 New call sites. All in the name of “we don’t want to set the username without validation” but without private constructors Username{“invalid”} can be invoked, the validation circumvented and I’m not convinced the overhead we paid was worth it.
Yeah, thats what I figured. Im not sure if I want the tradeoff of calling .GetValue in multiple places just to save calling validate in maybe 2 or 3 places.
Not to mention I cant easily marshal/unmarshal into it and next week valid username is a username that doesnt already exist in the database.
Maybe this approach appeals to people and Im hesitant to say “that’s not how Go is supposed to be written” but for me this feels like “clever over clear”.