Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I’m Frustrated with Go

dev.to

Post reply on HN
Print view View original

211–220 of 233 posts

Re: Why I’m Frustrated with Go

#211

Post by tscs37 »

thinbeige wrote: post #9

OT: I recently learned that the newer ETH client Parity is written in Rust and much faster than the older Go-based Geth ETH client. Guess it is due to a different architecture and design which makes the client faster (e.g. chaindata is smaller) but does anyone know why they chose Rust instead of Go for the Parity client?

The Geth client is still widely used as it's kind off the standard implementation of the Ethereum EVM and Node Mechanics.

The Go based client isn't that much "older" either, both are actively developed and received some code overhauls.

I've also found the go client's web3 console to be much more reliable and complete than Parity's.

Re: Why I’m Frustrated with Go

#212

Post by tscs37 »

nhumrich wrote: post #46
dvfjsdhgfv wrote: post #7

I personally tend to choose Go for newer projects as I'm looking for the efficiency of C and safety/elegance of more "modern" languages. However, I always keep an eye on D and Nim. It seems these are the only two languages that can compete with Go in both above aspects.

Go is nowhere near the speed of C. But why not consider Rust?

I've tried to get into Rust but I've found the syntax alone to be impenetrable despite reading through several guides multiple times.

If Rust was less complicated I might consider it.

Re: Why I’m Frustrated with Go

#213

Post by tscs37 »

rebolek wrote: post #45
jmaa wrote: post #31

Go was explicitly designed to be a simple language, without a rich tapestry of data structures to suit every use case. Languages are like tools. If you need a saw, use a saw, instead of complaining about the knife you are using.

No, languages are like toolboxes, they provide you with set of tools.

Then you should be using the toolbox for metalwork when trying to weld two steel plates instead of using the one for woodwork.

Re: Why I’m Frustrated with Go

#214

Post by sametmax »

seanwilson wrote: post #205
sametmax wrote: post #76

Earlier quoted context omitted.

Most modern dynamic languages have strong types. In Python you will get a TypeError if you try to add a string and an int or use > on a tuple and a dict. As for data validation, the hard part of it is not checking type but that the value is safe and coherent. And dynamic languages excel at that because they make complex declarative schema descriptions easy while powerful. See marshmallow for Python: https://marshmall…

> Most modern dynamic languages have strong types. In Python you will get a TypeError if you try to add a string and an int or use > on a tuple and a dict. You mean a dynamic check? It's better than nothing but I don't exactly want my e.g. scheduled data import process crashing because it was sent some bad data. I'd much rather have static checking and have all the possibilities accounted for before the code runs. >…

keyword being "easy"

Re: Why I’m Frustrated with Go

#215

Post by sametmax »

fnord123 wrote: post #188
sametmax wrote: post #76

Earlier quoted context omitted.

Most modern dynamic languages have strong types. In Python you will get a TypeError if you try to add a string and an int or use > on a tuple and a dict. As for data validation, the hard part of it is not checking type but that the value is safe and coherent. And dynamic languages excel at that because they make complex declarative schema descriptions easy while powerful. See marshmallow for Python: https://marshmall…

> Most modern dynamic languages have strong types. In Python you will get a TypeError if you try to add a string and an int or use > on a tuple and a dict. >>> (1,2) > {1: 2} True >And dynamic languages excel at that because they make complex declarative schema descriptions easy while powerful. Marshmallow looks like it works the same way as existing systems in statically types languages. e.g. Serde in Rust: https://…

I said "modern". Python 2 is not modern. Python 3 is.

And the keyword in my schema validation sentence is "easy".

I love rust, but a low level language cannot be compared in productivity to a high level language for this stuff. They are much, much easier. That's the whole purpose. You trade easiness for rigor.

Re: Why I’m Frustrated with Go

#216

Post by seanwilson »

sametmax wrote: post #214
seanwilson wrote: post #205

Earlier quoted context omitted.

> Most modern dynamic languages have strong types. In Python you will get a TypeError if you try to add a string and an int or use > on a tuple and a dict. You mean a dynamic check? It's better than nothing but I don't exactly want my e.g. scheduled data import process crashing because it was sent some bad data. I'd much rather have static checking and have all the possibilities accounted for before the code runs. >…

keyword being "easy"

I just don't find that personally. Having to run the code over and over again to manually check for errors or having to write unit tests to gain confidence it's working is more difficult to me than getting help from static type checking. I mean why do you think it's always going to be more difficult with static types? Because you have to write type annotations?

Re: Why I’m Frustrated with Go

#217

Post by nimmer »

dvfjsdhgfv wrote: post #7

I personally tend to choose Go for newer projects as I'm looking for the efficiency of C and safety/elegance of more "modern" languages. However, I always keep an eye on D and Nim. It seems these are the only two languages that can compete with Go in both above aspects.

Nim is among the fastest, more high level and people seem to like the Python-like syntax.

Re: Why I’m Frustrated with Go

#218

Post by ue_ »

masklinn wrote: post #129
ue_ wrote: post #93

Earlier quoted context omitted.

If by "bounds-checks indexes" you mean "panics when given an out of bounds index, even if it's a compile time constant" then sure. I'm not sure why people talk about Rust being safe when this sort of thing happens and it can't catch it at compile time. At least C compilers have sanitizers that pick up things like that.

> If by "bounds-checks indexes" you mean "panics when given an out of bounds index, even if it's a compile time constant" then sure. Er yes, it's safe as in memory-safe , as in an OOB will not own the entire application let alone machine. Error on OOB is a very common (if not quite universal) strategy — and incidentally also the one Go uses, the other primary one being returning null (which would be difficult in a la…

How is an error differentiated from a panic? Can a panic as is caused by the OOB situation I described be recovered from, or is it necessarily fatal?

Re: Why I’m Frustrated with Go

#219

Post by Dr_Emann »

humanrebar wrote: post #12

> You know how much code I’d have to write if this were C++, C#, or Java? None. They all have reusable notions of an immutable, ordered map. Actually C++ doesn't have immutable data unless you count compile-time constants and literals. You can declare things 'const', but that only provides a read-only (1) view on mutable data. Also, to provide good 'const' support in containers, you usually have to provide extra read…

Yes, if you use the escape hatch from the type system, the type system won't help you. Do you also avoid the use of strong types since you can always cast to a *char?

Re: Why I’m Frustrated with Go

#220

Post by sametmax »

seanwilson wrote: post #216
sametmax wrote: post #214

Earlier quoted context omitted.

keyword being "easy"

I just don't find that personally. Having to run the code over and over again to manually check for errors or having to write unit tests to gain confidence it's working is more difficult to me than getting help from static type checking. I mean why do you think it's always going to be more difficult with static types? Because you have to write type annotations?

External data are never perfectly documented or known. You usually have huge and painful experimentation phase with parsing it. Experimenting is way easier with dynamic languages. You type less. Changing your mind has a lower cost. You don't need to think about doing the right things as much.
Post reply on HN