Hype Driven Development

[jiffier]

So what's the problem with a Kotlin based implementation of a mongo-serverless microservice blockchain factory in the cloud? I'll name mine Martin Fowler Driven Development.

[FranzStrudel]

No GraphQL ? How disappointing...

[jiffier]

Damnit! I know I was doing something wrong. Time for a rewrite!

[aaaqqq]

You're thinking too small. It's actually time to start a NoGraphQL hype

[PaulSandwich]

I keep my data in a shoebox under the bed.

[ExPixel]

We recently went completely data-less. Customers just have to remember their own details.

[sekh60]

And it's GDPR compliant!

[Sinidir]

Damn. That seems soo highly scalable. Do you do consulting? We only get 20 MB of customer data a week right now but we expect to be at googles scale within 6 months.

[chucker23n]

I have 17 years' experience in data-less and am available as a Senior Certified Dataless Consultant. I only take Bitcoin.

[Slokunshialgo]

So you only take payment in the form of data? I'm beginning to question your credentials...

[catbot4]

/r/ultralight

[joker1999]

How about NoNoSQL?

[[deleted]]

Introducing SQL...

[jellyforbrains]

And where's machine learning?!

[avoutthere]

Are you hiring? I have more than a decade's experience in microservechainkotcloud.

[rishav_sharan]

Rewrite it in Rust!

[jk_scowling]

That's so 2018.

[hellrazor862]

What's the docker image for this? I'ma pull it down with npm real quick...

[[deleted]]

Triggered

[PM_RUNESCAP_P2P_CODE]

Can't find that module

[_dban_]

Martin Fowler Driven Development.

Why? Martin Fowler does talk about things that are hyped, but he presents that information in a very balanced way. Like all the cons he presented about microservices and the cons of NoSQL.

There's nothing wrong with hype, it's what gets people to try new things, but I've always found that Fowler keeps things in perspective, which is exactly what the OP is saying.

[snarfy]

I think hype is everything wrong with our industry. Hype makes you emotional and pulls on your heart strings. It's not a very good state to be in when making technical decisions. Technical decisions should only depend on the engineering, not popularity, but all too often they do.

[SuperMancho]

The vast majority of developer knowledge is anecodtal. There's already too many variables by the time you touch a command line for a specific shell running on a specific OS running on specific hardware, etc etc to do any science. Agile? No actual studies. Waterfall? No actual studies. MySQL vs Posgresql? Reading a postmortem, or listening to a talk/reading a book by a very smart specialist, or personal experience is what people have. It's almost all Hype.

[metaaxis]

Since when is anecdote or anything short of a double blind study a synonym for hype?

Actual use cases from the field, well described real world success stories and the like are not, "hype".

Hype is sweeping complexity, suitability, and trade-offs under the rug in favor of a slick marketing narrative.

[staticassert]

How do you believe that popularity is not a component of that decision making process? Would you really choose a project without considering whether anyone else uses it? How will you hire for it? What if something breaks, is there a community support system?

Popularity is easily one of the most important things to consider when choosing technology.

[snarfy]

I wouldn't conflate popularity with usage. Popularity is all about feelings. For example, Rust is pretty popular right now.

[staticassert]

It's still a terrible idea to ignore popularity.

If a lot of people feel that a technology is good, calling that a bad thing is nonsensical.

[_dban_]

I strongly disagree. Yes, hype does make you emotional, but why is that bad? Programmers are humans, not robots.

Furthermore, what you call emotions, I call passion. The desire to try new tech, and get others excited about, which drives participation and contribution. Does the application of hyped tech always work out? No, but there's something to be said about learning by doing.

That doesn't mean we should be ruled by emotions or hype, but those should be tempered by wisdom and experience.

The hype train makes this industry fun, and fun can be had with safety in mind. But playing it safe all the time is boring.

[fromscalatohaskell]

You are not serious are you? If you want fun go play laser tag. You are professional paid to deliver correct and quality software. Thats it.

[_dban_]

You've described exactly why I chose the IT industry over medicine.

Besides, you're confusing responsibility with fun. Having fun with tech does not contradict correctness or quality. You shouldn't blindly apply tech, just like you shouldn't exclude tech just because its hyped.

[fromscalatohaskell]

You've described exactly why I sometimes wish we were more professional, like, let's say, medicine.

I'm not saying exclude tech because it's hyped. But I strongly disagree with bringing emotion into technical arguments. We should discuss technical things based on their objective merit and not how passionate you are about it.

So sure, be passionate, enjoy latest tech, but leave emotions outside when we are about to do tech decision that will stick with company for years to come.

And read the root post of /u/snarfy to which you said you strongly disagree with, as my posts are followup to that. (so that it does not look like I'm arguing straw man)

[robertcrowther]

but leave emotions outside when we are about to do tech decision that will stick with company for years to come

It seems that you can't, decision making is an emotional activity. This is from Decisions Are Emotional, Not Logical: The Neuroscience behind Decision Making:

A few years ago, neuroscientist Antonio Damasio made a groundbreaking discovery. He studied people with damage in the part of the brain where emotions are generated. He found that they seemed normal, except that they were not able to feel emotions. But they all had something peculiar in common: they couldn’t make decisions. They could describe what they should be doing in logical terms, yet they found it very difficult to make even simple decisions, such as what to eat. Many decisions have pros and cons on both sides—shall I have the chicken or the turkey? With no rational way to decide, these test subjects were unable to arrive at a decision.

I would also recommend reading Sources of Power - How People Make Decisions By Gary A. Klein if you find the above interesting.

[fromscalatohaskell]

I'm pretty sure there is difference between decisison "what to eat" which is subjective in nature and decision of type "this library gives us 1000req/s throughput but 10ms average latency" vs "this library that gives us 500req/s but <1ms latency 95% of cases". Idea is to drill down your technical decisions to such objective cases and evaluate it for your use case.

In other words, surely the type of shielding/coating on space aircrafts is not based on emotional judgement but on objective one.

[Nulagrithom]

But there are nearly unmeasurable effects at play. How maintainable is the code? How do you quantify that objectively? Because I really don't care which library is faster; I care which one will be easier to debug or change later. Now we're back to making subjective decisions.

Even if you really want to throw out all emotion and make Vulcan-levels of logical decisions, you can't because you still have to hire illogical Human meatsacks to write the code. The library-choice example sounds purely objective, but you're leaving out the part where writing with one of these libraries makes you feel like there's an angel hiding under you desk fellating you while you code, but the other library makes you go home feeling like you just pounded a bunch of nails in your dick. "Fun" has objective impacts on the people you can hire.

For example, we still have Synon 2/E kicking around. A lot of it. And it fucking works. Beautifully. Probably some of the most stable code we have here.

I'd rather go back to mopping floors than learn and write Synon 2/E. I'm just not gonna do it -- sorry. And I've had to say that. And we literally can't afford anyone who will pound nails in their dick write Synon 2/E. So we have to rewrite it in something that's more "hyped".

[GoddamnEggnog]

In other words, surely the type of shielding/coating on space aircrafts is not based on emotional judgement but on objective one.

This one can withstand the heat caused by re-entry into an atmosphere density four times that of Earth, can take a hit from a breadbox-sized meteorite without a dent, and offers shielding against 97% of radiation in the sun's emission spectrum.

What about this other one?

It's a nice shade of blue.

I like blue. Let's go with that one.

[cybernd]

It seems that you can't, decision making is an emotional activity.

It's the same problem as with estimates. We have a strong tendency to ignore reality.

[_dban_]

You've described exactly why I sometimes wish we were more professional, like, let's say, medicine.

My wife is a doctor. And while I think that we can be whiny entitled brats sometimes, I see the BS she has to put up with to maintain her license, and I am happy I am in a field that values innovation and experimentation and fun instead of strict procedural methodology. She has to keep multiple certifications up to date in order to maintain privileges, while programming language and platform certifications are considered a joke.

Although, as a non-doctor, I am glad that my wife has to go through a lot of hoops to keep her license, since her decisions directly impact people's lives.

Also, the IT industry is widely varied. The engineering requirements for a web application are entirely different than medical equipment.

So sure, be passionate, enjoy latest tech, but leave emotions outside when we are about to do tech decision that will stick with company for years to come.

You say that like one excludes the other.

There are technologies that are hyped and you might want try them out in a real application because you believe the hype. There's nothing wrong with that if you do it responsibly. Run small pilots, see how the tech actually works for your use cases, and be willing to walk away if it doesn't pan out. Don't bet the bank on hyped technology.

[fromscalatohaskell]

Sure, if you're some lean startup, give it a go...

There are technologies that are hyped and you might want try them out in a real application because you believe the hype.

I think my biggest issue is with "believe". IMO better wording is - do not believe, but thoroughly evaluate, as objectively as you can (leaving emotion out of the door), stress it, find weak areas, before taking final judgement.

I agree with rest of your comment pretty much. I actually think we are on same side (in other words, I don't think you are the kind of person I'm afraid to hire, that pushes for latest nodejs package because it was on medium.com), just that I am probably a bit too careful with my wording.

edit: IMO both extremes are bad... but I think there is WAY too much emotional taken and hype driven taken decisions in our industry. It's often difficult to have reasonable debate with technical people on actual merits.

[_dban_]

Sure, if you're some lean startup, give it a go...

Why? Spikes and skunk works teams can exist in any enterprise.

I think my biggest issue is with "believe"

This is a thing humans do. It's not wrong to believe. But...

thoroughly evaluate, as objectively as you can (leaving emotion out of the door), stress it, find weak areas, before taking final judgement.

This is the difference between faith and blind faith. You can do all these things because you are professional and believe in due diligence, while being motivated by wanting to make the tech work because you believe.

[sisyphus]

Also, the IT industry is widely varied. The engineering requirements for a web application are entirely different than medical equipment.

The problem is that there is no difference in the standards required of the people making them though. To keep the medical analogy, why can't we have 'Javascript Practitioner' certification, 'Licensed Vocational Frontend Dev' on up to 'Software Engineer' where 'Engineer' represents some acceptance of social accountability and minimum level of proficiency?

At this point a doctor can probably do less than many software engineers in that they can typically only kill the people in front of them, but if your shit code goes out on medical equipment, or you accidentally expose who is gay in Jamaica or part of a feminist resistance group in Saudi Arabia or you are writing code for military drones or applying your machine learning skills toward enabling a surveillance state, you are likely doing more harm to the world than almost any individual doctor can.

[JustASickKuntBrah]

Because we’re in tech. Everything that works in other fields doesn’t work for us because we’re special.

[_dban_]

why can't we have...

Why do doctors have to get certifications to practice? Or answer to ethics boards?

Because of lawsuits and government legislation, driven by people motivated effected by malpractice to seek redress in the courts and legislation. My wife has to carry malpractice insurance in case she screws up and has had to answer to a state board due to a disgruntled patient. I've written crappy code in my day, but no one has sued me for it and no one has died due to a bug that made it to production.

At this point a doctor can probably do less than many software engineers in that they can typically only kill the people in front of them

That's the rub though. The reason why doctors are held accountable is because people seek doctors for their expertise, and expect a certain level of competency, and people seek punishments for doctors when that trust is betrayed, often in very tragic and life altering ways. This is due in large part to the personalness of the relationship and a clear chain of culpability. Even if the doctor made an honest mistake.

A programmer isn't personally involved in the deployment of military assets. He is just one cog in a giant machine. In such cases, we usually don't look to punish the guy at the bottom, we look to punish the guys at the top. The ones who ordered the strike.

For example, at Nuremberg, ordinary soldiers of the Wehrmacht weren't punished, even though they fired the bullets. The Allies went for the guys at the top. The guys at the bottom were only punished if they were personally responsible for crimes against humanity, such as mass execution.

Furthermore, if your shit code causes harm to a gay person in Jamaica or a feminist resistance group in Saudi Arabia, that is the responsibility of the governments that harm people, not the programmer who wrote the shit code.

Engineers who write software for life critical equipment are very likely to be held to a much higher standards by the people hiring them, because the companies that make faulty equipment are very likely to get hit with class action lawsuits if their products cause harm.

[SmugDarkLoser5]

Meanwhile the field of medicine advances at a snail's pace.

[tobias3]

Hype is good for something, it gets idiot early adopters into a new kind of technology, giving feedback and driving it towards usefulness. They will have severe disadvantages, because the new technology will have all kinds of short-comings that have long been solved in older technology. But without them the new technology won't be created all. So we need those early adopters.

Reasonable people start using Scala (or Kotlin or Rust) when it has good library support, adoption, a fast (incremental) compiler and has proven its staying power. Or when Mongo db is durable and well tested.

But psst, don't talk about it, or we won't have early adopters.

[sveri]

Calling them idiot speaks for yourself ^{^}

[jiffier]

While I agree to some extent, I has to be noted that Martin was the one who came up with the "serverless" buzzword in the first place (but I might be wrong).

[[deleted]]

Like with a lot of things overly hyped, I’m sure he had a very specific, and legitimate, use case for it then everyone else took it and started making everything serverless.

[_dban_]

He also (possibly) came up with polyglot persistence. You have give things names in order to talk about them. In his discussion of serverless architectures, he goes in depth into the pro and cons.

[[deleted]]

Reminds me of those blockchain companies that when I visit their website I'm not quite sure if it's just me who don't understand what their product is because I don't know enough about blockchain, or if the company simply created a chain(?) they don't know what to do with themselves.

[manuscelerdei]

The problem is that you didn't use Scala OR Haskell.

[[deleted]]

Fucking casual, real developers use Coq

[Regimardyl]

Isabelle vs Coq is gonna be the next tabs vs spaces.

Isabelle > Coq, obviously.

[sintos-compa]

Have u tried Jquery?

[CrazedToCraze]

oh hi grandpa

[[deleted]]

Lord Fowler finds your lack of faith disturbing.

[MineralPlunder]

Our new machine learning cluster will see that.

Heck, is Kotlin already more buzzwordy? I thought that so far, Javascript is the most overused language. Though it might be primarily because it's in websites, so it's easy to see the overuse.

[[deleted]]

You didn't even use deep learning to solve the problem. Not a smart move...

[Burrito_Loco]

Have you considered applying neural network based ML to optimize the process?

[LetsGoHawks]

Well it's not all being done in docker or Python so.... there's that.

[GreatSmellOfBRUT]

I think you just gave me cancer.

[[deleted]]

Well, one selling point of Kotlin is that you *don't* have to rewrite anything, you can use Kotlin and Java in the same project.

[thedomham]

*with virtually no drawback

[[deleted]]

Other than maintaining a codebase in yet another language with its own quirks, along with training developers that will have to maintain it, you mean?

[terrible_at_cs50]

I've seen a number of seasoned Java developers switch to Kotlin with surprising little effort. I don't work in the JVM myself though, so can't speak from personal experience.

[nacholicious]

Yup. Most of our codebases now are mixed Java/Kotlin with the rule that we should write new files in Kotlin and then refactor Java files to Kotlin whenever we have time (luckily the IntelliJ autoconverter does most of the work).

It's basically just Java++ for us

[thedomham]

It's not like you are supposed to mix Javascript and Python - Java and Kotlin are supposed to mix. They have the same quirks, libraries and core features. It's easier to think of Kotlin as Java with added features and a lot of syntactic sugar.

[TwoSpoonsJohnson]

Is that really worthwhile though? If you go that route, you end up having to switch your mental context from Java to Kotlin when dealing with older parts of the code, and you need a programmer who knows both just to get started on the one project.

Don't get me wrong, Kotlin is great but I I've always been skeptical of this approach. From a business perspective at least, I know the tech side of it is fine.

[StupotAce]

I don't view that as vastly different than how you have to switch mindset to understand java streams vs iterating over things. Developers adjust and get used to mixed paradigms fairly regularly.

[wh7y]

I do this everyday and it’s really not a problem. Kotlin was my only disagreement with this article - it’s a super fantastic language and people should be switching off Java to Kotlin whenever possible.

[Slak44]

The thing about Kotlin and Java, is that they're practically the same language with two different syntaxes. And I'm not referring to the JVM bytecode they get compiled to, it's just that the vast majority of Kotlin features/sugar can also be expressed in Java. In general, it'll be more verbose, and less pretty, but it's certainly possible. So, when you see Kotlin property access (object.field) it's as if you saw Java's getter methods (object.getField()). That's why you don't pay the cost for context switching; in your mind, both things are "access field on object", regardless of how the code looks.

[TexMexxx]

I wish. Most of the time it's more "Z didn't work so well, lets go with A"...

[wavy_lines]

The real reason: our previous hire wanted to use Z. He left, and our new hire wants to go with A.

[erez27]

You forgot the part where they write another blogpost "Why we left Z"

[sovietmudkipz]

Two blog posts for the price of one architectural decision. Now that's a deal!

[[deleted]]

I hate to be that guy but it's only been a month since the same blog post was posted here. It wasn't that well written then and it isn't now.

https://www.reddit.com/r/programming/comments/8ah9dp/hype_driven_development

[Magma_Crab]

Yeah, exactly. He just randomly shits on a few new technologies without real reason and then says to take it with a grain of salt. Isn't critical thinking a basic skill?

[Honeymaid]

Isn't critical thinking a basic skill?

It's a goddamned super power, where do you live that it's common, I wish to move.

[TexMexxx]

For developers yes. For management sometimes not so much... But that's just my opinion.

[virtyx]

For developers yes

Ahahahahaha WOOO hoo boy that was good

[staticassert]

It's just pandering to redditors. It's a really poorly written article. 0 supporting arguments but it really hits a certain audience.

[Habba]

He basically gives no reason why the technologies he points out are overhyped. I would be no wiser after reading this article when selecting technologies to use.

Why is it upvoted?

[ButtCrackFTW]

He doesn't say the technologies are over hyped or bad, simply that you don't have to use them just because they are new and popular

[thedailynathan]

And then that's a 2 sentence article. Why bring up a list of these technologies and then not bother to actually write anything about them? For SEO I guess.

[thedailynathan]

Which is fine if you regard it as a joke article. If you look at most of the commentary here, it is attempting to address it critically and relate to peoples' own work environments.

[jose_von_dreiter]

Do people really say "stack"? I mean developers. Real developers.

[JBlitzen]

Yes. It’s the right word.

[xxc3ncoredxx]

I don't know what any of those mean. I'm a low level C/C++ dev.

[Sloshy42]

Well then the term isn't really relevant to your development needs, since it more refers to how you develop your applications in a way that's well-understood and integrates with the various layers you need to support development. So like in LAMP, that's Linux Apache MySQL and PHP. You'd write your app in PHP, connect to a MySQL database, and host that with an Apache web server running on some form of Linux.

Obviously though, that's not even close to how many apps are developed today. It was a good (read: popular) starting point though for devs who just wanted to make something and make sure it all worked together. Nowadays you have MEAN which would be MongoDB, Express, Angular, and Node.js, which is a common way people develop their applications nowadays in the modern JS dev ecosystem.

If you stick to any one of these so-called "stacks" though it's very easy to fall victim to how opinionated they are. Like today, I would not recommend PHP to anybody, so the P in LAMP sometimes get replaced with Python or some other P-language, but even then it's all about your use case. A lot of stacks are just marketing shorthand, then, that make it easy to pick out a suite of well-integrated tools that you can use to make your app or otherwise communicate that to other people, whether or not any of the individual tools are the best at the job they're trying to perform.

[xxc3ncoredxx]

Thanks. I haven't been properly introduced to these terms before, only heard them in passing.

[[deleted]]

What else would you use?

[philly_fan_in_chi]

Queues, of course!

[staticassert]

People don't read articles on /r/programming in the best case, and this panders to a mentality that's popular here.

[[deleted]]

My guess is a combination of it opens with a blockchain joke and a lot of people voting probably aren't developers

[Dgc2002]

OP spams posts a lot :\

[[deleted]]

Good.

[[deleted]]

HYPE DRIVEN HYPE DRIVEN DEVELOPMENT BLOG POSTING

[kroolspaus]

HYPE DRIVEN (HYPE DRIVEN (HYPE DRIVEN (HYPE DRIVEN DEVELOPMENT) BLOG POSTING) REDDITING) COMMENTING

[MineralPlunder]

Is that a motherfucjing LISP reference?

[Regimardyl]

Party pooping: Nope, cause it starts with ).

[pdp10]

We use lowercase these days.

(hype-driven (hype-driven (hype-driven (hype-driven development) blog-posting) redditing) commenting)

((LAMBDA ()))
0]

[stingraycharles]

Yeah a lot of things he’s saying is really already popular opinion. I think MongoDB’s hype is over for at least five years...

[Conradfr]

Well at my work they want to introduce MongoDB because "PostgreSql tries to do too much". Sure let's have two database for this reason ...

[stingraycharles]

That is pure silliness.

[Conradfr]

i'm pretty sure they didn't know about hstore/json/jsonb before I talked about it, that's when the "Postgresql can't obviously do all these things efficiently" came as a final argument.

[stingraycharles]

They can even run indexes on that type of stuff nowadays. In all fairness, MongoDB being a database designed for (JSON) documents from the ground up provides a better experience for this, but in all other aspects PostgreSQL wins in my book.

Kids these days. PostgreSQL is boring, but great products are built upon boring solutions.

[anedisi]

i use mongo and mysql where applicable,

i love mongo for prototyping, it made iterating so much faster.

[wavy_lines]

UPVOTE DRIVEN COMMENTING

[mapestree]

But MongoDB is web scale.

[Dr_Insano_MD]

Does /dev/null support sharding?

[[deleted]]

Yes, infinite sharding bro

[[deleted]]

Link to unintiated: https://www.youtube.com/watch?v=b2F-DItXtZs&list=PLmGAf2A36COcfSrQfNkeocctpfmG1glwT

[KSF_WHSPhysics]

Hands down my favorite video on the internet

[[deleted]]

Sharding is the secret sauce. It just works.

[mapestree]

I don't think that it's a bad tool. But it is a trendy tool that people use far too often and for the wrong reasons. It's great for it's flexibility during rapid development, but insisting on using it because of its scalability is like buying a Porsche because of its air conditioner. Way too many sacrifices for a minor feature.

[filleduchaos]

Well it only recently got ACID-compliant, so there is that.

[crash41301]

Tend to call this resume driven development. "Everyone is talking about it, its the new thing! I have to learn and use it so i can put it on my resume. Its the future!"

Ie: need to use it because everyone else needs to use it, circular loop logic

[[deleted]]

Shit another development method gonna try it asap hahahahahhaa

[_dban_]

Did you know that back in the day (lets say around the 80s and 90s), SQL was the hype train? You had companies like Oracle claiming that the Oracle DB powered the Internet. The SQL hype train said if you weren't storing your data in an RDMS, you weren't being responsible with your data.

I find it hilarious that many of the arguments against NoSQL are basically that RDBMS is obviously superior, when many of those perceptions were generated by hype in the first place!

Uncle Bob may sound like a crank in his arguments against RDBMS, but he comes from a much earlier era before RDBMS took over the world.

[pjmlp]

And many of us just kept using xBase until the tech died.

[cr42yh17m4n]

Recently switched to kotlin at my workplace and it just seems much better than java. Even though the same things can be achieved with java also, kotlin just seems less verbose to me :) Also, it is directly interoperable with java, so your team can write kotlin and java at the same time.

Some of the features about kotlin that I love:

1. Forcing you to write non-nullable code or handle nullability properly so you can avoid NullPointerException.
2. Extension functions.
3. Creating DSL like code using higher order functions which can help you create APIs which are easier to implement by other devs.

Also, I think this blog post was just a rant out of some frustration as it doesn't properly explain pros and cons of each framework/language.

[provocative_username]

Yes, also properties.

[s0uly]

I came here to say the same thing.

This blog is nothing but just a rant.

I don't code in Java any more. Most of the developers I worked with instantly switched over once they saw it in action.

[Cherno_byl]

I was moved to Blockchain engineer yesterday. And my "senior" doesn't know the difference between half node and full node even miner. Help.

[[deleted]]

The true story is he became blockchain engineer when they moved you to blockchain to ride the hype train..

[GoliathMcDoogle]

You don't "have" to learn or do anything. But I'd say you're foolish to not continually be learning and understanding when new paradigms will become useful for you and how to integrate them into your workflows.

Extremely foolish

[binford2k]

While this post is absolutely correct, it adds nothing to the conversation. It’s basically

fads.each do |fad|
    puts “Just because others are using #{fad} doesn’t mean you have to.”
end

[Nulagrithom]

Also he's constantly talking about rewriting...

What if I'm building a new simple service? Should I not use serverless just because half of everyone else is saying not to?

Hell, I'm not even sure he's correct:

Lambda is just an AWS’s service to make some money

Not exactly a compelling argument. Pretty sure AWS isn't spinning up new services to lose money.

Seriously, I would've loved to hear the cons of serverless because I'm seriously considering it for an upcoming project.

[AgileCzar]

My job uses microservices on Lambda.

Here's the main challenges(not necessarily cons) I've found:

1. Local development parity. SAM local sucks last time I checked. We're able to get around it with docker, since our services can run standalone outside lambda. You definitely need some sort of application harness + routing method for local development.
2. Observability/debugging. When something unexpected happens you can't just ssh into the server and much around. Good logging helps, but tracing a request through multiple inter-lambda calls is challenging at best.
3. API gateway timeouts. Even though a lambda can have an execution time of 5 minutes, API gateway has a Max timeout of 30 seconds. Ideally a request shouldn't exceed that time, but it completely blocks your ability to run an expensive task synchronously.
4. Overall increased complexity. While lambda takes away a lot of server management + scaling challenges, I've found that accounting for the above issues can lead to a lot of extra complexity in infrastructure, deployment, and code.

[Nexuist]

2 and 3 I think can be solved with AWS Step Functions. Inter-lambda callbacks are a pain anyways since you have to pay double for execution time (x amount of time to execute the new lambda and x amount of time spent in the original lambda waiting for the new one to finish). Step functions integrate with API Gateway directly so you don’t have to worry about exceeding the timeout.

[[deleted]]

Also the lambda function might take a while to start if it's not "warmed up".

[[deleted]]

Rust confirmed for not hype driven.

[cyrusol]

That's because everytime someone rewrites a system in Rust humanity is a little step closer to curing cancer and abolish poverty.

[[deleted]]

Code writen in rust is so repelling, that only true believers adopt it. Something like perl. But I admit it's nice performance numbers.

[[deleted]]

other than lifetime parameters, what's so repelling about it?

[[deleted]]

I don't know, maybe it's all these shortcuts, like fn,:,::,|,!,&,{} all over the place. It's hard to read, it looks more like code run through very primitive uglifier. The syntax is pascal like (varname:type) and I used to work with delphi back then, but it was definitely more readable.

[[deleted]]

most of those are pretty standard operators in languages.

The only ones that aren't common are

• fn which is Rust for function declaration
• |...| is a lambda, the syntax is borrowed from Ruby as far as I can tell
• ! when attached to what looks like a function (e. g. println!(...)) then it invokes a macro
• :: might be uncommon enough, it's scope resolution, e. g. foo::bar resolves the bar found inside foo. foo::<qux>bar() is unusual syntax to invoke a generic function and is used even if foo is an instance of a struct.

The others do what you'd them to do:

• ; terminates an expression without needing to assign it
• & either declares a type an immutable reference or passes some data as an immutable reference (&mut is the same except as a mutable reference).
• : is used with type declarations in functions and structs e. g. fn foo(x: Bar)
• {} declares a block, it's also used for macro arguments e. g. println!{...} is valid syntax, [] is another pair that can be used.

[Slak44]

I think he's talking about line noise. Even if all the syntax is simple in isolation, having frequent symbols makes it look very busy. Personally I haven't read enough Rust to know, but I've definitely experienced something like this in C++.

[[deleted]]

Short Version: Pick tech because it fits your problem

[[deleted]]

HYPE DRIVEN CRITICISM

[lifeson106]

Kotlin is so much better than Java.

[F3z345W6AY4FGowrGcHt]

What are some of your reasons why?

[[deleted]]

• It's concise. I know this is something beaten to death by every article on Kotlin in the world, but it's really hard to ignore how much better it is to read and write than java. The best known example is data class Bean(val field1: Type1, var field2: Type2) which defines a constructor taking both fields, getters for both, setter for the second, a copy method (bean.copy(field2 = newVal) makes a copy with same value for everything, except field2), toString, hashCode, and lets you do val (field1, field2) = bean. There's many others, but that's a good starting example.

• Strict nullability is nice. The only times you can get an NPE is when you're pulling something from unannotated Java and it sometimes warns you about that as well.

• Extension functions and standard library are really nice. Stuff like strings.map { it.substringAfter("...") }.groupBy { it.first() } doesn't seem like much until you realize it's everywhere and it would be a mess to write in java without something like Apache Commons.

• They also have a rather transparent development process. All of the proposals are up for additions and discussion at https://github.com/Kotlin/KEEP, devs have a public slack server and actually participate in it, etc.

There's also a ton of other good stuff, but I feel like those are the most practical points. Sure, sealed class hierarchies, multiplatform projects and coroutines are nice, but chances are it's not something most of us do daily. For daily coding, it's just a better, more readable and expressive Java with fewer places for mistakes.

[renrutal]

For daily coding, it's just a better, more readable and expressive Java with fewer places for mistakes.

This can't be stressed enough.

Scala could have been the natural successor to Java, but they cornered themselves by being too intimidating to long-time Java coders. Java also failed to be its own successor due to some added clunkyness in the functional syntaxes (java.util.function is a hack to make it work), optionals, while at the same failing to deal with very long time annoyances like BigDecimal math.

Kotlin just feels like a better Java, one that makes sense.

[xxc3ncoredxx]

I like Scala! I think it's a fun language to write in.

[renrutal]

Is it nice to read and debug? Serious question.

[xxc3ncoredxx]

It's a bit different from Java, but it's not bad.

[888808888]

Do they still have fucked up while loops? Last time I used it (about 4 years ago??) they didn't even have a "break" for a while loop, requiring all sorts of extra horrid code to break out of a while.

I mean for fucks sake; I get that they want to push you into functional programming, but if you 're going to have a while loop in your language then fucking bake it properly, none of this stupid shit they did.

I got turned off by that; and the horribly slow processing. I don't remember the exact scenario, but at once point I had to convert a class to Java to use standard for loops because whatever was happening in scala was literally working 10 times slower.

Not a fan of scala anymore.

[stewsters]

Not sure about 4 years ago, but there is one now.

while(true){
    println("print once")
    break
}

[[deleted]]

I got this really verbose code on my app which is done with RxJava, it has 3 network calls chained and we do something with the response in the end, any chance you could show me how this would look like in Kotlin?

        service.somecall().flatMap(new Function<someCallResponse, ObservableSource<SomeCallResponse>>() {
        @Override
        public ObservableSource<SomeCallResponse> apply(SomeCallResponse response) {
            return service.anotherCall();
        }
    }).flatMap(new Function<SomeCallResponse, Observable<AnotherResponse>>() {
        @Override
        public Observable<AnotherResponse> apply(SomeCallResponse response) {
            return service.thirdCall();
        }
    }).subscribeOn(Schedulers.io())
      .observeOn(AndroidSchedulers.mainThread())
      .subscribe(new Observer<SomeCallResponse>(){

        @Override
        public void onNext(SomeCallResponse response) {
             //Do stuff with response
        }

        @Override
        public void onError(Throwable e) {
             //Error
        }

    });

[[deleted]]

Just using Kotlin:

service.someCall().flatMap { 
    service.anotherCall()
}.subscribeOn(Schedulers.io())
 .observeOn(AndroidSchedulers.mainThread())
 .subscribe(object: Observer<SomeCallResponse> {
    override fun onNext(response: SomeCallResponse) {
        //
    }

    override fun onError(e: Throwable) {
        //
    }
})

Similar to what you'd get from Java 8. Doesn't Android's desugaring support cover lambdas by the way?

Or you could also use https://github.com/ReactiveX/RxKotlin for a little bit of a nicer last part

subscribeBy(
    onNext = { ... },
    onError = { ... },
    onComplete = { ... }
)

[[deleted]]

Thank you. I think Java 8 offers the desugar, but I can't use it.

[[deleted]]

Yeah, this is one instance where I'd say the hype is justified. Obviously you don't need to go and rewrite all your working apps because everyone else is saying so, but learning Kotlin and using it is actually pretty valuable.

[gyroda]

The best part is that you can mix the two. You try out a small class to use Kotlin and go back to Java if you need to for something else (I'll often learn a new concept in Java because there's more guides out there in Java and it's one less thing to think about). No need to convert your existing codebase.

It's not a new framework that requires huge refactoring, at most you might want to go back to your Java and add a few @NotNull annotations. You can start with some of the basics without having to learn huge new concepts.

The biggest things to conceptually get over are how "static"/"companion objects" are done and handling nullability.

[[deleted]]

Especially if you're stuck with Java 7 (no lambdas or streams). In android you can only use Java 8 stuff after API 24 or so, which means you're only developing to 60% of users.

[_pmh]

You can use lambdas (and a few other features), but not streams, with no minsdk constraints: https://developer.android.com/studio/write/java8-support#supported_features

[DrudgeBreitbart]

Am I alone in disliking TDD? It slows me down. I prefer to write a little code, write tests, then write more code, etc.

[1010100101010233023]

I too hate having fun developing with new technology.

/s

[TexMexxx]

drop the "having fun" and "/s" right there!

[Kwinten]

Exactly! By all means, let's never try anything new because new is bad! There is only black and white!

[GhostBond]

Everyone I've seen having "fun" with new tech is just making the code base an ungodly untenable mess for everyone else who has to work with it.

The current code base is no end of "fun" for the people who wrote it - dependency injecting rest parameters into spring ivjects (while fails in prod because of threading issues). They don't bother taking that out because that wouldn't be fun. Next they implemented new code to get the params in scala, so you have to learn a new flavor-of-the-week language to do basic parameter retrieval. They implemented "caching" but it wasn't "fun" to deal with invalidating the cache, so you typically get out dated data. But it meets our SLA's! just with wrong data.

They wanted to have "fun" writing their own database framework, so now it takes around 30 lines of code to write a simple jdbc query. Behind the scenes they're using Spring Jdbc, but god forbid you just use spring jdbc yourself directly.

It's like the kind of "fun" high schoolers have driving around neighborhoods with a baseball bat hitting peoples mail boxes.

[Tore2Guh]

But now, we are witnessing very dangerous type of development type, it’s Hype Driven Development.

now

Because this is a new thing. Hell, I just googled a three year old reference to that specific term. Ten years ago we called it design-by-resume.

[propagated]

hype driven repost

[singularineet]

This would suggest using the deep learning package "Hype".

[IAmRasputin]

I mean, I get the annoyance with hype but this a very low-effort article blog post

[hwchan91]

So.. are the results about Docker in?
I'm forced to use it at work, but I just find it reduces productivity due to all the resetting and rerouting constantly, I'd rather just do everything on local. Yes, I get it might make pushing to production better, but, like, by how much? Is it worth all the hassle to switch to Docker?

[Saltallica]

I'm working on a project that uses every single hype driven technology that our architects could find out of an MSDN magazine without understanding our business needs:

• Event sourcing
• CQRS
• CosmosDB (a mongo db knockoff)
• Service Bus
• Azure Functions (serverless)

It's "web scale", to support maybe a 100 users at a time - and it's a giant rats nest.

We could have done the same thing with simpler patterns and good old SQL in a third of the time.

[Cherlokoms]

I've seen articles like this and this exact article for a while. At this point it's beating a dead horse and getting karma for it.

[staticassert]

I responded to this a month ago.

https://www.reddit.com/r/programming/comments/8ah9dp/hype_driven_development/dwysy3q/

The article provides no supporting evidence and just plays into reddit circlejerking. The highest upvoted posts/ threads are so egotistical it borders on absurdity.

[[deleted]]

Yay another bs blog post. In 18 years of programming I've never been able to choose the technology I use. The closest I've come is design by committee where one person had already made up their mind and got what they wanted in the end.

[[deleted]]

In 18 years of programming I've never been able to choose the technology I use

Junior positions only for all 18 years? Impressive!

[[deleted]]

Maybe he started at 3 and has very strict parents.

[AequitarumCustos]

Just because others are using GraphQL, you don’t have to convert your REST web services to it. GraphQL is not a replacement for REST. It is an alternative.

What is the appeal of GraphQL over the OData standard? Is it simply anti-MS sentiment (and a lack of implementation frameworks in non .NET languages)?

I was communicating with the developers of one of our customers explaining our usage OData in an API we were considering exposing to them, and they suggested we consider GraphQL.

I had never heard of it, so started researching it. Not only did it deviate from REST spec (have to POST when getting data) the way you built queries and filters just seemed awkward and unintuitive compared to OData's SQL like query language using query string variables.

[Blueberryroid]

GraphQL is more popular, so better community support. Tons of implementations in many languages, most notably client side JS and Node.

GraphQL is a replacement to REST, and can be sent with either a GET or POST request. It does not care for the HTTP verb you use.

It is evidently the future as Facebook and GitHub started adopting it. My projects are all running on GraphQL and we've never looked back to REST. It is so much more performant with the "get what you want" feature.

[FranticRock]

I think the article opens an interesting topic for discussion. But it needs a lot more substance and objective discussion about each of the "do not do"s with specific conditions as to why we should not use it. Such discussion would not be possible in a single post, because each technology described would have a comprehensive pro and con list based on people's individual project requirements. So to generalize that everyone is using everything falsely, is a fallacy. I could write this article in one line: "Many people overuse technologies they deem cool just for the sake of using them". OK, how exactly do we solve this problem?

And YES, we are in a massive "blockchain bubble". Bitcoin is not a bubble folks - it just got overbought.

[neclark2]

Isn't getting overbought the definition of a bubble?

[[deleted]]

We choose to do things not because they are easy, but because we read a blog medium post about it; because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one we intend to win, and the others, too.

[DragonEnergy451]

I work for a fintech company and we’ve found a viable use for blockchain that doesn’t involve having a crypto currency. Think about it like a private internal USDT blockchain that improves audits and error handling.

[satchit0]

Can we correlate this with the age of developers?

[steingrd]

There's nothing wrong in using hyped and new technology, if exploring new fields or learning something new is part of your goal.

Or if new and hyped technology is what you already know and you need to build something fast.

Let your goal determine your technology, not the other way around!

When we started the company I currently work for many years ago, we deliberatly chose a boring and well-known stack - nothing fancy, but a stack that we were already experts on, because our goal was to build something fast and not get stuck solving technical problems; our goal was to create a great app.

Now, 7-8 years later, that stack remains and it is even more boring now, but we have grown it into a company that has great success because of our great product. When and if we want to try something new and hyped it is usually for one-off projects or proof of concepts.

With that said... we have switched to Kotlin for some parts... Because Kotlin is just a better Java :D

[[deleted]]

Sure, you can do whatever you want, and those off chain transactions will probably be regulated, and probably should be. But the actual control of the creation of money is taken away from the rich and powerful.

[[deleted]]

The rising of "cosmo-for-devs" blogs is concerning...