Earlier quoted context omitted.
If you feel the need to use a multi line lambda you should be using a regular function. This is a code smell for sure.
Regular functions definitions can't be used as expressions. You are basically saying that one should never need a multi-line lambda. Obviously, I disagree.
Go + Services = One Goliath Project
131–140 of 449 posts
Re: Go + Services = One Goliath Project
#132Ok this is going to sound ignorant, as my only experiences in backend services have been Go and Python. I don't like either. Is there something I'm missing? For simple CRUD apps, both are sufficient. But (in my limited experience), the moment I've wanted to create more complex business logic with stricter constraints, neither has been quite up to the task. Go doesn't make things easy. It asks you to repeat yourself.…
>I'd rather just use Javascript Not a phrase you hear every day.
For some reason, JavaScript haters always seem baffled when confronted with a person who doesn't hate JavaScript.
Re: Go + Services = One Goliath Project
#133Re: Go + Services = One Goliath Project
#134Earlier quoted context omitted.
Numerous large projects and companies have publicly stated that they are stuck on Python 2 and it's easier to migrate languages, even to ones that they have to invent (Go) than to migrate to python 3. At least one of these companies had Guido on their staffs for years. Another, also with Guido on the staff, needed over three years to migrate from 2 to 3. The overwhelming body of evidence shows that migrating a large…
wait - what? Is Django a big enough project for you? Did you know that Django was not only successfully migrated from Python 2 to Python 3, it was ported in such a way that for many years it used the same codebase in both languages ... Perhaps that's the biggest advantage of porting from 2 to 3. A lot of the code could run in both languages.
Re: Go + Services = One Goliath Project
#135Earlier quoted context omitted.
> For loops take more reading to understand. A short comment would help here.
They could also improve the language. Map, filter, and reduce are such fundamental concepts.
Re: Go + Services = One Goliath Project
#136Ok this is going to sound ignorant, as my only experiences in backend services have been Go and Python. I don't like either. Is there something I'm missing? For simple CRUD apps, both are sufficient. But (in my limited experience), the moment I've wanted to create more complex business logic with stricter constraints, neither has been quite up to the task. Go doesn't make things easy. It asks you to repeat yourself.…
Re: Go + Services = One Goliath Project
#137As much as I personally don’t enjoy writing Go I really can’t fault them. I still find it interesting that for a relatively obvious feature set of fast compiles, fast startup and fast runtime there really isn’t anything mainstream out there to compete with Go. I really hope something like Kotlin, Swift, ReasonML or even AOT JVM/.NET brings something to the table soon. Or perhaps I’ll just have to wait for WASM to rea…
All I can think of is D, but it’s not quite mainstream. Are there any other less popular languages that meet all 3 conditions?
Re: Go + Services = One Goliath Project
#138Earlier quoted context omitted.
Complex languages don’t result in better programs. Else we would see Scala and C++ everywhere instead of them being relegated to narrow niches.
C++ is not a narrow niche. We do see it pretty much everywhere and it continues to be the most used language for systems programming, games, embedded systems, and pretty much anything else where performance is critical.
Re: Go + Services = One Goliath Project
#139Seems like such a waste. Is switching to python 3 really that hard? Is hardware that expensive? If this is indeed the right call it doesn't bode well for traditional scripting languages as the web scales to fewer high traffic apps. We might start to see more jvm, go (apparently) or even rust and c(++), rather than speed of development languages like Python or Ruby. Trend seems to be the reverse though, with python th…
I've worked with or known about too many places that have jumped on the microservices bandwagon and the only thing I've encountered is a lack of maturity (mine included) and a knee-jerk reaction against monolithic code, when the problem isn't the size of the codebase but its organic growth over time. Go is an excellent language for it but distributing your business logic and functionality over a network fundamentally…
It's almost religious. The reaction some people have when you suggest monoliths is completely baffling. It's apparently just "known" that it is the correct approach to all problems, so, y'know, it's embarrassing for you to have even suggested otherwise.
Re: Go + Services = One Goliath Project
#140Earlier quoted context omitted.
wait - what? Is Django a big enough project for you? Did you know that Django was not only successfully migrated from Python 2 to Python 3, it was ported in such a way that for many years it used the same codebase in both languages ... Perhaps that's the biggest advantage of porting from 2 to 3. A lot of the code could run in both languages.
The corollary of my complaint is there will always be someone who pops up on HN with no idea how many lines of code are in a "large project" like Dropbox or YouTube.
Is Dropbox open source? Is Dropbox even a typical Python application representative of the challenges of porting from 2 to 3?
My hunch is that the challenges of porting Dropbox to any other language have to do less with Python more with the need to deal with a filesystem at a lower and more granular level than what typical programming languages offer. Thus everything needs to be rewritten in bazillions of ways to handle the bazillion corner cases.