Hacker Newsnew | past | comments | ask | show | jobs | submit | more gregors's commentslogin

Timely post as a TN power plant is offline

https://www.local3news.com/local-news/tva-takes-sequoyah-nuc...


Timescale is sooooo much better. What a bad decision.


I think it depends a bit on perception. If you're coming from C, Go is a step up in my opinion. Everything surrounding Go's type system and lack luster error handling seems worse to me coming from almost any other language - except C.

Concurrency is also something they got more or less right. The most important thing is that they invented their (Google) language that they could exert complete control over. From a business perspective specifically, that was much better than Java.


> If you're coming from C, Go is a step up

Walking on burning coals is a step up if you're coming from C.

We shouldn't grade languages on that much of a curve by comparing them to garbage.

> Concurrency is also something they got more or less right

Except data-races are an incredibly common bug in Go, and an incredibly rare bug in Rust.

Data-races are way more common in Go than in modern C++ or Java, if only because mutex semantics in Go are awful, with many programmers opting for manual "lock" and "unlock" calls, and mentally reasoning about the correct scope for the critical section with no compiler assistance.

I will give you that they made concurrency very easy.


>>>> n the study, the researchers leveraged data from 1.1 million Swedish men

So in other words, light years better shape through out all age ranges compared to your average American.


>>>> The simple great thing about doing everything through a single process (with threads, goroutines, or whatever inside it for concurrency) is that you have all the shared state you could ever want, and that shared state makes it so easy to do so many things.

If you like the sound of this, check out Elixir/Phoenix


Works completely fine in Haproxy


I'm actually happy about that. It specifically targets gamers who want to play video games.


So yeah you can say it's entitlement but if you build your business in one way and then change the fundamental limits AFTER you've gotten market saturation you really shouldn't be shocked at complaints. It's their fault because they fostered the previous user behavior.

People understand that bandwidth costs money but that seems to have been priced in to their previous strategy or they did it knowingly as a loss leader to gain market share. If they knew this was a fundamental limitation they should have addressed it years ago.


how would you want to them to address it?

Perhaps they should have started by putting "we will enforce limits soon" in all documentation.. and in a few years, starting enforcement but with pretty high limits? and then slowly dialing limits down over a few years?

That's exactly what they did. I remember setting up the docker proxy 4 years ago when we started getting first "rate limit" errors. And if someone was ignoring the news for all that time.. Well, tough for them, there was definitely enough notice.


>>>> That's his decision to make and he doesn't owe anyone anything. If you want continued support, pay up.

Completely correct, and the users of Elm also don't owe him anything. They are free to hold their opinions and free to move away from Elm ...and they did.

In the end Elm will be remembered for being an extremely interesting technology but mainly failed in industry due to poor project/community relationship.

Sometimes interesting tech just isn't the right fit for business. C'est la vie.


It would be good to remember Joel did a complete rewrite and blogged about it.

https://www.joelonsoftware.com/2002/04/11/our-net-strategy/

The idea isn't that you can't rewrite in a new language, it's that want to do bit by bit. Don't just to the big bang thing.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: