HN user
If the compiler can prove there isn't action-at-a-distance between those lines (this might be non-trivial), then can't the destructor be called before running bar ? Does the C++ spec necessarily say that destructors are called at the end of the block, compared to, let's say, as soon as the variable is no longer used?
For the experts in this thread: is there any benefit to using these so called array languages compared to using something like numpy (or even pandas/polars) ?
renders fine on my 4y old android phone
why didn't you just get Amazon to refund you for the defective product?
mostly yes, at $work we're trying to move away from pandas entirely in favour of polars. Polars is mostly faster, with an API that's actually sane and makes sense. No reason to use pandas nowadays.
hindsight is 20/20.
Don't criticise people for making certain decisions years ago when those don't match what you'd choose to do now. Often you'll find that they were very reasonable given the constraints at the time.
Also the spec will have evolved over time with changes that would have been made under constraint of the existing system, which tends to produce things that are not as nice compared to something that was designed from the get-go to support the features. This is something that's seen very often in software engineering, and are probably partly a reason why long-lived codebases tend to be dumpster fires in general.
Calling them 'very biased and not very smart' is not very constructive.
That's not to say that the wheel format isn't a dumpster fire (I'll have to take your word on that), or hasn't morphed into one with time & revisions.
I would expect most people to read code in their IDEs, where small amounts of type inference like this is fine because the IDE tells you what the type is.
I agree that if you spend a lot of time reading code in something like GitHub, not having explicit types is annoying, but seriously, who does that?
I also believe that an IDE like Rider will complain that the IEnumerable returned by `.Select` is consumed multiple times.
if you have a reasonably good IDE you don't really need to explicitly compile the whole program outside of when you want to run it.
at work we use the ONNX serialisation format for all of our prod models. Those get loaded by the ONNX runtime for inference. works great.
perhaps it's be viable to add support for the ONNX format even for use cases like model checkpointing during training, etc ?
also means no autocomplete with the from bit first
we have a massive mixed c# and f# codebase at work.
F# is not magical. Yes it's an ML, but frankly, C# is better in every way, to the point we're slowly moving away from F# entirely.
The main reason is perf, it's really easy to shoot yourself in the foot with performance in c# (e.g. huge allocations, accidentally evaluating seqs twice, etc). Also IDE support for F# sucks when you get to the hundreds of project solutions like we have.
For side projects, sure use F#. For everything else, stick with C#.
Yeap, it's used as a case study for us as to the worst case scenario in trading incidents. Definitely humbling.
spamming the market with orders for one
well you expect 'input' to be something that you can iterate over, so clearly using any is wrong here.
bad food is better than no food.
Such a great show. I was so sad when I realised it stopped at season 2.
Surely these were never enforceable, but I guess people don't know better. Reducing the asymmetry of knowledge is also key here.
To be fair, pay is irrelevant in this context. Abusive non-competes should be banned, whether in the state's or elsewhere.
I obviously don't support Brexit.
but it's hard to believe your wild claims without some concrete sources.
As per usual: Never ascribe to malice that which is adequately explained by incompetence
He's 33 and doing internships? what am I missing?
or just units of measure a more general solution than what you're suggesting, implemented by languages like F#
https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
C# is great, if you ignore the lack of algebraic data types and the generally weak type system. Value types in C# are awesome and really make it easy to write super high performance code that doesn't allocate!
F# is awesome if you ignore the fact that it's so easy to shoot yourself in the foot from a performance standpoint with all the lazy constructs. It sure is awesome though to have such a strict type system, though I do sometimes miss features that Typescript has, such as structural typing and mapped types.
In general I do thing the dotnet ecosystem offers a really good set of compromises.
Doesn't matter. Pick one. Enforce it with a linter. Move on with your life.
In production code, you'd generally avoid recursion to avoid stack overflows.
Given in most languages you can't enforce tail call optimisation, it's risky to use unbounded recursion.
Yeah some stuff hasn't been migrated yet but it's pretty rare in my limited experience.
Regarding your devil's advocate example, it's obvious a power user (i.e. tax pro) will have different needs than a layman like me, and it's clear that the sites are built for the latter, which makes way more sense as that's like 99.999% of the users anyways. The power users are probably so rare that just forcing them to phone in makes sense.
I'm consistently really impressed with the UK gov's websites. They're fast, usable and mostly quite intuitive, something that is helped by the fact that they all share a common theme. They support pretty much everything you'd want to do from an admin perspective.
This contrasts greatly with US and French government websites I've had the displeasure of using in the past.
You must be trolling. European countries are considered the most free in the world.
https://freedomhouse.org/countries/freedom-world/scores?sort...
The quality of the generated JS is a bit irrelevant as they'll probably want to minify the generated JS to reduce the size of the assets and make cold starts quicker anyways.
coeheranch is certainly an interesting way of spelling coherence.
And generally if you have to scale you have money and money can make any system work
That's the thing, this is not always true. It's true that generally you can throw money and hardware at a problem, but at some point you just reach the fundamental limit of the technology, at which point throwing money at the problem doesn't work.
In fact, being in a position where you can throw money at the problem is _brilliant_, as spending money is easy. So the point of _scalable_ technologies is to enable you to scale just by throwing money at the problem.
Case in point, at my old company we had this _massive_ Pg database running in RDS. It did not scale. Performance was terrible, and made the user experience shit. We were basically using the biggest instance size we could, with a few replicas powering read only endpoints. So at some point we migrated parts of it to Dynamo, and poof all of our problems went away, including operational ones.