331–340 of 439 posts
Earlier quoted context omitted.
Write a code generator. That's the best solution at this moment.
Or, y'know, just copy and paste the trivial code. It should take all of 30 seconds. Not saying that it's pretty, but it's quick and easy.
Earlier quoted context omitted.
Code generation is not about a deficiency in the language, C++ has templating but I will often use code generation since you only need to run that once and templating bloats the compile time for ever.
>I will often use code generation since you only need to run that once and templating bloats the compile time for ever. Don't you need to compile the generated code?
Earlier quoted context omitted.
Go GC since 1.6 openly claims In my experience Java brings a mindset that there must be some complex way to solving a problem so lets find out that.
> Go GC since 1.6 openly claims Yes. HotSpot has had configurable max pause times for years and years [1]. If you want less than 10ms, set MaxGCPauseMillis to 10ms. It also has a state-of-the-art generational GC, which is very important for throughput, as bump allocation in the nursery is essentially impossible to beat with a traditional malloc implementation. [1]: https://docs.oracle.com/cd/E40972_01/doc.70/e40973/c…
> The following example JVM settings are recommended for most production engine tier servers: -server -Xms24G -Xmx24G -XX:PermSize=512m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:ParallelGCThreads=20 -XX:ConcGCThreads=5 -XX:InitiatingHeapOccupancyPercent=70
So Oracle mentions 200ms for most prod use. I am not sure how you are able to deduct ~10ms pause from that link.
And just because one can configure ~10ms does not mean at JVM will start respecting it. There is nothing in any official document by Oracle about max GC pause time. The results Google threw are mostly around ~150ms as min pause.
> It also has a state-of-the-art generational GC.
And it needs something like
http://www.amazon.com/Java-Performance-Charlie-Hunt/dp/01371...
to do what JVM can do in theory. In practice as a java users I am used to seeing ~20-30 sec pauses for Full GC.
The only effort in open for sub 10ms GC for large heaps is Project Shenandoah:
http://openjdk.java.net/jeps/189
and it is long way from availability.
Earlier quoted context omitted.
>Do we have 67 implementations of sort.Interface? Hahaha. This has to be satire right? >Generics would not make our codebase significantly better, more maintainable, or easier to understand. Generics are literally a form of abstraction. You might as well be arguing that abstraction doesn't help. Why do you even have subtype polymorphism then? Why not just reimplement everything? That's not a significantly difficult p…
Generics are literally a form of abstraction Is your unstated assumption then that all forms of abstraction must be used? If you've done substantive projects, you'll come to realize that abstractions have a cost, and that everything should be considered on a cost/benefit basis. You might as well be arguing that abstraction doesn't help. This is a black and white binary fallacy invoked to then create a straw man, whic…
Some of the benefits are opportunities for
* specialization
* reduction in boilerplate
* parametricity
* free theorems
* type classes
Objectively, a collections library written with generics and no subtyping will be much better and cleaner than a subtype based one.
The problem is, I've never heard generics argued against by someone who really understands generics. It's usually folks who got confused by them in java or really didn't dig into the theory behind them. An argument from ignorance isn't much of an argument.
I work on juju ( https://github.com/juju/juju ), which all told is about 1M LOC. In my almost 3 years on the project, I have not been bothered by lack of generics, basically at all (and I worked for 10 years in C# on projects that used a lot of generics, so it's not like I don't know what I'm missing). Do we have 67 implementations of sort.Interface? Sure. Is that, by any stretch of the imagination, a significantly d…
>Do we have 67 implementations of sort.Interface? Hahaha. This has to be satire right? >Generics would not make our codebase significantly better, more maintainable, or easier to understand. Generics are literally a form of abstraction. You might as well be arguing that abstraction doesn't help. Why do you even have subtype polymorphism then? Why not just reimplement everything? That's not a significantly difficult p…
> Hahaha. This has to be satire right?
Nope.
/home/nate/src/github.com/juju/juju$ grep -r ") Less(" . | wc -l
67
But in any other language, we'd still have the same 57 definitions of how to sort a type.... we'd just have 3 fewer lines of boilerplate for each of those (which live off in the bottom of a file somewhere and will never ever need to change).
Earlier quoted context omitted.
Yes, that's so much worse. At least to my eyes. It's a death by a thousand cuts. That's 3 dense lines that you need every time you map across a collection. Which obscures whatever else is happening in the rest of the method/function, so now you've got that much more cognitive load to figure out what it's actual core purpose is. Which may be subtly modified by the writer purposefully, but you miss it because you assum…
Actually readability at the point of use is very reader-friendly: machines := db.GetAllMachines() sort.Sort(byName(machines)) For those not familiar with Go, the sort.Sort line is converting the list of machines into a type that matches the interface that sort.Sort expects. The list of machines is sorted in-place The only part that can be subtly changed is the Less function, which determines the sort order. And as I'…
Earlier quoted context omitted.
> Go GC since 1.6 openly claims Yes. HotSpot has had configurable max pause times for years and years [1]. If you want less than 10ms, set MaxGCPauseMillis to 10ms. It also has a state-of-the-art generational GC, which is very important for throughput, as bump allocation in the nursery is essentially impossible to beat with a traditional malloc implementation. [1]: https://docs.oracle.com/cd/E40972_01/doc.70/e40973/c…
From the link I see: > The following example JVM settings are recommended for most production engine tier servers: -server -Xms24G -Xmx24G -XX:PermSize=512m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:ParallelGCThreads=20 -XX:ConcGCThreads=5 -XX:InitiatingHeapOccupancyPercent=70 So Oracle mentions 200ms for most prod use. I am not sure how you are able to deduct ~10ms pause from that link. And just because one can conf…
Nongenerational GC pretty much always without exception loses to generational in heavily GC'd languages like Java and Go. There is no silver bullet for GC; it requires lots of hard engineering work, and HotSpot is way ahead.
Earlier quoted context omitted.
I've had a very similar experience from about 3 years of writing Go. The lack of generics hardly affected me. When it did, it was dead simple to write the type-specific code and move on. I've been working on a Java project recently, and by contrast, this code base abuses generics to an almost pathological level. I've also been burned by Java's runtime type erasure, and wow that leads to some nasty bugs. (That's not t…
Too often I've seen [X] lead to complexity and abuse which greatly outweigh their utility. Programmer hubris is a problem. There was a widely acknowledged problem in Smalltalk with the overuse of #doesNotUnderstand: and other esoterica to do "clever" stuff which then makes it difficult for new programmers to debug and understand the system. There is a reason why certain methodologies emphasize "the simplest thing tha…
I see the same tendencies in many programmers - "hey, I want to write this once and cover every single case that could ever come up"... even when they really only need to solve one specific problem, and making the solution more generic makes the code a lot more complicated than it needs to be for the specific problem you're solving.
By Rob Pike, a man of contradictions.
Earlier quoted context omitted.
>Do we have 67 implementations of sort.Interface? Hahaha. This has to be satire right? >Generics would not make our codebase significantly better, more maintainable, or easier to understand. Generics are literally a form of abstraction. You might as well be arguing that abstraction doesn't help. Why do you even have subtype polymorphism then? Why not just reimplement everything? That's not a significantly difficult p…
> >Do we have 67 implementations of sort.Interface? > Hahaha. This has to be satire right? Nope. /home/nate/src/github.com/juju/juju$ grep -r ") Less(" . | wc -l 67 (granted, 10 are under the .git directory, so I guess 57) But in any other language, we'd still have the same 57 definitions of how to sort a type.... we'd just have 3 fewer lines of boilerplate for each of those (which live off in the bottom of a file so…
That claim turns out to not be the case.