Email or username:

Password:

Forgot your password?
Top-level
Hrefna (DHC)

The execs insistence here was especially painful for _data engineers_ because our lives revolved around taking data from one place, applying a series of transforms to it, and putting it somewhere else. The steps were often very similar to each other but with differently shaped data, so we could reuse a lot of code in a lot of cases.

Do you know what languages make that easy?

If you answered _anything with parametric polymorphism/generics_ you are most likely correct.

12/

5 comments
Hrefna (DHC) replied to Hrefna

I want to emphasize: None of this is really a flaw in Go _per se_ (well, some aspects may be, but I'm not talking about that right now). Go has a pretty strong core and it works well in that area. There are a lot of go programmers, and a lot of the issues I'm describing have been smoothed over with time, and execs have become less… enthusiastic.

It does mean I think that—for what Go was initially being advertised for—a lot of people who were already in that space found it difficult.

13/

Hrefna (DHC) replied to Hrefna

It works "well enough" in that space but it is just "well enough." Its advantages were muddled when compared to languages like Java, C++, and C# and it wasn't _clearly_ better, which made adoption difficult against those languages.

It's still managed at points, but it's because a team evaluates the tradeoffs and finds that it fits, not because it is head and shoulders better (like, you know, everyone in industry for more than six months would expect).

14/

Hrefna (DHC) replied to Hrefna

It goes back to: there are no silver bullets. You can't just rub a programming language on top of bad practices and get a good result.

You are going to get a bad result regardless of what language you are writing in, and safeguards can backfire in a large enough project because they make things difficult to reason about or adequately test.

Anyways, I may have more to rant about on this eventually, but I'll leave off for right now.

15/TBD

mnl mnl mnl mnl mnl replied to Hrefna

@hrefna one thing that golang “kind of” is a silver bullet for is not having to worry about the concurrency model with libbashing an app together, which was my main pain point in c++ and python (when I used to do Java I wasn’t writing systems so dodged that problem) and was something not entirely settled the last time I built something in rust.

The “developer hostility” is felt in the terse tools as well. It’s getting better, but compared to rust or JavaScript it feels of another century.

Go Up