Hacker News new | ask | show | jobs
by Narhem 617 days ago
Python offers typing with static compiling. .Net doesn’t really match with startup culture.

I’m on the fence about Go, but maybe that’s my preference to having classes.

But yeah I’m the general case if I was an investor I’d be more careful with purely Python based startups.
2 comments
bigstrat2003 617 days ago
> Python offers typing with static compiling.

Python doesn't enforce types and as far as I know has no plans to.

> .Net doesn’t really match with startup culture.

Who the hell cares? If it's the best tool for the job, use it. Anything else is unprofessional as hell.

link
Narhem 617 days ago
Tell that to the people who downvote me which seems unprofessional as hell.

If I want to learn .Net which is more time consuming and more difficult to find employees why would I use it? Makes sense if you are in an area with a lot of windows people, but that’s not the case anywhere other than Texas.

And the compiler enforce typing. Admittedly not as nice as Go since you have to rely on external tools but workable.

People like their curly brackets though. Just not as helpful when dealing with system problems.

link
stackskipton 617 days ago
.Net came from group we acquired who yes, deployed things on Windows. However, their code now runs on .Net Core, in Linux Containers on Kubernetes. It's very performant as well, my only gripe is startup JIT. .Net does great in startup culture if you are not chasing trends and want code that works.
link
neonsunset 617 days ago
Hmm, usually the application start latency is very good. Significant improvements have been made to ensure that Tier-0 compiles fast. A base ASP.NET Core template takes about 120ms to start on my machine as tested with .NET 8 and Hyperfine (I modified it with starting the server with await app.RunAsync, then raising a CancellationToken on it in 10ms which outputs an error message in console about the fact and exits).

There is a good chance something else might be going on in one of the dependencies or perhaps some other infra package a team maintains, that slows this down. Sometimes teams publish SDK images on accident that have to be pulled over the network if they got evicted from the node cache, or try to use self-contained instead of runtime image + plain application - I know at least two cases where this was causing worse than desired deployment speed on GKE (arguably GKE is as much at fault here, but that's another topic).

link
stackskipton 617 days ago
It's very likely it's some library but at this point, I'm over caring. It's 20 seconds, everyone can cope with deployment rollout in Kubernetes taking 3 minutes.
link