Its really not. For example, a map function tells you that there will be the exact number of outputs as inputs. A for loop doesn't have any guarantees. You have to read each line inside the loop to understand what its doing. In practice, having to be so explicit causes many more issues. I've never experienced as many mishandled errors on java projects as I have in Go.
On scrum projects I've been on, its essentially the waterfall model. Business comes up with a product and date, product and engineer give high level estimates. Program manager creates a project with all the stakeholders, product managers then write requirements, engineers then write designs. Finally this gets translated into jira epics/stories so engineers can do the implementation. The implementation runs in sprints so engineers can feel like they are doing agile. Finally when its all done, there's manual end to end testing with product and engineering.
I've been coding full time in it on a large team for four years now. If Go is this difficult to comprehend, then maybe its not the simple language it claims to be.
That is the joke. Go conflates simple with primitive, so you end-up building things like Computer Science has just emerged and it is the 50s with some syntax sugar, an decent concurrency to be fair.
Is there much boilerplate aside from err checks and JSON tags? Even then, your IDE / copilot should automatically insert those along with imports and package names.
Err checks are a big one. I don't want to worry about error handling when prototyping. There are little things like having to prefix methods with the struct name and type, and bigger things like no default arguments and by name parameters, which makes setting up test fixtures cumbersome. Also, functions don't compose well because there can be more than one return value, so you end up just writing more intermediate values.
The requirement to define at least one function by itself is a boilerplate. Also IDE doesn't fully solve the inability to compile and run a partially written program (in fact, Go compiler is even more pedantic than rustc in some aspect), which happens a lot when working with dynamically typed languages and their strongest use cases.
This is the same as what restaurants do now. They started charging a "service fee" or surcharge. You might assume those extra fees are for the workers but it goes to the business.
And this is why I will never understand why many think tipping is a practice upheld for the benefit of the restaurant. Cash in your hand is always better than cash in someone else's hand.
While that might theoretically be a benefit, it is one not realized. I have never seen a restaurant not hire staff as employees, as opposed to leasing the space to independent contractors, which means that the restaurant is on the hook for their compensation.
There is no realization of higher profit margins, though, which means that restaurants operating under that model also have to reduce their income in order to "save" on wages.
So, while a fun distraction, we're right back to you thinking that money in someone else's hand is better than money in your own. What is your rational? Conventional wisdom says that there is leverage in increased cashflow. Why is the conventional wisdom wrong?
This is the cost of doing business when you have to pay for engineering (and tooling + certification) on niche products. Nothing they do is really designed for mass market.
Desks, drum machines, synthesizers, mixers are not really niche products. They take fairly common items, and create a version that appeals to hipsters but is not as useful as cheaper options. Example $2k for this little synth https://teenage.engineering/store/op-1-field which wouldn't appeal to most synthesizer enthusiasts. Its more like office desk toy.
I definitely wouldn't pay $1600 but I like the idea of an ultra-modular and configurable desk. I wonder if you could build something similar with 80-20 extrusions (and/or similar knock-off) and an Ikea desktop. There's a huge ecosystem of ways to integrate/extend these and you could do some cool things with them.
This is the 10,000th time someone has posted TE products to HN and said they're overpriced. They make high-end luxury products for rich people, if you think it's too expensive then you're not the target audience. This is like saying a Lamborghini is too expensive because you can by a Toyota that does 90% of the same stuff for a fifth of the cost. Every one knows, that's the point.
I mean I get it, I would never buy anything from TE either, just like I can't afford a Lamborghini. But I can still look at it and go "Wow, that's really pretty."
Probably resentment because the original OP-1 was not crazily priced for its novelty and feature set. Once it got popular it rose from $800 to $1400 and the new OP-1 Field is $2000.
And the KO-II series is actually reasonably priced by their standards!
Not obvious to me. We just implemented a streaming solution using the iterator interfaces. They are just functions so reading the code its easy to understand. Adding special language support only serves to obfuscate the actual code.
reply