Hacker Newsnew | past | comments | ask | show | jobs | submit | caerwy's commentslogin

His real beef seems to be with “any lawful use”. He doesn't agree with the law and wants to only sell to customers who agree with his own moral code. I respect his moral choice but suspect this is not how a market economy ought to work. He ought to lobby government to change the law rather than make moral judgements about his customers.


When you make the market, you too can dictate how a 'market economy' ought to work :)


Free Speech rights mean not being compelled to act against your moral code.


The UNIX philosophy of tools that handle text streams, staying "quiet" unless something goes wrong, doing one thing well, etc. are all still so well suited to the modern age of AI coding agents.


You can go a long way with just Termux. You can upcycle old phones by installing or building code in Termux to turn the phones into a compute grid, AI inference nodes, file servers, compute servers, web servers.


I was actually just going to do that with an old Galaxy S24. Seems like there's no easy way to add something like docker. Best I can find is to try to use qemu to get a full Linux VM.

Do you happen to know what kind of performance you can expect? Or perhaps a better way?


There's an app called Termux that comes with distro sources compiled for the Android/Linux. They're not binary compatible with regular GNU/Linux, but runs most software through distro standard ways.



> AI inference nodes

Are phones any good for that? (I agree with the rest, and I'm a big fan of termux, I just wouldn't have thought of a phone - especially an old phone - as a useful way to run AI)


Modern phones pack a good bit of compute, and can run things like VLAs decently well.

Of course, that would require today's phones to age out of "being used as a phone" bracket, and robotics VLAs to become actually useful. But things like the Comma AI autopilot hardware use slightly obsolete smartphone chips internally - so it's not like it's impossible to run a useful AI on this kind of HW.


More generally the tools used to write the code show through in the code itself. In the way code is distributed across files, in the length and style of names, in the organization of modules. Using an editor without syntax highlighting like Acme, and also because it's Acme will encourage a different style of organizing a project and the code within a file.


Following Karl Popper's thinking on this topic, I'd say that our problems define us, and when we solve our problems we often discover new and interesting children problems demanding attention. “The best thing that can happen to a human being us to find a problem, to fall in love with that problem, and to live trying to solve that problem, unless another problem even more lovable appears.” — Karl Popper


That's not a real Popper quote, is it. The sentiment is nice, but it must be radically paraphrased, because he doesn't generate pithy quotes very often.

> To conclude, I think that there is only one way to science—or to philosophy, for that matter: to meet a problem, to see its beauty and fall in love with it; to get married to it, and to live with it happily, till death do ye part—unless you should meet another and even more fascinating problem, or unless, indeed, you should obtain a solution. But even if you do obtain a solution, you may then discover, to your delight, the existence of a whole family of enchanting though perhaps difficult problem children for whose welfare you may work, with a purpose, to the end of your days.

https://archive.org/details/realismaimofscie0000popp/page/8/...

Edit: if I heed the content of the paragraphs just before this quote, maybe I should prefer the rewritten version.


This feels right to me, but I wonder what he was thinking of when he said “problem”. For me life is most effortless when I’m working on math or cs problems/puzzles but I sometimes get this guilty feeling that I “should” be working on a problem that is useful to the rest of the world.


Yeah, there's problems, like puzzles and mysteries, and then there's difficulties, and there's no sharp dividing line but the difficulties are less fun. And are also called problems.

So far as moral duty goes, play to your strengths, you're at your best when having fun. This conveniently evaluates to "do what you like". It's not perfectly true, but you can get away with it, blamelessly. Nobody needs you miserable, usually. Then there's the wrinkle where the importance of something to humanity (or even the promise of a large cash reward) may make it fun ... if you happen to feel that way.


some legacy applications were designed around having a 32 bit wordsize for pointers. so calculations of offsets into memory where a data structure includes pointers depends on a pointer size.


Here's a counterpoint blog using a chan that sends a chan in order to implement a dynamic dispatch mechanism. This is in Limbo not Go. But same concepts. Maybe the complexity proves the point. https://ipn.caerwyn.com/2007/07/lab-78-dynamic-dispatch.html...


For those wondering, Limbo is a predecessor of Go hand used in the Inferno operating system, a descendant of plan9.


The software industry has become swamped with suits optimizing their status and prestige.


Very true, but that's why it's important for GOOD leaders to know how to sell themselves, so we can push the monkeys in suits out of the way. Learning how to talk about myself in a way that really communicates with business people is the single greatest aspect of my career success. Yeah, I'm smart and highly capable, but that's useless if I can't get in the door.


This article is not so much about Go but about choosing to specialize in one language ecosystem instead of spreading one's attention across several.


With the caveat that the broadened perspective you obtain by learning a variety of languages will make you better at your primary language.


This is true, but it doesn't mean you should actually use a variety of languages for your day job if you're self-employed; that is, you lose some productivity if you choose an unfamiliar tool, and you'll shoot yourself in the foot if you choose a language unsuitable for the problem at hand.

The other thing to watch out for if you're in a corporate setting is that if you use a language nobody else is using at your company, your project is doomed and / or it will be stupid expensive compared to other projects because it uses a different language from the rest of the organization. See also https://boringtechnology.club/


I would say there are many, many other ways to broaden my perspective, not just learning and using a different programming language. There are so many things to learn!

(And I don't necessarily suggest not learning different languages, if one fancies that. I just don't use any other ones at the moment.)


I actually find it a bit of a curse to know too many languages. Because settling on one for any given project becomes very difficult. Like you start coding it up and then hit some friction and start thinking about one of the other languages you know that would be more elegant. Or you might have chosen a language that does a lot of things elegantly but then start thinking of the performance you've given up performance for that. Swapping languages will never stop those thoughts because there's always tradeoffs somewhere.


I always wonder: why do some people like to do this (spreading)? I wonder the same about people who are "distro tourists". The latter tend to spend a lot of time on what seems like unproductive diddling (desktop skins, etc).


1. Because I like engineering more than programming. If a problem is best solved by, say, a mechanical system then I will do that instead. But even where programming provides the best solution, not all ecosystems are equal. If I have a problem best solved by, say, AI/ML, it is often impractical to avoid Python. Likewise, if I have a problem best solved in the web domain, it is often impractical to avoid Javsacript. SQL where databases are the best solution. So on and so forth.

2. Because I like to learn. In my younger days, I found a lot of value in exploring the different ways people live. In fairness, I've toured the programming world enough by now that I am less compelled to keep go on "programming language vacations" – at some point you start to feel like you've seen it all, but believe I would be a far worse programmer today had I not been able to take ideas from a wide range of different cultures over the years. There are some good ideas out there that don't seem to ever gain mass adoption outside of their originating ecosystem.


Diff langs have their strengths and weaknesses, the same reason you don't build every object out of concrete "because it's tough" you don't build every service out of Python (because it's slow).


Because there's so much to learn from having different perspectives.

Back in 2006, I was working mainly in C with a bit of C++. One of the things I was taught was that "macros are evil", period. Then, in my spare time, I decided to try Common Lisp. I had a blast. I never wrote anything more useful than a half-assed catalog for my MP3 collection, but I learned a lot. My main takeaway was the power of metaprogramming -- with all of its footguns and pitfalls -- and took that knowledge with me to my day job, where I suddenly had a more nuanced view of how preprocessor macros can avoid being evil.

Later, when I changed jobs, I went back to Java, which was my main language before the C stint. I slipped back into the comfort of having my memory managed for me and the expressiveness of OOP. But in my spare time, I discovered Self and Io, and the fact that you can have OOP without classes blew my mind.

At that same job, I undertook the task to make our proprietary in-house language not only transpile to C++, but also compile to be executed on JVM. Understanding how JVM bytecode instructions work was easier than it might have been had I not dabbled in Forth in my spare time.

These days my day job involves working with C++ full time, but my hobby projects in Rust taught me to structure my thinking about the ownership and lifecycle of memory allocations.

So yeah, most of what I do in my spare time with other languages is largely "unproductive diddling" if you only look at the code I write in those languages, but the insights I take away with me are useful.

Also, it's fun ;)


I can think of many reasons. Seeing other language perspectives definitely can help with your primary language. I have experienced this. But, I have also explored other languages as a means of procrastination or ways to do something easy when bumping into the more challenging depths of my language of choice.


Which is unfortunate because I think Go is very useful in a wide variety of business contexts.


Then you would find this article very fortunate.


It would be a misfortune indeed if I had nothing to complain about.


Another technique not discussed is to create an md5 hash of each record and to keep track of added and deleted hashes. The d hash would exist as an additional column on each table being tracked.


If I understand you right, this seems like a very course-grained way to track changes. You can record that a change was made, but not the specific change. It seems like it'd help facilitate something like, say, an etag, but I don't think could get any auditable data using this alone, could you? Keeping track of added/deleted hashes would probably be best handled by a trigger, unless you really want that in your app code, so this seems a lot like an audit trigger, with very little audit data. Have I misunderstood?


I'm not sure I understand what you mean. Where are the hashes tracked?


here's the article I learned this from. https://www.mssqltips.com/sqlservertip/2543/using-hashbytes-...

you'd add a hash column to the table you want to track. this would be used in a data warehouse where you want to track what has changed after a truncate and load. you'd keep additional tables on the side to track added/and delete hashes for a delta copy to downstream application tables.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: