Live data from Hacker News

Show HN: I made an SSH tunnel manager to learn Go

github.com

41–50 of 72 posts

Re: Show HN: I made an SSH tunnel manager to learn Go

#42

After having spent the last year writing rust, it's a breath of fresh air to clone and read through a concise and straightforward repo like this.

Is Rust still that hard to grok even after a year to you? This is by no means meant to be disrespectful but I'm itching to start learning Rust but having only worked in Python/C#/Go I'm getting cold feet just looking at a Rust codebase Disclaimer: I'm usually very good at hitting the ground running, but I am just as much bad at "keeping the pace", i.e. diving deep into stuff

> I'm usually very good at hitting the ground running, but I am just as much bad at "keeping the pace", i.e. diving deep into stuff

At a beginner level, rustlings[1] is an excellent resource for following along with any book/tutorial and do relevant exercise to apply the concepts from the learning material.

On a more higher level, I guess (re)implementing some tool that you use daily is another way to deep dive into rust. I suspect it's one of the reasons why we see an unusual number of "rewrite of x in rust" projects.

[1]. https://github.com/rust-lang/rustlings

Re: Show HN: I made an SSH tunnel manager to learn Go

#43
post #17

Well done. The ease of use and high quality of the Go SSH libraries (golang.org/x/crypto/ssh) is a killer feature of Go, imho. Also, there is a high level abstraction, github.com/gliderlabs/ssh, which makes it completely trivial to embed an ssh server into an application, giving you a nice way to inspect counters and flip feature flags and tuneables.

I'm curious what are some prototypical use cases for you to embed an ssh sever into an application?

[redacted for accuracy]

Re: Show HN: I made an SSH tunnel manager to learn Go

#44
post #13
post #10

Earlier quoted context omitted.

as someone who works on 3 different machines regularly and likes to have the same environment on all of them... i would LOVE if applications would stop cluttering my .config with cache data and other bullshit i keep having to exclude from sync.

`rsync` should have something like `.nosync` akin to `.nomedia`, and the directory should be added explicitly if one wants it to be synced. Or something like a `--profile` option where `.nosync` then can contain an allow/disallow filter for profiles. I have the same issue with the scripts which trigger `rsync` getting confusingly complex because of all the include/exclude arguments.

That's generally what the Cache Directory Specification attempts to cover: https://bford.info/cachedir/

Lots of things like the Rust tool chain now create the CACHEDIR.TAG files so that backup tools can ignore that part of the hierarchy. Alas, I believe the rsync folks refuse to implement it.

Re: Show HN: I made an SSH tunnel manager to learn Go

#45

Earlier quoted context omitted.

The only major downside to golang.org/x/crypto/ssh is that open issues seem to linger for years lately, even when people try to submit patches. So it's often necessary to look for third-party solutions. The knownhosts handling in particular has a bunch of common land-mines. I'm the maintainer of a wrapper package https://github.com/skeema/knownhosts/ which solves some of them, without having to re-implement the core…

I think in an ideal world, this would be the normal case. A hierarchy of packages, maintained by many independent parties, that extend useful base functionality, without too much logic being put in any one package. If one thing doesn't work well you can just create a new package to replace the one part. And building on top of simpler, smaller modules allows you to keep code DRY, reduce maintenance burden (like the 10…

I do not mean this as a loaded question, but what happens in this model when maintainers die?

Everything you've said sounds great, with the assumption that the maintainers can maintain their pieces indefinitely and independently. But we're mortal. And I know the independent maintainers in places like CPAN are humans, not companies.

I guess it's a sign you're getting old when you start worrying about this kind of thing

Re: Show HN: I made an SSH tunnel manager to learn Go

#46

Earlier quoted context omitted.

I'm curious what are some prototypical use cases for you to embed an ssh sever into an application?

[redacted for accuracy]

Going through the code, I couldn't find a server but only usage of ssh client. May be I missed it. But I think GP was looking for usecases where its helpful to run an embedded ssh server using a go binary.

Ansible facts can probably be a cross platform way to collect most of the information you need. For the usecases where scp'ng the binary is needed, I think ansible supports jumphost config too. But I agree that for one off tasks, running a single binary is convenient compared to setting up ansible.

Re: Show HN: I made an SSH tunnel manager to learn Go

#47

After having spent the last year writing rust, it's a breath of fresh air to clone and read through a concise and straightforward repo like this.

Is Rust still that hard to grok even after a year to you? This is by no means meant to be disrespectful but I'm itching to start learning Rust but having only worked in Python/C#/Go I'm getting cold feet just looking at a Rust codebase Disclaimer: I'm usually very good at hitting the ground running, but I am just as much bad at "keeping the pace", i.e. diving deep into stuff

I wouldn't say that it's hard to grok.. even a year ago I found that rust projects lent themselves well towards understanding the project structure due to rust being fairly explicit about most things, and with an LSP integration I could follow along fairly easily compared to something like a python or a ruby project.

Go is just easier to read. You don't have a lot of generics typically to assemble in your mental model, no lifetimes to consider, no explicit interface implementations, and so on. All of those things in Rust are great for what they do, but I think it makes it more difficult to breeze through a codebase compared to Go.

Re: Show HN: I made an SSH tunnel manager to learn Go

#48
post #46

Earlier quoted context omitted.

[redacted for accuracy]

Going through the code, I couldn't find a server but only usage of ssh client. May be I missed it. But I think GP was looking for usecases where its helpful to run an embedded ssh server using a go binary. Ansible facts can probably be a cross platform way to collect most of the information you need. For the usecases where scp'ng the binary is needed, I think ansible supports jumphost config too. But I agree that for…

Oop - you're right, I missed that they wanted server examples specifically. Thanks for the save.

Re: Show HN: I made an SSH tunnel manager to learn Go

#49
post #39
post #17

Well done. The ease of use and high quality of the Go SSH libraries (golang.org/x/crypto/ssh) is a killer feature of Go, imho. Also, there is a high level abstraction, github.com/gliderlabs/ssh, which makes it completely trivial to embed an ssh server into an application, giving you a nice way to inspect counters and flip feature flags and tuneables.

How is performance? We found the native Go SSL libraries (as used in, e.g. the http package natively) to add many ms to web api calls. We eventually substituted OpenSSL (despite not really wanting to). It significantly sped up the app. YMMV, this is for ARM 32-bit targets.

[dead]

Re: Show HN: I made an SSH tunnel manager to learn Go

#50

Earlier quoted context omitted.

I think in an ideal world, this would be the normal case. A hierarchy of packages, maintained by many independent parties, that extend useful base functionality, without too much logic being put in any one package. If one thing doesn't work well you can just create a new package to replace the one part. And building on top of simpler, smaller modules allows you to keep code DRY, reduce maintenance burden (like the 10…

I do not mean this as a loaded question, but what happens in this model when maintainers die? Everything you've said sounds great, with the assumption that the maintainers can maintain their pieces indefinitely and independently. But we're mortal. And I know the independent maintainers in places like CPAN are humans, not companies. I guess it's a sign you're getting old when you start worrying about this kind of thin…

[dead]
Post reply on HN