seven years of go and they still don't have a ternary operator.
This is a conscious decision. I believe the reasoning was readability. Ternary operators have a habit of being used in some really nasty nesting.
Seven years of Go
81–90 of 318 posts
Re: Seven years of Go
#82Earlier quoted context omitted.
I don't know how, but frankly i'd love to eliminate all simple panics. Nil pointers and channels seem two big culprits, offhand. Granted, i left out nil pointer/interface panics because it seems unrealistic given how difficult it was for Rust to get rid of nil pointers. I'm not sure Go 2.0 could do it and still be considered Go.
I agree; I want non-nillable types in Go. This despite the differences in Go that makes nil values more "valid" than they often are in other languages. I still faintly hold out hope. Unlike many of the complaints about Go that would require fundamental restructuring, C# showed that actually can be retrofitted onto a language without breaking it.
> Unlike many of the complaints about Go that would require fundamental restructuring, C# showed that actually can be retrofitted onto a language without breaking it.
C# added nullable types. Not non-nullable types.
In Go, the concept of zero values is so fundamentally baked into the semantics that non-nil pointers can never really be added to it.
Re: Seven years of Go
#83Earlier quoted context omitted.
When I started using go (coming from rails), ORM was really the thing I missed the most. And this made me realize I actually didn't know much about postgres. I started using pg functions, views, triggers, etc and found it extremely convenient. Now, my sql strings in go are mostly `SELECT * FROM func_name( )` and I'm happy with that. I'm not saying ORMs are useless (active_record is an incredibly cool tool), but it's…
Even writing Postgres functions, you're still writing the same basic SQL statements (for the 80% of your database interactions that are essentially CRUD) over and over again. People used to defend writing things in assembly language for similar reasons, as a way of getting more machine sympathy. I'm not buying it.
I'll argue this point. It takes me 30 seconds to write a SQL query. It's not hard. On the flip side, I don't end up running queries that haul megabytes of data in just to peek at one column.
SQL is already much higher level than assembly. Piling on more abstraction just increases the likelihood that the code is doing extraneous work.
Re: Seven years of Go
#84Earlier quoted context omitted.
> People used to defend writing things in assembly language for similar reasons, as a way of getting more machine sympathy. I'm not buying it. I have to assume those people did not first learn and use C, then went to assembly, but rather the opposite ;) So, the comparaison does not apply, here. > you're still writing the same basic SQL statements (for the 80% of your database interactions that are essentially CRUD) I…
What are the typical trade-offs of outsourcing all the data manipulation & lookups to the DB. Are there cases when this is absolutely what you don't want to do? I realize this is a very general and vague question but it's something I've been pondering about.
By far, it is dealing with migrations.
Initially, I would use `\ef ` in psql and just write and try my function, but this turned out to be not as pleasant as writing code in an editor in a dedicated file. The annoying thing with pg functions is that, if you want to replace them, you have to provide exactly the same in and out parameters. This means that if you want to change the parameters, you have to drop the function and create a new one.
This has been annoying at first, but now I'm more comfortable with it. I write my functions as migration files [1] and just migrate/rollback to do my tests. I guess I started to give more attention to the input and output parameters from the start in the mean time.
The cases where I won't use functions is when I want to do something extremely simple, like `SELECT email FROM users WHERE id = 1`. It's just not worth writing a function for that. It doesn't happen often that this is all I need to process my request either.
[1] I use https://github.com/mattes/migrate
Re: Seven years of Go
#85Question : Is there a possibility that when Go package management is launched there will be a good opinionated framework like rails for GO . Because for new learners ORM , authentication etc things matter a lot. I know Go promotes use of native HTTP package instead of frameworks but it is a large barrier for newcomers and have risk of writing error-prone web applications.
Re: Seven years of Go
#86So, i was a Go developer for ~4 years, then for the last 4 months or so i've been learning and using Rust. The pure joy of some things with Rust was astounding. Now, i joined a new job and they're in need of a new language for some backend tasks - the choice was mine. Rust or Go? The backend tasks were heavy API servers - nothing amazing, we don't do groundbreaking work. Python was their existing language, but they w…
Curious what they weren't so happy about with Python? Was it purely performance? If so, did they consider PyPy, or at least profile what the slowest bits are so they can evaluate whether to throw everything out or just rewrite the slow bits? Was it the language itself? Not everyone likes dynamic languages, though it's odd they started with it. Did you consider Node at all?
For me, it's the extremely straightforward conventions of Go, with it's straightforward tooling, and it's strong typing.
I "grew up" on Python, wrote a lot of code in it, and love it. But it doesn't feel as cohesive as Go.
As an example of cohesive tool design, let's look at Go package management. In Go, if I want to install a package, I install it with:
$ go get github.com/pkg/term
import "github.com/pkg/term"
$ go dock github.com/pkg/term
$ cd $GOPATH/src/github.com/pkg/term
Re: Seven years of Go
#87Earlier quoted context omitted.
When I started using go (coming from rails), ORM was really the thing I missed the most. And this made me realize I actually didn't know much about postgres. I started using pg functions, views, triggers, etc and found it extremely convenient. Now, my sql strings in go are mostly `SELECT * FROM func_name( )` and I'm happy with that. I'm not saying ORMs are useless (active_record is an incredibly cool tool), but it's…
Even writing Postgres functions, you're still writing the same basic SQL statements (for the 80% of your database interactions that are essentially CRUD) over and over again. People used to defend writing things in assembly language for similar reasons, as a way of getting more machine sympathy. I'm not buying it.
We prevented the grossness of writing things over and over again by just using Golang's script generation and some other stuff. http://github.com/spacemonkeygo/dbx.
Re: Seven years of Go
#88I have decided to get proficient in Go about 3 years ago and I am glad I did. One of the discoveries in the process was that Go enables you to do things that previously were extremely difficult and you'd typically not even consider as options. Many of the "old" ways of thinking do not apply to Go, and I had to get over the phase of looking for an ORM or webapp or testing frameworks - they don't exist because they are…
I use a testing framework[0] all the time in Go, and while I appreciate it's possible to write tests without one I think it's just pig-headed to not have something like that in the standard library.
If you just use testing.T you will most likely end up with a lousy, developer-hostile test suite. (Also, the default coverage metrics are very very weak. But I love Go just the same.)
Re: Seven years of Go
#89I have decided to get proficient in Go about 3 years ago and I am glad I did. One of the discoveries in the process was that Go enables you to do things that previously were extremely difficult and you'd typically not even consider as options. Many of the "old" ways of thinking do not apply to Go, and I had to get over the phase of looking for an ORM or webapp or testing frameworks - they don't exist because they are…
> what it does couldn't possibly be done in e.g. Python
What can you do in Go that you can't do in other languages? I can't think of anything. The only major benefits over, say, C++ or Java (which I don't think are very impressive languages) are a few convenient threading primitives, but you also lose a lot of expressive power.
Re: Seven years of Go
#90Earlier quoted context omitted.
Strong, strong disagree on the idea that ORMs aren't necessary because of some property of Golang itself. Lack of decent ORMs is probably my biggest complaint about Go, and I think if you look at a lot of large web app packages you'll find people are all writing their own 40-60% of an ORM.
In my experience there is one property of Go that minimizes the need for a good ORM, and that is that the problem domain Go excels in does not have great overlap with the problem domain that ORMs excel in. What interfacing with a relational database does come up is of the nature that does not fit well into the ORM model anyway. Of course, you can write software in the same domain where ORMs excel in Go, but I am not…
What domain are you referring to?