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

Go is my hammer, and everything is a nail

maragu.dev

Post reply on HN
Print view View original

801–810 of 816 posts

Re: Go is my hammer, and everything is a nail

#801

Post by bborud »

Klonoar wrote: post #251
bborud wrote: post #94

People always under-estimate the cost of properly learning a language. At any given time I tend to have a "main go-to language". I typically spend 2-4 years getting to the point where I can say I "know" a language. Then I try to stick to it long enough for the investment to pay off. Usually 8-10 years. A surprising number of people think this is a very long time. It isn't. This is typically the time it takes to under…

It’s not just the time to understand those nuances, but to keep up with the pace of changes. There’s an aspect of navigating those in some languages (JS…) that can be time consuming depending on where it’s deployed.

I think JS is a degenerate case. The reason I stay as far away from JS/TS as possible is that everything seems sloppy and therefore people try to "fix" things by replacing them every N months.

Indeed, when you see so many commenters advocating not bothering to learn a language deeply, you kind of get a taste for how prevalent the sloppiness mindset is. JS seems to attract a very high proportion of unskilled programmers.

I would struggle to name a single project I have been involved in where the JS/TS based front-end hasn't been reimplemented multiple times, from what I can tell, because people get lost.

Re: Go is my hammer, and everything is a nail

#802

Post by jose_zap »

kerkeslager wrote: post #735
mrkeen wrote: post #585

Earlier quoted context omitted.

> Attacking Haskell is sort of a straw man--so far I haven't seen anyone in this thread propose Haskell as a go alternative. I think we agree Haskell is far too dogmatic about its abstractions when it's impractical to be used as a general-purpose language (because I don't think it's intended as a general-purpose language). I'll be that guy. We like our stuff in Haskell. Watching the rest of the industry move forward…

> Exceptions or return values? Nope, monadic error handling, any day of the week. Ehhhh... The thing is, there are a lot of cases where I can look at the code and I know the error won't happen because I'm not calling it that way. Sure, sometimes I get it wrong, but the fact is that not every application needs a level of reliability that's worth the effort of having to reason around error handling semi-explicitly to p…

> imagine being able to insert `print(a)` into your program to see what's in the `a` variable at a specific time. Hey, I know that's not pure, but it's still damn useful.

In Haskell that’s Debug.Trace.traceShow. You can use it in pure code too.

Re: Go is my hammer, and everything is a nail

#803

Post by Yoric »

sanderjd wrote: post #774
Yoric wrote: post #427

Earlier quoted context omitted.

> The author lists multiple reasons for this, but for me the biggest one is the first one: Go is good for almost everything. I'd nuance that claim. I haven't found Go to be _particularly good_ at any specific task I've undertaken, but Go was _good enough_ for many of these tasks. Which makes Go a reasonable general programming language.

This is true, but there are a number of _good enough_ languages, and personally I don't think go is top-tier at this use case of being the go-to swiss army knife. I do think it is top-tier at being a good choice for tools in its niche. But not as "default language I reach for when I don't want to waste time thinking about it".

Agreed. For my personal sensibilities, Python or TypeScript are better default languages. Of course, I'm a bit obsessive about quality/safety, so I'm probably going to use Rust for most tasks :)

Re: Go is my hammer, and everything is a nail

#804

Post by bborud »

Dylan16807 wrote: post #425
nemo1618 wrote: post #279

Earlier quoted context omitted.

One of the most important qualities of Go is that it is actually possible to fully understand the language -- in the sense that you never see a snippet of Go code and think "wtf, you can do that?" or "hang on, why does that work?" Getting to that point takes many years, to be sure. But the language is simple enough, and changes slowly enough, that it is not an unrealistic goal -- the way it would be in C++, or Rust,…

Why is that important? Let's say one language has me find a weird rabbit hole every 50 hours of use, and I spend half an hour learning about it. Let's say another language has no rabbit holes, but I'm 5% slower at coding in it. Why would I not prefer the first language? (And 5% is supposed to be an intentional lowball. I'm confident I can find language pairs where my productivity differs by significantly more.)

That's an odd assumption. That you either have to choose between rabbit holes or development speed. Usually languages with lots of rabbit holes tend to require a lot more work.

Take C++ vs Go for instance. C++ is an endless series of deep, complex rabbit holes where you get enough rope to hang not only yourself but your entire team. Serious C++ projects tend to require a style guide for either the company (most companies don't have that kind of discipline) or at least some consensus of what subset of the language to use and how to structure problems for a particular project. Look at the guides Google use or the Joint Strike Fighter. They're massive. C++ is not a particularly fast language to develop quality code in unless you have a small team and/or you are supremely well aligned and disciplined. And even when you work on a disciplined team, it takes time.

Go has fewer rabbit holes. It gives you an easier path to concurrency. It has managed memory. It is sufficiently performant for a very wide range of projects. It has a very capable and practically oriented standard library that even includes HTTP, cryptography, support for some common formats and a decent networking abstraction that actually allows you design flexibility. And importantly: it comes with a shared code style which is tooling enforced, so you don't have to waste time on mediating between various opinionated hothead programmers on your project.

Re: Go is my hammer, and everything is a nail

#805

Post by bborud »

machiaweliczny wrote: post #598
bborud wrote: post #94

People always under-estimate the cost of properly learning a language. At any given time I tend to have a "main go-to language". I typically spend 2-4 years getting to the point where I can say I "know" a language. Then I try to stick to it long enough for the investment to pay off. Usually 8-10 years. A surprising number of people think this is a very long time. It isn't. This is typically the time it takes to under…

Using esoteric lang constructs is bad idea IMO. Makes software harder to read/port/maintain. It’s useful for some hack & high perf stuff but not typical apps.

Agreed. But knowing a bit about how a language (and runtime) actually works can make a huge difference when you design stuff.

For instance, I've seen lots of examples of people implementing LRU caches in Java, and then scratching their heads when performance drops because they have no idea how the GC works. Or complicating things immensely because they realize memory is tricky and then ending up with some complex pooling scheme that constantly breaks rather than realizing that often more naive code that exploits the low cost of ultra short-lived local objects.

If you know what you are doing it becomes easier to choose solutions that are performant and understandable.

Re: Go is my hammer, and everything is a nail

#806

Post by mapcars »

neonsunset wrote: post #306
mapcars wrote: post #302

Earlier quoted context omitted.

I understand its probably not the case today, just that C# shares some of the MS reputation and its hard to get rid of. Especially when there are dozens of open-source independent languages around.

I think phrasing with insistence that it is " probably not the case today" despite demonstrable evidence of certainty means that the motivation for this reply was not to learn something new or share something you know but to try to get a raise with low-effort bait. This is both tiresome and goes against guidelines. Somehow we all can normally discuss programming languages without bringing practices of Google or Oracl…

I phrase it this way only because I do not have enough knowledge to be certain. I've read the comments that you sent, but to be certain it requires much more in-depth investigation which I don't want to do simply because I have no plans on interacting with C# in any forceable future.

I only tried to explain how some people who are not directly involved with C# might see the language.

Re: Go is my hammer, and everything is a nail

#807

Post by mapcars »

marcus_holmes wrote: post #359
nrr wrote: post #290

Earlier quoted context omitted.

It comes down to how the standard library makes you do things. I don't think there's any reason why a more stringly-typed way of handling JSON (or, indeed, a more high-level way of using HTTP) is outside of the realm of possibility for Go. It's just that the standard library authors saw fit not to pursue that avenue. This variability is honestly one of the reasons why I dislike interviews that require me to synthesiz…

My favourite tech interview (so far) was similar: "here's the FOSS code base we're working on. This issue looks like about the size we can tackle in the time we have. Let's work on this together and solve it". I got to show how I could grok a code base and work out where the problem was quickly, and work out a solution to the problem, and how I understood how to contribute a PR. Way better than random Leetcode bullsh…

I'm not a fan of this approach because candidates may see it as a "cheap" way to do actual work without being payed.

Re: Go is my hammer, and everything is a nail

#808

Post by mapcars »

nrr wrote: post #290
mapcars wrote: post #151

Earlier quoted context omitted.

I do programming interviews and I found candidates struggling a lot in doing http request and parsing response json in Go while in Python its a breeze, what makes it particularly hard, is it lack of generics or dict data type?

It comes down to how the standard library makes you do things. I don't think there's any reason why a more stringly-typed way of handling JSON (or, indeed, a more high-level way of using HTTP) is outside of the realm of possibility for Go. It's just that the standard library authors saw fit not to pursue that avenue. This variability is honestly one of the reasons why I dislike interviews that require me to synthesiz…

In our case we give some high-level description beforehand (which mentions working with REST apis) and allow candidates to use any language of their choice.

Also in our case the API has typing in form of generated documentation and example responses. I even saw one Go-candidate copying a response into some web tool to generate Go code to parse that form of json.

I can also say that people who chose Java usually have even more problems, they start by creating 3-4 classes just to follow Spring patterns.

Re: Go is my hammer, and everything is a nail

#809

Post by mapcars »

randmeerkat wrote: post #264
mapcars wrote: post #151

Earlier quoted context omitted.

I do programming interviews and I found candidates struggling a lot in doing http request and parsing response json in Go while in Python its a breeze, what makes it particularly hard, is it lack of generics or dict data type?

> I do programming interviews and I found candidates struggling a lot in doing http request and parsing response json in Go while in Python its a breeze, what makes it particularly hard, is it lack of generics or dict data type? Have you considered that your interview process is actually the problem? Focus on the candidate’s projects, or their past work experience, rather than forcing them to jump through arbitrary l…

Well these are not arbitrary, we work with a number of json apis on a weekly basis, supporting the ones we have and integrating new ones as well. This is a basic skill we are looking for, and I don't see it as a "leet code challenge".

Candidates might have great deal of experience debugging assembly code or generating 3d models, but we just don't have tasks like that.

Re: Go is my hammer, and everything is a nail

#810

Post by neonsunset »

mapcars wrote: post #806
neonsunset wrote: post #306

Earlier quoted context omitted.

I think phrasing with insistence that it is " probably not the case today" despite demonstrable evidence of certainty means that the motivation for this reply was not to learn something new or share something you know but to try to get a raise with low-effort bait. This is both tiresome and goes against guidelines. Somehow we all can normally discuss programming languages without bringing practices of Google or Oracl…

I phrase it this way only because I do not have enough knowledge to be certain. I've read the comments that you sent, but to be certain it requires much more in-depth investigation which I don't want to do simply because I have no plans on interacting with C# in any forceable future. I only tried to explain how some people who are not directly involved with C# might see the language.

That's a shame. .NET does away with all the pain points you've grown to expect from Python or Java tooling, has arguably better support[0] story on the main platforms nowadays and extremely no-nonsense CLI tooling similar to Rust or Go:

    sudo dnf/apt install dotnet-sdk-8.0
    # or
    brew install dotnet-sdk

    dotnet new web
    dotnet run
    curl localhost:5050
[0]: Situations like https://blogs.oracle.com/java/post/java-on-macos-14-4 do not happen to .NET as it tries to use the platforms it is targeted at in a "canonical way". To be fair, not exactly a Java fault, but effort is invested to ensure that the runtime plays nicely with e.g. memory protection techniques.
Post reply on HN