lysdexic

This is very over-exaggerated. A lot of people started with C or C++ as their first language.

That took place over two decades ago. There were no better alternatives back then. Times have changed.

Both of which are significantly harder than learning Rust.

This is simply not true. It's far simpler and less frustrating to work on either C or C++ for the simple reason that you can shoot yourself in the foot anywhere you'd like. In Rust, newbies have to alternative to endure the compiler enforcing its safety constraints anywhere they'd like. Rust is also a far more complex and extensive language that enforces memory safety rules that can and very often are very frustrating to handle by those who don't have a firm grasp on them.

What features do you use often And what features are not that useful in an IDE and can be considered bloat?

Being able to build projects and debug them is a given. Why would anyone use an IDE that did not supported building or running a project?

Developers spend most/practically all their time navigating through a project. Therefore, features such as opening files, searching for symbols, going to definitions, navigating back to points you were in, end up being the ones everyone uses the most. Also, code bookmarks are also of critical importance to work on specific tasks.

Support for refactoring primitives is also of critical importance. It's extremely convenient to extract/inline functions, rename symbols across the whole project, automatically generate code such as classes and their unit tests, etc. Nowadays, if an IDE does not support basic refactoring features such as extract/inline function/variable then I'd argue that it's not worth bothering with.

Finally, source code formatting. It's surprising the impact on team dynamics and productivity that we get by having an entire team on the same page with regards to where a space is expected to show and not show up.

I'm sure that there are plenty of spectacular features that should be must-haves but I'm oblivious to. Not using them doesn't mean they are bloat.

We are not in the middle ages any longer, we need operate like an engineering discipline.

I'm not sure you realize how "engineering disciplines" operate as crafts.

Some engineering fields might be bounded by tons of regulations and standards and specifications, but that does not remove the craftsmanship from the problem domain. At most, those surface design requirements and convert them into hard design constraints, but that does not get rid of the need to go beyond those and leave our mark in terms of subjective definitions and measures of quality.

Also, these comments on "operate like an engineering discipline" are mostly sourced from a cargo cult mentality, where mindlessly mimicking the surface-level aspects of the things they try to emulate is perceived as being key to achieve their perceived qualities. However, software is not bound by most, if any, of the requirements that other engineering fields must adhere to. It makes no sense to presume that a solution that rose from a very specific set of constraints applied to a very specific set of problems will also be adequate for an entirely different problem subjected to entirely different constraints.

This SAM9x60D1G-I/LZB SOM module is a mouthful to say. But at 28mm x 28mm its roughly the same size as a US Quarter. But… at $60 it sounds like a bad value. Okay, it is a bad value, but stick with me here, this represents far more than you might think.

The Orange Pi Zero is not that larger (48 mm × 46mm), ships with up to 512MB DDR3 SDRAM, wifi, and 10/100M Ethernet RJ45, and can be bought for half the price.

Pick Rust

Rust is renowned for being hard and frustrating to onboard onto. I don't think this is a wise suggestion.

https://users.rust-lang.org/t/is-rust-lang-hard-for-a-beginner/93395/2

you trying to karma whore on Lemmy

You're spending way too much of your time online if you believe "karma" is something worth bothering about.

Lastly, you should use some of your keen attention to detail to realize I've been the only one contributing content to /c/loud for over 2 months. Cloud computing is a topic I find interesting and I'd love to see being discussed more often on Lemmy. If you have more interesting submissions to discuss, please be my guest and create posts to discuss them. Otherwise, at least read the rules and strive not to break them.

This is an article from 2020 my friend

That would explain why I added 2020 to the autogenerated title. Thanks for your keen attention to detail.

What major Java supporting ide doesn’t support Lombok?

Why would everyone have to onboard a code generator just to be able to use data transfer objects without having to write tons of boilerplate?

Also, Java records allow the runtime to optimize how these instances are handled.

I feel like so much effort is spent trying to solve problems that just aren’t problems.

I don't think your belief has any merit.

The popularity of tools such as Lombok and JVM languages such as Kotlin demonstrate the pressing need to eliminate the need for boilerplate code in Java to do basic things.

It matters nothing if an IDE can generate all the getters and setters you wish. The problem is the need to generate all those getters and setters for a very mundane and recurrent usecase. All this boilerplate code adds to the cognitive load and maintenance needs of all projects, and contribute to the introduction of bugs.

I can count on the fingers of one hand the number of times I’ve actually needed to write a hash or equals method.

That's fine. Other people write code and are able to assess their own needs, and the verdict is that not having to write boilerplate code beats having to write it.

If your personal experience was shared by many, Lombok or Kotlin would not be popular.

This is a good opportunity to state the fact that Raspberry Pi's value is not the hardware all on itself. The hardware actually lags behind some of the cheaper RPi clones out there, and misses some key features. Raspberry Pi's value lies on the software support for that platform. It ensures a best in class developer experience, which is key to actually serve it's purpose of an educational platform, and simplifies a great deal how to write software to run on it.

I think that it’s because a) the abstraction does solve a problem, and b) the idealized solutions aren’t actually all that simple.

I'd go a step further and state quite bluntly that these critics do not even understand the problem that the abstraction solves, and their belief is formed based on their poor and limited understanding of the problem space.

Everyone can come up with simpler alternatives if they throw most requirements out of the window. That's basically the ages old problem caused by major rewrites and their expected failure once the unknowns start to emerge.

But I still agree with the article because I also think that a) the problem solved by the added abstraction isn’t practical, but emotional, and b) the idealized solutions aren’t all that complex, either.

Hard disagree.

There is not a single technical argument refuting these abstraction layers; only ignorance of the problems they solve. It's easy to come up with simpler solutions if you leave out whole sets of hard requirements.

The idealized solution never leaves the conceptual stage because the idealized solution is never thought all the way through and the key requirements are never gathered. That's when the problems solved by the abstraction layers rear their head, and what forces these critics to face the fact that their proposed solution is inconveniently converging to the real world solution they are complaining about, but that they are reinventing the wheel poorly.

I don't think that this blog post adds much to what's already stated in JEP 444, right in the summary.