HackerTrans
TopNewTrendsCommentsPastAskShowJobs

eacafdcbac

no profile record

comments

eacafdcbac
·há 4 anos·discuss
It was fun to read your response compared to mine :) You mentioned some things I missed, and we had pretty different reasons. Just shows a well made tool carries a variety of values for a variety of users.
eacafdcbac
·há 4 anos·discuss
I've only worked in PHP once, in college, so take the following with whatever level of credibility you wish. I generally work in infosec related projects that often come at strange intersections, such as embedded systems and web applications or real time operating systems in safety critical situations which must deal with data from unreliable or weakly secured sources (802.11, LoRa etc.) So, mostly my experience with Go is the need to write one-off tools, which usually provide either a CLI or web-ui, to inspect things embedded devices are doing as a sort of "black box."

I'm sure generics are going to be useful in some instances. Also of note 1.18 is bringing built in fuzzing, which is nice.

Where I'm getting my margin of benefit over writing tooling in say Python or Ruby, or other languages that fit this domain:

1. Fewer choices: The build system, module layout, and networking APIs don't lead me down the road of trying to figure out which library is best, thereby wasting time learning different libraries. I have never had any desire to google around for external libraries etc. Everything seems to just work fine.

2. Clear design intent: Once you've figured out what you're supposed to do with language idioms, like passing around ReadClosers or whatever it becomes super easy to read code written by other people who've also come to understand the intent. I don't notice this until I try to go back to doing something in Python and remember how vastly many approaches folks take to the same problem (like how should a database object be passed around.)

3. Works for my workflow: I spend most of my life in terminals fussing with serial communication, or fighting with mqtt or an APK that won't load like I expect, etc. The tooling with Go for nvim is incredible. I've found that now that I've gotten fairly fluent in the language I will often crack off small scripts in Go to automate dumb things I don't want to do in Bash or whatever, this is maybe an anti-pattern, depending on who you talk to.

Summary: My big margin over other languages just comes from consistency of design and interfaces and the fact that Go integrates with my workflow. It's very easy to figure out how to do a thing the first time I'm working on it. It's also easy to throw together a one off tool in an afternoon, use it for two weeks, push it up to my github and forget I did it until the next time I need it.

YMMV
eacafdcbac
·há 5 anos·discuss
The Internet is not, and has never been, a "public forum." At the end of the day the only piece of hardware you own is (probably) the one on your desk. You may put whatever data you want into it, but it's no one's responsibility to share that data.

Beyond that the suggestion that all user's data should be shared equally is inherently flawed.
eacafdcbac
·há 5 anos·discuss
Playing with OpenBSD will be a learning experience. For me, that's usually enough to install something on a non-daily driver machine.

Are you a software engineer or CS student? If so, I'd say that OpenBSD really shines in code simplicity, clarity, and consistency. This is also a matter of taste. What drew me in initially was the quality and consistency of the kernel source code, consistent high standards in documentation, and the design of system interfaces and libraries.

I like being able to answer my own questions and I find that easier in OpenBSD than in Linux. Sometimes I sit for hours and simply flip back and forth between documentation and code exploring how things work. I feel that this level of consistency and availability of information within the system feed creative urges on my part.

I like to write code and I feel like I have an easier time doing that in OpenBSD than Linux (again, a matter of tastes.) This is in large part because my workflow tends to happen at the terminal.

I would be surprised to find that VSCode, Slack, Discord, and other electron-y applications can be made to work in OpenBSD at all... maybe they do, but I've never felt the need to try, so if they don't I'm fine with that.

I think OpenBSD is well adapted to a specific kind of user and a specific kind of problems. If you're paranoid, or a developer, or just like the terminal window, or prefer design consistency over broad compatibility and feature variety, you might find that you really enjoy using OpenBSD.

By all means, give it a spin if for no other reason than to learn about a thing that's out there that a bunch of people enjoy.

If OpenBSD is not for you, that's okay too. I don't think that the user base, developers, or community have ever been looking run campaigns aimed at growing the popularity of the system. For me that's a good thing, the developers seem less prone to chasing the next thing that will expand their share in a market, and are more focused on making a thing they want to use - which translates well for me. YMMV.