Pinboard.in blog - Technical Underpinnings - <AUTHOR> http://pinboard.in/blog/63/

<comment><USER2> _"A rule of thumb that has worked well for me is that if I'm excited to play around with something, it probably doesn't belong in production."_

That has to be incredibly difficult to adhere to, but doing so probably saves a ton of headaches.

<comment><USER3> Only difficult, I imagine, if spending time living life is preferable to pulling hair out in heroic acts of troubleshooting / bug fixing.

Since maciej lives in places around the world, it seems like a good rule of thumb.

</comment></comment><comment><USER4> It must be a very boring life to purposefully work with uninteresting technologies. It may sound selfish, but I'd never make that decision. When I'm interested in what I'm working on, I build a better product. I'll sacrifice a few 9's any day to enjoy my job and make something that's interesting.

<comment><USER5> You seem to be confusing the tools with the product. Nothing more boring than a brick, but you can build some pretty neat things with them.

<comment><USER4> My excitement for the tools I use is directly proportional to the excitement I have for a product.

For example: over the past 4 years, I've all but abandoned all of my PHP projects in favor of my Rails projects. Because Rails is far more interesting to me than PHP. Just a small example, but it goes all the way down the chain.

<comment><USER6> What's even more exciting is making things people want, and use day in day out.

Choosing the right tool for the job is better in the long run than choosing the one you'd enjoy the most.

</comment></comment></comment></comment><comment><USER7> "favor boring and faded technologies where possible" == our site is held up by tons of shell and perl scripts

<comment><USER8> And runs on an operating system of ancient '70s design!

The overwhelming part of the codebase is really PHP. There's a small smattering of perl to handle a couple of async tasks, as Maciej described.

</comment></comment><comment><USER9> I'm currently looking for decent VPS hosting, and am shocked at how cheap prgmr.com are; what have your experiences been like with them?

<comment><USER5> We just made the switch at the end of last month, so I can't say anything useful. I do like their blog, which gives some insight into what it's like running a service like this.

</comment></comment><comment><USER10> I like this: " _Our technical goals are to never lose data, be very fast, and favor boring and faded technologies where possible._ "

<comment><USER11> The quote: _"A rule of thumb that has worked well for me is that if I'm excited to play around with something, it probably doesn't belong in production."_ was what hit me.

<comment><AUTHOR> I had a sense that this would end up being quoted quite a bit.

</comment></comment></comment><comment><USER12> Are you afraid by the fact that, later down the road, this architecture of perl scripts may be a burden

I mean, everybody writes shell scripts, but usually the mindset when writing them is "let's get something done" instead of "let's get it done right".

<comment><USER5> I don't think there's anything inherently hacky about Perl scripts (or any other kind of scripts) if they're in the service of a coherent design.

</comment></comment><comment><USER13> OT: Is it just me or is that link unzoomable on an iphone?

<comment><USER5> That's a dumb error on my part, it should be fixed now.</comment></comment>


C++ Annotations - <AUTHOR> http://www.icce.rug.nl/documents/cplusplus/ <comment><USER2> So I immediately checked my favorite language gotcha, the macro NULL. The text is entirely wrong. The macro NULL is harmful in both C and C++. It is not "stylistic" AT ALL.

Here's the problem with the macro: the macro NULL can be either 0 or can be (void * ) 0. The issue is that the former can be accidentally interpreted as an integer depending on context.

In both C and C++, this manifests when you pass NULL to a varargs function. Instead of passing in a null pointer, the compiler may instead pass in an integer zero. If pointers and ints have different sizes, hilarity ensues. If the null pointer does not have the same bit representation as int zero, hilarity ensues.

In C++, this happens even more commonly. If there is an operator overload and you pass in NULL, then if NULL is 0 it will chose the int overload, if NULL is (void * ) 0 it will chose a pointer overload.

Never use NULL. Ever.

<comment><USER3> What would you suggest using instead? The actual (void *) 0?

<comment><USER4> In C++, nullptr.

<comment><USER3> And in C?

<comment><USER5> In C, always use 0 and check for 0, it's the only safe way. For C++, it depends on the standard you're using.

<comment><USER6> But 0 isn't always null right?

<comment><USER2> Literal zero in a pointer context is interpreted by the compiler to mean "the null pointer." The compiler then compiles the null pointer into the code.

<comment><USER6> But then how do you get a pointer to zero (not null) in those systems?

<comment><USER2> First, that's inherently non-portable. That aside...

On most systems, the null pointer happens to be a pointer to address zero. For other systems, e.g. 8086 16-bit mode, you can create a intptr_t (which is the same size as a pointer) and set it to zero. Then cast it to a pointer. Such casting is always done bitwise, so it will work.

The compiler knows to turn the following into the null pointer

      void *p = (void *) 0;

but the compiler will NOT turn the following into a null pointer

      void *p = (void *) (uintptr_t) 0;

because the literal 0 is now in an integer context, not a pointer context.

<comment><USER7> BTW 0 is a valid literal value of a pointer type (so you do not need a cast).

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> It's becoming increasingly hard to gather any useful information about software development topic from a concise title because rampant terminology growth and (sometimes fueled by reuse of concepts with different terminology in different projects) to the point that concise titles are almost always ambiguous in some manner.

For example, I've seen this submission for hours now, and every time I assumed it was sort of function annotation/decorator syntax addition to achieve some interesting result, which didn't pique my interest at those times.

Is any other field quite as bad with this as software development seems to be?

<comment><USER9> The first sentence of the link may be enlightening. Instead of puzzling over it, why not just clicm the link and take a peek?

> This document is intended for knowledgeable users of C (or any other > language using a C-like grammar, like Perl or Java) who would like to know > more about, or make the transition to, C++

<comment><USER10> It's not puzzling, it's that you read a title and think it is something different.

<comment><USER9> Sure, immediately. But OP said "I've seen this submission for hours now", as if he has been trying to decipher it for a long time.

<comment><USER8> > But OP said "I've seen this submission for hours now", as if he has been > trying to decipher it for a long time.

No, seen as in "Seen on the front page but it didn't interest me enough at the time to look into it given what I assumed it was about."

</comment></comment></comment></comment></comment><comment><USER11> If you are in the Groningen region for a longer period, I can highly recommended taking Frank Brokken's C++ course [1]. I took the course over ten years ago and benefitted from it many years thereafter. He is also a great and very entertaining lecturer.

[1] he is the writer of the C++ annotations.

</comment><comment><USER7> A nice detailed overview of C++ (not sure why it's titled "annotations", though).

</comment><comment><USER12> As a previous C++ and current python dev I am not surprised to see 24 chapters on decorators in C++. (Joking ofcourse)

</comment><comment><USER13> How is the accuracy and recency of this manual compared to Stroustrup's A Tour of C++? Has anyone here read both?

<comment><AUTHOR> Here is his Gitlab [1]. Looking at the history at least he maintains the book very actively for years.

[1] [https://gitlab.com/fbb- git/cppannotations/commits/master](https://gitlab.com/fbb- git/cppannotations/commits/master)

</comment></comment><comment><USER14> This is a treasure. Dipping back into C++ after a couple decades makes this document pretty much essential.

<comment><USER15> Then you will need this as well [https://github.com/AnthonyCalandra/modern- cpp-features](https://github.com/AnthonyCalandra/modern-cpp-features)

<comment><USER16> actively dipping back into c++. I've needed this and I didn't know it. thanks

</comment></comment></comment><comment><USER17> Good read but class template argument deduction is not mentioned.</comment>


Tilig: A Password Manager for Everyone - <AUTHOR> https://blog.tilig.com/posts/introducing/ <comment><USER2> You can only log in/sign up using a Google account? Thanks, but no thanks.

</comment><comment><USER3> closed source, cloud-based? no thanks.</comment>


GitHub censorship, Code of Merit author's account deleted - <AUTHOR> Code of Merit author and spoken critic of censorship, Roberto Rosario, is the latest victim of the censorship wave invading the tech industry. Earlier today users of the Awesome Django project were surprised to find the repository had disappeared without trace or explanation. Awesome Django with 5.9K stars is the 4th most popular Django repository in Github.<p>https://github.com/rosarior/awesome-django <comment><AUTHOR> Update: The repository appears to be online once again, albeit missing almost 100 stars. Rosario's account is also back online but is missing all his followers (the count is reset to 0). his account follower count was 2.2k before disappearing.

Censorship or convenient tech glitch?

[https://github.com/rosarior](https://github.com/rosarior)</comment>


What could Facebook target next? Our mental health data - <AUTHOR> https://www.theguardian.com/commentisfree/2016/nov/01/facebook-target-mental-health-data-online <comment><USER2> Or operating systems.</comment>


The World Has a Germany Problem: Debt Obsession Ate the Economy - <AUTHOR> https://www.nytimes.com/2019/08/19/opinion/trump-germany-europe.html <comment><USER3> Given that German bonds are in negative territory out to thirty years, the government would actually profit by issuing them:

* [https://www.bloomberg.com/markets/rates-bonds/government-bon...](https://www.bloomberg.com/markets/rates-bonds/government-bonds/germany)

* [https://www.reuters.com/article/eurozone-bonds/update-3-yiel...](https://www.reuters.com/article/eurozone-bonds/update-3-yields-across-entire-german-bond-market-dip-below-zero-for-first-time-idUSL8N24Y326)

Is there any reason not to "borrow" when you're being paid to do so?

<comment><USER4> > Is there any reason not to "borrow" when you're being paid to do so?

If negative yields forecast shrinking economy and smaller tax base in a future.. You will pay back less nominaly but more in proportion to your revenues. But this is a topic for another time..

<comment><USER5> It's still better than _not_ borrowing, isn't it?

<comment><USER4> Goverment budgets are highly unelastic - railways, submarines, healthcare, pensions must be paid. So even small increase in costs of servicing debt results in embarasing and painfull cuts in elastic areas of the budget.

So in general MoFs avoid that unless they are going to pass the ball to the opposition.

But of course you have to borrow to roll old debt.

<comment><USER6> "But of course you have to borrow to roll old debt."

Not if you have your own currency. Currency issuers never need to borrow.

It makes no sense to even suggest borrowing something that you can create at will.

</comment></comment></comment></comment></comment><comment><USER7> Austerity, is it really? How about not increasing spending at the same pace as other countries. Many countries could be come debt free by simply keeping spending increases under the rate of inflation.

Krugman was having a hissy in 2014 about Germany for similar things, yet it worked for the Swiss. They have a cap! So staying under three percent paid off for the Germans and this upsets those who subscribe to the idea that government spending is never bad, well if you never plan to pay it off in your lifetime you can borrow against the future quite easily.

<comment><USER8> Why going debt free though? What's the point of going debt free? The real economy is dictated by production and consumption, not amount of number that you have on the either side of the balance sheet. If going into debt creates a bigger economy by balancing/revitalizing production/consumption, it should be done. The debt gets larger but so does the economy.

<comment><USER9> This assumes the debt you're incurring is going to grow the economy. This is a big "if" in most developed countries, where no amount of debt will change foundational demographic transitions (see: Japan).

But as long as you control monetary policy and can inflate debt away in the future, no one today really cares as the can is kicked down the road.

<comment><USER8> And that's correct too, how much debt you have doesn't nearly matter as much as the perception that it will be paid eventually. And sovereign countries (Might only be a few on this planet) have almost unlimited choices there. The only kind of debt that matter is the debt denominated in another currency, which is dangerous.

</comment></comment></comment></comment><comment><USER10> Uhm, sorry, but is the author serious?

I mean, how did we come to the point where not being indebted is bad and should be condemned?

<comment><USER11> Because government finance is not the same as personal finance. Debt craze gripped the US in the early 2010s shortly after the lows of the great recession, defecit spending would've boosted the economy and allowed the US economy to recover quicker, instead we have a 10 year recovery that only recently started to provide gains for the most marginalized workers. Also, climate change is a existential risk, I'd rather finance solutions with defecit spending now than finance a war over water in the future.

<comment><USER10> If I remember correctly, it was a debt crisis that caused this. You basically allowed people who couldn't pay to "own" houses that were so beyond their means that (combined with a couple of financial derivatives) it collapsed the economy.

Now the solution is clearly more debt?

<comment><USER11> Once again, there is a difference between sovereign debt and personal / corporate debt. Subprime mortgages are subprime because the debtor has a risk of default, the US prints it's own currency, issues debt in its own currency, has some of the strongest institutions in the world, and controls the global reserve currency. The risk of default is essentially nil. When governments spend money on infrastructure and health / education the ROI is positive.

<comment><USER10> Germany is not in a position to print the reserve currency of the planet.

<comment><USER11> I'm not advocating for Germany to go all MMT here, but negative bonds are a clear indication that government has ample room for debt financing. Germany has notoriously poor internet service, investing in broadband infrastructure could help them transition into more of a service economy, which would be a smart hedge as the slowdown in Chinese consumption led to a slowdown in consumers buying German cars and a contraction last quarter. Also as mentioned, all the European players are big on tackling climate change -- why not fund solutions? Instead, Europeans leaders like Macron have gone with the politically infeasible route of higher petrol prices.

<comment><USER10> Germany has invested substantially into tackling climate change. Google "Energiewende".

Maybe also do some research on the internet infrastructure in Germany. It's a cartel. That's why service is so bad.

I'm not saying I'm against good infrastructure investments. But just telling us to "keep spending" because "debt is cheap" won't cut it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> In both governing parties, SPD and CDU/CSU, many people including government ministers and the chancellor-to-be are now willing to give up on "no debt"[1].

Even fiscal hawks are now playing ball with that new party line.

Expect Germany to make debt again.

[1] This refers to the policy of "Schwarze Null"/"black zero" which means revenue and expenditures shall be balanced. This has only been a policy statement that the former finance minister achieved for the first time in decades and the current finance minister adhered to. This must be distinguished from the "Schuldenbremse"/"Debt Brake" which is actually in our Constitution and limits the amount of new debt the state is allowed to take on.

</comment><comment><USER13> Germany had a Harvard problem - [https://en.wikipedia.org/wiki/Growth_in_a_Time_of_Debt](https://en.wikipedia.org/wiki/Growth_in_a_Time_of_Debt)

</comment><comment><USER14>
      > Realistically, America has no ability to pressure Germany into changing its domestic policies.

This statement is so false. US is already pressing to spend idotic amounts of money for military budged.

Next time in NYT: Germany has too much debt. Us rating agency about to drop rating...

</comment><comment><USER15> Hacker News has a paywall problem.

</comment><comment><USER16> Here's a simple fix to getting people to not obsess over debt - <USER2> debt. Recognize it as the nonlinear burden that it is, and that, unlike Krugman's belief that ignoring it makes it a'ok, that it needs to be addressed and not kicked to the next generation. Make it unacceptable for politicians to incur debt for anything other than a catastrophe, and absolutely not as a normal way of doing business. Yes, America, I'm especially criticizing you, for 20 trillion reasons and counting. After all, if it's so unimportant, then it should be trivial to eliminate.

<comment><USER13> >After all, if it's so unimportant, then it should be trivial to eliminate.

I think you would have to scrap nearly every piece of fintek since at least the time of Newton and completely reinvent how modern monetary systems and economies work from the ground up, to eliminate debt.

</comment></comment><comment> lota-putty This reminds me of :

Daniel: Drainage! Drainage, Eli, you boy! Drained dry. I'm so sorry. Here: if you have a milkshake, and I have a milkshake, and I have a straw — There it is. That's a straw, see? Watch it. Now my straw reaches across the room, and starts to drink your milkshake. I. Drink. Your! Milkshake! [makes a loud slurping noise] I DRINK IT UP!

USA asking everyone to give up their milkshakes!

World has the USA problem.</comment>


The 70-Year-Old Computer That Runs on Water - <AUTHOR> http://www.wired.com/2014/11/tech-time-warp-week-70-year-old-computer-runs-water

<comment><USER2> These machines were invented in Soviet union ca. 1930 and were in mass production until 1980, and only went into total disuse and were scrapped when perestroika began and brought smuggled used IBM XTs along with it. For many tasks, with the level of Soviet per hour tech workers pay and level of technology, they were more efficient than all Soviet pre-microprocessor digital computers and some early microprocessor-based ones. All thermal and mechanical simulations for construction engineering purposes were successfully ran on them.

As for the economic tasks i don't know, i don't think it could work the the soviet economy - where imbalances weren't necessarily cancelling themselves and were frequently kept with a purpose, or just stayed because there was no force motivated to fix. But logically, market economy resembles connected volumes with liquid of various level difference and hydraulic resistance and can be described with same equations, so in the West it probably worked very well.</comment>


Why You Need To Work For A Big Company - <AUTHOR> http://onstartups.com/tabid/3339/bid/33111/7-Reasons-Why-You-Need-To-Work-For-A-Big-Company.aspx <comment><USER3> Some of the things I learned at big companies:

\- Process is not the enemy, inefficient process is the enemy

\- Project Management makes a huge difference

\- Technical people make for bad managers

\- Communication is critical, ego only creates conflict, learn to pick your battles, don't sweat the small stuff: how to deal with your work and other human beings

\- Perks are the last thing you should worry about

\- When nobody cares, everything turns to shit

\- Not centralizing/simplifying management of resources makes everything take a lot longer to get done

\- Salaries are arbitrary and 2 weeks of vacation is total bullshit

\- Health insurance for non-corporate people is expensive

\- Unless you want to fix the same problem twice, do it better the first time

<comment><USER4> > " _Salaries are arbitrary and 2 weeks of vacation is total bullshit_ "

Could you expand more on what you mean by the vacation stuff? Do you mean like it's total bullshit that you only get 2 weeks? I was not sure how literal to take that.

<comment><USER5> I suspect that's what he meant. In a small company two weeks is often all you'll ever get, if that much. In a large company you'll start there and pretty quickly get to three weeks, and if you stay long enough you'll get to 4-5 weeks.

This is in the US, of course. In a humane country you start with 3-4 weeks, and I think after a couple of years in some European countries you get around six months of vacation per year ;-)

<comment><USER6> You need to work at better small companies.

<comment><USER5> My company is pretty good about vacation time, plus flex time whenever I need it. I was generalizing.

</comment></comment></comment></comment></comment><comment><USER7> Speaking from a non-IT standpoint (mech engineer, rail industry), BigCo offers a number of cool benefits that I'd not get working for SmallCo (that may or may not hold analogous to the IT sector in some cases):

\- Economies of scale #1: when you're purchasing 10,000 instances of something, people listen and new techniques of doing things become available.

\- Economies of scale #2: Design changes when milking an extra $100 out of the design or manufacturing process means saving $1m at 10,000 instances. You get exposure to new design/manufacturing techniques as a result.

\- Project diversity: I could find 20 projects in this office of 150 engineers, all significantly different. They range across design, asset management, PM work, maintenance/reliability, acquisition, etc. Each applies to a number of different targets - fixed plant, mobile assets, facilities, etc. If I grow bored of something I can reasonably rotate to something new and different within 6 months. More long-term, there's opportunities in multiple countries if I so wish to pursue them.

\- Institutional knowledge: I can walk in to our drawing room and still find drawings dated from 1870. Some of the greybeards here seem almost as old, and come with a huge amount of knowledge (both specific and simply general 'tricks of the trade') that isn't recorded anywhere.

There's also downsides:

\- Work sometimes feels like it's a game of thrones. The fiefdoms can grow tiring.

\- Stuff happens slowly. BigCos carry inertia that can be cumbersome. Counterpoint: inertia can produce some amazing results if you get everyone paddling in the same direction

\- Career advancement usually requires jumping ship to different companies. Said greybeards are in it for the long haul and unless a new position opens up, you're generally stuck below the glass ceiling.

<comment><USER8> Great insight from the physical world. I really liked economies of scale points.

</comment></comment><comment><USER9> One reason why one goes to college is to learn how to learn social acclimation around people wealthier than you are, because this is a useful skill in convincing them to give you things that you want. A company, and the decisionmakers thereof, is almost by definition richer than you are, and broadly representative of an entire class of entities whose behaviors are totally opaque to you if you've never worked in one (+). That would be unfortunate, because those entities have budgets and are willing to spend them on you if you know how to work with them.

\+ People who have never worked in a megacorp often think that their literal internal decisionmaking model is "MAXIMIZE THE EVIL.", which is both wrong and will not allow you to successfully predict their behavior.

<comment><USER10> Are there one or two things you would recommend to help bridge that communication gap between a solo person and a megacorp? One thing I've observed (possibly incorrectly!) is that megacorps seem to "like" to do business with other megacorps.

<comment><USER9> Rule #1: all megacorps are, like Soylent Green, made out of people. If you want to sell something to Microsoft, you aren't selling it to Microsoft, you're selling it to one or a few identifiable people within Microsoft. The entity we think is Microsoft is the sum of the emergent behaviors of lots of little Microsoftite particles which are bouncing around in Brownian motion.

After you understand that, it's VASTLY easier to get Microsoft to give you money, and you might find that Microsoft (or whatever BigCo) you're dealing with considers More Money Than I've Ever Dreamed Of (TM) to be a fairly routine decision, in the same manner that you might decide to purchase a new keyboard.

In terms of communication style: learn to talk to business people. ROI and TCO over TDD and DRY, PowerPoint decks over README.md in your Github projects, wearing a suit when appropriate instead of making fun of people who own one, etc etc. It's really not hard to learn how to talk like someone if you listen attentively. You've done this your entire life in other contexts and other communities. Decisionmakers at BigCo are not intrinsically a more hostile audience than, e.g., your local freestyle rap club meetup thing, the rhymes are just different, yo. [1]

[1] I should stick to WoW metaphors, but you get the general idea.

<comment><USER11> It should be noted that 'wearing a suit' is not just wearing your normal thinkgeek t-shirt with a suit jacket over the top.

</comment></comment></comment></comment><comment><USER12> Say what one will about Microsoft, I probably learned more there than anywhere else. Source control and how to branch/merge at scale. How to work cross-team relationships. How to work with people much smarter than I'll ever be. How to do a little political wrangling when necessary, and a bunch of other things I've probably forgotten.

Having worked at several small companies since, it's disappointing how often I get to watch teams find out the hard way why things are done this way, or not that way. Sure, I will point out the potential folly along the way, but few care to hear it, and instead wish to invent their very own wheel because their case requires a special kind of roundness.

<comment><USER13> It sounds like our experiences at Microsoft could hardly have been more different. Virtually everything I learned at Microsoft could be filed under "whatever you do, no matter how desperate you are, never do it this way". The systems were unreliable, inefficient when they worked, and the number of person-hours routinely wasted on tool management was staggering. The culture was unhealthy, competitive and individualistic, sometimes to the point of hostility. You saw cross-team communication, I saw at least a quarter of every working day wasted in routine status meetings, in which two or three of the ten or twelve people present spent an hour making a couple of decisions while the rest of us tried not to look too bored...

Of course Microsoft is a big place and different divisions work differently. I'll never take the risk of landing in such a mess again, though.

<comment><USER14> > I saw at least a quarter of every working day wasted in routine status > meetings, in which two or three of the ten or twelve people present spent an > hour making a couple of decisions while the rest of us tried not to look too > bored..

That sounds horrible. Did you mention your concerns to the people who owned those meetings, in a way that made it clear you were trying to help improve them?

I've had success several times with this in BigCo, with various satisfactory outcomes:

1\. "You're right, this meeting is BS! But it has to happen for various reasons X Y Z -- since you don't care about this area you don't need to come, we'll grab you if we need you."

2\. "You're right, and other people feel tuned out as well, so let's try cutting it to 10 minutes / mailing out an agenda beforehand / starting exactly on time."

3\. "You're right, this is an inefficient way to gather state so we're going to just swing by each person 1-on-1."

4\. "You're right, this team is too big so we're splitting in 2/3 smaller groups"

<comment><USER13> No, I never did. It just seemed to be an accepted part of the institutional culture, and I felt like fighting against it would have only made me look like a complainer. Maybe someone with more status could have tried it, but I was just a newbie and nobody seemed to care what I thought.

I think the project I worked on was worse than average because it was the sort of cross-cutting change that affected a lot of different teams - six different products, I think? There were a _lot_ of PMs involved.

<comment><USER11> I'd just like to add that pointing out seemingly mundane things like these are what allowed me to move from engineering into the consulting team at my company (which is what I wanted).

It's worth testing the waters a few times. You'll know pretty quickly if they value your input, and if not you can decide if you want to continue working for them.

</comment></comment></comment></comment></comment><comment><USER15> Gah. Sorry, No. My experience has been the opposite.

In particular:

"You see lots of very good ideas (like proper source control)" \- you mean the group that still uses VSS 4.0 on a network share b/c they're terrified of moving their repo to Git (or even SVN)?

"You get to work with lots of clever people" \- no, you get to work with people who work there for no reason other than they live close to the office and have spent the last 14 years building an impenetrable fortress around themselves.

"They have lots of perks" \- Yes, that one day a year I got to donate $5 to cancer research so I could wear bluejeans (collared shirt still, of course) makes it all worth it. I'll take my catered breakfasts, lunches, impromptu beer runs, work-from-anywhere policy and unlimited vacation days, thank you.

"You are not going to be sent on that week-long training course on using Oracle or have your part-time MBA fully-funded while at that boot-strapping startup." \- Ok, starting to think this is a case of Poe's law in action...

Yeah startups (and small companies) come with their share of headaches, but I'll take it any day over the soul-crushing, creativity-stifling cubicle hell that is a big company.

<comment><USER16> A few retorts (I work for Big Tech):

 _" You see lots of very good ideas (like proper source control)" \- you mean the group that still uses VSS 4.0 on a network share b/c they're terrified of moving their repo to Git (or even SVN)?_

Unsurprisingly, companies that have millions of lines of code have to take extra precautions.

 _" You get to work with lots of clever people" \- no, you get to work with people who work there for no reason other than they live close to the office and have spent the last 14 years building an impenetrable fortress around themselves._

This is a lazy dismissal.

In reality -- lots of smart people work at big companies and small companies. That being said, big companies will invariably have more people dedicated to research than startups. Microsoft Research alone has over a hundred people just doing brilliant things.

 _" They have lots of perks" \- Yes, that one day a year I got to donate $5 to cancer research so I could wear bluejeans (collared shirt still, of course) makes it all worth it. I'll take my catered breakfasts, lunches, impromptu beer runs, work-from-anywhere policy and unlimited vacation days, thank you._

Again, this is lazy and untrue -- unless you want to say that Facebook and Google's perk packages are about wearing bluejeans -- but I think playing the perks game is silly anyway. Distilling things down to money (with some exceptions, like WFH) is always the smarter way to go.

\---

Personally, I think the biggest difference working at a big company vs. a small one is that of depth vs. breadth. At a startup, its not beyond the realm of possibility to understand the majority of the code base: you'll be wearing lots of different hats, doing lots of things at once. At a big company, the organization is usually such that you'll spend your entire employment working on one little niche -- this has its advantages (you become an expert at that one thing) and disadvantages (you're only an expert at that one thing, after all).

Personally, I can't imagine why someone wouldn't want to just spend time at both types of companies and see which one they like more.

<comment><USER15> Fair enough. Of course, I am only drawing on my own anecdotal experience. However, the big companies you mentioned above, Facebook, Google, and Microsoft - I would propose that they are truly exceptional in "big company" culture. Like one-in-a-million exceptional.

Perhaps my experience in each world was exceptional, but I have a feeling they were rather typical.

<comment><USER17> Those three being "1 in a million" implies that there are three million big companies.

</comment></comment></comment></comment><comment><USER18> The main difference between working for a big company vs. a small company is that the roles tend to be explicitly defined and specialized at a big company. You don't need/get to wear as many hats as you will at a small company or a startup. Basically, instead of being a jack-of-all-trades / "full stack" developer, you might become an expert on one layer of a huge technology stack. This can be good, or bad, or mixed. There is more formal training and you can get deeper knowledge, but it's harder to get broad knowledge. It can be hard to change roles or try new things. Generally, I think learning "full stack" is preferable when you're young, and specializing might be better as you get a little older.

<comment><USER5> I worked for a fairly big company (100+ employees pre-acquisition) and I was able to develop a very broad role. I started as just a web UI developer, but soon helped design the deployment architecture of our entire runtime system and throughout my tenure I designed and implemented many of the services within that architecture. That included everything from DB schemas, custom XML databases, authentication servers, several mid-tier servers/services, as well as always being the lead owner of the UI.

What helped, I think, is that I was part of a small team in that big company. At peak we probably had about two dozen programmers, with 8-10 on my team. That's not much bigger than the team I'm on now in a tiny company where I also get to work end-to-end.

I disagree with specializing as you get older: there's going to be a tendency to do that, but it's the last thing you want to do. Never stop learning, never stop broadening your skillset. Sooner or later you're going to be a 40+ year old developer looking for work, and if you're a specialist you're going to be looking for a long time. As an experienced developer with a proven track record of adaptability you'll be able to justify the salary that you're going to want/need.

<comment><USER19> IMHO 100 people isn't a big company at all... two dozen programmers can still comfortably fit in a room and know eachother. My current company has 200k employees, we spend a large amount of time just looking for whoever is responsible for something...

<comment><USER5> When we got acquired we became much, much bigger. Depending on how you counted divisions you could come up with anywhere between 50 to hundreds of developers. A few of our projects involved developers coordinating across those divisions, but when I left they were still fairly independent most of the time.

</comment></comment></comment></comment><comment><USER20> I think the article misses on all the biggest benefits I had working at a BigCo:

1) You can actually get to work with a lot of companies. We acquired a ton of companies over the years, and I'd often go work in those companies post acquisition while it was still being run as a separate company. So these were smaller companies that were generally successful - you got to see a lot of different practices.

2) Once you are done learning a new job/role (or new company as above), you can easily get the opportunity to move to around to different departments or jobs. I personally did consulting, product management, engineering, architecture, sales operations and strategy (sometimes for the mothership, sometimes for the acquired companies).

3) It's not about smart people I wouldn't say - its about mentors. At a small company, there are just less senior people around, and they are often more focused on delivering. At a big company, more senior execs are really willing and able to mentor the superstars in their teams that make them look good. You combine that with moving about companies or departments, and you get a mix of different mentors with different styles and strengths.

4) It won't apply to everyone, but I personally must have evaluated 50 - <USER2> companies for M&A or partnerships. I know exactly how to analyze a business, where to look for skeletons, what works well/what doesn't, what a big company will look for (and what are red flags) in an acquisition, when you can/can't get a partnership and what you can use to your advantage in negotiations, etc. Will all be extremely useful skills when you're on the other side of the table.

Between the above things, you can learn so much. Stuff like the food/work environmental is so irrelevant compared to this.

Don't get me wrong - I have no intentions of ever going back to a big company again. But these were the big benefits for me.

<comment><USER21> I think you were fortunate, perhaps exceptionally so, in your experiences - few people will get to move around as much as that.

</comment></comment><comment><USER22> I worked at startups before joining megacorp. I always thought I wouldn't like working at a big company but everything the author said resonated with me. At some point I can see myself going back to a smaller outfit but for now it's great.

What the author doesn't mention and what I perceive as a great plus are the tools and infrastructure I get to enjoy. We've got a lot test equipment, machine shops and technicians a smaller shop couldn't afford.

On the other hand, I keep hearing managers say "we have to be nimble, like a startup". I think that's exactly the wrong approach, big companies should approach big problems that startups can't tackle.

</comment><comment><USER23> The biggest big company problem is the lack of focus slows everything down. The ability to execute is there, but the focus is not. Start ups will attempt to manage 20 products and services at once, and that feels like too much, where big companies attempt to launch 200 new products, 80 new services, 40 special partnerships, 750 pet projects, 380 special events, 30 broad initiatives, plus the CEO mandate of the week ... all while maintaining support for 3100 legacy products and acquisitions ... the result is everyone is very busy yet unfocused. Too much context switching at all levels, too many works in progress get blocked on waiting for other teams to contribute their part.

Second challenge of big companies: trying to keep up with all of the latest project code names which change on a weekly basis.

</comment><comment><USER24> I guess it depends on your definition of "large." I worked at a large company (20k+ employees), and each department was like its own dysfunctional 50 person company: nothing got done, the technology was stale, and the perks were minimal.

I work at a medium-sided company now (~200 employees according to Wikipedia), and I love it. We have a great mix of technology and perks, and are all treated really well. I worked at a handful of start-ups during the first tech boom (and during the crash), and some were exceptional and some were meh.

I wouldn't rule out working at another start-up sometime in the future; it would just be one of the many factors I consider.

<comment><USER25> It depends more on the company than the size.

I work for a company with over 60k employees and the technology is incredible, and the people are interesting and super smart.

</comment></comment><comment><USER26> Normally I'd just let a post like this go, but that word "need" really rubs me the wrong way. No, I don't _need_ to work for a big company, ever. I haven't yet, and don't ever plan to do so. Go away.

I learn an awful lot? Because I can't learn things otherwise? Come on.

I get to work with lots of clever people? No problem doing that now.

Large community? Ditto.

Perks? Uh... how does that translate to "need"?

You learn the art of politics. Great! What you're saying is, I _need_ to work for a big company so I can learn something that's only useful when working for a big company. What?

You have time to reflect? Why assume that all small companies are balls-to- the-wall, 100-hour-week, venture-funded, Valley startups? Oh right, because this post comes from a fantasy world where the only two kinds of companies are gigantic Googles and tiny places filled to the brim with foosball tables, not actually the Earth where I live.

You get a baseline? What is this I don't even.

<comment><USER27> You haven't worked in a big company so not sure if you are even qualified to comment on this post in such language. If you previously had the experience in working for a bigger company and then mentioned these things - your comment would have been a lot more credible.

You don't know know what you are missing till the time you experience it. Dharmesh Shah is one of the more acclaimed entrepreneurs in the industry and I do believe his words more than someone who doesn't even know what it feels like working in an environment he is commenting on.

<comment><USER26> It would be nice if you could tell me what I got wrong instead of just saying I'm not "qualified" to comment. Maybe we just have different ideas of what the word "need" means. I've managed to go three decades and change without this, and don't see any obstacles to continuing. To me, that means I don't "need" it. I don't need to work for a big company to see that.

I have no idea who Mr. Shah is and don't really care. I am criticizing the article, not the author.

</comment></comment></comment><comment><USER28> The biggest reason to work at a big company is that you can have an opportunity to work on "stuff that matters" fairly quickly and you get introduced to ways of dealing with processes around working with important things, which can give you skills and confidence you might not otherwise attain.

You're not going to acquire the experience of knowing what it's like to jump headfirst into fixing a build break during the runup to release on a billion dollar product unless you're working at a company that has a billion dollar product, of course.

</comment><comment><USER21> Rubbish

Every CxO at every large company looks at startups as _the_ model to emulate - lean, focused, full of feedback.

The benefits listed, every single one, are examples of overlooked, hidden or inefficient practises by the large company - practises they try hard to eliminate.

Do you think the CEO of Megacorp thinks that weeks "training" in Amsterdam was a good use of his money? Do you think he realises there are good passionate people trying to do good on no budget. If he found out he would either give them a budget or fire their arses for working in the wrong things.

As for your time for reflection ... screw that, reflect at home.

No - big companies are trying very hard to stop being a source of "informal" VC money, rest stops for the tired and weary or uncontrolled cash spenders.

One day they might succeed.

<comment><USER29> i've recently spotted in the wild the latest mutation of the beast - "lean 6 sigma".

10 years ago we had "6 sigma" pandemic in the Valley, last 5 years - "lean" and now ... behold their monsterous progeny.

<comment><USER30> As a current Lean Black Belt and 6Sigma Green Belt working in QI... I cannot agree with you more.

Still, some people just can't look at a rubric to help you organize your thoughts/analysis without dropping to their knees and worshiping it as the second coming of Christ.

Lean, 6S, TQM, CQI, not a single one of them has conclusively been shown to actually work long-term (post-6 months). But, on the bright side, it's a fantastic job for getting to see every last corner of operations in an organization. I'm using the position to learn the pain points of my preferred field, before going into start-up land to address their needs.

</comment></comment></comment><comment><USER31> Over the years I have worked for both, much of what the author said is true, there are many things that are great about working for a start up,I would be preaching to the choir to mention them here. The one thing that got left out is the access to resources. Some of the projects I have worked on, just due to the scale, would have been impossible to do at a start up level, they just do not have access to that kind of capital usually. There are some things that are just too big to do that way.

</comment><comment><USER32> 8\. You work on really large applications and projects. This is completely different from working on small projects.

</comment><comment><USER33> You also learn what kinds of unmet needs there are in the marketplace. You learn how decisions are made, who the gatekeepers are, how budgets are allocated, and what frustrations exist with the current roster of vendors - not to mention building your network and credibility in the industry. Want to develop a product/service to sell to the ______ industry? Go work there for a year or two first.

</comment><comment><USER34> The author's point isn't that big companies are better, just that it's a good experience to have. I worked for a public company post acquisition and it was a great learning experience (some good lessons, some "don't do it this way" lessons, but overall good). I wouldn't want to make a career working for big companies, but I think you're better off as a business person if you end up in one from time to time.

Now if you want some definitive advice on where not to work. Don't work for a husband and wife operated company, ever. There you will encounter the worst aspects of a lifestyle business combined with nepotism (especially the unfireable but totally incompetent spouse).

Otherwise spend some time in a combination of startups and big companies. Both have their strong points, and remember 90% of startups fail, so its not as if startupland is nirvana.

<comment><USER35> Never work for someone else's lifestyle business, ever.

</comment></comment><comment><USER36> The biggest difference that appears to me is the lifetime and size of applications. I work on applications that have existed for a decade (and that's short, among our various application teams). Many of our applications are hodge-podged mixes of legacy and more modern technology.

Whenever we "rewrite" an application that has outlived any possibility of keeping it alive, we can't start from scratch: we have to continue meeting all existing customer needs. So even from day one designs are often bloated and frustrating. There is no "MVP".

Meanwhile at a startup you can "move fast and break things", and when an application starts to get stale either it can go away, or you can switch to another startup and begin fresh.

</comment><comment><USER37> Had my own startup. Brought my lessons into a large company. Worked wonders as a result and proud to work with them. To this day, still learning a lot.

</comment><comment><USER38> It's a valuable experience, but can be a very frustrating one to go through, especially if the company has internal power battles and little appreciation for the importance of technology.

<comment><USER25> Same can be said of startups, it's not really big company specific.

<comment><USER39> It can be said in general: If there is a lack of technical expertise or value for any company, expect much frustration.

</comment></comment></comment><comment><USER40> > _" And you will get a range of ages - let's face it, most startups reckon > you are past it if you are over 23."_

What? Not to disparage people my own age but that seems like hyperbole. Is this the image most people have of startups? Fresh out of college at 23 (a few months ago) I couldn't even find a decent startup (that I wanted to work at*) that was offering positions to new grads.

</comment><comment><USER41> The thing to remember about "big companies" is that they don't just spontaneously come into existence at that size; with x-thousand employees, y-percentage of market share, and z-millions of revenue. They are grown, over years or decades, because they've done something right.

Worth keeping in our minds when discussing such topics, before passing them off as competitive or cultural failures.

</comment><comment><USER42> Politics is one of the most valuable lessons learned at a big company. Although I work in a small startup, all the management is from big companies. Like any other startup, what's valued the most is getting stuff done. But I learned that shouting at the top of your lungs or bottling your emotions while being passive aggressive are the worst strategies in leading discussions.

I had to quickly learn how to present my argument in a non-confrontational way, get individual buy-in (and perspective) from all stakeholders before any meeting, and balance being transparent and forthright versus protecting your interests (it really helps that your interests aligns with company goals!).

To sum it up, "politics" IMO has made me a more effective leader.

</comment><comment><USER43> I sincerely recommend working at a large University as an alternative to this. Instead of one large company it is a constellation of large companies. They are almost always desperate for more good talent, and in many cases the innovations you can bring to the table can benefit the entire community, not just shareholders and customers. Otherwise, all of these points hold true.

</comment><comment><USER44> There are things to be learned at big companies, but it is very bad to say X is right for everyone.

Big companies have been good for: \- Providing training \- Formalizing feedback \- Introducing me to a lot of people

But they also: \- Stifle career progression ("We have you doing X, so we are sorry that you can't help on Y") \- Are not nearly as safe as their size would suggest \- Tolerate mediocrity

</comment><comment><USER45> You'll _probably_ make more money at a large company than at a startup unless you get in with single digit or better equity and you get lucky.

Other than that, I prefer the creative chaos of startups to the process and tools over interactions and individuals of large companies (even the ones that pretend they're _agile_ )...

</comment><comment><USER46> I really grok this article. One thing that I found was that after learning to navigate office politics I really didn't like it. I made it a point in subsequent jobs to get a feel for what politics are like and if they seemed to be too toxic to avoid the company.

</comment><comment><USER47> The point of the article is to say everyone should have experience working at a large company to get perspective. The same thing can be said for small startups. The debate over which is better is endless and childish.

</comment><comment><USER48> You get to work with smart people? How is that unique to bigger companies? In fact, I'd say it's more unique to smaller companies, that have to be more selective with their hiring process.

</comment><comment><USER49> This is exactly how people rationalize the story of how they became "trapped." And learning politics is nothing to be proud of or to seek out.

</comment><comment> slash-dot Not a very credible source seeing that onstartups.com is run by a co-founder of Hubspot, which is starting to become a rather big company.</comment>


Show HN: ConvertKit – Email marketing for authors - <AUTHOR> https://convertkit.com

<comment><AUTHOR> As an ebook author I found that the common email marketing tools just didn't cut it. So I built one specifically to help technical authors make more money.

I'd love to hear what you guys think!</comment>


Hands-On Scala Programming - <AUTHOR> http://handsonscala.com <comment><AUTHOR> This was posted once before when it was work in progress, I thought it would be nice to put it up again now that it is complete :)

In one 400 page book, Hands-on Scala takes you from from FizzBuzz, to Sudoku solving, to Websites and API servers, all the way to implementing programming languages, actor-based concurrent architectures, and massively-parallel web crawling with futures. Every chapter has multiple multiple self-contained executable examples, and multiple exercises with full executable solutions.

It's a paid book, but the first 5/20 chapters (~100 pages) are free to read online or download in PDF/Epub/Mobi formats, as is the github repo of 125 executable examples.

Whether you are a Scala newbie or an experienced Scala programmer, there's something for everyone in this book. The chapters on Actors and Futures in particular are the best explanations for the concepts you will find in any language, and would be useful even for people not using Scala.

Feel free to check it out!

<comment><USER2> The previous discussion: [https://news.ycombinator.com/item?id=22914610](https://news.ycombinator.com/item?id=22914610)

</comment></comment><comment><USER3> I bought Hands-On Scala Programming as soon as it became available. I bought it on the strength of Li Haoyi's blog posts about Scala, which I have enjoyed for years: [https://www.lihaoyi.com/](https://www.lihaoyi.com/)

This book is an excellent way to dive in to Scala for application development, even though at this point it is more of a refresher than an introduction for me personally.

I started using Scala at a new job in 2014 with no prior Java/JVM experience. I bought Functional Programming in Scala, followed by Programming in Scala. FPiS was completely the wrong choice for getting up to speed in my new role, though it was academically interesting. Programming in Scala was closer to what I needed although it didn't deal with larger ecosystem issues. Hands-On Scala Programming feels like the book I should have started reading the first day I started working in Scala development.

6 years later, I no longer have the new-user perspective on Scala and the JVM ecosystem. Does Hands-On Scala adequately prepare someone for the JVM/Java quirks that leak through into the Scala environment? I can't tell now. I've internalized too much of that knowledge.

Assumed Java knowledge was a rough point for me in the first year or so using Scala. If something goes wrong when you're fetching Maven dependencies in an SBT based project, and you have never used Maven-as-Maven because you never used Java before, you may encounter some baffling error messages and lack the context to understand where you go next to fix it. I also encountered a lot of "Like Java's Foo, but with X" explanations of Scala features that didn't help because I never used Java. In the case of the problem with Maven dependency failures and baffling error messages from SBT, I had to resort to running SBT under strace before I found the root cause.

<comment><USER4> Same thing happened to me when trying to learn Clojure without Java knowledge or F# without C#. It's a big hurdle.

<comment><USER5> I did F# without having any deep knowledge of C#. I'm doing Scala without being a Java expert. It is all quite possible and a lovely experience. Moreover, the benefits that F# brings over C# and especially Scala over Java are enormous.

</comment></comment></comment><comment><USER6> Easily one of the best technical books I've read. I really enjoyed the clear examples and clear writing. Making something extremely simple is super important for understanding.

And the lovely typesetting is a huge plus when reading this on my laptop. Looks great even when viewing in two-page mode.

Only complaint I can think of is that I'd have liked more exercises at the end of each chapter. Ideally with less Sudoku as I don't want to have to dive into the rules of a game in order to practice the collections programming. But this is really a minor nitpick, 5/5 book in general.

<comment><AUTHOR> Glad you like the typesetting! I'm a professional web developer, among other things, and the typesetting is just HTML + Bootstrap CSS 4.4.1, rendered into PDFs using Puppeteer. Turned out looking much better than I had hoped!

<comment><USER7> Oh wow, I didn't realize that this bootstrap! Do you mind documenting your typesetting process? Would be a fun read!

<comment><AUTHOR> I'm planning on open sourcing the build pipeline soon, but it's basically a Mill ([http://lihaoyi.com/mill](http://lihaoyi.com/mill)) build pipeline which uses Scalatags + CommonMark-Java + Puppeteer + ApachePDFBox + EPubLib + kindlegen to transform Markdown into HTML and then into {Web, PDF, EPub, Kindle} X {sample, full} versions

Updating a single chapter and re-rendering the PDF takes less than 1 second, and re-rendering the entire book in one format takes about 30s running parallel on my 4 core macbook.

</comment></comment></comment></comment><comment><USER8> Hm... Was this posted seven times?

[https://news.ycombinator.com/from?site=handsonscala.com](https://news.ycombinator.com/from?site=handsonscala.com)

<comment><USER9> Yes, he finally got traction.

</comment></comment><comment><USER10> Scala is a language I find interesting. Between Spark, Akka, and all of the FP, it seems like it has most of the boxes I'd want. I have read mixed things about the language though, specifically with respect to its future viability and development. Is Scala worth learning in 2020?

Are there other languages with a well developed actor model that is also performant with numerical computing? That seems like a deal breaker with respect to a language like Elixir.

<comment><USER11> I'm in this boat too. If you look at lot of the Scala talks from 5-8 years ago it talks a lot about why Scala is better than Java, but since then Java has copied a bunch. Now Kotlin is taking over and Scala seems like yesterday's language. I've heard its really slow to compile too which makes it frustrating.

<comment><AUTHOR> The book's web page makes this pitch: Python-like convenience with Go-like performance, easy safety and correctness via compiler checks, and a huge ecosystem of tools and libraries. Compilation time is definitely a tradeoff, but if any of those bullet points seem interesting to you then you should definitely give Scala a serious look

<comment><USER12> I think a better way to sell a language is to name a few concrete niches that they are amazing at. For example: C for low level systems, javascript for browser apps, bash for shell scripts, java/swift for mobile, erlang for actor models, haskell for compilers, python for ml, go for distributed systems, etc etc.

To me, scala used to own the niche of "if you must use a jvm language but don't want to use java". But now kotlin is the first language that springs to mind. What would you say scala is best in class for now?

<comment><USER13> I'd argue Scala still owns that niche. Kotlin is nice if you're stuck on Android, but with the speed Java is progressing I don't see a huge difference. Especially in 2-3 years.

Also with Scala you get a best in class JS compile target, a great scripting platform in Ammonite, and Graal native image for binaries with fast startup.

<comment><USER14> > I don't see a huge difference. Especially in 2-3 years.

There is a huge difference now. Maybe 50% of that difference could be made up by what Java has in the planning stage.

Even if it was 100%, I'm writing code right now.

<comment><USER13> What's the huge difference? Coroutines? Boilerplate reduction? I guess there are some minor type system improvements, but its not like you're getting dependent types or anything like that.

<comment><USER14> It is the sum-total of all of the little things. I could write out a list but it would end up looking like the official site's sidebar.

It all adds up to making me far more productive and more sure of my code.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Just used Gatling which is based on Scala for performance testing on one of my projects, it's the best performance testing frameworks I have ever used. highly recommend

</comment><comment><USER16> Scala has a really steep learning curve when you encounter user libraries. Though I am moderately experienced in functional programming, I still have difficulties understanding scala libraries from very experienced users. It almost feels as if I didn't understand the language at all.

It is true that you can use the JVM ecosystem, but you'll see that your code doesn't look like scala at all. Then you look for scala ported version of java libraries (some essential but boring libraries like xls read/write) that isn't likely to be maintained actively

<comment><USER17> I'd agree with this. I think it's because if you're writing a web server then you're probably settled on one way you're going to deal with say asynchrony - plain futures or cats or whatever. But Scala has this level of abstraction above that where you can write a library that doesn't care which of those you're using and just slot in around your choice. What it can't avoid is that as soon as you jump into the source code of that library you see all these type classes everywhere and have to mentally fit your concrete use case into those complex looking function signatures that probably use concepts you're not using much in your actual application code.

For better or worse it's super easy to write application code in Scala without going to a very abstract level, particularly in an ecosystem like Play. And that does make library code feel less familiar because it's using features that you just don't necessarily use very much in your application code.

<comment><USER16> Play is very well documented (compared to other libraries) but some of scala libraries are not very well documented that I had to actively dive into source code level. Reading and understanding it wasn't easy at all.

Scala seems to have many black magics under the hood and this is one of biggest drawback of using scala

</comment></comment></comment><comment><USER18> I just bought it. It looks beautiful and the topics are very practical.

With Scala 3 almost in sight, will this book update to Scala 3?

<comment><AUTHOR> It will, but the Scala3 launch date is still up in the air so I can't give any concrete promises as to when

<comment><USER18> That makes sense. Thank you for your response!

</comment></comment></comment><comment><USER19> Haoyi has written some excellent libraries and tools for scala. I use ammonite daily. Im sure this book is great!

<comment><USER20> Ammonite is great! I think it could use more exposure, especially the REPL.

</comment></comment><comment><USER21> Great book I can tell from the Contents. I used Scala for interactively inspect functions in jar you don't have source code. In most of other domains I tend to use other languages with a less powerful syntax to collaborate easier with other people.

<comment><USER22> > I used Scala for interactively inspect functions in jar you don't have > source code.

How do you do that? I've only used javap on the command line for this.

<comment><USER21> Of course I first decompile using cfr. And then use scala REPL to load the jar and call functions to see the effect and find the parts interesting for further analysis.

</comment></comment></comment><comment><USER23> Fantastic book from the sample chapters!

Any plans to offering a printed version using one of the print-on-demand services(Leanpub etc)?

I'd gladly pay the full $75 for such an offering.

I plan on using the book for a practical Scala course that I will be teaching in the fall.(Programming in Scala is fine but not as practical).

</comment><comment><USER24> I would love to buy this books, but the price seems way too high. I would pay ~$20 without thinking, but seeing that bundle costs $78 I don't feel comfortable anymore. I start to second guess if I really need this book right now etc.

</comment><comment><USER25> Fantastic book by a fantastic OSS engineer. Keep up the good work Li Haoyi!

</comment><comment><USER26> Thanks for great work!

I just bought a PDF version. It looks nice at the first glance.

Do you plan to keep updating the book's content and code in the future? I'm really looking forward to your views about Scala 3.

<comment><AUTHOR> The book is basically done for now. I will likely update it for Scala 3, but that's still a moving target, so I'll wait for the dust to settle before considering it.

I don't expect the code to need to change too much to support Scala 3: Scala 3 is likely going to be backwards compatible to a large degree, and the code you'll be writing in Hands-on Scala is pretty simple Scala that doesn't touch the more advanced features that might be affected by the upgrade

</comment></comment><comment><USER27> Oh, wow. This looks fantastic. Unfortunately far beyond my current budget, but definitely going to keep it in mind. I've been wanting to learn Scala for a while now.

</comment><comment><USER28> This looks absolutely fantastic! Does anyone know or have recommendations for a book similar to this but for Golang?

</comment><comment> bra-ket thanks for the book and blog!

what do you think of Scala adoption and prospects these days

<comment><AUTHOR> I think Scala adoption is doing great.

A lot of the initial hype around things like Akka and Pure Functional Programming has died down since the frothy excitement of 2015-2016, but honestly I think a lot of that hype was oversold and many of these things never quite lived up to their original excitement.

Right now, the level of hype has fallen back to where the _real_ value is: a solid language allowing flexible styles to suite a wide range of use cases, as concise and convenient as any scripting language, with excellent performance, tooling, and static checking to prevent defects.

With this book, I'm obviously hoping to drive adoption and prospects up, and I'm doing so by trying to sell the value prop above rather than the value props that were (over-)hyped in the 2015-2016 era

<comment><USER20> I agree that Akka was over-hyped, and over-used. I don't think that pure FP is or was over-hyped. It is, however a large reward for a large time investment to learn. Many simply don't have the time capacity or motivation to completely change their mindset from imperative programming.</comment></comment></comment>


Codebashing – Online AppSec Student Edition - <AUTHOR> http://www.codebashing.com/try-it <comment><AUTHOR> there's a student edition of 20 modules available from their website... its an interactive, online appsec/secure coding training platform for software devs... everything runs in a modern desktop browser.

</comment><comment><AUTHOR> looks like you can get 12 months of access for the cost of 1 month on their website under pricing.</comment>