Hacker News Reader

Comment by bloopernova | Hacker News Reader

Regarding the Language Server, terraform-ls: does anyone know if that will also be forked?

Gah, this is frustrating! I am learning Python but TF and tf-ls are written in Go. I need to figure out how best to contribute.

View on HN

Marcin here, one of the OpenTF folks

This repo [0] seems to still be licensed under MPL, so there is no need for an immediate action, but if there is a willingness in the community to take it over and improve, I see no reason why we wouldn't do it.

[0] https://github.com/hashicorp/terraform-ls

I can't imagine how much you all have on your plates right now, so this can definitely wait.

Tools, frameworks, etc all have to be written by people, and I'm sure you're already keenly aware that poor programmer tooling can be the death of a project.

This is definitely selfish on my part since I write a lot of Terraform and lean on the language server a lot, but I hope that terraform-ls can have a couple of people dedicated to it eventually.

Unfortunately (of course!!) my own pet issues are pretty niche, since I expect there aren't many people using a lot of private registry modules like the client I work for. Hence my desire to fix it myself :)

> but I hope that terraform-ls can have a couple of people dedicated to it eventually.

I 100% agree with your perspective on tooling, and hope the OpenTF team will take terraform-ls (and hcl-lang) under their org, too, because I will never contribute one more character to any repo in the hashicorp org.

Adopting hcl-lang is very low risk, but not zero, and it would be a spiteful move for Hashicorp to introduce some BuSL-only change to hcl for the purpose of hard-forking the language

Python translates really well into Go. You could probably learn both at the same time

I’d call that a bit of a stretch. Python can have full blown OOP, even multiple inheritance. It can be very functional (decorators are used a lot). It’s interpreted, not compiled. It has tons of syntax sugar. Properties, context managers are very Pythonic. Async also works entirely differently. Multi threading with channels is not really a thing in Python. Neither are interfaces (abstract base classes come close though). Python can have impressively expressive type systems nowadays, with mypy and typing. Generics, paramspecs and whatnot. Go is much more rigid in that regard.

If you can handle Python, you will have no issue with Go, which is overall a simpler language.

I mostly agree, but subtle thing is that GP is "learning" Python. I don't think they know yet if they can handle it

That's very much it. At the risk of too much information I'm partially disabled, looking after my disabled wife, and working full time. I have a very limited "bucket" of stamina and strength that I can dedicate to anything else.

On the weekend I try to get through a couple of Exercism items, and rest. I really wish I had 10x the energy to contribute to so many worthy open source projects :(

In my book, mirroring what a friend recently told me about instruments: Learn Python. Ignore everything else for 1-3 years.

The main drawback is: You won't be able to write 10^3 - 10^5 events per second throughput services. That's where you need Go, (weird) Java and C++. But I don't think these are your current main problem.

However, Python exposes you to a lot of very valuable concepts in the programming language space. If you know Python well, you easily know 80% of the language fundamentals of Java, 70% of Go or Ruby and like half of Haskell or C++. And the other half of those languages is mystical wonderous ponderous voodoo magic.

TBH IDK about Haskell. I personally love it but it requires me to take a different view on problems than most other languages I've worked with. And I did all the things you've mentioned professionally at one point or another. That said, I'd highly recommend learning Haskell to anyone who's spent most of the career using "boring" languages like Go, C++ or Java. It's eye-opening.

How deep did you get into Haskell? Did you end up writing anything non-trivial in it? Do you feel that learning Haskell made you a better programmer in other languages?

I bought a paper copy of Learn You a Haskell many years ago and got about half way through it and got pulled away and haven't gone back to it, but every so often I get this longing. I love FP (currently maining in Elixir) so I wonder if I shouldn't just try to make it happen (even though I'm strapped for time for projects as is).

I never wrote a production system in Haskell, no, and haven't worked as part of a team writing Haskell for money. I wrote some convenience utilities for myself, and did more than a fair bit at codewars.

> Do you feel that learning Haskell made you a better programmer in other languages?

Exactly that. So while Haskell as such was not professionally useful to me, having learned Haskell made me much better in Ruby, for example. And more recently when I did a lot of Rego I still find the Haskell style of thinking very useful.

As fishnchips says, Haskell is more of an introspective journey imo.

Like, Monads are fucking weird.

Until you realize that monads are more about dealing with context and making data-dependencies and side-effects explicit.

And then you start realizing how most application server frameworks are about a simple task: The framework decomposes a possibly multi-threaded server into single-threaded request handling. And then does a shit-ton of other heavy-lifting for you.

Or, on the other hand, currying is a weird thing. Until we had a decorator which takes some initial parameters and transforms every incoming thing based on these parameters. It's a decorator in java, it's currrying in Haskell.

I've learned a lot from Haskell, ML, SML and OCaml as well as Haskell at a meta-level. We've written a full compiler in OCaml in one course, and then I made it assemble microcode instructions later on as well, because it made exercies easier in that other course.

But I wouldn't do that in production. Other languages are easier to comprehend for other people.

> currying is a weird thing

Is it? I think it's actually extremely elegant. A function has exactly one input and returns exactly one output.

If you need two inputs, you have a function that takes one input and returns a function that takes one input and produces the output. Functions that look like they have multiple inputs are just syntactic sugar.

I ain’t changing the license for mine(so it will stay the same license)

Learn both, you will eventually have to anyway, and it won't hurt your learning curve, in fact will probably help to see similar ideas implemented and expressed very differently.

Reply on news.ycombinator.com