Hacker News new | past | comments | ask | show | jobs | submit login

99 out of 100 questions.

Solidity is ostensibly designed to let people write smart contracts for Ethereum.

More realistically, it is a marketing tool for enabling and onboarding people onto the Ethereum platform, which Ethereum benefits monetarily (enormously so) from. Security and design are secondary goals to the extent that they help prevent disasters which hurt adoption or churn developers away.

Through this lens it's not a mystery why the language is "hacky". Perhaps being a good language is not even the driving goal.

> 99 out of 100 questions.

Curious question of a non-native speaker: What does this phrase mean? (in general, and in this context)

Don't feel too bad, I am a native speaker and I didn't recognize this phrase either.

Brilliant... and so true!

The answer to why most things are done is... Money !

>> it is a marketing tool for enabling and onboarding people onto the Ethereum platform

+1 : My feelings after going thru basics of ethereum.

a marketing tool that gets your money stolen is probably counterproductive in the long run

From a Hegelian perspective, the best thing for Ethereum is for it to race back and forth across dialectics as quickly as it can. There will be many money stealing events as we discover how to do cryptocomputing safely. Better to get them over with now while the market cap is small and people know not to rely on it for anything too serious.

If they were to be as safe as possible, there would be less news, and they would push the traversal of those dialectics further into the history, when more people are using Ethereum and these kinds of events can do more damage.

It's beta. Don't worry about it. Come back in 10 years when the Heroku of Ethereum is released. Buy a couple Ethers now so you'll be rich then.

The guys who just stole $30M and $70M beg to disagree.

but so is making developers write smart contracts in haskell, severely limiting the number of developers who can jump in and start coding, leading to a lack of adoption.

Being a good, secure language for writing smart contracts is absolutely one of the most important goals for Solidity. I can say so because I have been involved as a regular contributor to the compiler for more than a year. If onboarding a lot of people to the platform quickly were the goal instead, they would have ported some crippled version of Java or JS and called it a day.

The problem is that it's just not easy to get all those details right from day 1, and interest in Ethereum has grown way faster than its capacity to produce a reliable, mature set of tools around it.

To pick just one: mutable state by default is very difficult to justify as being a decision intended to promote security in a tool that is literally meant to construct financial/contractual instruments.

Not that difficult. There is not much point in creating immutable contracts since they act like singletons.

This is different from the kinds of objects that you would instantiate in a language like Java, where best practices suggest defining as immutable unless you have a good reason not to.

Just because a contract is mutable doesn't mean that everything needs to be.

For starters, not all functions on the contract are supposed to be mutating. Marking those that are as such would catch accidental mistakes when unnecessary mutations happen.

Then there's the issue with structs, collections etc all also being mutable by default, which is separate of contracts.

Finally, none of this actually requires any mutability at all. A contract could treated as a pure function that takes initial state as input, and returns the new state as output. Such a function can be written without any mutations at all, by constructing the new state piece by piece from the old one.

Sure, it would be a more verbose (although functional languages usually offer shortcuts like "give me a copy of this object, but with these fields set to different values", making it not so verbose after all). But on the other hand, it means that you have to explicitly consider the effect of every operation of the contract on every bit of state. "Don't repeat yourself" is not always a good thing - when it comes to security, you often do actually want to make people do redundant things, e.g.: http://www.atlasobscura.com/articles/pointing-and-calling-ja....

These things are not just details. Things like scope, mutability, and operator precedence are core language design decisions.

Registration is open for Startup School 2019. Classes start July 22nd.

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