Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go + Services = One Goliath Project

engineering.khanacademy.org

Post reply on HN
Print view View original

151–160 of 449 posts

Re: Go + Services = One Goliath Project

#151

Post by UK-Al05 »

StillBored wrote: post #135
dwaltrip wrote: post #90

Earlier quoted context omitted.

They could also improve the language. Map, filter, and reduce are such fundamental concepts.

Fundamental? IMHO, they are just syntactic sugar on a foreach loop. Which in many ways is bad because it provides yet another way to express the same concept, without a significant difference in the method of execution. What am I missing?

I mean a for loop is just a syntatic sugar of a if and a go-to, but go-to is easier to mess up.

Same with map, they are a constrained for each that is guaranteed to be a correct implementation.

Re: Go + Services = One Goliath Project

#152

Post by smadge »

smadge wrote: post #150
thatswrong0 wrote: post #39

Ok 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.…

Just write an implementation of map/reduce/filter for every type in your go program!

Maybe you could create some text macros to simplify the process, and then run a preprocessor on your program, and then.... uh oh.

Re: Go + Services = One Goliath Project

#153

Post by jlokier »

firethief wrote: post #144
nordsieck wrote: post #67

Earlier quoted context omitted.

> But what I can't really figure out is why so many devs love it. I think, in order to understand why so many people love Go, you first need to understand why so many people love C. Go is C with most of the warts removed (for application development). GC, easy strings, maps, easier first-class function syntax, code formatting, modern standard library, easy concurrency, etc. Yes, there are plenty of places that C can…

> GC, easy strings, maps, easier first-class function syntax, code formatting, modern standard library, easy concurrency, etc. So what part of C is not in the list of warts averted in Go?

> So what part of C is not in the list of warts averted in Go?

A simple language with only a few things to learn. Everything built up from those few things.

Re: Go + Services = One Goliath Project

#154

Post by antielectronite »

WoodTree wrote: post #138
antielectronite wrote: post #118

Earlier quoted context omitted.

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.

That is a niche, because most applications are IO bound and not compute bound. What even qualifies as “systems programming” is ill defined. Far more critical business systems run on Java and C# servers than C++. If there are C++ components they tend to be small parts along the critical path and not the primary implementation language.

I disagree with the notion that most applications are IO bound only. This is something people often say uncritically, but in my experience is false. Just using a non-native Electron or even Java application feels very sluggish and when you look at the Waterfall on slow web pages, what's slowing it down is very often unrelated to "I/O".

Secondly, C/C++ is like the third or fourth most commonly listed programming language in job listings. If you think all but 2 or 3 languages are niche, that is not what the word means.

Re: Go + Services = One Goliath Project

#155

Post by ljm »

goostavos wrote: post #139
ljm wrote: post #40

Earlier quoted context omitted.

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…

>knee-jerk reaction against monolithic code 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.

The best systems I've worked on have all been well architected monoliths. The code is ugly as fuck in some places but that's what tech debt is.

If you release a bug to prod in your monolith, it is exactly the same as a dependent microservice releasing the same and bringing the cluster down. You get a crash either way, and at least with a monolith you're not spreading your call-stack over the network; it's all in memory.

Re: Go + Services = One Goliath Project

#156

Post by dangoor »

thatswrong0 wrote: post #39

Ok 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 have a lot of JavaScript history, but if I were optimizing for the things you want to optimize for, I would absolutely pick Kotlin above JS+TypeScript. It's got bunches of language features, including superior concurrency, and runs on a faster runtime to boot. Unlike TypeScript, it doesn't have a 20+ year old dynamic language at its heart.

In backend systems, I think that the overall architecture and management of data are much more interesting problems than the code. I feel like Go helps direct more of the thinking toward the overall rather than creating beautiful abstractions in the code.

We'll see if I still feel this way in a year.

Re: Go + Services = One Goliath Project

#157

Post by baron816 »

WoodTree wrote: post #88
im3w1l wrote: post #69

Earlier quoted context omitted.

If you need more power than a lambda you would use a nested function, e.g. def a(n): def b(): print(n) return b

Nesting functions like this can have a bad performance impact because functions in Python are objects. Normally, all of those function objects are instantiated once when you load the module. However nested functions will be instantiated at runtime every time their parent is called, even if they aren’t used. This cost is perceptible in hot paths.

I’ve never seen it create a bottle neck, have you?

Re: Go + Services = One Goliath Project

#158

Post by FpUser »

WoodTree wrote: post #138
antielectronite wrote: post #118

Earlier quoted context omitted.

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.

That is a niche, because most applications are IO bound and not compute bound. What even qualifies as “systems programming” is ill defined. Far more critical business systems run on Java and C# servers than C++. If there are C++ components they tend to be small parts along the critical path and not the primary implementation language.

"most applications are IO bound" - there is a whole world of not IO bound software running on cars, toasters, airplanes, desktops, hospital equipment etc etc. I do not think it is any smaller then that niche of web spaghetti being churned out by undergrads

Re: Go + Services = One Goliath Project

#159

Post by bauerd »

Improvotter wrote: post #116
dwaltrip wrote: post #90

Earlier quoted context omitted.

They could also improve the language. Map, filter, and reduce are such fundamental concepts.

No, Go does not need this and I do not want it to get these useless "features". Go is simple and it gets things done with an amazing standard library. Use a different programming language if this does not suite you. Every programming language ends up with its own implementation of these "concepts" that it is hard to keep track. What is so difficult about for loops? It's simple for everyone and you don't need to learn…

Thing is that simple != easy

But oh man it's the same discussion every time when Go comes up here

Re: Go + Services = One Goliath Project

#160

Post by dfee »

thatswrong0 wrote: post #39

Ok 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 dislike JS, but love TS. But really, who cares about me anyway?

The big picture is that JS is the English of software languages. It’s not beautiful, it steals from everyone else, and it’s never the best tool, but it’s becoming - more and more - rarely the wrong tool.

I expect this trend to continue. Some genius will get JS to compile to native bytecode (WASM is the intermediate step). And, it too will be neither the best language for the job, nor the wrong tool for the job.

The proof is in the pudding, nothing so wrong (JS) can be so right - and yet it survives, nay thrives.

Post reply on HN