tdbgamer

I guess the upside is that you end up with a "compiler" that checks the invariants of your project and that domain rather than strict type safety. I love static typing, but I did try Elixir w/ Phoenix recently and was impressed that they were able to implement compile time checks like verifying that all redirects are valid routes, etc. Depending on what you're building, having a few small domain specific checks like that could be more valuable than strict type safety.

Improving performance isn't the only way you can make something "better". A system could be architected in a fragile or rigid way that makes extending it or adding new features extremely difficult without a rewrite.

I can't tell you how many times I've seen people "make it work" and create a mess that has to be rewritten later with much greater difficulty than if even the slightest amount of forethought had been given before hand.

While I agree with you that the JVM is great, I think most people that don't like it really just hate Oracle. It's not really a technical argument as much as it is philosophical. I don't really care either way, but I can see why people would mistrust Oracle knowing their history.

If you just hate the JVM, Clojure was designed in such a way that it could be hosted on many VMs which is nice. As others have pointed out, it can run on BEAM VM or even V8 with Clojurescript I believe.

This isn't just a design principle for .NET libraries, it's a SOLID design principle. All classes should be inextensible unless they are explicitly designed to be extended.

Yeah so if there are any vulnerabilities in his software, he just gave them all they need to exploit them...

This article seems like a great argument for using open source encryption software. This guy handed over his source code to the NSA without a warrant or anything? So any idiot that steals your laptop can just call him up and exploit his software to get to your files. Great.

Uhhh did he say it wasn't Sony's fault? His point was cross-play isn't the worst part, but the way Sony locks your account in. Don't see how that exonerates Sony.

I really liked Elm a lot, but the issue for me was that composing components is a shit show. You have to add variants to the root Msg type for every single subpage and have it dispatch to the right update/view functions.

I'm really excited about a project inspired by Elm called Yew but allows you compose components much more naturally and easily.

https://github.com/DenisKolodin/yew

Did you look into Google App Engine, Heroku, etc.? Those were pretty seamless managed experiences for me, of course you pay for the convenience though.

A tool doesn't need to fix _all_ problems to be useful. Yes, Docker doesn't cover differences in Linux kernel versions but it will take care of basically every other difference. Now the search space has been narrowed to Kernel/FS issues. Sounds great to me.

My impression is that people use Rust for correctness, security, and speed over ease of use. Although I do think once you get over the initial learning curve (which is admittedly large) it mostly makes sense.

To be clear, cyclic references are just as much an issue in GCed languages. In Python I had to use weakref lib to ensure cyclically referenced objects are still GCed. Rust is the same in that aspect, you use the Rc builtin type and create a weakref for one of them.

There is tons of C software out there that depends on libc that is never going to be rewritten in Rust. Also think about interpreted languages like Python, Ruby, etc. I imagine they all depend on libc. The only real way for Redox to gain adoption is through cross platform compatibility.

He mentioned some bad C experiences he had for a whole 7 sentences and that's your take away from the article?

You're totally missing the point dude. The point is that C doesn't protect developers from some of the most basic mistakes and offers very little tooling compared to modern languages. It turns out that maintaining huge software projects in C is actually really hard.

C++ does have a lot of the features that Rust has. You won't get any of the memory safety guarantees or compile time checks though. I will say that to me a lot of the C++ equivalents to Rust features seem very awkward to use (maybe not once you're used to C++ I guess).

This guy does a pretty good presentation on Polymorphism in Rust vs C++: https://www.youtube.com/watch?v=VSlBhAOLtFA

Uhh did you read the same article I did? 90% of the article was features missing in C: Generics, Slices, Dependency Management, Tests, Useful macros, Pattern matching, etc.

Those things have nothing to do with good or bad code and have everything to do with the language.

You just have to intentionally use a method on integers called wrapping_add() to explicitly allow overflows. That said I believe overflows are only checked when you compile with the debug target. So when you compile to the release target it doesn't check them I believe.

I personally think it's a good thing to only allow overflows when explicitly allowed.

We need net neutrality because ISPs are allowed to be monopolies. Way easier to replace an OS than start a new ISP.

Iron and Diesel are pretty new, so they may not have very sophisticated templates yet. If you just mean setting up a rust project though it's as simple as 'cargo new --bin [project_name]'. I've found cargo to be a lot simpler to use than Gradle with the added bonus of not having to learn Groovy!

It's mostly part of everyone's dream of using the same language for frontend and backend code. When Node/NPM became popular and built up lots of useful libraries and could be used for backend code, people started trying to use Js everywhere. It helps that a lot of the ecosystem is based around asynchronicity.

To be fair to Cython, they have access to the entire C++ stdlib, so that's a fairly good amount of tooling. The main thing is lacks is good documentation and memory safety.

Cython deceptively similar to Python with a lot of the pitfalls of C baked in. I personally found their documentation lacking and had to read through tons of Cython projects to discover how it behaved in many scenarios. I've had a much better experience with Rust documentation in comparison.

Sounds like the author picked a very specific case and assumed all LTS was that way. I've personally always understood LTS to be a feature freeze with only security patches being back ported.

I've worked at places that did stuff like the author suggests without pinning versions, and it always just ends up with some unlucky person spending their weekend fixing a dumb bug cause by an upgrade.

LTS is the reason we can all sleep soundly knowing our code won't spontaneously break, so I'm extremely grateful to the hard work everyone puts into it.

No problem!

I did read Clean Code by Robert Martin. He's definitely in the "die hard TDD guru" category, but there are still useful examples to be extracted from the book.

Besides that, I mainly learned a lot of testing tricks in the wild, reading through Github projects. My learning process now-a-days is mostly:

1. Discover a really cool trick or concept I didn't know existed in a Github project. 2. Research the hell out of it. 3. Try to use it in some personal example project.

I am generally for TDD, but I don't think APIs really need heavy code coverage.

That said, testing the input/output directly doesn't work well because now a single change the output data (adding a field to the JSON for example) will call tons of tests to fail.

I usually use or create some JSON serialization/deserialization classes and use those to generate fake data and ensure that the API returns 200 responses.

That way if I add a field to the JSON objects, my tests are unaffected and will generate the new fields in the tests.

So I may do something like this (Python-ish):

    new_user = User.generate_user()
    response = api.post('/users', new_user.serialize())
    assert response.status_code == 200
    
    response = api.get('/users')
    users_json = json.loads(response)
    users = {}
    for user in users_json:
        users.add(User.unserialize(user))
    assert new_user in users

Hope that helps.

  It's too high-level for a lot of low-level work, and too low-level for a lot of high-level work.

Even the example of writing a GC that requires tons of unsafe code, that is not a good argument for making all the code unsafe. All the unsafe GC code would be abstracted away into a module and would be more obvious to those looking at it that they will need to be watchful for undefined behavior. Now you can proceed writing the rest of the project in safe, simple Rust.

  People will also mention "fearless concurrency", but guaranteeing the absence of data races is not hard

Also, the reasoning behind "x is easy so why do I need my language to check it for me" is questionable. The whole point is that you have a guarantee. Have you never had a compiler catch a stupid mistake before it happened and felt relieved? I doubt it. Now imagine if instead of debugging stupid data races in your parallel code you can spend that time optimizing and improving it. I fail to see how this can be viewed as negative.

Sure Rust doesn't cover 100% of use cases, but it definitely covers more than you're implying. It's low-level enough that Redox OS can be written in Rust, but high-level enough that Firefox is now outpacing other browsers and parallelizing everything with Rust.

Python has asynchronous coroutines (the async/await thing) so you don't really need to do callbacks as far as I know. I personally find that syntax much easier to follow than callbacks.

() is an empty tuple (1,) is a tuple with one element

Most small numbers are Singleton's, hardcoded or single character strings are Singletons as well.

Scaling reads is pretty easy with MySQL as you can create read replicas and just have a single write node. Scaling writes while maintaining strong consistency is very hard and requires a sharding setup. Facebook wrote an article showing a bit under the hood details of how they setup MySQL sharding here:

https://www.facebook.com/notes/facebook-engineering/under-th...

You should look into CockroachDB if you want something very easy and scalable. It's strongly consistent like a conventional RDBMS but still scales horizontally pretty easily. It's basically like Google Cloud Spanner if you've heard of that.