HNHacker News
TopNewBestAskShowJobs

dispose13432

480 karma · joined November 24, 2016

submissionscomments
dispose13432··on Rust is mostly safety
>As a total beginner (learning programming by myself since 2 or 3 years), i am always asking myself, how often "little" things like race conditions break something in production

Rookie mistake (and a shoot-yourself-in-the-foot-at-2-am) mistake coming up:

package main

import ( "fmt" "sync" )

func main() { var wg sync.WaitGroup

for i := 0; i < 10; i++ { wg.Add(1)

		go func() {
			fmt.Printf("i= %d\n", i)
			wg.Done()
		}()
	}
	wg.Wait()
}

https://play.golang.org/p/XDzFq_XK_1

And what about this code:

package main

import "fmt"

func main() {

var intArray []int for i := 0; i < 1000; i++ {

		intArray = append(intArray, i)
		fmt.Printf("i= %d\n", i)
	}

	fmt.Println(intArray)
}

https://play.golang.org/p/UuI4uESZ_f

If you don't care if intArray is in the proper order, you might do something like this:

package main

import ( "fmt" "sync" )

func main() { var wg sync.WaitGroup var intArray []int

for i := 0; i < 1000; i++ { wg.Add(1)

		go func(i int) {
			intArray = append(intArray, i)

			fmt.Printf("i= %d\n", i)
			wg.Done()
		}(i)
	}
	wg.Wait()
	fmt.Println(intArray)
}

What's wrong?

On my multi-core computer (though not on playground), len(intArray) could be as low as 500!

Why?

Because a = append isn't atomic.

Go, which is so pedantic about "stupid" mistakes (including something, changing your mind, and not "unincluding" it), didn't catch this. Not an error and no warning.

But the worst part is that when you loop until 10, it works. You can unit test it, integrate test it, and have it break at any point in time.

dispose13432··on Rust is mostly safety
> re: generics: If they aren't implemented carefully, they could unacceptably complicate the language.

Can you explain why?

For example, simple generics which could be implemented as regex doesn't seem to complicated? Am I missing something?

For example (in Java), an ArrayList <String> could be turned into a StringArrayList by a basic internal pre-processor.

dispose13432··on Chrome browser for businesses
>Companies have far too much internal plumbing to permit browsers to auto-update themselves. Being feature-compatible with the latest SV-poster-child website is insignificant compared to maintaining stability for the tax-management team's internal web app.

So why don't they have two browsers - one for internal use only (IE6), which is firewalled to only internal network shares and another browser (Chrome, whatever) which can only go to the real internet?

At least that way you'll be browsing the wild internet safely.

dispose13432··on People's underestimation of AI
>I'm of the opinion that there is an infinite amount of jobs; as we as a species always want our current situation to be better than it currently is

One of the unspoken problems with the tech revolution is that there are a lot of people who are simply not smart.

Remember, that for every genius, for every "above average" guy, there's the guy who's below average, a bit slow.

Until 1960s, you could be the hotshot lawyer, doctor, scientist, businessman or engineer, or you could work as a farmer, factory worker, tailor or water-carrier.

In a few years/decades, one will need outright brilliance to find jobs.

dispose13432··on Rust is more than safety
>There are no final variables in Go.

const?

dispose13432··on Rust is more than safety
>Because those communities, logically due to the UNIX influence, are biased towards C.

Not Linux (Warning: Typical Linus rant - http://harmful.cat-v.org/software/c++/linus).

dispose13432··on Rust is more than safety
>Take a guess which strategy makes junior developers write better code.

An org can mandate use of only safe pointers.

dispose13432··on Rust is more than safety
C++ can be safe. Just use only safe pointers and vectors.

The thing is that rust does two things:

1. Safety

2. FP style code ("magic")

I wouldn't mind #1, but #2 kind of turns me off.

dispose13432··on Rust is more than safety
>I don't even understand why you'd want to remove functional programming from a low level language like Rust

Because I want a simple to read language?

It's not all about performance. C++ doesn't have bad performance and is safe, yet isn't used in Linux, nginx, or OpenBSD.

Why?

I've heard here how every team has their "subset" of the language that they use.

So you're trying to unseat C from it's perch. Fine. I understand, it's too easy in C to have memory errors and pwn computers.

But if you want to fix that by forcing people to switch to a different paradigm, it aint gonna happen.

Out of the top 10 programming languages on GitHub, most (by far) are imperative.

If someone would make a safe C, there can be hope in convincing Linus to slowly switch.

Now? There's 0 chance of that happening.

dispose13432··on Rust is more than safety
>unwieldy and slow

So force one to do it consciously (kind of like unsafe).

dispose13432··on Rust is more than safety
>Something like threading race conditions is a real problem, but not easy to fix.

It is. It's called channels.

dispose13432··on Rust is more than safety
Well, that's an "easy" bug.

What about not-shadowing a "non-loop" variable?

Take a look at this question:

http://stackoverflow.com/questions/18499352/golang-cuncurren...

It's easy to mess up during refactoring, and there's pretty much no reason to allow it.

dispose13432··on Rust is more than safety
That's one thing I hate about Go, is how easy it is to shoot yourself in the foot with it.

Really, it has a decent way to manage inter-thread communication - channels. But the language still permits me to read/write a "non const" global variable from a goroutine.

This is horrible, especially when refactoring.

Each goroutine should have it's own scope (unless explicitly defined).

dispose13432··on Rust is more than safety
You know what I would like? (Yeah, speaking of entitlement :) )

A "safe C". No classes, no functional programming (except function pointers, maybe anonymous functions), no exceptions, just plain C but

1. memory safe 2. optional array overflow detection (possibly unset by an operator in code, so [] is safe, but a^[] is unsafe. It's nice so if you _really_ need speed in a certain block and you know it's safe, you can turn it off).

Maybe something like Go but with "manual" (c++ safe pointer style) memory management.

Rust seems (to my untrained eye) too similar to C++ (it's quite a complicated/powerful language).

dispose13432··on With Cyanogen dead, Google's control over Android is tighter than ever
http://arstechnica.com/gadgets/2012/09/google-blocked-acers-...

So Amazon can't get Acer to build them phones or tablets. As most independent manufacturers build Android phones, Amazon had a hard time finding someone to make Fire for them.

dispose13432··on Some Google Pixel devices shutting down at 30% battery
Don't let perfect be the enemy of good enough.

While most people run Android the same way people run Apple, you can run Android and get your apps from f-droid, and you can run CM (and, if your into these things, Xprivacy), so while Google may still be getting your private data, random apps won't.

dispose13432··on With Cyanogen dead, Google's control over Android is tighter than ever
True!! I thought they were aquihired by OnePlus after the CM deal fell through to make OxygenOS
dispose13432··on With Cyanogen dead, Google's control over Android is tighter than ever
> Closed source apps are not the threat > Yes, they are. See > https://www.gnu.org/philosophy/shouldbefree.html

Well, they should. But I wouldn't call a closed-source messaging app (which you can replace with qksms) proof that AOSP is over.

>According to the EU, they didn’t – they abused their market power to extort companies to force them to bundle their products.

I meant legal to contrast "force" (closing the source), not that it's not illegal. They could really open-source everything and still mandate people to use Hangouts.

>Yet Google cracked down even more on OEMs that shipped non-Google Android in markets where Google Android exists in the meantime. They definitely saw a threat.

Did they fight CM?

What did they do to make CM's life difficult?

>See the EU argument again: Google does not have the right to restrict their services in that way, due to having too much market power. They can not discriminate against the environments their products will be used in.

But they can refuse to license the Google Play store to entities outside of OEMs, as long as the terms aren't discriminatory.

dispose13432··on With Cyanogen dead, Google's control over Android is tighter than ever
> "Android" per-se is Apache 2, i.e. free to use without restrictions (thus Amazon's "Fire OS").

That's why I stressed "in a factory". No factory which makes commercial Android is permitted to make unlicensed android.

dispose13432··on With Cyanogen dead, Google's control over Android is tighter than ever
The article is wrong on so many counts:

1. Closed source apps are not the threat (Nowhere does it say that the dialer, home screen, messaging app, or camera are a part of the OS. All are replaceable, and all replacements integrate just as well as the original, it's not an iPhone).

2. Google controlled Android through legal means - If you want to make your Android phone in a factory, or if you want to use any google app, you need to obey their rules. So if yo want Play store, you have to play along.

3. Cyanogen saw Google as a threat, but Google didn't see Cyanogen as a threat. Cyanogen didn't die because of Google's behavior. They died because of terrible execution.

Remember the spat over split-windows. Google didn't ban the appstore (despite being able to), they demanded that the environment not be _too_ modified.

Cyanogenmod backed down and Google let it go.

The only thing is that they were forbidden to _package_ it, but opengapps is still around.

4. Google isn't closing-source because of Cyanogenmod or other custom Roms. It's bigger threat is Samsung or Amazon.

dispose13432··on With Cyanogen dead, Google's control over Android is tighter than ever
We'll see in a few months how viable is it.
dispose13432··on With Cyanogen dead, Google's control over Android is tighter than ever
AOKP - dead.

PA - dead

AOSB - Exceeded bandwidth and archive doesn't seem to have archived it properly. According to Google cache, they're working on L, so seems dead.

Slim - was dead for a few years. Seems to have revived.

The question is what will LineageOS look like?

dispose13432··on The Resurgence of C Programming
>I don't hear much about performance problems causing major trouble in popular software and making everyone patch things in haste.

How did nginx unseat apache?

dispose13432··on The Resurgence of C Programming
>Many popular languages nowadays essentially have just one viable open source toolchain: Go has the Go toolchain (gccgo being niche), Python 3 has CPython (Jython and IronPython only support Python 2.7, and PyPy is not up-to-date), Swift has the apple toolchain, Haskell has GHC (none of the other compilers is widely used).

The problem is that having multiple providers prevents the BDFL from playing too hard with the language.

If there was an alternate Python toolchain, Python3 wouldn't have happened.

dispose13432··on The Resurgence of C Programming
The question is not so much how many working compilers are there, but how many rely on the language.

Practically, PHP has one interpreter, but if they go out, you can be assured that someone will fork and maintain it.

On the other hand, if MyToyLangOnGitHubGraduateProject goes belly up, you're stuck maintaining it yourself.

dispose13432··on The Resurgence of C Programming
>That argument seems akin to avoiding C# because only MS supports it

Or avoiding Flash because only Adobe supports it, or SilverLight/VB because only MS supports it, or Objective C because only Apple supports it.

dispose13432··on Rust vs C Pitfalls
>On similar note, why Rust over Go?

I was going to say that rust has performance advantages over Go (due to GC), but look at benchmarks:

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

Go wins some and looses some, but it's all in the ballpark (except Binary trees [1] which it loses even to Java(!)).

It's true that rust is a new language, but so is Go.

[1]: I assume it's because it's a test of GC, but Go loses to Java (which, like Go, is a GC language)

dispose13432··on Darktable 2.2.0 released
It's an unfortunate situation, but the way _they_ put it (two sides to every fight) is that they don't know if he'll drop out in a week and all those who downloaded it will come screaming "Were's our updates!!"
dispose13432··on Thank You and Goodbye, the CyanogenMod Team
They have one. It's called LineageOS.
dispose13432··on Thank You and Goodbye, the CyanogenMod Team
They were the darling of custom ROMs before Cyanogen Inc.

When they incorporated, a lot of people hoped it would help sponsor development (while others, suspecting what would happen, forked into OmniRom).

Unfortunately, once they incorporated, the company spokesman (McMaster) went against the whole original culture (they installed bloatware on their phones) and generally spoke without thinking (kill Google, etc.).

Now, they're seen as a weak wannabee Oracle.

← PreviousPage 2 of 9Next →