Definitely not the case. I’ve been doing C# for over 20 years. For the last 6 years I’ve used it to write Linux services exclusively.
The “Java” relation was true 20 years ago, and the “Linux” argument was true 7 years ago. But neither hold any water anymore. It’s a great language and framework to write a wide variety of software with.
After many years (10+), I finally find a company that actually, really, implements CI/CD. Then I look at the tests and it’s actually the most inane shit imaginable, tacked on top of ancient existing code, not maintained. I spent more time fixing the stupid tests than actually fixing the bugs I was tasked fixing. Amazing.
I can’t really imagine working on any code base that has to actually be maintained and doesn’t have tests. The amount of times that tests have safed my ass at my job are uncountable
And it’s number 1 priority for management to employ as few developers as possible and stretch their team as thinly as possible. Hence still no unit tests in any of the companies I’ve worked at recently, despite everyone knowing they’re worth it, including lip service from management. They just won’t invest in testing, no matter what. One company even fired all the testers then complained to the developers that the product was getting less reliable.
We test the shit out of our Apis. We do more API level/integration testing though.
I.e. a test will be something like “if the db is in this state, and we hit this endpoint with these params, does it return what we expect and update the db correctly”.
Our app is primarily about users maintaining stuff on big datasets with complicated aggregation and approval logic. So setting up a scenario and checking the app does what the business logic says it will do is what we want to know.
It makes refactoring wayyyyy less painful to just know that the app will always behave itself. Rather than testing whether a function can add 1 + 2 correctly, we can test each endpoint does what it’s supposed to do.
It gives us loads of confidence that the backend is doing what it’s supposed to. If you do a huge refactor you don’t need to worry about whether you broke the test or if the test is failing correctly. If the tests all pass everything is working as it should.
Downside is longer test execution times (because a temporary db needs set up) when running the full suite. Worth the trade off for us though.
People seems to be riled up by this, but turbo is mostly used with ruby on rails, right? I’m not familiar with ruby on rails, does it actually support some form of static typing it type hints? From the blog post, the dev (which is also the ruby on rails creator) doesn’t seem to be a fan of bolting static typing into dynamic typing language.
In Ruby, the convention is usually that things are duck-typed (the actual types of your inputs don't matter as long as they implement whatever you're expecting of them, if not, we throw an exception). Type hinting could be possible, but it basically runs contrary to the idea.
Now, Ruby on Rails developers are expecting some kind of magic conversion happening at the interfaces. For example, ActiveRecord maps the database datatypes to Ruby classes and will perform automated conversions on, say, date/time values. But from the developer perspective it doesn't generally matter how this conversion actually happens, as long as there's something between the layers to do the thing.
RoR is very… specific. Some love it because it comes with magic. Many hate it for the same reason.
You either knows the magic and love it, or you hate it with a passion. You never really know when (not if) your change will break the system because it’s supposed to name in a very specific way that work by, again, magic.
I’m kind of a beginner… Can someone explain why you would make/use/have a dynamically and/or weak typed language? Is it just to not write some toInteger / as u64 / try_from()? I mean the drawbacks seem to outweigh the benefits…
If you are writing small and simple apps it will give you more velocity and much less boiler plate.
As apps grow it becomes harder to keep track of things and can quickly grow into a mess. You then start to need external tools to give you the features of a strong static type system.
Also from a web point of view you don’t want the website to crash and burn with every error. JS will power through things like invalid types. Imagine if any error caused the website to just stop.
There’s no real alternatives to JS “for websites” (meaning on the frontend, the part of your code that gets executed on your client’s browser). That’s what JS was invented for and what it does best.
I say “no real alternative” because technically we also have WebAssembly, which is a tool that allows you to run code written with any language on the web, but if you indeed are a beginner approaching to web development you should just forget about this for now and stick to JS as you learn.
Of course this doesn’t mean that you can’t use Python on your backend, your server.
Why should beginners approaching web development stay away from WASM? I’ve used it a few times to create online demos of software I made in Rust and it was a very simple and painless experience to get it working in a website. I consider myself a beginner and I have not run into any issues with it so far.
WASM is simply further down the rabbit hole for someone who is new to programming (but not someone who’s already a programmer and just doesn’t focus on web dev today). You are likely far less beginner than you think if you’re making decisions like “I’m going to compile my software written in Rust targeting WASM so I can demo it.”
The typical arguments for a dynamic typed language are that it takes less time to write something in it.
The benefits of static typed languages are that your development environment can be a lot smarter (ironically enough leading to faster development speed) and several classes of bugs being unable to happen. In a statically typed language, the IDE can detect if you’re trying to call a function that takes a number but you’re actually providing a string. In this case the IDE will let you know and you can immediately fix silly mistakes like that.
I prefer using JS because I can see the errors, while having to figure out which part generated the problematic JS code with errors when using something else.
Yeah, almost certainly the software only uses 4GB because it limits itself to what memory it has available.
I have seen this conversation pan out a few times already. It has always been because of that, and once expanded things work much better. (Personally I have never took party at one, I guess that’s luck.)
programmer_humor
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.