Updated, thanks!
HN user
itsmefaz
Author here! I have finally come to realize why and where Python is required.
- Python is a fantastic frontend (glue) language that interop well with C/C++ libraries. This seamless binding is not natively available in languages in Go or Java or even JS.
- Python has an excellent data science / modelling / data engineering / ml ecosystem. There is no other language that comes close.
- Python is a fantastic MVP language. One can rapidly prototype and iterate and to a very good extend scale a product.
Ease of use, less ceremony, huge package ecosystem including several de-facto standards for many use cases/industries, suitable for glue work, are benefits.
Sure, these are operational advantages. But purely from an computational perspective (GPUs, multi-core, concurrency, etc) does it offer anything natively without interfacing with C/C++ that validates it to be called a general purpose language.
My experience has been that to efficiently write computationally expensive operations I need to know the low-level libraries that Python interfaces with. Other languages provide me this functionality natively and I only go to the low-level stuff only after a few iterations.
Thank you!
I found this extremely interesting, I have been working for almost 8 years as a software engineer and this hit me hard.
Wow! I love you..
I wanted to develop an understanding of the market, where the industry is generally heading. To give some context, I am a software engineer typically spend time building enterprise software. I want to understand the landscape enough to be able to build a product (in the domain) on my own.
Thanks for your detailed response. But I still see all of these as computational problem that can also be scaled very easily.
Thanks for a detailed summary. This was really helpful.
Maybe I was hoping to find someone who has already made such a transition.
Thank you. This is a very helpful suggestion.
I am skeptical of job opportunities for Rust in my country. However, I get a sense the language appeals to a specific audience (and company), and most of the companies here are only building SaaS applications so it might not benefit them to transition their codebase.
Mostly around time + space optimization rather than being first.
Can you give me a small summary about what is being said in that book? And what you learned reading that book?
I have bradycardia and my resting heart is around ~50. Is this something I must about concerned about?
Thanks for your detailed assessment of the languages. This has given me a good idea which direction to go towards.
Your pay is basically a measure of "this is how hard it is to replace you" with an adjustment for how bad it would be if you quit and your employer doesn't bother to replace you. Your talents, insofar as they are a factor, are only useful to you in figuring out how to do something that is both uncommon and useful.
This is striking, the problem seems to be that most of the jobs that engineers are doing are easily replaceable.
Do you happen to know platforms / languages that are primarily built to work on scale both for users and developers? I sense Go has projected itself to be the one, do you have any other suggestions?
Thanks for your response!
I completely agree with the Big Ball of Mud and Swap guide analogy as that has also been my experience. I am also looking for alternatives and Go seems to be the logical conclusion that I am getting to. What would you suggest?
Nice
The current set of w3 apps are typically restricted to - wallets, nfts, etc. Also there are no new class of w3, it mostly rehash of w2 apps (openSea, etc).
I understand that the economic incentive is largely poor for large-scale research. However, the institutions should do it regardless as they don't want to lag and be dependent on certain central authorities (OpenAI and DeepMind) for AI capabilities.
Can you please elaborate more on the Maslow's Pyramid and why tech is plays a lesser role?
I think they call themselves Solution Engineers.
His answers might be, not the questions themselves.
One of the difficulties I am having is figuring out the idea - i) What is your idea generation process? ii) Building a startup of any kind is not as rosy as you put it? iii) Can you define what a micro startup is?
Do you have a fallback in case any of this fails, and where you working before you built your first startup?
Also, just from this brief interaction, I can see that you are more of a problem -> solution-oriented guy and don't care much about the tech stack. How can one eliminate this mindset? As engineers seem to be more invested in such things?
OpenAI Codex.
We are moving towards a time where the entire notion of programming languages would be nothing more than compiling a proper dataset.
Programming languages will not become irrelevant but would be more akin to the fate of humanities, likely a personal passion. The economic value of learning programming languages in the distant future would be close to none.
Programmers should view languages as nothing more than a tool to perform some tasks.
Not true at all. When you evaluate opportunity you are evaluating the people. Your success depends not only on your abilities but also on the abilities of your network.
The unproductive ones that invite for coffee, make jokes also have successful careers as they are perceived to be - friendly, high in openness, and high in consciousness. Now, I'm skeptical of your claim that these people are unproductive, not sure whether such an individual would survive a highly competitive environment. I could argue that they are productive enough to have time not just for work but also to engage in things outside of them.
I'm that type of person, my career growth has improved tremendously due to this ability of mine though it is natural for me to engage with people in my workplace. I am the guy people come to build XFN features and products because everyone knows me and I don't come off as a threat. This is a huge plus in large-scale enterprises where each BU works as a startup of its own and collaborating with them becomes a hassle.