What is the basic mechanic that is going on here? Searching the document then using it with one shot or multi-shot prompting?
1,665 karma · joined August 6, 2011
Teams. Go does "teams" better. Shipping an Erlang app to production was simultaneously one of the happiest and most depressing points in my career.
Happiest because it did exactly what we intended with minimal code and it was done early and under budget (yey!). The initial group liked Erlang, already knew Erlang and simply were able to bang it out -- delightful!
Depressing because of everything that happened after... trying to teach DevOps crew was a nightmare, they HATED us -- all that introspection you can get on an Erlang system only makes sense after lots of experience. Trying to hire people who already knew Erlang was borderline impossible. Worse still, hiring people who didn't know Erlang and trying to train them up was swimming upstream in multiple ways -- it just didn't work. Erlang is really a bit of its own thing -- and if you are absolutely new to it, very hard to get over the hump... it is a weird pragmatic FP actor system and lacks any sense of purity or type niftyness.
... For initial development, Go was less elegant than Erlang, but due to simplicity and really solid tooling probably slightly more productive, but not so much that I would favor it over Erlang. But the magic happened when we involved other people. Handing off to DevOps was a DREAM... it was just a binary that logged stuff. They didn't need to know anything about what was in the black box. Hiring people is already relatively easy for Go, and training up developers in it is a AMAZING. You can hire basically any competent developer and a week later you have a competent Go developer... 50 page spec and dead simple language works wonders. No debates about code formatting, builds static binaries in seconds, super-easy to experiment with from minute one (versus getting your head around OTP).
I consider myself a programming language geek, I program in dozens and dozens of languages, and love building my own little DSLs. Go is -- breathtakingly boring as a language, "exceptionally unexceptional". Honestly, it isn't much fun at all to program in, it is a bit of a grind. However, Go as a tool (when the language isn't the point, the product is, your customers are) is amazing... it is viciously focused on getting things done on teams, and so far, it has been an incredible asset to our team.
I still follow and toy with Elixir in hopes that it will hit critical mass, but wasn't willing to bet my livelihood on it as a founder.
I realize it might be painful to relive a bit, but would you be willing to go into some more detail (it is a throwaway anyway). What did you do, what were you thinking as you did it, and how could someone have reached you sooner to do 1/2/3?
This exists in rather decent form in Google Groups already -- there is Google Groups for Business (with a Google Apps account) that gives you a great web interface as well as email interface all just for your company.
You can either remove "Source Code Pro" from your box, or use Tampermonkey / Greasemonkey to remove it from the markup.
If I could go back and edit I would -- but it has been too long.
> I stress to my patients and the parents of my patients that if you can’t hear anything going on around you when listening to headphones, the decibel level is too high.
This is just stupid. It ignores type of headphone entirely. IEMs like the ER-4P (https://www.etymotic.com/consumer/earphones/er4.html) have insane noise isolation (up to 42 dB). When using them, I can't hear someone talking to me, standing right next to me, with no music! They physical block the ear canal and create a seal blocking outside noise.
> As a rule of thumb, you should only use [personal audio] devices at levels up to 60% of maximum volume for a total of 60 minutes a day. The louder the volume, the shorter your duration should be. At maximum volume, you should listen for only about five minutes a day.
Again, idiotic. "60%" is entirely meaningless. It might as well be "Don't listen above FALASFDABURAGA". Headphones vary in sensitivity vastly, on some sets of IEMs -- 60% would be ear bleeding, deafeningly, painfully loud. On a high impedance, low sensitivity set of big headphones, 60% is a whisper. As a "rule of thumb" all it does is reinforce that the person who gave that quote is an idiot.
> If you listen to music with earbuds or headphones at levels that block out normal discourse, you are in effect dealing lethal blows to the hair cells in your ears.
... again, quotes from people who have no understanding that there are different types of headphones. MAYBE you could claim with fully open headphones this to be the case... but what is the level of "discourse"... sigh. Again, literally nonsense because it is impossible to make sense of...
> ... Music Is Distracting (entire section) ...
There exists multiple categories of music WITHOUT WORDS! Shocking I know. Most developers I know listen to these types of music because, lyrics are distracting. That isn't a cut against headphones.
> ... Feeling of Vulnerability ...
Getting to some sad points. Again, I hate open office plans, but come on -- really -- the feeling of vulnerability being caused by headphones? It is caused by an open office layout.
It doesn't even need to be that extreme. I don't think a student and professor can't be on the same campus, the only thing that would need to happen is the student to drop the class.
That trivial, that simple, that easy. If you are screwing a college teacher, you can't be in that class. In the RARE case were the class is absolutely essential and only taught by a single person, then yeah, might need to quit for true love... or find a way to get that credit elsewhere.
Sadly, in the near term, the Rust boat has sailed. LTS releases would give a real good reason to reconsider if they ever come about. What support durations are you considering for LTS, and where can I read more?
Well -- if we are going into what I would have preferred. I would have preferred a rest period after release. No ongoing changes across 3 trains on a 6 week cycle. Give the community time to accept, adapt, bitch, moan, whine, create workarounds, and then better workarounds. Let enterprises have time to buy in, test, accept or reject and give feedback. Deal with critical issues and focus on stability as a deliverable... and don't break anything during the rest period (even if that means being on a single version of LLVM and no new traits or modules or functions or whatever). But, that ship has sailed.
> I'm not sorry for doing so much development in the open instead of behind closed doors
Who asked you to be? I was simply pointing out the reality that Rust has a reputation to contend with -- you can't change that be being righteous about it, it just is.
Exactly, which was my point. Rust-the-community (and you as a member of it) see no problem with it... which for me, IS the problem. The timing, the fact that it played into all the existing narratives about why you never trust Rust, it made it a brutal bit of political weaponry in the hands of those who are pushing against Rust in organizations... and a bit of a kick in the junk to those of us who supported it. You saw it as without impact, when it has already had a huge impact on at least one organization.
> Golang has made many changes that could technically, and actually did, break code as well (just to name a recent example, the GOMAXPROCS default bump; there have been several others).
Rust isn't Go, that might seem "unfair" but that is the way it is. Go does not have the same reputation to fight against as Rust, the same famed history of breaking peoples code who are trying to use it, Rust WILL be held to a higher standard when it comes to breakage than ANY other language I suspect.
Twenty-two days after release, Rust started talking about making breaking changes (https://internals.rust-lang.org/t/pre-rfc-adjust-default-obj...). This conversation killed a Rust project I had pushed for... it played into all the existing negative ideas about Rust (constantly changing, not worth investing in) and gave the doubters all the ammo they needed to kill the project.
The change wasn't yet implemented, and had ZERO impact on our code-base even if implemented. But Rust-the-community seems too clueless on the importance of APPEARING stable and able to follow promises.
I wonder how many other Rust projects died because Rust-the-community appears like an untrustworthy ally (I am speaking of perception not reality).
Any public websites or services you can reference? I legitimately can't think of a single website or service I use that will be impacted. Or are you talking more about like ancient internal systems written as a java applet?
> companies and services relying on [NPAPI] this technology will simply fail since there is no alternative
Any company that bet their business on NPAPI deserves to fail. The signals where clear since 2012 that this was coming, and was explicitly and directly stated since 2013. They had a lot of time to transition off.
A full decade ago I was helping companies transition off NPAPI because it was "legacy", "slow" and "buggy". I couldn't fathom a company being silly enough to develop a modern product using it.
Most of the "major" things dependent on NPAPI have fairly clear migration paths. Java Applet -> Java Web Start. Silverlight is entirely dead (despite MS supporting it out till 2021) and there are tons of migration paths off of it.
In my experience that "iterate and change the system easily and quickly" simply doesn't end up being true. That is the bait, but then comes the switch. Once you have a real system, heavily interdependent, the cost of changing things starts to go up greatly, and your ability to cleanly describe a working system becomes challenging. Answering simple management questions like "OK, so if we change X, what could break?"... "We should send out an email to all the teams to ask!" (ugh)
The problem is that for most significant changes to a component -- there are changes to the interface to that component. So you have 'the choice' -- (1) Maintain this interface forever or (2) Ensure all the teams transition off it by X date, via a deprecation system. Both work, and most companies seem to use a mix of both, they strive for (1) until it gets insane, then they do (2) and force everyone to upgrade to X version by Y date.. rinse and repeat.
We are currently doing the "fat binary" cookie cutter system. Our deploy is a single binary that does "all the things". There is a lot to like about this system. Easy to manage and role back. Compile time checking, including additional tools for static analysis, etc. No network overhead on making local calls. You know and can clearly describe 'the system', it isn't in some continuous flux state. Due to compiling time checking and static analysis you can maintain 'one truth' and when you upgrade a component, you can go into all the callers and update them, so you don't have to maintain that old interface. You can scale decently vertically not just horizontally, which at times is a far more efficient way to scale. Overall, it has made us able to move much faster because it gives us a lot of confidence in what we are shipping, and a sense of safety in that we can quickly go back to what we had.
This sounds like a person arguing on behalf a cast system. Without the right family culture and DNA you can't possible be successful/worthwhile, lets just put those people in a cast to save time, easy labeling for all! Maybe if you breed with a better cast and become part of their family your future would be brighter, so we will arrange a marriage to make this so. This isn't some far off idea - this is the norm in some places, and it is disgusting.
Do you support eugenics? Do you think less of intelligent people who choose to adopt rather than breed? Do you think overpopulation is a non-issue? Do you believe cast systems are useful?
Human knowledge and functional advancement is vastly more important than genetics or children. Jonas Salk had three children, but anyone who claimed "his children are his greatest accomplishment" would be laughed at. His impact on mankind was direct. Direct impact is always better, because no matter how many generations your DNA is passed on, it is all meaningless until they at some point take action and do something. Mindless breeding is something rabbits can do.
There is this desperately sad tendency to want to "pass the buck" to children... sure, MY life was a huge waste, but maybe my children will be something special, maybe it was all worth it because of them.... or my grandchildren. People who do something in the here and now are to be admired because they are a rarity.